What a social engineering test report must contain

Why a social engineering report is not a technical finding list

A social engineering test report cannot be structured as a list of CVEs with CVSS scores. The finding is behavioural: a staff member was persuaded to open an attachment, hand over credentials or allow physical access. The question the report must answer is not which software is vulnerable, but which controls failed and under what conditions.

This distinction shapes every section of the document. Technical pentest reports read top to bottom: exploited service, root cause, patch. A social engineering report must show the scenario that was run, the response from each targeted population, and what the response means for the organisation's control posture. The scope agreed before a social engineering test defines the variables the report then measures against. If the scope specified phone pretexts and email, the report shows how each channel performed independently.

Readers arrive from three directions. Leadership wants a risk rating and a priority action list. The security or HR team wants to know which groups were targeted and what they did. An auditor wants evidence that the test was authorised, run within scope, and that findings have been assigned to owners. The article on scoping pretexts and channels covers how the scope document creates the baseline the report then measures against. One document must serve all three readers, which is why the structure described below separates the executive summary from the technical findings and from the evidence appendix.

What the executive summary must cover

The executive summary is one to two pages. It states the test's authorised scope, the period it ran, the number of attempts made and an overall susceptibility figure: the percentage of targeted individuals who completed the attacker's intended action. No target names appear here. Roles or departments are acceptable; individuals are not, because the purpose of the report is to improve controls, not to document who failed.

The summary must include a risk rating and the top two or three findings that drive it. Each finding names the channel, the scenario type and the outcome: a vishing call, an account verification pretext, a credential disclosure. These three facts give a summary reading its meaning without disclosing any individual's behaviour to everyone in the room.

The order of content in the summary matters. A reader who stops after the first page should still carry away the risk verdict and the priority actions. Everything that supports those belongs in the layers below, available to whoever needs the depth.

Documenting each attempt: the minimum record

Each attempt is documented in a consistent record. The minimum fields are: attempt identifier, date and time, channel, pretext used, targeting population (role or department, not individual name), outcome (no response, partial response or completed action), evidence reference and tester initials. Partial responses are recorded separately from completed ones. A user who typed credentials but abandoned the page before submitting is closer to a success than the aggregate numbers show, and the distinction matters for training design.

Pretexts fall into two broad categories: standard impersonations (IT helpdesk, parcel delivery, HR reset) and constructed scenarios built from open-source intelligence about the specific organisation. Record which applies. The OAuth device code phishing article illustrates how a constructed scenario targeting a specific workflow looks different from a generic credential harvesting page. That difference belongs in the finding record because it changes the remediation path: a generic pretext calls for general awareness training; a targeted one points toward an OSINT exposure problem that training alone cannot close.

The sequence below shows how a single attempt flows from execution to a documented record. The evidence capture step is the moment that matters. A screenshot taken at the moment of credential entry carries evidential weight; a tester's written reconstruction several days later does not.

Scoring and metrics: what to measure and how to present it

Scoring serves two purposes. First, it gives leadership a comparable figure across test cycles: a susceptibility rate this year against one from a previous cycle is a signal about whether controls are improving. Second, it lets the reporting team identify which variables drove the result, so remediation targets the right layer. An aggregate click rate across all channels and all pretexts in a single number is not useful: it blends very different populations and scenarios into a figure that cannot support a decision.

The breakdown should cover at least three dimensions: channel, pretext category and targeting population. Channel performance varies because of how staff in different workflows handle inbound contact. The article on detection evidence per channel covers what the monitoring side sees during a test, which complements the scoring picture. NIST SP 800-115 sets the standard for evidence quality in technical security testing; the same rigour applies here, meaning metrics must derive from recorded outcomes, not from recollection.

The table below shows the four reporting dimensions for the most common channels, the primary metric for each, the secondary metric and the typical remediation path each finding points toward. Presenting this structure in the report rather than a free-form narrative makes it easier for the fixing team to match findings to owners.

Remediation section: findings that have owners and dates

Remediation for social engineering findings falls into three categories: awareness training for populations that showed high susceptibility, process changes for scenarios that exploited procedural gaps, and technical controls for vectors that could be closed technically. These categories are not exclusive. An email phishing finding may need both a mail gateway change and training for the users who bypassed it.

Each finding should carry a remediation owner, a proposed action type, a target date and a verification method. Verification for social engineering findings is the retest: the same pretext, the same channel, the same targeting population, run after the control has been applied. An assumed breach exercise can then test whether a credential obtained through a successful phishing scenario would have been usable in a wider attack chain, linking the social engineering finding to the network exposure it represents. The report lifecycle closes when the retest result is documented alongside the original finding.

MITRE ATT&CK maps techniques to detection and mitigation entries. Where a finding maps to a known ATT&CK technique, citing that mapping in the remediation section gives the fixing team a starting point for coverage, particularly for the detection controls that sit alongside the awareness and process actions.

Evidence handling and what the report must not contain

The evidence appendix holds the proof: captured credential pages, recorded call segments where consent was obtained and recording was authorised, access control logs showing badge events, and any communication artefacts created during the test. What it does not hold is unredacted personal data about individuals. A report that names employees individually in the finding body, rather than by role or department, creates a document that cannot safely be distributed across a leadership group and that may conflict with applicable data protection obligations.

UAE data protection obligations apply to personal data collected during a test. The scope document should specify the retention period for recorded evidence and who holds it. Evidence relevant to a regulatory review must stay available for the agreed period. Evidence of individual behaviour that the regulator did not ask for should not remain in a document that circulates beyond the security function. The article on UAE regulations for social engineering testing covers which regulatory frameworks apply and what they require.

The guide to buying a social engineering test covers what authorisation documentation should be in place before the test begins, which also forms the basis for the authorisation statement in the report. Entities regulated by CBUAE should ensure that the report format satisfies the evidence requirements for any review under the CBUAE Information Assurance framework. Without that structure, a well-run test produces a document that cannot support the compliance review it was run to enable.

Social engineering test reports in the UAE regulatory context

Social engineering test reports carry additional weight in the UAE because of how the main regulatory frameworks approach human factors in security controls. CBUAE-regulated financial institutions in Dubai and Abu Dhabi are expected to demonstrate that staff awareness programmes are tested, documented and effective. A report that lacks attempt-level evidence and remediation tracking cannot satisfy that expectation, regardless of how well the test itself was run.

DESC-supervised entities in Dubai that supply to Dubai government entities face similar expectations under the Dubai Electronic Security Centre's control framework. The UAE Information Assurance Regulation, which applies federally to government entities and their suppliers, asks for evidence of human-layer controls as part of the broader security management posture.

ADHICS-regulated healthcare providers in Abu Dhabi face an additional consideration. Any test involving patient-facing or clinical staff should be authorised at the level ADHICS requires, and the report should document that authorisation statement explicitly. Without it, a healthcare organisation cannot demonstrate compliance even if the test found no significant susceptibility.

The practical effect in both emirates is that a report structured for internal team use is not the same as one that can be presented to an auditor. Format it for both from the start. The investment is in the structure, not in writing the same information twice, and the structure described in this article satisfies both purposes without additional work.

Frequently asked questions