A record that cannot survive adversarial interrogation is not an evidence record. It is a candidate record with unresolved verification cost. DORA Regulation (EU) 2022/2554, Article 17, establishes an ICT incident record-keeping obligation for covered entities. This entry describes engineering properties that can reduce dispute cost under audit scrutiny; it does not claim legal sufficiency.
NIST SP 800-92 discusses log integrity and time-source reliability as recurring engineering challenges. In adversarial settings, mutable logs and unattested timestamps are difficult to defend and increase verification cost. Adversarial defensibility is largely determined at point of creation. Later remediation is limited and typically leaves residual doubt and higher verification cost. When evidence debt accumulates silently, adversarial defensibility tends to degrade over time.
Definition
Adversarial interrogation (formal): A structured challenge to the authenticity, integrity, provenance, or timing of a record, conducted by a party whose interests may be opposed to those of the record holder. Includes regulatory inquiries, legal proceedings, counterparty disputes, and forensic investigations.
Adversarial defensibility (formal): The property of a record whereby it can withstand adversarial interrogation without reliance on the record holder's assertions. Defensibility is a function of cryptographic integrity binding, independent time attestation, verifiable provenance, and unbroken chain of custody.
Interrogation burden (formal): The shift in evidentiary obligation that occurs when an external party demands proof of a record's authenticity, integrity, or timing. At this point the obligation moves from "we have the record" to "we can prove the record is what we say it is."
Boundary
Adversarial defensibility is not about whether a record is truthful. It is about whether its truthfulness can be proven independently, without reliance on the assertions of the party that created or holds it.
Mechanism
How interrogation burden shifts:
Under normal operations, records serve operational functions. Their integrity is assumed. The burden of proof does not arise.
Interrogation burden shifts at a defined trigger point:
Normal Operations
|
v
Trigger Event
(audit / dispute / regulatory inquiry / incident investigation)
|
v
Interrogation Burden Shifts
|
v
"Prove the record" replaces "produce the record"
|
v
Defensibility is largely determined at point of creation.
Post-event remediation can add new attestations, but it
cannot reliably recreate original creation conditions.
Trigger events include: regulatory inquiry related to ICT incident record-keeping under DORA Article 17, legal proceedings in which a counterparty challenges the authenticity or timing of a record, forensic investigations in which an independent party must verify the integrity of a log or transaction record, and internal audit challenges in which a record's provenance or completeness is questioned.
What makes a record defensible: Content is cryptographically bound at point of creation — any modification is detectable. Time of creation is attested by an external, independent timestamp authority — internal clock values alone are not sufficient. Provenance is recorded and itself integrity-protected — the creator, system, and context are verifiable. Chain of custody is unbroken and documented from point of creation to point of production.
What makes a record indefensible: Content is stored without cryptographic binding — modification is undetectable. Timestamp is sourced from a system clock without external attestation — time of creation is an assertion, not a proof. Provenance metadata is stored separately and not integrity-linked to the record. Custody transfers are undocumented — gaps exist between creation and production.
Failure Modes
Failure Mode 1: Possession Without Proof. A record exists and is produced in response to an interrogation demand. The record holder cannot demonstrate that the record is unmodified, correctly timestamped, or properly attributed. Possession satisfies the production obligation. It does not satisfy the proof obligation.
Failure Mode 2: Timestamp Assertion Without Attestation. A record carries a creation timestamp sourced from a system clock. Under interrogation, the record holder cannot demonstrate that the clock was accurate or unmanipulated at the time of creation. NIST SP 800-92 discusses time-source reliability as a documented integrity challenge. An unattested timestamp is an assertion, not evidence.
Failure Mode 3: Mutable Log as Evidence. A log record is produced as evidence of an ICT-related incident. The log is stored in a mutable store with write access available to administrators. Under interrogation, the record holder cannot demonstrate that the log has not been modified since creation. NIST SP 800-92 discusses the risk of log alteration and the need to protect logs from modification and deletion. A mutable log is difficult to defend under adversarial interrogation and commonly becomes a focal point of challenge.
Failure Mode 4: Provenance Assertion Without Binding. A record is attributed to a specific system, user, or process. The provenance metadata is stored in a separate table or service, not cryptographically linked to the record. Under interrogation, the record holder cannot demonstrate that the attribution has not been altered. The record's provenance is an assertion, not a proof.
Failure Mode 5: Custody Gap at Transfer. A record is transferred between systems, vendors, or jurisdictions without a signed, timestamped custody record. Under interrogation, a gap exists in the chain of custody. An adversary can exploit this gap to challenge the authenticity of the record at the point of transfer.
Failure Mode 6: Retrospective Remediation Attempt. Following a trigger event, a record holder attempts to re-attest, re-sign, or reconstruct provenance for records that were not integrity-bound at creation. Re-attestation can document that a re-signing event occurred. It cannot reliably recreate the original creation conditions. The interrogation burden is not satisfied by retrospective remediation.
Failure Mode 7: Selective Completeness. A record set is produced in response to an interrogation demand. A subset of records is missing due to retention policy gaps, pipeline failures, or partial migrations. The gap is exposed by an external reference such as a counterparty log, network capture, or third-party audit trail. The incomplete record set undermines the defensibility of the records that do exist. This is a general failure mode across the industry, not a claim about any specific platform.
Operational Tests
The following tests allow a practitioner to validate or falsify the adversarial defensibility of a given record set. Pass conditions are internal engineering gates, not regulatory requirements.
Test 1 — Interrogation Simulation. Select a bounded record set from production, for example all ICT incident records from a defined 30-day window. Treat the set as if it were subject to an external regulatory demand. Attempt to independently verify: content integrity, time of creation, provenance, and chain of custody for each record. Pass condition: all four properties are independently verifiable without reliance on the record holder's assertions. Any gap is a failure.
Test 2 — Timestamp Attestation Check. Select ten records from the set. Verify that each carries an external timestamp token issued by a TSA independent of the writing system. Pass condition: 100% of sampled records carry a verifiable external timestamp token. Unattested timestamps are a failure.
Test 3 — Log Immutability Verification. Identify the store in which the relevant log records are held. Verify that the store is append-only or write-once and that administrative write access is access-controlled and itself logged. Pass condition: no write access path exists that does not generate an audit event. Mutable store without audit trail is a failure.
Test 4 — Provenance Link Verification. Select five records. For each, verify that provenance metadata is either co-located with the record or cryptographically linked to it. Verify the link. Pass condition: provenance is verifiable without reference to a separate, unlinked store.
Test 5 — Custody Chain Trace. Select a record that has undergone at least one transfer between systems or custodians. Trace its custody documentation from creation to current location. Pass condition: unbroken, signed, timestamped custody record exists for every transfer. Any undocumented transfer is a failure.
Test 6 — Gap Detection. Identify a bounded event window. Cross-reference the count and identifiers of internal records against an external reference such as counterparty confirmations, network logs, or external API call logs. Pass condition: no unexplained gaps. Any gap unexplained by documented retention policy is a failure.
Controls
A high-assurance evidence system subject to adversarial interrogation 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:
- Content hash at point of write, bound to full record payload.
- External time attestation token stored with the record, e.g., per RFC 3161 timestamp tokens.
- Provenance binding, cryptographically linked to the record at creation.
- Signed custody record per transfer event.
These four controls represent the floor. Everything below extends them.
Integrity Controls. Cryptographic hash computed over the full record payload at point of write. SHA-256 is a common baseline. Hash stored immutably alongside the record. Any pipeline that transforms records should produce a transformation record: input hash, output hash, transformation type, timestamp, signing key.
Time Attestation Controls.
Clock synchronization (operational hygiene, not evidentiary proof): System clocks should be synchronized to an authenticated external time source. Clock synchronization confirms that a system believed the time to be X. It does not produce an independently verifiable proof. It should not be treated as a substitute for external attestation.
External time attestation (evidentiary anchoring): Evidence-class records often carry a timestamp token issued by an external TSA independent of the writing system. One common approach is RFC 3161. In implementations that use RFC 3161, practitioners typically verify that SHA-256-class bindings are supported for the message imprint and that RFC 5816-era ESSCertIDv2 / SigningCertificateV2 behavior is handled where applicable. Equivalent mechanisms may apply depending on jurisdictional or operational context. The timestamp token should be stored with the record and be independently verifiable against the issuing authority's certificate chain. Where the operational assurance of the timestamp service is a requirement, the TSP should operate under ETSI EN 319 421 or an equivalent documented policy framework.
Provenance Controls. Provenance metadata should be co-located with the record or cryptographically linked to it. Writing system identity should be included in provenance: hostname, process ID, service version, signing key identifier.
Log Integrity Controls. NIST SP 800-92 discusses the risk of log alteration and the need to protect logs from modification and deletion. Append-only or write-once storage is one implementation pattern that reduces alteration risk. Administrative write access to log stores should be access-controlled and itself logged. Log aggregation pipelines should not overwrite or strip source timestamps or identifiers.
Custody Controls. Every inter-system transfer should generate a signed, timestamped custody record naming source, destination, transfer method, and hash of transferred content. Backup restoration procedures should include a post-restoration integrity verification step with results logged.
Retention and Completeness Controls. Retention schedules should be documented per record class. Deletion events should be logged with record identifier, hash, deletion timestamp, and authorizing identity. Gap detection tooling should run on a defined schedule and produce a verifiable completeness report.
ICT Event Occurs
|
v
Record Created
|
v
Hash(payload) ---------> External TSA
| |
| Signs: Hash + Time
| |
| Timestamp Token
| v
Provenance Binding <--- Stored with record
|
v
Append-Only / Write-Once Store
|
v
Transfer Event
|
v
Signed Custody Record Generated
|
v
Interrogation Demand
|
v
Independent Verification (no reliance on record holder assertions)
|
v
Defensible / Not Defensible
Diagram reflects controls described in this entry. No new claims are introduced.
What This Is Not
This is not a legal compliance framework. DORA Article 17 is cited as a regulatory instrument that establishes an ICT incident record-keeping obligation. No claim is made that the controls described here satisfy DORA or any other regulatory obligation in full. Legal sufficiency requires separate analysis by qualified counsel.
This is not a log management policy. NIST SP 800-92 is cited for its treatment of log integrity and time-source reliability as engineering challenges. Full log management scope is broader and is covered separately in SP 800-92.
This is not a post-incident remediation guide. Records that were not integrity-bound at creation are generally not restorable to their original provable state. Re-attestation can reduce future verification cost but cannot reliably recreate original creation conditions.
This is not an encryption or confidentiality framework. Encryption addresses access control. Adversarial defensibility addresses verifiability. An encrypted record with no integrity binding is a confidential record with no defensibility.
This is not limited to financial services. The interrogation burden shift and the failure modes described apply to any regulated or litigated environment in which records may be demanded as proof by an opposing party.
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.