02 — Security Assessments

Security assessments are one of the most common responsibilities of a Senior Security Consultant.

An assessment is not simply a vulnerability scan, compliance checklist, or collection of screenshots.

A professional security assessment determines:

What assets and systems are important
What threats are relevant
Which controls should exist
Which controls actually exist
Whether those controls are effective
What security gaps remain
What risk those gaps create
What the organisation should fix first

The objective is to transform a complex environment into a clear view of:

Current security posture, meaningful risks, control weaknesses, and prioritised improvement actions.

This module will help you build a repeatable methodology for doing that.

Module Mission

Your mission is to develop a structured assessment process that moves from:

Assessment Objective
        ↓
Scope
        ↓
Assessment Criteria
        ↓
Discovery
        ↓
Evidence Collection
        ↓
Control Validation
        ↓
Gap Analysis
        ↓
Risk Evaluation
        ↓
Findings
        ↓
Recommendations
        ↓
Remediation Roadmap

By the end of this module, you should be able to approach an unfamiliar environment and systematically determine where meaningful security risks exist.

1. What Is a Security Assessment?

A security assessment is a structured evaluation of an organisation’s:

Technology
Processes
Architecture
Security controls
Governance
Operational practices

The purpose is to determine whether risks are being appropriately managed.

A good assessment answers four core questions:

1. What should be happening?

Based on:

Policies
Standards
Security frameworks
Regulatory requirements
Architecture requirements
Threat scenarios
Industry good practice

2. What is actually happening?

Validated through evidence.

3. What is the gap?

Determine where actual implementation differs from expected control requirements.

4. What risk does that gap create?

Translate the weakness into a realistic business risk.

2. Security Assessment vs Vulnerability Assessment

These are not the same thing.

Security Assessment	Vulnerability Assessment
Broad security evaluation	Primarily technical vulnerability identification
Includes governance and process	Usually technology-focused
Reviews architecture	Often scans systems
Evaluates controls	Identifies weaknesses
Considers business risk	Frequently uses severity scores
Uses multiple evidence sources	Often tool-driven
Produces strategic recommendations	Often produces remediation lists

A vulnerability scanner may identify:

TLS 1.0 enabled.

A broader security assessment asks:

Where is TLS 1.0 enabled?
Is the service externally accessible?
What information passes through it?
Is exploitation realistic?
Are compensating controls present?
What business process depends on it?
What is the appropriate remediation timeline?

This additional context is where consulting value appears.

3. Types of Security Assessments

A Senior Security Consultant may perform many different assessment types.

Enterprise Security Assessment

Evaluates broad security posture across domains such as:

Governance
Identity
Network
Endpoints
Applications
Cloud
Data
Vulnerability Management
Security Operations
Incident Response
Third Parties
Compliance

Cloud Security Assessment

Evaluates platforms such as:

AWS
Azure
Google Cloud
Kubernetes
SaaS environments

Typical domains include:

Cloud Governance
      ↓
IAM
      ↓
Network Security
      ↓
Workload Security
      ↓
Data Protection
      ↓
Logging & Monitoring
      ↓
Detection & Response
      ↓
Compliance

Identity Security Assessment

Focuses on:

Identity lifecycle
Authentication
MFA
Privileged access
Access reviews
Service identities
Conditional access
Federation
Secrets
Identity monitoring

Network Security Assessment

Evaluates:

Network architecture
Segmentation
Perimeter controls
Firewalls
Remote access
DNS
Egress controls
Administrative networks
Monitoring

Security Operations Assessment

Evaluates:

Logging
Detection
SIEM
SOC processes
Alert triage
Incident response
Threat intelligence
Threat hunting
Security automation

Compliance Assessment

Evaluates control alignment with requirements such as:

ISO/IEC 27001
NIST
CIS Controls
PCI DSS
SOC 2
Internal policies

4. Assessment Principles

Before starting any assessment, establish several principles.

Evidence-Based

Every meaningful conclusion should be supported by evidence.

Risk-Based

Prioritise issues according to realistic risk rather than checklist count.

Repeatable

Another qualified consultant should be able to understand how the conclusion was reached.

Defensible

The assessment should withstand technical and management challenge.

Proportionate

Assessment depth should match:

Business criticality
Threat exposure
Engagement objectives
Available time
Required assurance

Actionable

Recommendations must be realistic enough to implement.

5. Start With the Assessment Objective

Do not begin with tools.

Begin with the question:

What decision does this assessment need to support?

Examples:

Is this platform ready for production?
What are our largest cloud security risks?
Are security controls aligned with ISO 27001?
Is privileged access adequately controlled?
What security investments should we prioritise?
Is this architecture appropriate for sensitive workloads?
How mature is our detection capability?

The objective determines the assessment approach.

6. Define the Assessment Scope

Scope should identify:

Systems

Examples:

AWS accounts
Azure subscriptions
Applications
Kubernetes clusters
Networks
Identity platforms
Security tooling

Locations

Examples:

Production
Development
Corporate network
Cloud
Data centre
Remote workforce

Domains

Examples:

IAM
Network Security
Data Protection
Logging
Incident Response
Vulnerability Management

Exclusions

Examples:

Penetration testing
Source code review
Physical security
Social engineering
Third-party platforms

7. Establish Assessment Criteria

You need a benchmark against which the environment will be evaluated.

Possible criteria include:

Internal Requirements

Security policies
Security standards
Architecture principles
Control requirements

Industry Frameworks

Examples:

NIST Cybersecurity Framework
NIST SP 800-53
CIS Controls
CIS Benchmarks
ISO/IEC 27001

Regulatory Requirements

Examples:

PCI DSS
Privacy requirements
Industry-specific regulations

Vendor Guidance

Examples:

AWS security guidance
Microsoft security guidance
Google Cloud security guidance
Kubernetes security guidance

Threat-Based Requirements

Sometimes the most important assessment criterion is:

Can this control prevent, detect, or respond to realistic attack scenarios?

8. Build an Assessment Matrix

Create a structured matrix before beginning detailed analysis.

Example:

Domain	Control Objective	Evidence	Status	Risk
IAM	MFA for privileged users	Identity config	Partial	High
Network	Production segmentation	Network diagram	Met	Low
Logging	Central security logs	SIEM config	Partial	Medium
Data	Encryption at rest	Storage config	Met	Low

This prevents random assessment activity.

9. Understand Control Objectives

Do not assess controls without understanding what they are supposed to achieve.

For example:

Control

MFA.

Control Objective

Reduce the likelihood that stolen credentials alone can be used to compromise an account.

Assessment Question

Is MFA appropriately enforced for relevant identities?

Evidence

Identity policies
Authentication methods
Exception lists
Sign-in records

Risk

Credential compromise may lead to unauthorised access.

This control-oriented thinking is critical.

10. Assessment Domain — Governance

Governance establishes how security is directed and controlled.

Review areas such as:

Security ownership
Policies
Standards
Security roles
Risk governance
Exception management
Security metrics
Architecture governance
Security committees

Questions include:

Who owns cybersecurity risk?
Are responsibilities clearly defined?
Are security policies maintained?
How are exceptions approved?
How is security performance measured?

11. Assessment Domain — Asset Management

You cannot protect assets you do not understand.

Assess:

Hardware inventory
Software inventory
Cloud resources
Applications
Data assets
Service ownership
Criticality
Lifecycle management

Ask:

Can the organisation identify what assets exist and which ones matter most?

12. Assessment Domain — Identity & Access Management

Identity is frequently one of the highest-risk domains.

Assess:

Identity Lifecycle
      ↓
Authentication
      ↓
Authorisation
      ↓
Privileged Access
      ↓
Service Identities
      ↓
Access Reviews
      ↓
Monitoring

Look for:

MFA coverage
Dormant accounts
Excessive privileges
Shared accounts
Standing administrative access
Weak service-account governance
Inconsistent access reviews

13. Assessment Domain — Network Security

Assess network design and protection.

Review:

Segmentation
Firewall architecture
Internet exposure
Remote access
Administrative networks
East-west controls
Egress restrictions
DNS security
Network monitoring

A network diagram is often one of the most valuable pieces of assessment evidence.

14. Assessment Domain — Endpoint Security

Review:

Endpoint inventory
EDR
Anti-malware
Hardening
Patch management
Disk encryption
Local administrator rights
USB controls
Endpoint logging

Determine whether endpoint security controls are both deployed and monitored.

15. Assessment Domain — Application Security

Assess:

Secure development lifecycle
Code review
SAST
DAST
Dependency scanning
Secrets management
Authentication
Authorisation
API security
Security testing
Production release controls

Application security should be assessed in the context of the organisation’s development model.

16. Assessment Domain — Cloud Security

Cloud assessments should consider:

Governance

Account/subscription structure
Landing zones
Guardrails
Policy enforcement

Identity

Privileged roles
Federation
Workload identities
MFA

Network

Public exposure
Segmentation
Private endpoints
Firewalling

Data

Encryption
Key management
Storage exposure

Monitoring

Audit logs
Threat detection
SIEM integration

Resilience

Backups
Recovery
Region strategy

17. Assessment Domain — Data Protection

Understand where critical information exists.

Assess:

Data classification
Storage locations
Access control
Encryption
Key management
Data retention
DLP
Backup
Secure destruction

One useful question is:

Where is the organisation’s most damaging data exposure likely to occur?

18. Assessment Domain — Vulnerability Management

Review the complete vulnerability lifecycle.

Asset Discovery
      ↓
Scanning
      ↓
Validation
      ↓
Prioritisation
      ↓
Assignment
      ↓
Remediation
      ↓
Verification
      ↓
Metrics

Do not assess vulnerability management solely by whether a scanner exists.

19. Assessment Domain — Logging & Monitoring

Evaluate:

Log source coverage
Central collection
Retention
Time synchronisation
Access control
Detection rules
Alerting
SIEM coverage
Monitoring ownership

Ask:

If an attacker compromised a critical system today, would the organisation generate and retain enough evidence to detect and investigate it?

20. Assessment Domain — Incident Response

Review:

Incident response plan
Roles
Escalation
Communications
Playbooks
Evidence handling
Forensics
Exercises
Lessons learned

Important distinction:

Having an incident response document is not the same as having incident response capability.

21. Assessment Domain — Third-Party Security

Assess:

Vendor onboarding
Due diligence
Contractual requirements
Risk classification
Security questionnaires
Assurance evidence
Continuous monitoring
Offboarding

Third-party exposure can create risks outside the organisation’s direct technical control.

22. Collect Evidence

Evidence can be obtained using several methods.

Documentation Review

Examples:

Policies
Standards
Architecture diagrams
Procedures
Previous assessments

Interviews

Speak with:

Security teams
Architecture teams
Engineers
Business owners
Risk teams
Operations teams

Configuration Review

Examples:

IAM settings
Firewall rules
Logging configuration
Cloud policies
Security tooling

Tool Output

Examples:

Vulnerability scans
CSPM results
SIEM queries
EDR reports
Configuration exports

Observation

Watch processes being performed when useful.

23. Evidence Quality

Not all evidence has the same strength.

Consider:

Statement
    ↓
Document
    ↓
Configuration
    ↓
Operational Evidence

For example:

Weak Evidence

“We review privileged access regularly.”

Better Evidence

A documented privileged access review procedure.

Stronger Evidence

Completed access review records demonstrating the process is actually performed.

24. Use Evidence Triangulation

Do not rely on one source when risk is significant.

For example, to evaluate logging:

Interview

Security team says all critical cloud logs are centralised.

Documentation

Logging standard requires organisation-wide collection.

Configuration

Three cloud accounts are missing central logging.

This triangulation reveals the difference between expected and actual control implementation.

25. Test Control Design

Control design asks:

If implemented correctly, would this control reduce the intended risk?

Example:

Policy:

Privileged users must change passwords every 30 days.

This may exist as a control.

But if privileged accounts authenticate through phishing-prone passwords without MFA, the control may not adequately address the relevant threat.

A control can therefore exist but be poorly designed.

26. Test Operating Effectiveness

Operating effectiveness asks:

Is the control consistently operating as intended?

Example:

Security standard requires MFA for administrators.

Testing identifies:

100 Admin Accounts

92 → MFA Enabled
8  → MFA Exempt

The design may be appropriate.

Operation is incomplete.

This difference must appear in your assessment.

27. Identify Control Gaps

A gap may occur because:

Control does not exist
Control is poorly designed
Control is partially implemented
Control is inconsistently implemented
Control is not monitored
Control is not tested
Exceptions are unmanaged
Control has failed operationally

Document the actual cause where possible.

28. Move From Gap to Risk

Never stop at:

Control missing.

Ask:

What threat scenario becomes possible because this control is missing?

Use:

Control Gap
     ↓
Threat
     ↓
Attack Scenario
     ↓
Affected Asset
     ↓
Business Impact
     ↓
Risk

Example:

No MFA
   ↓
Credential Theft
   ↓
Account Compromise
   ↓
Cloud Administrator
   ↓
Infrastructure Manipulation
   ↓
Service Disruption / Data Exposure

29. Evaluate Existing Controls

A weakness may already be partially mitigated.

Consider:

Network restrictions
EDR
WAF
Monitoring
Approval workflows
Segmentation
Backup
Rate limiting
Compensating controls

This helps determine residual risk rather than theoretical worst-case risk.

30. Risk Rating

Risk models vary, but most consider:

Likelihood × Impact = Risk

Likelihood

Consider:

Exposure
Threat capability
Ease of exploitation
Existing protections
History of attacks

Impact

Consider:

Confidentiality
Integrity
Availability
Financial loss
Regulatory impact
Reputation
Safety
Business interruption

31. Example Risk Matrix

Likelihood	Low Impact	Medium Impact	High Impact
Low	Low	Low	Medium
Medium	Low	Medium	High
High	Medium	High	Critical

Use the client’s risk methodology when one exists.

CVSS can be useful for technical vulnerability severity.

But business risk may differ.

For example:

CVSS 9.8 Vulnerability

may affect:

An isolated lab system
No sensitive information
No production connectivity

Business risk may be limited.

Conversely:

Weak MFA Policy

might not have a CVSS score at all.

Yet it could expose:

Global administrator accounts
Production cloud infrastructure
Sensitive business data

Business risk may be severe.

33. Create Clear Findings

Every finding should contain:

Title
   ↓
Observation
   ↓
Evidence
   ↓
Affected Scope
   ↓
Risk
   ↓
Potential Impact
   ↓
Recommendation
   ↓
Priority

34. Example Finding

Excessive Standing Administrative Access

Observation

Multiple users retain permanent administrative permissions in the production cloud environment despite not requiring continuous privileged access.

Evidence

Role assignments reviewed during the assessment identified permanent privileged access for operational users.

Risk

Compromise of these accounts could provide an attacker with extensive administrative permissions.

Impact

Potential consequences include:

Infrastructure modification
Security control disruption
Data access
Persistence
Service disruption

Recommendation

Introduce privileged access management and just-in-time elevation, reduce permanent administrative assignments, and periodically review privileged access.

Priority

High

35. Finding Titles Matter

Avoid vague titles:

IAM Issue

Prefer:

Excessive Standing Administrative Access

Avoid:

Logging Problem

Prefer:

Critical Cloud Audit Logs Are Not Centrally Retained

The reader should understand the issue from the title.

36. Separate Facts From Assumptions

Document facts clearly.

Fact

CloudTrail was disabled in two assessed AWS accounts.

Assumption

Those accounts may contain production workloads.

If the assumption affects the rating, validate it.

Do not quietly transform assumptions into facts.

37. Validate Findings With Control Owners

Before finalising:

Confirm technical accuracy
Check for missing evidence
Identify compensating controls
Confirm affected scope
Understand implementation constraints

Validation improves quality.

But the consultant retains independent responsibility for the final assessment.

38. Handle False Positives

Automated tools frequently produce false positives.

Never copy tool output directly into a client report without validation.

Use:

Tool Alert
    ↓
Technical Validation
    ↓
Environmental Context
    ↓
Risk Analysis
    ↓
Finding

This distinction is critical.

39. Identify Systemic Findings

Sometimes 50 individual issues are symptoms of one larger problem.

Example:

You find:

Public storage
Excessive IAM permissions
Missing logging
Inconsistent encryption
Unapproved services

Rather than reporting only separate technical issues, you may identify:

Cloud governance controls are not consistently enforced across environments.

Systemic findings often have greater strategic value.

40. Look for Root Causes

Ask why the weakness exists.

Possible root causes:

Missing governance
Poor ownership
Manual processes
Lack of technical guardrails
Skills gaps
Weak change management
Rapid cloud adoption
Decentralised responsibility
Tool limitations

Example:

Repeated Public Storage
       ↓
Why?
No policy enforcement
       ↓
Why?
No cloud guardrails
       ↓
Why?
Cloud governance not established

A strong recommendation addresses the root cause.

41. Prioritise Findings

Do not prioritise only by technical severity.

Consider:

Factor	Consideration
Risk	Likelihood × impact
Exposure	Internal or internet-facing
Criticality	Importance of affected asset
Scope	One resource or enterprise-wide
Exploitability	Practical likelihood
Compliance	Regulatory consequences
Dependency	Required before other fixes
Effort	Complexity of remediation

42. Quick Wins vs Strategic Improvements

Separate remediation into categories.

Immediate

Examples:

Disable public access
Enable MFA
Remove inactive accounts
Patch critical exposed systems

Short Term

Examples:

Improve firewall governance
Centralise logging
Introduce regular access reviews

Strategic

Examples:

Implement Zero Trust
Introduce PAM
Build cloud security guardrails
Redesign network segmentation
Establish enterprise security governance

This makes recommendations easier to execute.

43. Build a Remediation Roadmap

Example:

0–30 Days
│
├── Critical exposure reduction
├── Privileged access fixes
└── Logging gaps

30–90 Days
│
├── Access governance
├── Network controls
└── Vulnerability process improvements

3–6 Months
│
├── PAM
├── Security architecture improvements
└── Cloud guardrails

6–12 Months
│
├── Zero Trust maturity
├── Security automation
└── Enterprise transformation

A roadmap often provides more business value than the findings alone.

44. Assess Maturity Carefully

Some engagements require maturity assessment.

A simple maturity scale might be:

Level 1 — Ad Hoc

Processes are inconsistent or undocumented.

Level 2 — Developing

Some controls exist but implementation is inconsistent.

Level 3 — Defined

Processes are documented and generally implemented.

Level 4 — Managed

Controls are measured, monitored, and governed.

Level 5 — Optimised

Continuous improvement and automation are established.

Do not assign maturity scores without evidence.

45. Avoid Score Theatre

A maturity score such as:

Security maturity = 3.4 / 5

can appear precise without actually being meaningful.

Always explain:

Assessment criteria
Evidence
Strengths
Weaknesses
Improvement priorities

The number should support the analysis, not replace it.

46. Document Positive Observations

Assessment reports should not contain only weaknesses.

Examples:

Strong MFA coverage
Mature SOC operations
Effective network segmentation
Central logging architecture
Strong cloud landing zone controls

Positive observations help:

Provide balanced reporting
Demonstrate what should be preserved
Improve stakeholder trust
Highlight mature practices

47. Maintain Assessment Traceability

You should be able to trace:

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

This is especially important in regulatory or assurance engagements.

48. Sample Assessment Workbook Structure

Build a workbook with columns such as:

Control ID
Domain
Control Objective
Assessment Question
Evidence Required
Evidence Received
Assessment Result
Observation
Risk
Recommendation
Owner
Status

This becomes the working backbone of the assessment.

49. Assessment Status Values

Use consistent status terminology.

For example:

Effective
Partially Effective
Ineffective
Not Implemented
Not Applicable
Not Assessed

Define them before using them.

50. Consultant Field Technique — Follow the Attack Path

When assessment time is limited, think like an attacker.

Example:

Internet
   ↓
Application
   ↓
Workload Identity
   ↓
Cloud API
   ↓
Sensitive Storage

Ask:

What controls exist at each stage?

This quickly identifies security dependencies.

51. Consultant Field Technique — Follow the Data

Pick sensitive data and trace its lifecycle.

Collection
    ↓
Transmission
    ↓
Processing
    ↓
Storage
    ↓
Access
    ↓
Backup
    ↓
Deletion

Review security controls at every stage.

52. Consultant Field Technique — Follow the Identity

Pick a privileged identity.

Trace:

Provisioning
    ↓
Authentication
    ↓
Authorisation
    ↓
Privilege Elevation
    ↓
Activity Logging
    ↓
Access Review
    ↓
Deprovisioning

Identity journeys reveal many enterprise control gaps.

53. Consultant Field Technique — Follow an Incident

Ask:

Assume an administrator account is compromised at 2 AM.

Then investigate:

Would MFA stop it?
      ↓
Would monitoring detect it?
      ↓
Would the SOC investigate it?
      ↓
Would logs support investigation?
      ↓
Could access be contained?
      ↓
Could systems recover?

This tests several controls together rather than in isolation.

54. Common Assessment Mistakes

Avoid:

Checklist Without Context

Marking controls pass/fail without considering risk.

Screenshot Collection Without Analysis

Evidence is not the same as assessment.

Tool Output as Findings

Validate everything.

Over-Reliance on Interviews

Statements must be supported where appropriate.

Ignoring Compensating Controls

This exaggerates risk.

Ignoring Scope

Never assess systems without authorisation.

Reporting Every Small Issue

Focus on meaningful security risk.

Generic Remediation

Recommendations must be actionable.

55. Assessment Quality Review

Before finalising an assessment, ask:

Scope

Did we assess what we promised?

Evidence

Are conclusions supported?

Accuracy

Are technical statements correct?

Completeness

Were important security domains considered?

Risk

Are ratings reasonable?

Recommendations

Are they practical?

Consistency

Are similar findings treated consistently?

Communication

Can both technical and business readers understand the results?

56. Practical Exercise — Enterprise Security Assessment

Imagine you have been asked to assess the security posture of an organisation with:

Microsoft Entra ID
AWS
Microsoft Azure
Corporate endpoints
SaaS applications
Kubernetes
Central SIEM
Remote workforce

Your first task is not to run tools.

Create an assessment plan.

Step 1 — Define Domains

Use:

Governance
Identity
Network
Endpoints
Applications
Cloud
Data
Vulnerability Management
Logging & Monitoring
Incident Response
Third Parties

Step 2 — Create Assessment Questions

For identity:

Is MFA enforced?
Are privileged identities governed?
Are access reviews performed?
Are dormant accounts removed?
Are workload identities controlled?

Step 3 — Identify Evidence

Request:

Identity architecture
Administrative role exports
Conditional access policies
Authentication reports
Access review records

Step 4 — Evaluate Controls

Determine:

Expected Control
      ↓
Actual Control
      ↓
Gap
      ↓
Risk

Step 5 — Build Findings

For each significant issue:

Observation
Evidence
Risk
Impact
Recommendation
Priority

Step 6 — Develop Roadmap

Group improvements into:

Immediate
Short term
Medium term
Strategic

57. Build Your Security Assessment Toolkit

Add the following to your consultant toolkit:

Security Assessment Toolkit
│
├── Assessment Scope Template
├── Assessment Planning Checklist
├── Security Domain Checklist
├── Discovery Questionnaire
├── Evidence Request List
├── Evidence Tracker
├── Assessment Matrix
├── Risk Matrix
├── Finding Template
├── Root Cause Template
├── Remediation Roadmap
└── Executive Summary Template

You will reuse these assets in later modules.

Key Takeaways

A professional security assessment should:

Begin with a clear objective
Define the scope before assessment begins
Establish assessment criteria
Evaluate control objectives
Gather reliable evidence
Test design and operating effectiveness
Validate automated findings
Identify control gaps
Translate weaknesses into realistic risk
Consider compensating controls
Find systemic weaknesses and root causes
Prioritise remediation
Develop practical recommendations
Maintain traceability
Communicate technical and business impact
Produce an actionable roadmap

The assessment workflow is:

Plan
  ↓
Discover
  ↓
Collect
  ↓
Validate
  ↓
Assess
  ↓
Analyse
  ↓
Prioritise
  ↓
Recommend
  ↓
Report

A Senior Security Consultant does not simply tell the client what is wrong.

The consultant helps the client understand:

What matters, why it matters, and what should be done about it.

What’s Next?

➡️ 03 — Architecture Reviews

Now that you can systematically assess security controls and identify meaningful gaps, the next module moves into one of the most important senior consulting capabilities: reviewing security architecture.

You will learn how to evaluate enterprise architecture from a security perspective, identify trust boundaries and attack paths, assess identity, network, application, data, cloud, and monitoring design, challenge architecture decisions, document risks, and recommend secure design improvements.

The goal is to move from:

“This control is missing.”

to:

“This architecture creates a security weakness, here is the attack path it enables, and here is how the design should change.”