Audit Report Structure and Communicating Findings

A complete security audit report contains six core sections. The order is fixed by convention for good reason: readers encounter context before detail, and the most important information appears first for those who will not read the full document.

The executive summary is written last, after all findings are graded and verified, but placed first in the final document. It should not exceed two pages. It names the audit period and scope in one sentence, describes the organisation's overall security posture in two or three sentences, lists the critical and high findings by title only, and states the most important action required. Anything that requires technical explanation belongs in the detailed findings section, not in the summary.

The scope and methodology section defines the boundaries of the audit: which systems, processes, facilities, or people were included; which were explicitly excluded and why; the dates of fieldwork; the frameworks or standards against which controls were assessed; and any constraints that limited testing, such as production system restrictions or unavailable personnel. A reader should be able to determine from this section alone whether a specific system or control domain was tested.

Each finding entry follows a fixed internal structure. The issue statement opens with a declarative sentence naming the control gap without hedging: 'Multi-factor authentication is not enforced on the organisation's VPN gateway' rather than 'It was noted that multi-factor authentication may not be in use.' The passive, hedged formulation obscures accountability and urgency.

The evidence section records the specific artefacts that prove the finding exists. Evidence must be specific and reproducible: a screenshot of the VPN configuration panel showing MFA disabled, a command output from the firewall CLI, a log extract showing successful logins without a second factor, or a configuration file excerpt. The evidence must be sufficient for an independent reviewer to verify the finding without repeating the test. Assertions without evidence are observations, not findings.

The recommendation must be specific and actionable. 'Improve security practices' is not a recommendation. 'Enable MFA on the Cisco AnyConnect VPN server by 30 August, requiring TOTP or hardware token as the second factor, and verify by re-testing login flows against the five accounts listed in Appendix C' is a recommendation. The recommendation should name the control, the method, and a suggested timeframe calibrated to the risk rating.

Some organisations include a references section within each finding that maps it to one or more framework controls: NIST CSF PR.AC-7, CIS Control 6.3, ISO 27001 Annex A 8.5, or PCI-DSS Requirement 8.4. See the topic on Mapping Controls Across Frameworks for how these cross-references are structured. Framework mapping helps remediation owners identify whether an existing control in another framework already covers the gap and also helps organisations show regulators the breadth of their compliance programme.

Risk ratings translate a technical finding into a priority for remediation. The standard method combines two dimensions: likelihood (how probable is it that this weakness will be exploited or will cause harm, given current controls and threat actor capability) and impact (how severe would the damage to confidentiality, integrity, or availability be if the finding were realised). Most frameworks use a matrix that places likelihood on one axis and impact on the other and reads the severity from the cell where they intersect.

A Critical finding requires immediate remediation, typically within 24 to 72 hours for a live production environment, because the combination of high exploitation probability and high damage potential means the risk is realised quickly and severely. A High finding requires remediation within 30 days in most frameworks. Medium findings are addressed within 90 days. Low and Informational findings are scheduled into the regular maintenance cycle.

The rating must be justified in the finding text. 'This finding is rated High because the misconfigured S3 bucket is internet-accessible (high likelihood of discovery by automated scanning tools) and contains personally identifiable information of 340,000 customers (high impact to confidentiality under GDPR Article 32 and the Digital Personal Data Protection Act 2023 Section 8)' is a justified rating. In EU or UK jurisdictions, a High or Critical rating on a data exposure finding may trigger mandatory breach notification obligations; the finding should note this explicitly. In US healthcare, a similar finding implicates HIPAA Security Rule 164.312. Audit reports that cross jurisdictions should identify which legal obligations attach to each finding.

The executive summary serves a different communication purpose from the detailed findings section. Board members and senior executives need to know three things: what is broken, what the business risk is, and what decision or investment is required from them. They do not need to know the technical mechanism of exploitation, the specific configuration parameter that is wrong, or the version number of the affected software.

Translating a technical finding into business language means expressing the impact in terms the reader already cares about: regulatory penalties, customer data loss, service downtime, reputational damage, or financial loss. 'The organisation's VPN does not require a second authentication factor. An attacker with a stolen password can log in with no additional barrier. This represents a realistic pathway to a ransomware incident that, based on sector averages, would cost between £200,000 and £1.2 million to recover from and would require notification to the Information Commissioner's Office under UK GDPR within 72 hours.' That framing is actionable for a board member.

The detailed findings section serves the remediation team. Technical readers need full reproduction steps, exact configuration values, affected hostnames or system identifiers, the specific version of software involved, and a sufficiently detailed recommendation to implement the fix without further consultation with the auditor. Vague recommendations generate follow-up questions and delay remediation. The cost of writing a precise recommendation once is far lower than the cost of a 30-minute follow-up call with five engineers three weeks later.

The management response section transforms the audit report from a one-way communication into a commitment document. For each finding, the audited organisation states one of three positions: accept the recommendation (and commit to implementing it), reject the recommendation (and explain why the risk is accepted or mitigated by a compensating control not observed during the audit), or accept with modification (implement a different control that addresses the same risk). Each response must name a remediation owner by role, not by personal name, which avoids the need to update the report when personnel change, and a target remediation date.

A risk acceptance is a legitimate response to a finding. An organisation may determine that the cost of remediation exceeds the probable loss from the risk, or that compensating controls reduce the residual risk to an acceptable level. Risk acceptances must be formally authorised by a named senior executive or the risk committee, documented in the report, and recorded in the organisation's risk register. See the topic on Risk Treatment and the Risk Register for how accepted risks are managed over time.

The management response section provides the audit committee with the data it needs to track remediation. After the report is issued, the audit committee or internal audit function should schedule a follow-up review at 30, 60, or 90 days, depending on the risk levels present, to verify that committed remediation actions have been completed. Findings closed without verification are a common weakness in internal audit programmes and a finding in their own right when an external auditor reviews the internal audit function.

Different audit frameworks use different report vocabulary, but the underlying structure is consistent. ISO 27001 certification audits use the language of nonconformities: a major nonconformity is a systematic or severe control failure that must be closed before certification is granted or maintained; a minor nonconformity is an isolated gap that can be addressed within an agreed timeframe after certification. The certification body issues a nonconformity report rather than a findings report, but each nonconformity entry contains the same components: statement of the issue, the clause of the standard not met, the evidence, and the required corrective action.

SOC 2 Type II reports, issued by US-based CPA firms under the AICPA Trust Services Criteria, take a different form. The report contains an opinion paragraph from the CPA firm, a description of the service organisation's system and controls, and, where testing found a failure, a description of exception items. The language is more formal and the structure is dictated by AICPA AT-C Section 320. The report is typically shared under NDA with the service organisation's enterprise customers as evidence of controls, rather than submitted to a regulator.

Regulatory audits, such as those conducted by data protection authorities under GDPR in the EU, the Information Commissioner's Office in the UK, or by the supervisory structure under the Digital Personal Data Protection Act 2023 in India, may use their own report templates and may not share the full report with the audited organisation, depending on the jurisdiction. For HIPAA-covered entities and business associates in the US, audit findings from HHS Office for Civil Rights investigations are recorded in a resolution agreement or corrective action plan that is publicly accessible. Auditors working across jurisdictions should know which report format applies to each regime and what disclosure obligations attach to it.