Who is accountable when DORA cryptography evidence is missing or incomplete?

Why This Matters for Security Teams

When cryptography evidence is missing or incomplete under DORA, the issue is not limited to a paperwork gap. It becomes a governance failure because the management body is expected to approve, oversee, and evidence ICT risk controls. That includes the cryptographic baseline, key management decisions, assurance from third parties, and the records that prove those controls exist and operate as intended.

This matters because evidence gaps often mask deeper control weakness: unclear ownership, fragmented vendor attestations, weak inventory discipline, or undocumented exceptions. NHI-heavy environments are especially exposed, since secrets and service identities are easy to lose track of. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives notes that 68% of organisations do not know how to fully address NHI risks, which is why evidence quality often lags control design.

In practice, many security teams discover missing cryptography evidence only after audit requests, supervisory scrutiny, or a vendor incident has already forced the question.

How It Works in Practice

Accountability under DORA follows the governance chain, not the ticket queue. Operations teams may collect logs, register keys, or maintain evidence packs, but senior leadership remains responsible for ensuring the control framework is complete and defensible. That means the organisation should be able to show what cryptographic assets exist, where they are used, who approves them, how keys are generated and rotated, and what assurance exists for outsourced components.

Practically, this is best handled as an evidence lifecycle. Map each cryptographic control to an owner, a source of truth, and a retention rule. Tie key inventory to asset inventory, and tie third-party attestations to contract and review cycles. Use control language from NIST SP 800-53 Rev 5 Security and Privacy Controls to structure evidence for access control, key management, audit logging, and system integrity, even when DORA is the legal driver.

• Assign a named accountable executive for cryptography governance and evidence completeness.
• Maintain an inventory of keys, certificates, algorithms, and systems using them.
• Document key lifecycle events, including creation, rotation, revocation, and escrow where applicable.
• Collect third-party assurance, but verify it against internal control objectives.
• Track exceptions with expiry dates, compensating controls, and board visibility.

For organisations with large NHI estates, evidence discipline must also cover API keys, service account credentials, and automation tokens. NHIMG research on the Ultimate Guide to NHIs shows 79% of organisations have experienced secrets leaks, which is a strong signal that control evidence and actual control hygiene are often misaligned. These controls tend to break down when cryptographic services are spread across cloud, SaaS, and legacy systems because ownership and proof artifacts become inconsistent across platforms.

Common Variations and Edge Cases

Tighter cryptography governance often increases reporting and evidence overhead, so organisations must balance auditability against operational speed. That tradeoff is manageable when evidence collection is automated, but it becomes harder when controls are distributed across business units, managed service providers, and cloud-native platforms.

There is no universal standard for exactly which cryptography artifacts must be packaged for every DORA review, so current guidance suggests building an evidence model that is risk-based, repeatable, and board-readable. The strongest approach is to treat missing evidence as a control deficiency until it is remediated, not as a documentation inconvenience. If a vendor manages part of the stack, the organisation still retains accountability and should insist on contractually defined assurance, not informal reassurance.

This is especially important where secrets are embedded in automation or CI/CD. NHIMG’s research on Hard-Coded Secrets in VSCode Extensions shows how easily credential evidence becomes detached from actual use. In those environments, incomplete records usually signal that the organisation cannot yet prove control effectiveness, even if the tools are present. If evidence depends on manual chasing across teams and suppliers, the model breaks down during incidents, not just during audits.

Related resources from NHI Mgmt Group

• Who is accountable when user access reviews are incomplete or not evidence-ready?
• Who is accountable when Microsoft 365 access reviews are not completed on time or evidence is missing?
• Who is accountable when an organisation issues an ID card using incomplete or unverified data?
• Who is accountable when records of processing activities become stale and incomplete?