Compliance evidence
Evidence an assessor can check, with its limits written on it
Export a control-tagged pack that says what the register proves for each control and what it does not. Built against ISO 27001 Annex A and Cyber Essentials, and useful for the Cyber Resilience Act and customer due diligence.
What the register evidences
These are the controls the pack is organised around today. The claim column is kept narrow on purpose: it covers what the data supports, not everything the control asks for.
| Control | What the register holds |
|---|---|
| ISO 27001 A.5.9 Inventory of assets | Every device and every software component, with owner, classification and lifecycle state, reconstructable for any past date. |
| A.5.11 Return of assets | What each custodian still holds, including kit in repair or recorded lost, and the record of its return. |
| A.5.12 Classification of information | A data classification per asset, and the corrections made to it with reasons. |
| A.5.19–A.5.23 Supplier relationships | Components by supplier and licence, with policy verdicts and attributable waivers. |
| A.8.1 User endpoint devices | Disk-encryption state per endpoint, counted over the endpoint population specifically, with "never recorded" reported as a gap and never as a pass or a failure. |
| A.8.8 Management of technical vulnerabilities | Findings per deployed release, the position taken on each, who approved it, and when a human was alerted. |
| A.8.15 Logging | Every change to the register in a hash-chained append-only log: what it was before, what it became, who made it, when, and the request it came in on. Verifiable end to end without taking our word for it. |
| Cyber Essentials CE.3 / CE.4 | How long known vulnerabilities have been outstanding on deployed releases, and every credential issued, its scopes, expiry, last use and revocation. |
What this contributes to each framework
No tool makes an organisation compliant with anything. What a register can do is answer a specific control with evidence somebody else can check. This is where that line falls.
| Framework | What the register contributes | What it does not |
|---|---|---|
| ISO/IEC 27001 Annex A | A control-tagged evidence pack covering the asset inventory controls, ownership, classification, return of assets, supplier records, endpoint encryption state, technical vulnerability management and logging. | Your ISMS, your risk treatment plan, or the certification itself. It answers the inventory half of an audit, not the management system around it. |
| Cyber Essentials | The device inventory, the encryption state per endpoint, and how long a known vulnerability has been outstanding on something you run. | Firewall, malware and access-control questions, which are not inventory facts and are not recorded here. |
| EU Cyber Resilience Act | A retained SBOM per release for products with digital elements, and the vulnerability position taken on each component over the product's supported life. | Conformity assessment, CE marking, or your reporting obligations to authorities. |
| NIS 2 | Supply-chain security evidence: what your services are built from, which suppliers' components you depend on, and the record of how an exposure was handled. | Incident reporting timelines, governance and management accountability, which are organisational duties rather than register entries. |
| DORA | The ICT asset register and the third-party component dependency picture underneath a financial entity's critical services. | The register of information in its prescribed reporting format, contractual arrangements, or resilience testing. |
| SOC 2 | Population evidence for change management and vulnerability management criteria: what exists, what shipped, when, and who approved a position on a finding. | The audit itself, the other trust services criteria, and any opinion. There is no SOC 2 report template here. |
Where a framework is not listed, the honest answer is that nothing here is shaped for it. Nothing on this page asserts certification, accreditation or an assessor's opinion.
Three things that make it evidence, not a report
- The export is itself recorded. Every pack written is logged with the digest of the bytes produced. The document is not retained; the record of having released it is, so "which version did we send the auditor in March" is answerable.
- Counts state their population. Working set or whole record, endpoints or every asset — a figure whose population is unstated is a figure two readers will interpret differently, and one of them will be quoting it in an audit.
- Unknowns are labelled unknown. A release with no SBOM produces no findings and is reported as unknown, never clean. An encryption state nobody has checked is a gap, not a pass.
Compliance questions
Does this make us ISO 27001 certified?
No, and no tool can. Certification is an audit of your management system by an accredited body. What this does is hold the evidence several Annex A controls ask for, in a form an assessor can check, and state for each control what the register proves and what it does not.
What is in an evidence pack?
It is organised by control reference, not by feature. Each section states what the register evidences for that control, the limits of that claim, and the queries behind the figures. It exports as JSON for a pipeline, printable HTML, or a PDF to attach to an audit file, and every export is recorded in the audit log with the digest of the bytes produced.
Why does every control carry a caveat?
Because a pack that claims more than it can support is worse than no pack: the assessor finds the gap before you do. Putting the limit next to the claim is how the document survives an adversarial read, and it is also how an honest reviewer decides what other evidence they still need.
Does it help with the EU Cyber Resilience Act?
It holds the parts the CRA asks a manufacturer to keep: a bill of materials for products with digital elements, a record of known vulnerabilities and the positions taken on them, and a durable trail of when each was learned and handled. It is not legal advice and does not assess conformity.
Can an auditor verify the record independently?
Yes, and that is the design. The audit log is hash-chained and the service publishes the exact fields each digest covers, plus the whole log in genesis order, so the chain can be recomputed outside the platform. Breaks are annotated, never repaired, because repairing one is the act the chain exists to detect.
Take a pack to your next audit
Pick the scheme, or the individual controls an assessor asked about, and export.