06 — Client Reporting

Finding security problems is only part of a consulting engagement.

A Senior Security Consultant must also communicate those problems clearly enough that:

• Engineers understand what needs to change
• Architects understand the design implications
• Security leaders understand the risk
• Business owners understand the impact
• Executives understand what decisions are required

A technically accurate assessment can still fail if the report is confusing, overly technical, poorly prioritised, or impossible to act upon.

Client reporting transforms:

Technical Evidence
        ↓
Security Observation
        ↓
Risk
        ↓
Business Impact
        ↓
Recommendation
        ↓
Priority
        ↓
Management Decision

The objective is not to produce the longest report.

The objective is to produce a report that helps the client understand, prioritise, and act.

Module Mission

Your mission is to develop a repeatable reporting methodology that moves from:

Assessment Evidence
        ↓
Validated Findings
        ↓
Risk Analysis
        ↓
Finding Development
        ↓
Risk Themes
        ↓
Executive Summary
        ↓
Recommendations
        ↓
Remediation Roadmap
        ↓
Client Presentation
        ↓
Final Deliverable

By the end of this module, you should be able to transform complex technical assessment results into professional consulting deliverables suitable for technical teams and senior leadership.

1. Why Client Reporting Matters

The final report is often the most visible product of a consulting engagement.

Many stakeholders will never see:

• Your assessment workbook

• Security tool output

• Interview notes

• Configuration exports

• Evidence repository

• Technical analysis

They may only see:

The final report and executive presentation.

Your report therefore becomes the client’s permanent record of:

• What was assessed

• What was discovered

• Why it matters

• What should be improved

• What should happen first

Poor reporting can undermine otherwise excellent technical work.

2. Reporting Is Part of the Assessment

Do not treat reporting as something that begins after technical work finishes.

A stronger workflow is:

Assessment
    ↓
Document Evidence
    ↓
Draft Observation
    ↓
Validate
    ↓
Develop Finding
    ↓
Assess Risk
    ↓
Develop Recommendation

This allows findings to mature throughout the engagement.

Waiting until the final day to write everything usually reduces quality.

3. Know Your Audience

Different stakeholders need different information.

Engineers

Usually need:

• Technical evidence

• Affected resources

• Configuration details

• Attack scenario

• Remediation steps

Architects

Usually need:

• Design weaknesses

• Trust relationships

• Attack paths

• Architecture implications

• Target-state recommendations

Security Leadership

Usually needs:

• Major risks

• Control weaknesses

• Security themes

• Priorities

• Remediation dependencies

Executives

Usually need:

• Overall security posture

• Business impact

• Major risk themes

• Strategic priorities

• Investment requirements

• Decisions required

One report may serve several audiences, but the information should be layered appropriately.

4. Think in Reporting Layers

A professional report can be designed in layers.

Layer 1
Executive Summary

Layer 2
Key Risk Themes

Layer 3
Prioritised Findings

Layer 4
Detailed Technical Findings

Layer 5
Evidence / Appendices

This allows readers to consume the level of detail appropriate to their role.

5. Typical Security Consulting Report

A professional report might contain:

01 Executive Summary

02 Engagement Background

03 Objectives

04 Scope

05 Methodology

06 Environment Overview

07 Overall Security Posture

08 Key Risk Themes

09 Positive Observations

10 Detailed Findings

11 Recommendations

12 Remediation Roadmap

13 Conclusion

14 Appendices

The exact structure depends on the engagement.

6. Report Cover Information

A formal client deliverable may include:

Security Assessment Report

Client:
Example Corporation

Engagement:
Enterprise Cloud Security Assessment

Assessment Period:
01 August – 15 August

Report Version:
1.0

Classification:
Confidential

Also consider:

• Document owner

• Author

• Reviewer

• Distribution list

• Version history

7. Document Classification

Security reports frequently contain highly sensitive information.

They may include:

• Vulnerabilities

• Internal architecture

• IP addresses

• Security weaknesses

• Identity information

• Cloud account details

• Security control gaps

Apply the client’s classification requirements.

Examples:

Public
Internal
Confidential
Restricted

Do not casually distribute security assessment reports.

8. Version Control

Maintain clear report versions.

Example:

Version	Date	Description	Author
0.1	10 Aug	Initial draft	Consultant
0.5	12 Aug	Internal review	Consultant
0.9	14 Aug	Client validation	Consultant
1.0	16 Aug	Final report	Consultant

Avoid filenames such as:

Final_Report_v2_FINAL_latest_final2.docx

Professional document management matters.

9. Write the Engagement Background

Provide enough context to explain why the assessment occurred.

Example:

Example Corporation engaged the security consulting team to assess the security posture of its production cloud environment before expansion of its customer-facing digital platform.

Keep this section concise.

The reader should understand:

• Why the engagement happened

• What business initiative it supported

• What the assessment intended to achieve

10. Define the Objectives

Clearly document what the engagement was designed to accomplish.

Example:

The assessment objectives were to:

• Evaluate cloud security governance

• Assess privileged access

• Review network security

• Evaluate workload protection

• Review logging and monitoring

• Identify significant security risks

• Develop prioritised recommendations

This helps readers understand how to interpret the results.

11. Document the Scope

Clearly state what was assessed.

Example:

In Scope

AWS Organisation
├── Production Account
├── Security Account
├── Logging Account
└── Shared Services Account

Security Domains
├── IAM
├── Network Security
├── Data Protection
├── Logging
└── Incident Response

Also state important exclusions.

12. Document Out-of-Scope Areas

Examples:

Out of Scope

Application penetration testing
Source code review
Social engineering
Physical security
Third-party SaaS platforms

This prevents readers from assuming the report provides assurance over areas that were never assessed.

13. Document Limitations

Every assessment has limitations.

Examples:

• Evidence was unavailable

• Some systems were inaccessible

• Testing was non-intrusive

• Assessment was point-in-time

• Production testing was restricted

• Some stakeholders were unavailable

Example wording:

The assessment represents the environment and evidence available during the review period and should not be interpreted as a guarantee that additional security weaknesses do not exist.

Limitations protect report accuracy.

14. Describe the Methodology

Explain how the assessment was conducted.

For example:

Discovery
   ↓
Documentation Review
   ↓
Stakeholder Interviews
   ↓
Configuration Review
   ↓
Evidence Validation
   ↓
Risk Assessment
   ↓
Finding Development

Mention relevant standards or benchmarks where appropriate.

15. Avoid Methodology Overload

Do not spend ten pages describing methodology unless required.

Clients generally care more about:

What did you find?

than:

Every detail of how your assessment framework works.

Keep methodology sufficient for credibility and repeatability.

16. Write the Environment Overview

Help the reader understand what was assessed.

Example:

The assessed environment consists of a multi-account AWS organisation supporting internet-facing production applications, central identity federation, shared networking, central security services, and development workloads.

You may include a simplified architecture diagram.

Avoid exposing unnecessary sensitive detail in executive sections.

17. Develop the Executive Summary

The executive summary is one of the most important sections.

Many senior stakeholders may read only this section.

It should answer:

Why Was the Assessment Performed?

What Was Assessed?

What Is the Overall Security Position?

What Are the Most Important Risks?

What Should Leadership Prioritise?

Do not simply copy technical findings into the executive summary.

18. Executive Summary Structure

A useful structure is:

Engagement Context
        ↓
Overall Assessment
        ↓
Key Strengths
        ↓
Key Risk Themes
        ↓
Priority Actions
        ↓
Strategic Direction

This provides a narrative rather than a list of vulnerabilities.

19. Example Executive Summary

The assessment identified a number of established security capabilities, including central identity federation, baseline cloud logging, and endpoint protection. However, weaknesses in privileged access governance, cloud policy enforcement, and security logging isolation increase the potential impact of credential or workload compromise.

Priority should be given to reducing standing administrative privileges, strengthening phishing-resistant authentication, centralising cloud security guardrails, and protecting security telemetry outside production administrative boundaries.

Notice that this communicates the security story without requiring the executive to understand individual configurations.

20. Start With the Overall Story

Before writing detailed findings, ask:

What is the overall security story of this environment?

Perhaps the environment has:

• Strong technical controls

• Weak governance

Or:

• Strong perimeter security

• Weak identity security

Or:

• Good security architecture

• Inconsistent implementation

Or:

• Mature controls

• Weak operational effectiveness

Your report should communicate this clearly.

21. Identify Risk Themes

Do not make leadership interpret 40 individual findings.

Group related issues into themes.

Example:

Privileged Access Governance
        ↓
Finding 01
Finding 04
Finding 09

Cloud Governance
        ↓
Finding 03
Finding 07
Finding 12

Security Monitoring
        ↓
Finding 05
Finding 08

Themes reveal systemic weaknesses.

22. Example Risk Themes

Common themes may include:

Identity Governance

• Excessive privileges

• Weak MFA

• Incomplete access reviews

Cloud Governance

• Missing guardrails

• Inconsistent baselines

• Decentralised ownership

Detection & Response

• Incomplete telemetry

• Weak detection coverage

• Unclear escalation

Data Protection

• Excessive access

• Weak classification

• Inconsistent encryption

These themes are often more valuable to executives than raw finding counts.

23. Report Positive Observations

A balanced report should identify strengths.

Examples:

• Strong central identity federation

• Effective EDR deployment

• Mature SOC processes

• Good cloud account separation

• Centralised vulnerability management

• Strong backup controls

Positive observations help the client understand what should be maintained.

They also make the report more credible than one that appears designed only to find faults.

24. Do Not Manufacture Praise

Positive observations should also be evidence-based.

Avoid vague statements such as:

The client has excellent security.

Prefer:

Central identity federation and MFA are consistently implemented across the assessed workforce applications.

Specific observations are more meaningful.

25. Anatomy of a Strong Finding

A professional finding should usually contain:

Finding ID

Finding Title

Risk Rating

Observation

Affected Scope

Evidence

Risk

Potential Impact

Recommendation

Management Response

Depending on the engagement, you may also include:

• Control mapping

• Root cause

• Remediation owner

• Target date

26. Finding IDs

Use consistent identifiers.

Examples:

IAM-01
IAM-02

NET-01
NET-02

LOG-01

CLOUD-01

Or simply:

F-001
F-002
F-003

Consistency is more important than complexity.

27. Write Strong Finding Titles

Weak:

MFA Issue

Better:

MFA Is Not Consistently Enforced for Privileged Accounts

Weak:

Logging

Better:

Critical Cloud Audit Logs Are Not Centrally Protected

Weak:

IAM Permissions

Better:

Excessive Standing Administrative Access Increases Production Exposure

The title should communicate the problem immediately.

28. Write the Observation

The observation describes what you actually identified.

Good observation:

Review of privileged role assignments identified 14 operational accounts with permanent administrative access to production subscriptions.

Avoid emotional or exaggerated wording.

Poor:

The organisation has dangerously insecure administrator access everywhere.

Observations should be factual.

29. Separate Observation From Risk

Observation:

Eight privileged identities do not enforce MFA.

Risk:

Compromise of valid credentials could allow unauthorised privileged access.

Do not mix the two unnecessarily.

This makes the finding easier to defend.

30. Document the Affected Scope

Clearly state what is affected.

Example:

Affected Scope

AWS Production Account
AWS Shared Services Account
12 Privileged IAM Roles

Avoid making enterprise-wide claims when only a small sample was assessed.

31. Document Evidence Carefully

Evidence may include:

• Configuration output

• Screenshots

• Policy extracts

• Logs

• Interview confirmation

• Architecture diagrams

Do not overload the main report with every screenshot.

Use appendices or evidence repositories when appropriate.

32. Avoid Exposing Sensitive Secrets

Never include unnecessary:

• Passwords

• API keys

• Access tokens

• Private keys

• Sensitive personal data

If evidence contains secrets, redact them.

Example:

Access Key:
AKIA****************

Reports themselves can become security risks.

33. Write the Risk Statement

A useful pattern is:

Because of [condition],
a [threat actor/event]
could [security event],
resulting in [business impact].

Example:

Because privileged administrative access is permanently assigned to multiple operational identities, compromise of one of those identities could provide extensive production access, potentially resulting in unauthorised infrastructure modification, data exposure, or service disruption.

34. Explain Business Impact

Avoid stopping at technical consequences.

Technical:

Attacker could modify S3 objects.

Business:

An attacker could modify or remove production data, potentially disrupting customer-facing services and affecting data integrity.

Senior reports should connect the two.

35. Keep Impact Realistic

Do not automatically write:

This could lead to complete enterprise compromise.

Ask whether that outcome is realistically supported by the architecture and evidence.

Credibility is more important than dramatic language.

36. Risk Rating

Use the client’s risk methodology whenever possible.

Typical ratings:

Critical
High
Medium
Low

You may also include:

• Likelihood

• Impact

• Residual risk

The rating should be consistent with the written risk scenario.

37. Explain Risk Ratings When Necessary

If a finding is rated High, the reader should understand why.

Example:

Likelihood: Medium

Impact: High

Overall Risk: High

Reason:

Exploitation requires valid credentials, but successful compromise would provide administrative access to business-critical production resources.

This improves transparency.

38. Avoid Severity Inflation

Do not make everything High or Critical.

This creates:

Everything Is Critical
        ↓
Nothing Is Prioritised

A good report helps the client decide what to address first.

39. Write Actionable Recommendations

Weak:

Improve IAM security.

Better:

Remove unnecessary permanent administrative assignments and require approved temporary privilege elevation for operational administrators.

A strong recommendation should answer:

What should change?

40. Recommendations Should Address Root Cause

Finding:

Multiple public storage resources exist.

Weak recommendation:

Make the identified storage resources private.

Better:

Remove unnecessary public access and implement organisation-level policy guardrails that prevent public storage from being created without an approved exception.

The second addresses both immediate exposure and systemic cause.

41. Use Layered Recommendations

For significant findings, divide recommendations into stages.

Immediate

Reduce current exposure.

Short Term

Improve control consistency.

Strategic

Address underlying architecture or governance.

Example:

Immediate
Enable MFA for exposed privileged accounts.

Short Term
Remove unnecessary standing administrator access.

Strategic
Implement PAM and Just-in-Time privilege elevation.

This makes remediation practical.

42. Consider Client Constraints

Recommendations should consider:

• Existing technology

• Budget

• Skills

• Architecture

• Business deadlines

• Operational dependencies

• Regulatory deadlines

Do not recommend replacing the entire technology estate to solve a small problem.

43. Avoid Product-First Recommendations

Instead of:

Buy Product X.

State the required security capability:

Implement centralised privileged access management supporting temporary elevation, approval workflows, session auditing, and credential protection.

Specific technologies can be discussed where appropriate, but the recommendation should focus on the security outcome.

44. Document Root Cause

Where useful, identify why the issue exists.

Examples:

• Missing governance

• Decentralised ownership

• Manual process

• Incomplete standard

• Lack of technical guardrails

• Legacy architecture

• Skills gap

Example:

Observation
Multiple public resources

Root Cause
No centrally enforced cloud policy

Recommendation
Implement organisation-level deployment guardrails

This creates better remediation.

45. Management Response

Some reports include a management response section.

Example:

Management Response

Accepted.

Owner:
Cloud Platform Team

Target Date:
31 December

Planned Action:
Implement temporary privileged access using the enterprise PAM platform.

This converts findings into accountable actions.

46. Finding Validation

Before finalising findings, validate them with relevant technical owners.

The validation process may look like:

Draft Finding
      ↓
Internal QA
      ↓
Technical Validation
      ↓
Additional Evidence
      ↓
Risk Adjustment
      ↓
Final Finding

This reduces errors and surprises.

47. Validation Is Not Negotiation

Clients may challenge findings.

That is normal.

Listen carefully.

If additional evidence proves your conclusion wrong:

Correct the finding.

If evidence reduces the risk:

Adjust the rating.

If no new evidence changes the conclusion:

Maintain the finding professionally.

Do not remove legitimate findings simply because they are uncomfortable.

48. Track Finding Status

During validation, statuses might include:

Draft

Internal Review

Client Validation

Updated

Accepted

Closed

Final

This is especially useful for large engagements.

49. Maintain a Finding Register

Example:

ID	Finding	Risk	Owner	Status
IAM-01	Standing admin access	High	IAM	Validated
LOG-01	Logging gaps	High	SOC	Draft
NET-01	Broad segmentation	Medium	Network	Validated

The register becomes the working source for reporting.

50. Prioritise Beyond Risk Rating

Two High findings may require different priorities.

Consider:

• Exploitability

• Exposure

• Asset criticality

• Dependency

• Regulatory requirement

• Remediation effort

• Quick-win potential

This helps build the remediation roadmap.

51. Build a Remediation Roadmap

Do not leave the client with 50 disconnected recommendations.

Group them.

Example:

0–30 Days
│
├── Protect privileged identities
├── Remove exposed credentials
├── Restrict public management access
└── Enable critical audit logging

30–90 Days
│
├── Improve access reviews
├── Centralise cloud logging
├── Implement baseline policies
└── Improve vulnerability governance

3–6 Months
│
├── Introduce PAM
├── Improve network segmentation
├── Centralise secrets management
└── Implement cloud guardrails

6–12 Months
│
├── Zero Trust improvements
├── Policy-as-Code
├── Continuous compliance
└── Security automation

52. Identify Dependencies

Some recommendations must happen before others.

Example:

Central Identity
      ↓
MFA
      ↓
PAM
      ↓
JIT Access
      ↓
Continuous Access Governance

A roadmap should reflect these dependencies.

53. Identify Quick Wins

Some improvements provide significant risk reduction with limited effort.

Examples:

• Enable MFA

• Disable unused accounts

• Remove public access

• Enable audit logging

• Remove exposed secrets

• Restrict administrative interfaces

Highlight them.

Quick wins help the client begin remediation immediately.

54. Separate Tactical and Strategic Actions

Tactical

Fix immediate weaknesses.

Strategic

Improve underlying security capability.

Example:

Tactical
Remove excessive administrator permissions.

Strategic
Establish enterprise privileged-access governance.

Both should appear where appropriate.

55. Create an Executive Risk View

Executives may benefit from a simple summary.

Example:

Theme	Current Risk	Priority
Identity	High	Immediate
Cloud Governance	High	Immediate
Monitoring	Medium	Short Term
Data Protection	Medium	Short Term
Resilience	Low	Maintain

Do not overload this view with technical detail.

56. Avoid Finding Count as the Main Metric

Reporting:

42 findings identified.

provides limited information.

Suppose:

1 Critical
3 High
10 Medium
28 Low

Even that still does not explain the security story.

Better:

The assessment identified three priority risk themes: privileged access, inconsistent cloud governance, and insufficient logging isolation.

Risk themes provide more decision value.

57. Executive Presentations

The final presentation should not simply be the report copied into slides.

A useful presentation might contain:

01 Engagement Objective

02 Environment Overview

03 Overall Security Posture

04 Key Strengths

05 Priority Risk Themes

06 Critical / High Findings

07 Target Security Direction

08 Remediation Roadmap

09 Decisions Required

10 Next Steps

Keep the narrative focused.

58. Start Presentations With Context

Before discussing findings, remind the audience:

• Why the engagement occurred

• What was assessed

• What was not assessed

• What methodology was used

Then move quickly into the results.

59. Present Risk Themes Before Detailed Findings

Instead of immediately showing:

Finding 1
Finding 2
Finding 3
Finding 4
...

Start with:

Three Priority Themes

1. Privileged Access

2. Cloud Governance

3. Security Monitoring

Then show the important findings supporting each theme.

60. Tell the Security Story

A strong presentation has a narrative.

For example:

Cloud Adoption Increased
        ↓
Governance Did Not Scale
        ↓
Security Controls Became Inconsistent
        ↓
Privileged Access Expanded
        ↓
Monitoring Coverage Became Fragmented
        ↓
Enterprise Risk Increased

Then:

Recommended Direction

Central Governance
        ↓
Identity Modernisation
        ↓
Automated Guardrails
        ↓
Central Monitoring
        ↓
Continuous Assurance

This is more memorable than isolated findings.

61. Use Diagrams Where They Add Value

Some risks are easier to explain visually.

Example attack path:

Phished Administrator
        ↓
Cloud Console
        ↓
Standing Administrator Role
        ↓
Production
        ↓
Logging Configuration
        ↓
Evidence Deletion

This may communicate the risk more effectively than several paragraphs.

62. Use Before-and-After Architecture

Current:

Users
  ↓
Permanent Admin
  ↓
Production

Target:

Users
  ↓
MFA
  ↓
PAM
  ↓
Approved Temporary Access
  ↓
Production

Architecture comparison can make recommendations immediately understandable.

63. Avoid Slide Overload

Do not put:

• 20 bullets

• Large paragraphs

• Raw scanner output

• Tiny screenshots

on executive slides.

The presentation supports your communication.

It should not replace it.

64. Prepare for Questions

Executives may ask:

How serious is this?

Could this result in a breach?

Why has this not already been fixed?

How much will remediation cost?

What should we fix first?

Can we accept this risk?

Are we compliant?

Prepare answers based on evidence.

65. Do Not Guess

If asked something you cannot verify, say:

“That was outside the evidence available during this assessment. We would need to validate it before reaching a conclusion.”

This is better than inventing an answer.

66. Handle Technical Challenge

An engineer may challenge a finding.

Use:

Requirement
    ↓
Evidence
    ↓
Observation
    ↓
Threat Scenario
    ↓
Risk

Keep the discussion technical and evidence-based.

Avoid making it personal.

67. Handle Executive Challenge

An executive may say:

“We have never had an incident, so why is this High risk?”

Explain:

• Threat exposure

• Potential impact

• Existing controls

• Why absence of historical incidents does not necessarily mean low future risk

Keep the explanation concise.

68. Communicate Uncertainty

Use professional language such as:

Based on the evidence available during the assessment…

The assessment identified…

The current architecture increases the likelihood…

The available evidence did not demonstrate…

Avoid absolute claims unless evidence supports them.

69. Avoid Accusatory Language

Poor:

The cloud team failed to secure the environment.

Better:

Cloud security controls are not consistently enforced across the assessed environments.

Focus on the condition, not blame.

70. Avoid Consultant Ego

Do not write reports to demonstrate how technically sophisticated you are.

Write them so the client can act.

Complex language does not automatically equal expertise.

Clarity is a senior consulting skill.

71. Keep Terminology Consistent

Do not alternate randomly between:

Issue
Finding
Risk
Problem
Gap
Deficiency

Define your terminology and use it consistently.

For example:

Observation

What was identified.

Finding

A material control weakness.

Risk

Potential business consequence.

Recommendation

Required improvement.

72. Quality Assurance

Every client report should undergo QA.

Review:

Technical Accuracy
        ↓
Evidence Accuracy
        ↓
Risk Consistency
        ↓
Recommendation Quality
        ↓
Grammar
        ↓
Formatting
        ↓
Executive Readability

Senior consultants are often responsible for reviewing the work of others.

73. Technical QA Questions

Ask:

Is the observation factually correct?

Does the evidence support it?

Is the affected scope accurate?

Is the attack scenario technically plausible?

Are compensating controls considered?

Is the risk rating justified?

Does the recommendation address the risk?

74. Editorial QA Questions

Ask:

• Is the finding understandable?

• Are acronyms defined?

• Is terminology consistent?

• Are sentences unnecessarily complicated?

• Are there unsupported claims?

• Does the report repeat itself?

Technical accuracy does not compensate for poor writing.

75. Executive QA Questions

Ask:

If the CISO reads only the executive summary, will they understand the important risks?

Does leadership know what should happen next?

Are priorities clear?

Are required decisions obvious?

If not, improve the executive section.

76. Evidence Traceability

Maintain traceability between:

Evidence
   ↓
Observation
   ↓
Finding
   ↓
Risk
   ↓
Recommendation

Example:

EV-014
    ↓
IAM-03
    ↓
Privileged Access Risk
    ↓
Implement JIT Privilege

This helps during challenge and audit.

77. Report Review Workflow

A mature workflow may be:

Consultant Draft
       ↓
Peer Review
       ↓
Technical Lead Review
       ↓
Risk Review
       ↓
Client Validation
       ↓
Final QA
       ↓
Final Delivery

Not every engagement needs every stage, but important reports should not rely on one person’s review.

78. Final Report Delivery

Before delivery verify:

[ ] Correct client
[ ] Correct version
[ ] Correct classification
[ ] Correct scope
[ ] All findings validated
[ ] Risk ratings final
[ ] Sensitive data redacted
[ ] Recommendations reviewed
[ ] Executive summary updated
[ ] Roadmap included
[ ] QA completed
[ ] Distribution approved

Never rush final delivery without checking these basics.

79. Engagement Closeout

Reporting is usually followed by engagement closure.

Discuss:

• Final findings

• Open questions

• Remediation ownership

• Next actions

• Evidence handling

• Deliverable location

• Follow-up activities

The client should clearly understand what happens after the report.

80. Evidence Retention and Disposal

Follow contractual and organisational requirements.

After the engagement:

Evidence
   ↓
Retention Requirement
   ↓
Archive or Secure Disposal

Do not keep client security evidence indefinitely without a valid reason.

81. Reporting Common Mistakes

Avoid:

Scanner Dump

Copying automated findings directly into a report.

Screenshot Report

Using screenshots instead of analysis.

Excessive Technical Detail

Making executive sections unreadable.

Generic Recommendations

Writing “Improve security.”

Risk Inflation

Making everything High.

Unsupported Claims

Making conclusions without evidence.

Report Surprise

Presenting findings that technical owners have never seen.

Finding Overload

Reporting hundreds of minor observations without prioritisation.

82. Weak vs Strong Reporting

Weak

MFA is not enabled.

Strong

MFA is not consistently enforced for privileged cloud identities, increasing the likelihood that compromised credentials could provide unauthorised administrative access to production resources.

Recommendation:

Require phishing-resistant MFA for all privileged identities and centrally enforce the requirement through the enterprise identity platform.

The second provides context, risk, and action.

83. Practical Scenario — Build a Finding

You identify:

Five production administrators have permanent Global Administrator privileges.

Step 1 — Observation

Five operational identities retain permanent Global Administrator privileges within the production identity environment.

Step 2 — Risk

Compromise of any of these identities could provide extensive administrative control over enterprise identities and connected services.

Step 3 — Impact

Potential impact includes:

• Account takeover

• Privilege modification

• Security policy changes

• Persistence

• Access to connected services

Step 4 — Recommendation

Remove unnecessary standing Global Administrator assignments and introduce approved, time-bound privileged elevation protected by phishing-resistant MFA.

Step 5 — Priority

High

You now have a defensible finding.

84. Practical Scenario — Build a Risk Theme

Suppose your assessment finds:

Finding 01
Standing administrators

Finding 04
Weak MFA

Finding 07
Infrequent access reviews

Finding 11
Shared emergency accounts

Instead of presenting four unrelated findings, identify:

Privileged Access Governance

Then explain:

Privileged access controls are inconsistently implemented, increasing the likelihood and potential impact of administrative account compromise.

This becomes an executive-level theme.

85. Practical Scenario — Build the Roadmap

From the same findings:

0–30 Days

• Protect all privileged identities with strong MFA

• Remove unnecessary administrator access

30–90 Days

• Implement quarterly privileged access reviews

• Formalise emergency-access procedures

3–6 Months

• Introduce PAM and temporary privilege elevation

6–12 Months

• Implement continuous privileged-access governance

Now the assessment has become a transformation plan.

86. Practical Scenario — Executive Presentation

Your presentation might tell this story:

Current State

Rapid Cloud Growth
      ↓
Privilege Expanded
      ↓
Governance Remained Manual
      ↓
Identity Risk Increased

Then:

Recommended Direction

Central Identity Governance
      ↓
Strong Authentication
      ↓
Temporary Privilege
      ↓
Continuous Access Review

This is far more useful to leadership than showing dozens of IAM screenshots.

87. Build Your Client Reporting Toolkit

Add:

Client Reporting Toolkit
│
├── Security Assessment Report Template
├── Architecture Review Report Template
├── Cloud Security Report Template
├── Finding Template
├── Finding Register
├── Risk Rating Guide
├── Executive Summary Template
├── Positive Observation Template
├── Remediation Roadmap Template
├── Management Response Template
├── Report QA Checklist
├── Executive Presentation Template
└── Engagement Closeout Checklist

These templates will save significant time across future engagements.

88. Senior Consultant Reporting Questions

Before submitting a report, ask:

Accuracy

Can I defend every important statement?

Evidence

What evidence supports this finding?

Risk

Have I explained why the issue matters?

Scope

Am I making claims beyond what was assessed?

Recommendation

Can the client realistically implement this?

Priority

Does the client know what to fix first?

Executive Communication

Can leadership understand the security story?

Outcome

Does this report help the organisation make a better security decision?

89. Client Reporting Checklist

Use:

[ ] Engagement context documented
[ ] Objectives documented
[ ] Scope confirmed
[ ] Exclusions documented
[ ] Limitations documented
[ ] Methodology explained
[ ] Environment summarised
[ ] Positive observations included
[ ] Risk themes identified
[ ] Findings validated
[ ] Evidence traceable
[ ] Risk ratings consistent
[ ] Business impact explained
[ ] Recommendations actionable
[ ] Root causes considered
[ ] Quick wins identified
[ ] Strategic actions identified
[ ] Dependencies considered
[ ] Remediation roadmap developed
[ ] Executive summary completed
[ ] Technical QA completed
[ ] Editorial QA completed
[ ] Executive QA completed
[ ] Sensitive data redacted
[ ] Correct classification applied
[ ] Final presentation prepared
[ ] Client next steps defined

Key Takeaways

A Senior Security Consultant should be able to:

• Write for different audiences

• Structure professional security reports

• Document scope and limitations

• Build strong executive summaries

• Identify security themes

• Report positive observations

• Write clear and factual observations

• Separate observations from risks

• Explain business impact

• Assign defensible risk ratings

• Develop actionable recommendations

• Address systemic root causes

• Validate findings with technical owners

• Handle disagreement professionally

• Prioritise remediation

• Build short- and long-term roadmaps

• Create executive presentations

• Communicate attack paths visually

• Maintain evidence traceability

• Perform technical and editorial QA

• Protect sensitive client information

• Close engagements professionally

The core reporting workflow is:

Evidence
   ↓
Observation
   ↓
Validation
   ↓
Risk
   ↓
Finding
   ↓
Recommendation
   ↓
Risk Theme
   ↓
Roadmap
   ↓
Executive Message
   ↓
Client Decision

The value of consulting is not demonstrated by how many pages you produce.

It is demonstrated by whether the client can answer:

What is wrong?

Why does it matter?

What should we do?

What should we do first?

What’s Next?

➡️ 07 — Security Transformation

In the next module, you will move beyond identifying and reporting security weaknesses to helping organisations change their security environment at enterprise scale.

You will learn how Senior Security Consultants assess current-state maturity, define target-state security capabilities, perform gap analysis, establish transformation workstreams, develop multi-phase security roadmaps, prioritise initiatives, define governance and metrics, and help leadership move from assessment findings to a sustainable security programme.

The goal is to move from:

“Here are the security improvements you should make.”

to:

“Here is how we can systematically transform the organisation from its current security state to the required target state.”