Doctrine entries in this series may include operational tests and controls. These are design requirements derived from first principles; references are illustrative, not determinative. They are not audit methods or compliance checklists. Confidence is high because claims are architectural and derived from first principles, not event reporting. References are included only as context. Failure modes described in this entry reflect general engineering and compliance patterns. They are not claims about any specific platform or organisation.
Summary
NIS2 Directive (EU) 2022/2555, Article 21(2), mandates security measures covering incident handling, business continuity (including backup management, disaster recovery, and crisis management), cryptography and encryption policy, and access control. It does not define an evidence obligation.
DORA Regulation (EU) 2022/2554, Article 9, covers protection and prevention of ICT risks, including continuous monitoring and control and documented ICT security policies. DORA's use of the term authenticity in Article 9(2) and Article 9(4)(a) refers to a security property of data alongside integrity, confidentiality, and availability. It is not a specification for independently verifiable provenance or external time attestation.
A system that satisfies both directives in full can still retain records that are mutable, unattested, and indefensible under adversarial scrutiny.
The gap between security obligation and evidence obligation is structural. It is not addressable by increasing security control coverage alone.
Compliance programs that map security controls to evidence requirements without accounting for this gap carry unresolved evidence debt (as defined in the companion entry on structural accumulation of evidence debt).
Definition
Security obligation (as used in this entry): A regulatory or policy requirement to implement controls that protect systems, data, and operations from unauthorised access, disruption, or compromise. Defined by frameworks such as NIS2 and DORA. Does not, by itself, require that retained records be independently verifiable as to content, provenance, or time of creation.
Evidence obligation (as used in this entry): A requirement that retained records be independently verifiable as to content integrity, provenance, and time of creation, under adversarial scrutiny by an external party. Not defined as a discrete obligation in NIS2 Article 21 or DORA Article 9. Arises from the evidentiary demands of audits, disputes, regulatory inquiries, and legal proceedings.
The integrity gap (as used in this entry): The structural space between what security obligations require and what evidence obligations require. A system operating fully within its security obligations may carry full evidence debt. The gap is not a deficiency in the security frameworks. It is a property of what those frameworks are designed to address.
Boundary
Security obligations address protection of systems and data. Evidence obligations address provability of records. These are distinct requirements. Satisfying the first does not satisfy the second.
Mechanism
What NIS2 Article 21(2) requires
NIS2 Directive (EU) 2022/2555, Article 21(2), requires essential and important entities to implement measures based on an all-hazards approach that shall include at least the following:
- (a) Policies on risk analysis and information system security.
- (b) Incident handling.
- (c) Business continuity, such as backup management and disaster recovery, and crisis management.
- (d) Supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.
- (e) Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.
- (f) Policies and procedures to assess the effectiveness of cybersecurity risk-management measures.
- (g) Basic cyber hygiene practices and cybersecurity training.
- (h) Policies and procedures regarding the use of cryptography and, where appropriate, encryption.
- (i) Human resources security, access control policies and asset management.
- (j) The use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate.
NIS2 Article 21(2) does not specify controls that make records independently provable as to content integrity, time of creation, provenance, or chain of custody.
What DORA Article 9 requires
DORA Regulation (EU) 2022/2554, Article 9, requires financial entities to implement ICT security policies covering:
- Protection and prevention of ICT risks (Article 9(1)).
- Design, procurement, and implementation of ICT security policies, procedures, protocols and tools that aim to ensure resilience, continuity, and availability of ICT systems, and to maintain high standards of availability, authenticity, integrity and confidentiality of data, whether at rest, in use or in transit (Article 9(2)).
- Continuous monitoring and control of ICT security and functioning (Article 9(1)).
- Documented ICT change management controls, including that all changes are recorded (Article 9(4)(e)).
- Development and documentation of an information security policy defining rules to protect the availability, authenticity, integrity and confidentiality of data, information assets and ICT assets (Article 9(4)(a)).
DORA's use of authenticity in Article 9(2) and Article 9(4)(a) refers to a security property of data alongside integrity, confidentiality, and availability. It is not a specification for independently verifiable provenance or external time attestation of individual records under adversarial scrutiny.
DORA Article 9 does not specify controls that make records independently provable as to content integrity at point of creation, external time attestation, or verifiable chain of custody.
Where the gap opens
Security Obligation Satisfied
(NIS2 Article 21(2) / DORA Article 9)
|
v
System is protected.
Incidents are handled.
Access is controlled.
Changes are recorded.
Cryptography is used for protection.
|
v
Evidence Obligation Arises
(audit / dispute / regulatory inquiry / legal proceeding)
|
v
External party demands:
- Prove this record is unmodified.
- Prove when it was created.
- Prove who created it.
- Prove the chain of custody.
|
v
NIS2 Article 21(2) and DORA Article 9 do not specify
controls that make those demands independently provable
(per-record integrity binding, external time attestation,
custody proofs).
|
v
If evidence controls are absent: evidence debt is due.
Why the gap is structural
Security frameworks are designed to reduce risk of compromise, disruption, and unauthorised access. They are not designed to produce independently verifiable records. The requirements are different. The controls are different. A log written to a secure, access-controlled, encrypted store can satisfy security obligations. The same log, written without a cryptographic integrity binding and without external time attestation, does not satisfy evidence obligations.
Some security controls, such as access control and change recording, can partially support later evidence arguments. They do not substitute for per-record integrity binding, external time attestation, and chain of custody documentation.
Failure Modes
Failure Mode 1: Security Compliance Treated as Evidence Compliance. A compliance program maps NIS2 Article 21(2) and DORA Article 9 controls to its records management program. The program documents security coverage. It does not document evidence integrity controls. Under adversarial scrutiny, the program can demonstrate security compliance. It cannot demonstrate that its records are independently verifiable.
Failure Mode 2: Encrypted Log Treated as Evidence-Grade Record. A log record is written to an encrypted, access-controlled store. Encryption satisfies confidentiality requirements under applicable security obligations. The log carries no cryptographic integrity binding and no external time attestation. Encryption confirms that access was controlled. It does not confirm that the record is unmodified or correctly timestamped. These are independent properties.
Failure Mode 3: Incident Record Without Provenance. An ICT incident record is created within an ICT risk management and monitoring environment. The record is written without provenance binding. Under subsequent scrutiny, the record holder cannot demonstrate that the record accurately attributes the event to the correct system, user, or process. The security obligation is addressed. The evidence obligation is not.
Failure Mode 4: Monitoring Data Without Integrity Binding. Monitoring and telemetry data is collected under DORA Article 9 continuous monitoring and control requirements, and under organisational security monitoring practices aligned to NIS2 risk management. The data is stored in a centralised system. The system does not apply cryptographic hashes at point of write. The monitoring data is available and accessible. Under adversarial scrutiny, the record holder cannot demonstrate that the monitoring data has not been modified since collection.
Failure Mode 5: Cryptography Used for Protection, Not Provenance. NIS2 Article 21(2)(h) requires policies and procedures regarding the use of cryptography and, where appropriate, encryption. Cryptography is deployed for data protection: encryption at rest, encryption in transit, key management. No cryptographic binding is applied to individual records at point of creation for evidentiary purposes. Cryptography addresses the security obligation. It does not address the evidence obligation.
Failure Mode 6: Gap Unrecognised in Audit Preparation. An organisation prepares for a regulatory audit by documenting its NIS2 and DORA compliance posture. The audit preparation covers security controls in full. Evidence integrity controls are not documented because they are not explicitly required by the applicable security obligations. The audit reveals records that cannot be independently verified. The compliance program had no mechanism to detect this gap before audit.
Operational Tests
The following tests allow a practitioner to identify the integrity gap in a given compliance program. Pass conditions are internal engineering gates, not regulatory requirements.
Test 1: Security vs. Evidence Control Mapping. Review the compliance program documentation. Identify all controls mapped to NIS2 Article 21(2) and DORA Article 9. For each control, determine whether it addresses security protection, evidence integrity, or both. Pass condition: at least one documented control addresses each of the following independently: cryptographic integrity binding at point of record creation, external time attestation, provenance binding, and chain of custody documentation. A program with no controls in the evidence column has the integrity gap.
Test 2: Log Integrity Verification. Select ten log records from the incident management system. Verify that each carries a cryptographic hash computed at point of write and an external time attestation token. Pass condition: 100% of sampled records carry both. Records that address NIS2 and DORA requirements but carry no integrity binding or time attestation have the integrity gap.
Test 3: Encryption vs. Integrity Separation. Select records stored in an encrypted store. Verify independently: first, that the records are encrypted (security control); second, that the records carry cryptographic integrity bindings and external time attestation (evidence control). Pass condition: both properties are verified through separate, independent checks. Encryption without integrity binding addresses the security obligation and leaves the evidence obligation unaddressed.
Test 4: Provenance Binding Check. Select five incident records. For each, verify that provenance metadata is cryptographically linked to the record at point of creation. Verify the link. Pass condition: provenance is verifiable without reference to a separate, unlinked store. Records that address NIS2 incident handling requirements but carry no provenance binding have the integrity gap.
Test 5: Audit Preparation Gap Analysis. Review the most recent audit preparation documentation. Identify whether evidence integrity controls (cryptographic binding, time attestation, provenance, chain of custody) are documented as a distinct control category from security controls. Pass condition: evidence integrity controls are documented independently of security controls. A program that documents only security controls has not addressed the integrity gap.
Controls
A high-assurance compliance program addressing both security obligations and evidence obligations typically implements the following at minimum. These controls are architectural reference points derived from first principles. They are not a compliance guarantee and are not a prescriptive checklist.
Minimum viable set
- Security controls implemented per applicable obligations (NIS2, DORA, or equivalent).
- Evidence integrity controls implemented as a separate, independent layer: cryptographic hash at point of write, external time attestation, provenance binding, signed custody record per transfer.
- Both control layers documented independently in the compliance program.
- Gap assessment conducted to confirm neither layer is treated as a substitute for the other.
These four controls represent a minimal baseline. Everything below extends them.
Security Controls (per applicable obligations)
- Incident handling, business continuity, cryptography policy, access control, asset management, and vulnerability handling implemented per NIS2 Article 21(2) and DORA Article 9 as applicable.
- Cryptography deployed for data protection: encryption at rest, encryption in transit, key management.
- These controls address system and data protection. They do not address evidence integrity.
Evidence Integrity Controls (independent layer)
- Cryptographic hash computed over the full record payload at point of write. SHA-256 or stronger is a common operational choice in practice.
- External time attestation token issued at point of write, consistent with RFC 3161 timestamp token controls.
- RFC 5816 updates RFC 3161 by allowing ESSCertIDv2 so the TSA certificate identifier can be computed with hash algorithms other than SHA-1. Where a non-SHA-1 algorithm is used, SigningCertificateV2 must be used per RFC 5816. Separately, as an operational control choice, SHA-256 or stronger should be used for the messageImprint hash in timestamp tokens.
- Per RFC 3161 Section 4 (Security Considerations), item 3, tokens should be re-timestamped as TSA signing keys age. For long-retention records, a documented re-timestamping schedule is appropriate.
- Provenance metadata cryptographically linked to the record at creation.
- Signed custody record generated per inter-system transfer.
Gap Documentation Controls
- Compliance program documentation should explicitly distinguish security controls from evidence integrity controls.
- Mapping security controls to evidence requirements without accounting for the integrity gap should be treated as a documentation deficiency.
- Gap assessment should be conducted as part of audit preparation, not only in response to audit findings.
Monitoring and Log Integrity Controls
- Log and telemetry records treated as evidence-class should be written to an append-only or write-once store.
- Administrative write access to log stores should be access-controlled and itself logged.
- Log records treated as evidence-class should carry cryptographic integrity bindings in addition to any security controls applied to the logging system.
Architecture
Regulatory Obligation
|
v
Security Obligation Evidence Obligation
(NIS2 Art. 21(2) / (audit / dispute / inquiry)
DORA Art. 9)
| |
v v
Security Controls Applied Evidence Controls Applied
- Encryption - Hash at point of write
- Access control - External time attestation
- Incident handling - Provenance binding
- Change recording - Custody record
| |
v v
System Protected Record Provable
| |
v v
Security Audit Passed Adversarial Scrutiny Survived
| |
v v
Security Obligation Met Evidence Obligation Met or Not
Diagram reflects controls described in this entry. No new claims are introduced.
What This Is Not
This is not a critique of NIS2 or DORA. Both directives are cited for what they define. The integrity gap is not a deficiency in either framework. It is a property of what security frameworks are designed to address. Evidence obligations are a separate requirement class.
This is not a legal interpretation of NIS2 or DORA. No claim is made about the full scope, implementation requirements, or jurisdictional application of either directive. Whether specific controls satisfy specific obligations under either directive requires separate legal and compliance analysis by qualified counsel.
This is not a statement that security controls are unnecessary. Security controls are a necessary condition for any compliant system. The argument here is that they are not sufficient for evidence integrity. Both are required. Neither substitutes for the other.
This is not limited to financial services or EU-regulated entities. The gap between security obligation and evidence obligation exists in any regulated environment where records may be demanded as independently verifiable proof. NIS2 and DORA are cited as specific examples of security frameworks that illustrate the gap structurally.
This is not a prescriptive compliance checklist. Controls described represent a minimum architectural baseline. They are not a guarantee of legal sufficiency for any specific deployment or jurisdiction.