08 — Consulting Projects

You have now developed the core capabilities expected from a Senior Security Consultant:

Security consulting methodology
Security assessments
Architecture reviews
Cloud security reviews
Risk and compliance analysis
Client reporting
Security transformation planning

It is now time to combine these capabilities.

Real consulting engagements rarely arrive as neatly separated technical tasks.

A client does not normally say:

“Please demonstrate your knowledge of IAM.”

Instead, the client may say:

“We are moving critical applications to the cloud and leadership wants to know whether our environment is secure enough for production.”

You must determine:

What needs to be assessed
Who needs to be interviewed
What evidence is required
Which architecture components matter
Which security risks are significant
Which frameworks are relevant
What should be recommended
What leadership needs to know

This module places you in that position.

Module Mission

Your mission is to execute realistic consulting projects using the complete engagement lifecycle:

Client Requirement
       ↓
Scoping
       ↓
Planning
       ↓
Discovery
       ↓
Evidence Collection
       ↓
Technical Assessment
       ↓
Architecture Analysis
       ↓
Risk Analysis
       ↓
Finding Development
       ↓
Recommendations
       ↓
Client Reporting
       ↓
Remediation Roadmap
       ↓
Executive Presentation

The objective is to move from learning consulting concepts to producing professional consulting deliverables.

1. How to Approach These Projects

Each project should be treated as a real client engagement.

Do not immediately start searching for vulnerabilities.

Begin with:

Understand
    ↓
Scope
    ↓
Discover
    ↓
Collect
    ↓
Assess
    ↓
Analyse
    ↓
Recommend
    ↓
Communicate

For every project, create an engagement workspace.

Consulting Project/
│
├── 01 Engagement Scope
├── 02 Stakeholders
├── 03 Discovery
├── 04 Architecture
├── 05 Evidence
├── 06 Assessment
├── 07 Findings
├── 08 Risk Register
├── 09 Recommendations
├── 10 Remediation Roadmap
├── 11 Final Report
└── 12 Executive Presentation

This structure simulates professional consulting work.

2. Core Deliverables

Across these projects you will create:

Engagement scope
Discovery questionnaire
Evidence request list
Architecture diagrams
Assessment workbook
Security findings
Risk register
Control-gap analysis
Remediation recommendations
Transformation roadmap
Executive summary
Final assessment report
Executive presentation

Do not focus only on technical findings.

The quality of the consulting process and deliverables matters equally.

Project 01 — Enterprise Security Posture Assessment

Client Scenario

You have been engaged by Northstar Financial Services, a fictional financial technology organisation.

The organisation has approximately:

3,500 employees
Hybrid workforce
Multiple offices
AWS workloads
Microsoft Azure services
Microsoft Entra ID
SaaS applications
Windows endpoints
Kubernetes workloads
Central SIEM
External vendors

The organisation has grown rapidly during the previous three years.

Leadership is concerned that security controls may not have matured at the same speed.

The CISO asks:

“What are our biggest enterprise security risks, and what should we prioritise during the next 12 months?”

Your Role

You are the Lead Senior Security Consultant.

You must conduct an enterprise security posture assessment.

3. Define Project Objectives

Your assessment should determine:

Current security posture
Critical security weaknesses
Control maturity
Significant enterprise risks
Systemic security issues
Priority remediation actions
Strategic improvement opportunities

4. Define Assessment Scope

Include:

Governance
Identity & Access
Network Security
Endpoint Security
Cloud Security
Application Security
Data Protection
Vulnerability Management
Logging & Monitoring
Incident Response
Third-Party Risk
Security Compliance

Document any assumptions and exclusions.

5. Build the Discovery Questionnaire

Develop questions across each security domain.

Example:

Governance

Who owns enterprise security?
How are policies maintained?
How are security exceptions approved?
How is risk reported?

Identity

Which identity providers are used?
Is MFA mandatory?
How is privileged access controlled?
How often are access reviews performed?

Cloud

How are cloud accounts created?
Are security guardrails enforced?
Is cloud logging centralised?
Who has administrative access?

Security Operations

Which logs reach the SIEM?
Who monitors alerts?
Is detection coverage mapped to threats?
How are incidents escalated?

6. Build an Evidence Request List

Request evidence such as:

Security policies
Asset inventories
Architecture diagrams
IAM exports
Privileged account reports
Firewall rules
Cloud configuration reports
Vulnerability reports
SIEM architecture
Incident response plan
Access review evidence
Risk register
Third-party assessment records
Audit reports

Track each request.

7. Simulated Assessment Findings

Assume your assessment discovers:

Finding 01

18 privileged identities have permanent administrative access.

Finding 02

Phishing-resistant MFA is not required for privileged users.

Finding 03

Several AWS accounts operate without organisation-level guardrails.

Finding 04

Cloud audit logging is incomplete across development accounts.

Finding 05

Network segmentation between application environments is inconsistent.

Finding 06

Critical vulnerabilities frequently exceed remediation SLA.

Finding 07

Several SaaS platforms are not integrated with central SSO.

Finding 08

Third-party security assessments are performed inconsistently.

Finding 09

Incident-response exercises have not been conducted during the previous 18 months.

Finding 10

Security metrics focus primarily on vulnerability counts.

8. Identify Security Themes

Do not simply produce ten disconnected findings.

Group them.

Possible themes:

Identity Governance
│
├── Permanent privileged access
├── Weak privileged MFA
└── Decentralised SaaS identity

Cloud Governance
│
├── Missing guardrails
└── Logging inconsistencies

Security Operations
│
├── Vulnerability SLA issues
├── Limited IR exercises
└── Weak risk metrics

Enterprise Governance
│
├── Third-party assessment gaps
└── Inconsistent security standards

9. Build Enterprise Risks

Example:

Risk 01 — Privileged Identity Compromise

Credential Theft
      ↓
Privileged Identity
      ↓
Permanent Administrative Access
      ↓
Production Systems
      ↓
Data / Service Impact

Risk 02 — Uncontrolled Cloud Deployment

Decentralised Cloud
      ↓
Missing Guardrails
      ↓
Insecure Configuration
      ↓
Internet Exposure
      ↓
Cloud Compromise

10. Develop the Roadmap

Example:

0–30 Days

Protect privileged identities
Remove unnecessary administrators
Enable critical cloud logging

30–90 Days

Implement cloud guardrails
Improve vulnerability escalation
Centralise SaaS authentication

3–6 Months

Implement PAM
Improve segmentation
Formalise vendor risk management

6–12 Months

Continuous cloud compliance
Threat-driven detection
Enterprise security metrics
Mature incident-response exercises

11. Project 01 Deliverables

Create:

01 Engagement Scope
02 Discovery Questionnaire
03 Evidence Request List
04 Security Assessment Matrix
05 Findings Register
06 Enterprise Risk Register
07 Security Maturity Assessment
08 Remediation Roadmap
09 Executive Summary
10 Final Security Assessment Report

Project 02 — Secure Architecture Review

Client Scenario

A client is developing a new internet-facing customer platform.

Architecture:

Internet
   ↓
CDN
   ↓
WAF
   ↓
Load Balancer
   ↓
Web Application
   ↓
Application Services
   ↓
Database

Additional components include:

Entra ID
CI/CD
Secrets Manager
Cloud Storage
Monitoring
Third-Party Payment API

The application will process sensitive customer information.

Production launch is scheduled in six weeks.

The client asks:

“Is this architecture secure enough for production?”

12. Your Architecture Review

Start by identifying:

Critical assets
Entry points
Trust boundaries
Data flows
Identity flows
Administrative paths
External dependencies

Create an annotated architecture.

13. Identify Trust Boundaries

Example:

Internet
   │
=== Trust Boundary ===
   │
Application Edge
   │
=== Trust Boundary ===
   │
Application Services
   │
=== Trust Boundary ===
   │
Sensitive Data

Determine what protects each boundary.

14. Follow Customer Data

Trace:

Customer
   ↓
Web Application
   ↓
API
   ↓
Application Service
   ↓
Database
   ↓
Backup

Evaluate:

Encryption
Authentication
Authorisation
Logging
Data retention

15. Follow Administrative Access

Trace:

Administrator
      ↓
Identity Provider
      ↓
Cloud Console
      ↓
Production

Ask:

Is MFA required?
Is access temporary?
Are sessions monitored?
Can administrators access data?

16. Follow the Deployment Path

Trace:

Developer
   ↓
Source Repository
   ↓
CI/CD
   ↓
Deployment Role
   ↓
Production

Determine whether developers can indirectly gain production control.

17. Simulated Architecture Findings

Assume you discover:

CI/CD uses permanent production administrator credentials
Application workload has broad cloud permissions
Database network access is broader than required
Administrative portal is internet accessible
Security logs remain inside production
Third-party API credentials are stored in pipeline variables
Production and development share several cloud resources

18. Build Attack Paths

Example:

Developer Account
      ↓
Repository Modification
      ↓
CI/CD
      ↓
Production Admin Credential
      ↓
Production Compromise

Another:

Application Exploit
      ↓
Workload Identity
      ↓
Broad Cloud Permission
      ↓
Sensitive Storage

19. Design the Target Architecture

Recommend:

Developer
   ↓
Protected Repository
   ↓
Controlled CI/CD
   ↓
Approval
   ↓
Temporary Deployment Identity
   ↓
Production

And:

Application
   ↓
Dedicated Workload Identity
   ↓
Least-Privilege Cloud Access

Security logs should flow to an independently controlled security environment.

20. Project 02 Deliverables

Create:

01 Architecture Discovery Questions
02 Architecture Review Checklist
03 Annotated Architecture
04 Data Flow Diagram
05 Identity Flow
06 Trust Boundary Map
07 Attack Path Analysis
08 Architecture Findings
09 Target-State Architecture
10 Production Readiness Report

Project 03 — Multi-Cloud Security Review

Client Scenario

An international enterprise operates:

AWS
Azure
Google Cloud
Kubernetes
Microsoft Entra ID
Central SIEM
CI/CD Platform

Different business units adopted cloud independently.

Leadership is concerned about inconsistent security.

The CISO asks:

“Do we have a consistent security model across our cloud environments?”

21. Review Cloud Governance

Assess:

AWS Organizations
Azure Management Groups
Google Cloud Organization
Account/subscription/project creation
Policy enforcement
Ownership
Exception handling

Compare the environments.

22. Review Identity

Map:

Entra ID
   ↓
Federation
   ↓
AWS
Azure
Google Cloud
SaaS

Assess:

MFA
Federation
Privileged access
Local cloud users
Service identities
Cross-cloud administration

23. Review Workload Identity

Look for:

Applications
    ↓
Static Credentials
    ↓
Cloud APIs

versus:

Applications
    ↓
Managed Workload Identity
    ↓
Temporary Credentials

24. Review Logging

Map:

AWS ───────┐
Azure ─────┤
GCP ───────┼──→ Central SIEM
Kubernetes ┤
SaaS ──────┘

Determine whether telemetry coverage is consistent.

25. Simulated Findings

Assume:

AWS has mature organisation-level governance
Azure policy coverage is partial
GCP projects are created without central approval
Several local cloud administrator accounts exist
Kubernetes workloads contain static cloud credentials
Logging retention differs significantly between clouds
Cloud incident-response procedures are incomplete

26. Identify the Systemic Risk

Instead of reporting only:

Azure Policy missing.

GCP governance missing.

Kubernetes credentials weak.

Identify:

Enterprise cloud security governance is inconsistently implemented across cloud platforms.

27. Build the Target State

Enterprise Cloud Security Standard
            ↓
Central Identity
            ↓
Cloud Governance
            ↓
AWS / Azure / GCP
            ↓
Automated Guardrails
            ↓
Central Security Telemetry
            ↓
Continuous Compliance

28. Project 03 Deliverables

Create:

01 Multi-Cloud Inventory
02 Governance Comparison Matrix
03 IAM Assessment
04 Workload Identity Review
05 Cloud Network Review
06 Logging Coverage Matrix
07 Multi-Cloud Risk Register
08 Attack Path Analysis
09 Target Cloud Security Model
10 Multi-Cloud Security Roadmap

Project 04 — Privileged Access Security Assessment

Client Scenario

A large organisation has:

12,000 employees
850 IT administrators
Microsoft Entra ID
Active Directory
AWS
Azure
Linux
Windows
Databases
Network devices
SaaS applications

The organisation recently experienced credential theft.

Leadership wants a review of privileged access.

29. Discover Privileged Identities

Identify:

Domain Administrators
Cloud Administrators
Database Administrators
Network Administrators
Application Administrators
Security Administrators
Service Accounts
Emergency Accounts

30. Map Privileged Access

Example:

Administrator
      ↓
Authentication
      ↓
Privileged Role
      ↓
Target System
      ↓
Administrative Action
      ↓
Audit Log

31. Assess the Privileged Lifecycle

Review:

Request
   ↓
Approval
   ↓
Provision
   ↓
Authentication
   ↓
Elevation
   ↓
Monitoring
   ↓
Review
   ↓
Removal

32. Simulated Findings

Assume:

310 permanent privileged accounts
26 shared administrator accounts
MFA is inconsistent
Service-account passwords rarely rotate
Access reviews occur annually
Privileged sessions are not centrally monitored
Emergency accounts have weak governance

33. Build the Risk Scenario

Credential Theft
      ↓
Privileged Account
      ↓
Standing Administrative Access
      ↓
Critical Systems
      ↓
Privilege Expansion
      ↓
Business Impact

34. Develop the Target State

Standard Identity
      ↓
Strong MFA
      ↓
PAM
      ↓
Approval
      ↓
JIT Elevation
      ↓
Monitored Session
      ↓
Automatic Removal

35. Project 04 Deliverables

Create:

01 Privileged Account Inventory
02 Privileged Access Flow
03 PAM Maturity Assessment
04 Privileged Risk Register
05 Findings
06 Target-State PAM Architecture
07 Migration Strategy
08 Privileged Access Roadmap
09 Executive Summary

Project 05 — Security Operations & Detection Review

Client Scenario

A client has invested heavily in:

SIEM
EDR
Cloud security monitoring
Email security
Network detection

However, several recent incidents were discovered by users rather than the SOC.

Leadership asks:

“We have all these tools. Why are we still missing attacks?”

36. Review the Detection Lifecycle

Assess:

Threat
  ↓
Telemetry
  ↓
Collection
  ↓
Detection
  ↓
Alert
  ↓
Triage
  ↓
Investigation
  ↓
Response

A failure at any stage reduces detection capability.

37. Review Telemetry Coverage

Assess logs from:

Identity
Endpoint
Cloud
Network
Applications
Email
SaaS
Kubernetes

Ask:

Can the SOC observe the most important attack paths?

38. Review Detection Engineering

Do not measure maturity by the number of detection rules.

Determine whether detections cover realistic threats such as:

Credential theft
Privilege escalation
Cloud persistence
Data exfiltration
Ransomware
Suspicious administrative activity

39. Simulated Findings

Assume:

Important Entra ID logs are missing
AWS telemetry reaches the SIEM with significant delay
Detection rules generate excessive false positives
Cloud privilege escalation has limited detection coverage
Incident playbooks are outdated
Detection testing is not performed
Metrics focus on alert counts

40. Target State

Threat Model
      ↓
Required Telemetry
      ↓
Detection Engineering
      ↓
Validation
      ↓
SOC Investigation
      ↓
Automated Response
      ↓
Continuous Improvement

41. Project 05 Deliverables

Create:

01 SOC Discovery Questionnaire
02 Telemetry Coverage Matrix
03 Detection Coverage Matrix
04 Detection Gap Assessment
05 SOC Maturity Assessment
06 Findings Register
07 Detection Improvement Roadmap
08 Executive SOC Assessment

Project 06 — Security Transformation Strategy

Client Scenario

A multinational organisation has completed several assessments.

Common findings include:

Weak identity governance
Inconsistent cloud security
Fragmented security tooling
Manual compliance
Limited DevSecOps
Weak security metrics

The board asks:

“What should our cybersecurity programme look like over the next three years?”

This is no longer simply an assessment.

You are now acting as a strategic security consultant.

42. Establish Current State

Create a capability assessment across:

Governance
Risk
Identity
Cloud
Network
Endpoint
Application
Data
SOC
Incident Response
Vulnerability Management
Third-Party Risk
Compliance

43. Define Target State

For each capability:

Current State
      ↓
Required State
      ↓
Capability Gap

Example:

Identity

Current:
Permanent privilege

Target:
JIT + PAM + continuous governance

44. Build Transformation Workstreams

Possible workstreams:

WS01 Security Governance

WS02 Identity Modernisation

WS03 Cloud Security

WS04 Zero Trust

WS05 DevSecOps

WS06 Data Protection

WS07 Security Operations

WS08 Vulnerability Management

WS09 GRC Automation

45. Build the Three-Year Roadmap

Year 1 — Stabilise

Focus on:

Critical risk
Identity
Logging
Cloud governance
Vulnerability management

Year 2 — Automate

Focus on:

PAM
DevSecOps
Security guardrails
Detection engineering
GRC automation

Year 3 — Optimise

Focus on:

Continuous control validation
Zero Trust maturity
Threat-driven security
Advanced automation
Continuous assurance

46. Define Transformation Metrics

Examples:

Privileged MFA Coverage

Standing Administrator Reduction

Cloud Guardrail Coverage

Critical Vulnerabilities Beyond SLA

Detection Coverage

Mean Time to Detect

Mean Time to Respond

Compliance Automation Coverage

47. Project 06 Deliverables

Create:

01 Current-State Assessment
02 Security Capability Map
03 Maturity Assessment
04 Gap Analysis
05 Target-State Security Model
06 Transformation Workstreams
07 Dependency Map
08 Three-Year Roadmap
09 KPI / KRI Framework
10 Executive Transformation Strategy

Project 07 — Security Due Diligence Assessment

Client Scenario

Your client plans to acquire a technology company.

Before completing the acquisition, leadership wants to understand the target company’s cybersecurity exposure.

The assessment must be completed quickly.

This introduces another important consulting skill:

Risk-focused assessment under limited time and evidence.

48. Focus the Assessment

Prioritise:

Critical Assets
      ↓
Identity
      ↓
Internet Exposure
      ↓
Cloud
      ↓
Sensitive Data
      ↓
Security Operations
      ↓
Incident History
      ↓
Compliance

Do not attempt a full multi-month audit.

49. Key Due Diligence Questions

Ask:

Have significant breaches occurred?
Are critical vulnerabilities unresolved?
How is privileged access controlled?
Which cloud platforms are used?
Where is sensitive customer data?
Are regulatory obligations being met?
Are major security investments required?
Are key security capabilities outsourced?
Are critical vendors involved?

50. Identify Deal-Relevant Risks

Examples:

Major unresolved breach
Regulatory exposure
Unsupported infrastructure
Significant identity weakness
Large security remediation cost
Critical vendor dependency
Poor security staffing

The objective is to inform the business transaction.

51. Project 07 Deliverables

Create:

01 Due Diligence Questionnaire
02 Evidence Request
03 Critical Risk Register
04 Security Maturity Snapshot
05 Deal Risk Summary
06 Estimated Remediation Priorities
07 Executive Due Diligence Report

Project 08 — Production Security Readiness Review

Client Scenario

A major application is scheduled for production deployment.

The project team believes security is complete.

The CISO wants independent assurance before launch.

Your question is:

Is the system ready to accept production security risk?

52. Review Readiness Domains

Assess:

Architecture

Identity

Network

Application Security

Secrets

Data Protection

Logging

Detection

Incident Response

Backup

Vulnerability Management

Operational Ownership

53. Classify Readiness Issues

Use:

Launch Blocker

Unacceptable risk requiring remediation before production.

Required Remediation

Important issue with defined remediation commitment.

Improvement

Lower-priority enhancement.

This is more useful than simply generating finding severity.

54. Example Launch Blockers

Potential blockers might include:

Default credentials
Critical exploitable vulnerability
Public administrative access
Missing production logging
Exposed secrets
No backup capability
Uncontrolled privileged access

Always evaluate context before declaring something a blocker.

55. Go / Conditional Go / No-Go

Your final recommendation may be:

Go

Security risk is acceptable for launch.

Conditional Go

Launch may proceed subject to defined conditions.

No-Go

Material unresolved security risk makes production deployment inappropriate.

The business ultimately owns the decision.

Your role is to provide defensible security advice.

56. Project 08 Deliverables

Create:

01 Production Readiness Checklist
02 Architecture Review
03 Security Requirements Matrix
04 Evidence Tracker
05 Launch Risk Register
06 Security Findings
07 Launch Conditions
08 Go-Live Recommendation
09 Executive Readiness Summary

57. Consulting Project Quality Standard

For every project, your work should demonstrate:

Accuracy

Conclusions are technically correct.

Evidence

Findings are supported.

Context

Business importance is understood.

Risk

Technical issues are translated into meaningful risk.

Prioritisation

Important issues are separated from minor ones.

Practicality

Recommendations can realistically be implemented.

Communication

Technical and executive audiences can understand the results.

58. Use the Evidence-to-Decision Model

Every major project should demonstrate:

Evidence
   ↓
Observation
   ↓
Threat Scenario
   ↓
Risk
   ↓
Recommendation
   ↓
Priority
   ↓
Decision

If you cannot connect a recommendation back to evidence, reconsider it.

59. Maintain Consultant Working Papers

For each engagement maintain:

Working Papers/
│
├── Meeting Notes
├── Evidence Tracker
├── Assessment Workbook
├── Architecture Notes
├── Findings Register
├── Risk Register
├── Decision Log
└── Action Tracker

These are not necessarily delivered to the client.

They support your analysis.

60. Maintain a Decision Log

Example:

Date	Decision	Reason	Owner
12 Aug	Kubernetes excluded	Separate review planned	Client
14 Aug	IAM-03 reduced to Medium	Additional control evidence	Consultant
16 Aug	Logging finding retained	Compensating control insufficient	Consultant

This becomes valuable during complex engagements.

61. Maintain an Assumption Log

Examples:

A-001

Production architecture diagram supplied by client is assumed current.

A-002

Assessment assumes listed AWS accounts represent complete production scope.

If assumptions change, findings may also change.

62. Maintain an Issues Log

Examples:

Evidence delayed
Stakeholder unavailable
Architecture document outdated
Tool access unavailable
Scope ambiguity

Consultants should identify delivery risks early.

63. Maintain a Finding Register

Use:

Finding ID

Title

Domain

Observation

Evidence

Affected Scope

Risk

Likelihood

Impact

Rating

Recommendation

Owner

Status

This becomes your source of truth for reporting.

64. Maintain Traceability

You should be able to move from:

Requirement
     ↓
Assessment Question
     ↓
Evidence
     ↓
Observation
     ↓
Finding
     ↓
Risk
     ↓
Recommendation

This is one of the strongest habits you can develop.

65. Project Review Gate — Scoping

Before assessment begins verify:

[ ] Objective understood
[ ] Scope documented
[ ] Exclusions documented
[ ] Stakeholders identified
[ ] Timeline agreed
[ ] Methodology defined
[ ] Evidence requirements prepared
[ ] Deliverables agreed

66. Project Review Gate — Assessment

Before developing final findings verify:

[ ] Evidence reviewed
[ ] Architecture understood
[ ] Control design assessed
[ ] Operating effectiveness considered
[ ] Threat scenarios developed
[ ] Compensating controls considered
[ ] Systemic weaknesses identified

67. Project Review Gate — Findings

Before client validation verify:

[ ] Observation is factual
[ ] Evidence supports conclusion
[ ] Scope is accurate
[ ] Risk is realistic
[ ] Rating is justified
[ ] Recommendation addresses risk
[ ] Root cause considered

68. Project Review Gate — Reporting

Before final delivery verify:

[ ] Findings validated
[ ] Risk themes developed
[ ] Positive observations included
[ ] Executive summary completed
[ ] Roadmap developed
[ ] Technical QA completed
[ ] Editorial QA completed
[ ] Sensitive information reviewed
[ ] Final presentation prepared

69. Consultant Portfolio

These projects can also become the basis of your professional consulting portfolio.

Do not include real client confidential information.

Instead create sanitised or fictional examples.

A portfolio might include:

Senior Security Consultant Portfolio/
│
├── Enterprise Security Assessment
├── Security Architecture Review
├── Multi-Cloud Security Review
├── Privileged Access Assessment
├── SOC Security Review
├── Security Transformation Strategy
├── Security Due Diligence
└── Production Readiness Assessment

70. What to Include in Each Portfolio Project

For each project include:

Business Scenario

What problem was being solved?

Scope

What was assessed?

Methodology

How was the engagement performed?

Architecture

What environment was involved?

Findings

What significant weaknesses were identified?

Risk

Why did they matter?

Recommendations

What improvements were proposed?

Roadmap

How should remediation be prioritised?

Outcome

What decision did the work support?

This demonstrates consulting capability far better than simply listing tools.

71. Interview Value

These projects also prepare you for interview questions such as:

Walk me through a security assessment you have performed.

How would you approach a cloud security review?

How do you challenge an architecture?

How do you determine risk?

How do you handle disagreements with clients?

How do you present findings to executives?

How would you build a security transformation roadmap?

Instead of answering theoretically, you can structure your answer around an engagement.

72. Use the Consulting Story Format

A useful interview structure is:

Situation
   ↓
Objective
   ↓
Approach
   ↓
Technical Analysis
   ↓
Risk
   ↓
Recommendation
   ↓
Outcome

This demonstrates both technical and consulting maturity.

73. Senior Consultant Project Questions

For every engagement, ask:

Business

What decision is this engagement supporting?

Scope

What exactly are we assessing?

Architecture

How does the environment work?

Evidence

What proves the control exists and operates?

Threat

What realistic attack scenario matters?

Risk

What happens to the business?

Root Cause

Why does this weakness exist?

Recommendation

What practical change reduces the risk?

Priority

What should happen first?

Communication

Who needs to understand the result?

Outcome

What decision should the client be able to make?

74. Final Consulting Project Checklist

Before considering a project complete:

[ ] Client requirement understood
[ ] Business context documented
[ ] Scope defined
[ ] Exclusions defined
[ ] Stakeholders mapped
[ ] Discovery completed
[ ] Evidence collected
[ ] Architecture understood
[ ] Trust boundaries reviewed
[ ] Critical assets identified
[ ] Controls assessed
[ ] Attack paths considered
[ ] Risks evaluated
[ ] Compensating controls considered
[ ] Findings developed
[ ] Findings validated
[ ] Root causes identified
[ ] Recommendations developed
[ ] Findings prioritised
[ ] Risk themes established
[ ] Remediation roadmap developed
[ ] Executive summary prepared
[ ] Final report completed
[ ] Executive presentation completed
[ ] QA performed
[ ] Client next steps defined

Key Takeaways

The purpose of these projects is not simply to prove that you understand cybersecurity.

They are designed to develop the ability to operate like a Senior Security Consultant.

You should now be able to combine:

Business Understanding
        +
Technical Security
        +
Architecture
        +
Threat Analysis
        +
Risk
        +
Compliance
        +
Communication
        +
Transformation
        =
Senior Security Consulting

A mature consultant does not begin an engagement by asking:

“Which tool should I run?”

They begin by asking:

“What decision does the client need to make?”

Then they build a defensible path:

Client Problem
      ↓
Scope
      ↓
Discovery
      ↓
Evidence
      ↓
Analysis
      ↓
Risk
      ↓
Recommendation
      ↓
Roadmap
      ↓
Decision

That is the consulting capability these projects are designed to build.

What’s Next?

➡️ 09 — Enterprise Engagements

The next module moves beyond individual consulting projects into large-scale enterprise consulting engagements.

You will learn how Senior Security Consultants operate when engagements involve:

Multiple business units
Large stakeholder groups
Complex hybrid environments
Multiple cloud platforms
Parallel assessment teams
Large evidence sets
Conflicting stakeholder priorities
Executive steering committees
Programme dependencies
Formal governance
Risk escalation
Multi-phase delivery

You will also learn how to manage engagement planning, stakeholder communication, workstreams, evidence governance, finding consistency, executive escalation, quality assurance, and engagement closure.

The goal is to move from:

“I can execute a security consulting project.”

to:

“I can lead and coordinate a complex enterprise security consulting engagement.”