What is the difference between DORA documentation and cloud configuration evidence?

DORA documentation describes the policies, governance, and obligations an organisation says it has in place. Cloud configuration evidence shows whether the technical controls actually exist in production. Both are necessary, but they answer different questions. Documentation supports accountability and process. Configuration evidence proves implementation for controls such as MFA, encryption, logging, backup, and exposure reduction.

Why Documentation and Configuration Evidence Answer Different Audit Questions

DORA documentation is the organisation’s statement of record: policies, procedures, governance decisions, and assigned obligations. Cloud configuration evidence is the operational proof that the environment actually reflects those statements, such as enforced MFA, encryption at rest, logging, backup, network exposure limits, and privileged access restrictions. The difference matters because audit confidence depends on both intent and implementation, not one or the other. A policy that exists only on paper can satisfy process expectations while leaving material control gaps in production.

For DORA-related assessments, reviewers are often looking for traceability from governance to technical enforcement. That means documentation should explain what the organisation requires, who owns it, and how exceptions are approved, while configuration evidence should show the current state of the cloud environment. The two artefacts are complementary, not interchangeable, and they can diverge when teams update policy faster than platforms, or when cloud changes occur without corresponding control review. EU Digital Operational Resilience Act (DORA) provides the regulatory context for operational resilience expectations. In practice, many teams discover the gap only when an auditor asks for live control proof rather than relying on the policy set.

How the Two Evidence Types Work Together in Practice

Think of DORA documentation as the control design layer and cloud configuration evidence as the control operation layer. Documentation should describe the intended safeguard, its scope, the accountable role, and any approved exception path. Configuration evidence should show the live settings or outputs that demonstrate the safeguard is active. For example, a document may require encryption for stored customer data, but the evidence that matters is the actual storage configuration and any corroborating monitoring or audit output.

This distinction becomes especially important when organisations rely on shared cloud responsibility. A policy may say backup is mandatory, but the cloud provider may only supply the mechanism while the tenant must enable and manage it. Similarly, a document may define logging requirements, but evidence must show that logs are enabled, retained, and accessible for review. The right test is whether a reviewer can follow the chain from policy to control owner to production state without guessing. Where possible, evidence should be time-bound and environment-specific, because screenshots and exported settings can age quickly and lose value if they are not tied to a change record or system inventory.

Use documentation to prove intent, governance, and accountability.
Use configuration evidence to prove the control exists in the live environment.
Cross-check both for drift, especially after platform changes or exception approvals.
Keep evidence linked to the exact cloud account, subscription, tenant, or workload in scope.

This guidance breaks down when organisations treat exports or screenshots as a substitute for verified, current system state.

Where the Boundary Gets Blurry

Tighter evidence standards often increase collection effort, requiring organisations to balance audit readiness against operational overhead.

Some controls sit between documentation and configuration, which is where teams often misclassify the evidence they have. A documented standard for MFA is not enough if it does not specify enforcement scope, conditional access rules, or break-glass handling. Likewise, a cloud console screenshot may show a control switched on, but not whether the setting applies to all relevant accounts, regions, or workloads. Guidance versus consensus matters here: there is broad agreement that policy and technical proof should align, but organisations differ on how much automated evidence they need versus manually collected artefacts.

The biggest edge case is exception handling. A policy can permit a temporary deviation, but the cloud state may still show the control missing or partially applied. In that situation, the documentation may be accurate while the environment is still non-compliant. Another common issue is inherited evidence from platform teams that does not prove tenant-level control by the regulated entity. For DORA purposes, the practical question is not whether a control exists somewhere in the stack, but whether the organisation can demonstrate ownership, scope, and current enforcement for the assets it is accountable for. External guidance such as the DORA source page is useful for regulatory framing, but the evidence decision still depends on the specific control and the exact cloud boundary being assessed.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and CIS Controls v8 set the technical controls, while DORA define the regulatory obligations.

Framework	Control / Reference	Relevance
DORA	ART-5 — ICT Risk Management Framework	Documentation vs live configuration shows governance intent versus operational control under DORA.
Recommendation — Map policies to enforceable ICT controls and retain proof that production settings match the documented framework.
NIST CSF 2.0	GV.PO-01 — Policy	Policies describe required control intent, separate from implementation evidence.
	PR.DS-01 — Data-at-Rest Protection	Encryption at rest is a core example of configuration evidence versus policy intent.
Recommendation — Document control requirements clearly and verify that technical enforcement matches the stated policy. Capture production settings that demonstrate data protection controls are actually enabled.
CIS Controls v8	1 — Inventory and Control of Enterprise Assets	Cloud evidence depends on knowing which assets and environments are actually in scope.
	6 — Access Control Management	The example control evidence includes MFA and privileged access enforcement.
Recommendation — Maintain an accurate asset inventory so configuration evidence can be tied to the correct cloud scope. Use live configuration checks to confirm access settings are enforced, not just documented.

Practitioner Guidance

What to prioritise: Treat documentation as a control-map problem and cloud evidence as a control-validation problem. If the policy cannot be tied to a named system owner, scoped environment, and verification method, it is too weak to support assurance.

What to verify: Confirm that each documented obligation has a corresponding technical artefact in the relevant cloud account or tenant, and that the artefact reflects the current state rather than a historical export. Verify exception approvals separately, because they often explain apparent mismatches.

Common mistake: Teams frequently overvalue polished policy packs and underweight live configuration proof. That shortcut creates false confidence, especially when a cloud control is disabled, partially deployed, or enforced only in one environment.

Practitioner takeaway: The strongest assurance comes when policy, ownership, and live cloud settings all tell the same story; if they do not, the gap is the issue, not the paperwork.