The Cyber Evidence Handbook: A Practitioner's Guide to Generating, Managing and Presenting Cybersecurity Evidence
Why Evidence Is the Real Compliance Problem
Every major cybersecurity regulation enacted in the last five years shares a structural requirement: demonstrable evidence of security capability. Not security itself — regulators cannot directly observe security — but artefacts that a competent third party can examine, test and evaluate.
The Cyber Resilience Act demands technical documentation. NIS2 demands risk management records. DORA demands tested resilience frameworks and third-party assessment evidence. The NCSC CAF demands demonstrated outcomes against fourteen principles. Procurement bodies in defence, healthcare and critical infrastructure demand supplier security dossiers before they will award a contract.
In every case the demand is the same: show us the evidence.
Yet despite evidence being the central currency of regulatory compliance, there is no single reference document that practitioners can consult to understand what evidence exists, how to generate it, how to evaluate its quality, how long it remains valid, and how to manage it across the lifecycle of a product or operational system. The Cyber Evidence Handbook fills that gap.
What Is Cybersecurity Evidence?
In the assurance context, cybersecurity evidence is any artefact that a manufacturer, operator or service provider relies upon to demonstrate that a security property has been achieved. It ranges from a penetration test report generated by a CREST-accredited firm to an automated SBOM vulnerability check run on a CI/CD pipeline. It includes threat models, ISO 27001 certificates, incident response records, configuration audit outputs, supplier security questionnaires and CRTF assessment conclusions.
Not all evidence is equal. The Handbook structures every evidence type against the Evidence Quality Framework (EQF), a four-level taxonomy that assigns evidential weight based on the independence and rigour of the generating process.
EQF-1 — Self-Attested. Evidence generated by the subject organisation using internal methods, without independent review. Internal audits, self-assessment questionnaires, automated scanning outputs. Accepted for lower-risk obligations and as supplementary evidence.
EQF-2 — Second-Party Reviewed. Evidence reviewed by a customer, partner or other external party with a direct commercial relationship. Accepted in some procurement contexts; generally insufficient as standalone regulatory evidence.
EQF-3 — Third-Party Assessed. Evidence generated by an independent party operating under a recognised scheme. CREST penetration test reports, ISO 27001 certification, Cyber Essentials Plus assessment. Accepted by most regulators as primary supporting evidence.
EQF-4 — Independently Validated. Evidence generated or validated by an accredited body operating under formal national or international accreditation. NCSC CRTF assessment conclusions, UKAS-accredited inspection reports, Common Criteria evaluation reports. Accepted by all UK and EU regulators as primary evidence.
The Eight Evidence Domains
The Handbook organises cybersecurity evidence into eight domains, covering every significant category of artefact required by CRA, NIS2, DORA, the PSTI Act, the NCSC CAF, IEC 62443 and major procurement frameworks.
Domain 1 — Vulnerability and Testing Evidence. Penetration test reports, automated vulnerability scanning outputs, static application security testing (SAST) results, dynamic testing and fuzzing outputs, hardware security evaluation reports. This is the most immediately recognisable evidence category and often the most critical for regulatory compliance. The Handbook covers generation methods, scheme requirements (CREST, NCSC CHECK, TIBER-EU), validity periods and the most common pitfalls — scope too narrow, methodology not documented, findings not tracked to closure.
Domain 2 — Software Composition and Supply Chain Evidence. Software Bills of Materials (SBOMs) in CycloneDX or SPDX format, NVD vulnerability monitoring records, secure development lifecycle documentation, supplier and component security evidence. CRA Article 13(3) makes machine-readable SBOM a mandatory requirement for products with digital elements. The Handbook covers automated generation tooling, the transitive dependency problem, and how to handle the common completeness failures that make SBOMs inadequate as standalone regulatory evidence.
Domain 3 — Architecture and Design Evidence. Threat models (STRIDE, PASTA, TARA), security architecture documentation, data flow diagrams annotated with trust boundaries, cryptographic implementation documentation. This domain provides the primary evidence for claims about attack surface minimisation, least privilege and secure by default — requirements that appear in CRA Annex I, IEC 62443-3-3 and NCSC CAF Principle B1.
Domain 4 — Operational Security Evidence. Security monitoring and logging records, patch management records, access control and identity management records, configuration management records. This is the evidence category that demonstrates security as an ongoing operational discipline rather than a point-in-time state — critical for NIS2's continuous risk management requirement and DORA's operational resilience framework.
Domain 5 — Governance and Management Evidence. ISO 27001 certification and Statement of Applicability, risk management records, security awareness and training records, supplier and third-party management records. The Handbook covers scope verification — why an ISO 27001 certificate scoped to head office operations does not satisfy NIS2 obligations for a cloud platform delivering regulated services — and the gap between documented policy and operational practice.
Domain 6 — Incident and Response Evidence. Incident response plan and testing records, incident notification records, vulnerability disclosure records. NIS2 Article 23 and DORA Article 19 impose mandatory incident reporting obligations with defined timescales. A well-managed vulnerability disclosure process — including a published VDP, acknowledgement records and CVE assignment history — is increasingly treated as a positive quality signal by both regulators and procurers.
Domain 7 — Certification and Accreditation Evidence. NCSC CRTF assessment conclusions, ISO 27001 certification, Cyber Essentials Plus, UKAS accreditation under ISO 17020, Common Criteria evaluation reports, IEC 62443 certification. This is the highest-EQF evidence category — formally issued credentials from recognised independent bodies that provide the most efficient regulatory currency.
Domain 8 — Business Continuity and Resilience Evidence. Business continuity plans and testing records, Recovery Time Objective evidence, disaster recovery test records. DORA Articles 11–13 mandate specific BCP testing requirements for financial entities, including tabletop exercises and documented RTO evidence. This domain has the most demanding testing evidence requirements of any framework.
Evidence Lifecycle Management
The most commonly overlooked dimension of cybersecurity evidence is lifecycle. Evidence artefacts are not static documents — they have validity periods, they become stale, and they require active management across the product and operational lifecycle.
A penetration test report conducted eighteen months ago does not demonstrate that a product is secure against attack techniques published since. An SBOM generated at product launch does not reflect component vulnerabilities discovered in the interim. A threat model that has not been updated since a new attack technique was published against the product's architecture may no longer support the claims it was generated to evidence.
The Handbook defines recommended validity periods and unscheduled review triggers for every major evidence type — from continuous SBOM monitoring to the twelve-month CE+ renewal cycle to the product-version-specific nature of CRTF assessment conclusions. It also covers chain of custody requirements, evidence storage and access controls, and the evidence management infrastructure needed to support rapid assembly of regulatory and procurement packages.
The Multi-Audience Evidence Problem
One of the most practically significant insights in the Handbook is the extent to which regulatory evidence requirements overlap. An organisation that invests in a well-structured threat model will find that single artefact relevant to CRA Annex I §1, NIS2 Article 21(2)(a), DORA Article 6, CAF IGPs A1 and A2, IEC 62443-3-2 §4.3, and ISO 27001 clause 6.1.2 simultaneously.
This overlap is not accidental. The regulatory instruments that have emerged since 2020 were designed with awareness of one another. Organisations that design their evidence programme to exploit this overlap — generating evidence at the right EQF level, structured for reuse across multiple audiences — consistently achieve 40 to 60 per cent reduction in total assessment effort compared with those who assemble bespoke evidence packages for each regulatory or commercial audience in isolation.
The Handbook provides a master regulatory cross-reference matrix mapping fifteen evidence types to seven regulatory frameworks, enabling practitioners to identify exactly which evidence satisfies which obligations and to prioritise evidence generation accordingly.
Key Takeaways
Cybersecurity evidence is the primary currency of regulatory compliance. Regulators assess evidence of security, not security itself.
The Handbook covers eight evidence domains spanning the full range of artefacts required by CRA, NIS2, DORA, PSTI Act, CAF, IEC 62443 and major procurement frameworks.
Every evidence artefact should be assigned an EQF level at generation — from EQF-1 (self-attested) to EQF-4 (independently validated) — determining its regulatory acceptance weight and the claims it can support.
Evidence lifecycle management is as important as evidence generation. Defined validity periods, unscheduled review triggers and refresh processes are essential to maintaining currency.
The regulatory frameworks share substantial evidence requirements. Well-structured evidence generated for one purpose routinely satisfies requirements across multiple frameworks simultaneously.
Chain of custody and provenance documentation is not bureaucratic overhead — it is the mechanism by which evidence survives adversarial scrutiny under regulatory or legal challenge.
NCSC CRTF assessment and UKAS-accredited inspection provide EQF-4 validation, the highest level of independent assurance available in the UK context.
Download the Full Handbook
The full Cyber Evidence Handbook includes complete guidance for all eight evidence domains; generation methods, EQF levels and validity periods for every major evidence type; the master regulatory cross-reference matrix; a Master Evidence Register template with fourteen field definitions; a regulatory cross-reference appendix; and a complete evidence generation programme checklist.
Free to download. No registration required.