A defensible assessment begins before testing. The planning and reporting guidance in NIST SP 800-115. provides a useful basis for agreeing objectives, controlling execution and documenting results. Regulator-ready means organised for scrutiny, not regulator-approved. No report can guarantee security or compliance.
Use the report to connect technical evidence with accountable action. The supporting disciplines are OWASP WSTG, ASVS 5.0, MASVS and CVSS v4.0 . Select the relevant standards, pin their versions and state which requirements were examined. Web, API, mobile and infrastructure assessments need different coverage. A named framework does not prove that every control was tested.
Why a scan export rarely answers an auditor
A scanner identifies potential weaknesses. It does not by itself establish business impact, authorised coverage or whether a result is reproducible. A report should distinguish automated observations from manually validated findings and explain what remained untested.
For Nigerian DMBs and PSBs, the CBN Risk-Based Cybersecurity Framework 2024, issued on 31 May 2024, addresses risk and vulnerability management alongside governance, resilience and monitoring. Its scope is DMBs and Payment Service Banks, not every payment provider. Confirm licence-specific obligations before presenting a report as compliance evidence.
Four questions should be answered without guesswork:
- The authority is clear: who approved testing, on which systems and under which conditions.
- The scope is bounded: assets, exclusions, credentials and test dates are recorded.
- The finding is reproducible: a reviewer can follow safe steps to the supporting evidence.
- The next action is owned: an accountable team has a target date and a retest plan.
Five sections that turn findings into decisions
Each section answers a different reviewer question. Keep the executive summary readable without removing the technical detail engineers need.
1. Executive summary: what needs attention?
State the assessment objective, tested environment and main risk themes. Explain what a weakness could mean for payment approval, patient records or privileged access. Identify urgent decisions without turning a severity count into a claim about overall security.
2. Scope and authority: what was permitted?
Record written authorisation, asset identifiers, exclusions, credentials, testing windows and third-party permissions. Include incident contacts, stop conditions and evidence-handling rules. Social engineering and denial-of-service require separate explicit permission.
3. Method and coverage: what was actually tested?
Describe discovery, scanning, manual validation and any controlled exploitation. Map relevant checks to the agreed WSTG, ASVS or MASVS version. Distinguish attempted tests, completed tests and blocked checks; explain how access restrictions affected coverage.
4. Technical findings: can engineers reproduce them?
Give each finding a stable identifier, affected asset, preconditions, safe reproduction steps and redacted evidence. Separate observed behaviour from inferred impact. Record the CVSS v4.0 vector where used, then explain the business context rather than letting the score stand alone.
5. Remediation and retest: what closes the issue?
Recommend a practical fix, a responsible owner and a target date. Explain any interim control and residual risk. The retest should reference the original finding and identify the deployed change, environment and evidence supporting its final status.
Match the report to the assessment scope
Coverage should follow the contracted attack surface. These scopes need different evidence, not a recycled checklist.
- External infrastructure: public assets, exposed services, perimeter controls and tested entry points, with ownership confirmed.
- Internal infrastructure: segmentation, privilege boundaries and movement paths under the agreed credentials.
- Web and API testing: authentication, authorisation, session handling and business-logic checks.
- Mobile applications: platform-specific controls and relevant MASVS requirements, with versions pinned.
A combined engagement can cover several surfaces, but each needs its own asset list and limitations. A mobile assessment does not silently include every backend service; an external scan does not establish internal segmentation effectiveness.
The evidence rule: show only what was established
A finding becomes unreliable when its language goes beyond the evidence. Distinguish a confirmed unauthorised read from a theoretical route to a full database export. Record preconditions and constraints, including where safe-testing limits prevented further validation.
Apply these evidence-handling rules:
- Minimise sensitive data: capture enough to prove the issue without copying unnecessary records.
- Never expose working credentials: redact secrets, tokens and personal data in the distributed report.
- Keep evidence tied to the finding: use asset identifiers, timestamps and stable reference numbers.
- Control report access and retention: agree encryption, named recipients, storage and secure disposal.
Technical evidence may itself contain exploitable detail. Use an executive summary for wider circulation and restrict the technical annex. Agree the handover route before testing, not after sensitive screenshots have been collected.
From authorised testing to a traceable retest
Set the reporting and retest expectations in the statement of work. Timing depends on asset count, access, complexity and change windows; there is no credible universal promise that every engagement can finish within a week.
The engagement should describe its phases and decision gates. A useful reference is the Penetration Testing Execution Standard . It covers pre-engagement through reporting. Document changes to scope and permissions as they occur. If a third-party platform cannot be tested, record the exclusion and its implications rather than treating an untested dependency as safe.
After the initial report, let owners confirm assets and clarify evidence without quietly deleting uncomfortable findings. Record revisions, preserve finding identifiers and separate factual corrections from risk acceptance. The final version should have a clear issue date and distribution list.
For severity scoring, use the CVSS v4.0 specification . alongside business context. For application requirements, refer to OWASP ASVS 5.0 . Neither replaces a remediation decision. An exposed administrative path may need urgent attention because of its role in the business, even when a numerical score alone does not communicate that urgency. Related governance considerations appear in our guide to the CBN's automated AML standards.
Keep the retest separate from the original claim
A retest verifies an agreed fix against the original finding. It is not automatically a fresh assessment of the whole environment. Record the release, configuration and test date, and say when a change needs broader regression testing.
Use explicit retest outcomes that owners can act on:
- Fixed: the original steps no longer demonstrate the weakness in the tested environment.
- Partially fixed: the change addresses only part of the original issue.
- Not verified: access, deployment or evidence was insufficient to establish closure.
Evidence also has to support incident decisions. See our explanation of the NDPA breach-notification clock.
Checklist: is your VAPT report ready for review?
- Written permission, test windows and third-party consent are documented.
- Assets, exclusions, credentials and coverage limitations are explicit.
- Every validated finding has reproducible steps and redacted evidence.
- Severity is distinguished from business impact and remediation priority.
- Each action has an owner, target date and risk-acceptance route.
- Retest outcomes reference the original finding and tested change.
Use this checklist when commissioning VAPT & threat assessments, and align the evidence with the responsibilities described in Security & Governance. Scope and cost depend on assets, access and testing depth; agree them before work begins. Our VAPT & threat assessments service can be scoped around your systems, review needs and operating constraints. To discuss written authorisation, reporting requirements and a practical retest plan, talk to us.
