Look for broad IAM roles, missing retention locks, exception queues without expiry, and audit evidence that is reconstructed manually at the last minute. Those are usually the signals that controls exist as documentation but are not wired into the operational cloud lifecycle.
What “paper compliance” looks like in cloud standards
Cloud standards are being applied only on paper when the control design exists in policy, but the live environment does not enforce it consistently. The clearest sign is a gap between written requirements and runtime behaviour: access remains broad, retention is optional, exceptions never age out, and audit proof is assembled after the fact instead of produced by the platform itself.
That gap matters because cloud controls are only trustworthy when they are expressed in the same systems that create workloads, grant access, manage storage, and generate logs. If the standard lives in a document while the cloud estate behaves differently, the organisation has compliance language, not control assurance.
How to spot standards that are not wired into the cloud lifecycle
The first clue is over-permissioned access. When IAM roles are broad, inherited too widely, or reused across teams and environments, the control may exist in a policy register but not in actual entitlement design. Real enforcement usually leaves a trace in role boundaries, approval paths, and periodic review evidence that is generated from the platform, not from spreadsheets.
A second clue is missing data retention enforcement. If retention locks, deletion holds, or immutability settings are described in standards but not visible in storage or backup configuration, the control is advisory rather than operational. You should expect to see policy-to-configuration parity, not a promise that someone will set the right option later.
A third clue is exception handling with no expiry or owner. Temporary waivers are sometimes necessary, but paper compliance shows up when exceptions sit in queues indefinitely, have no compensating control, and are never forced back through review. A functioning programme treats exception handling as a governed lifecycle, not as a permanent side channel.
Why manual audit evidence is the strongest warning sign
Audit evidence that is reconstructed manually at the last minute is one of the most reliable signs of paper compliance. If the evidence trail must be assembled from screenshots, ad hoc exports, or hand-written narratives, the control is probably not producing durable operational records. The audit process becomes a rescue exercise instead of a verification exercise.
That pattern usually means the standard is not integrated into change management, logging, access review, or backup governance. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames controls around auditable, repeatable operation, not just policy statements. NIST Cybersecurity Framework 2.0 is also a good lens when you need to check whether governance and protective activities are actually being performed across the environment.
When audit proof only exists at reporting time, the organisation usually lacks continuous evidence generation. That is a process failure, but it is also a control failure, because the standard has not been translated into a control point that can be observed repeatedly.
Risk and Threat Considerations
Paper-only standards create hidden exposure because the environment appears governed while real privilege, retention, and evidence controls remain weak. That increases the chance of unauthorized access, weak recovery posture, and failed audit defensibility, especially when cloud changes happen faster than manual review cycles.
Failure mechanism: The policy exists as documentation, but enforcement is not embedded in provisioning, storage configuration, exception expiry, or logging, so deviations accumulate unnoticed until an incident or audit exposes them.
Impact: Attackers and insiders can exploit excessive access or weak retention controls, while the organisation may be unable to prove control effectiveness when it matters most.
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 NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Paper compliance is a governance and accountability issue tied to how cloud controls are operationalized. |
| Recommendation — Define control ownership and verify standards map to live cloud operations. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Broad roles and weak lifecycle handling are core signs of over-permissioned access. |
| AU-2 — Event Logging | Manual last-minute evidence often means logging is not generating durable audit proof. | |
| Recommendation — Review role assignments and remove access that is not operationally justified. Ensure cloud systems generate audit evidence automatically and consistently. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question centers on whether access standards are enforced in practice rather than documented only. |
| A.8.15 — Logging | Reconstructed audit evidence points to weak operational logging and evidence retention. | |
| Recommendation — Tie access standards to enforced cloud configurations and periodic review. Produce logs and audit evidence directly from cloud systems instead of manual assembly. | ||
Practitioner Guidance
What to verify: Check whether the control produces a runtime artifact, such as a role boundary, enforced retention setting, expiring exception record, or immutable audit trail. If the only evidence is a policy document or a manually built report, treat the control as unproven.
Decision rule: If a cloud standard cannot be validated from live configuration and system-generated records, escalate it as a control-design gap rather than accepting it as operating state. The question is not whether the standard sounds correct, but whether the platform is forced to comply with it.
What good looks like: The strongest signal is a closed loop where policy, provisioning, logging, and review all point to the same state, and exceptions expire unless explicitly renewed with evidence.
Practitioner takeaway: In cloud governance, compliance is real only when the control can be observed in the environment without human reconstruction at audit time.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org