What do organisations get wrong about evidence in compliance programmes?

Why This Matters for Security Teams

Evidence is not just a compliance artifact. It is the proof that a control is actually operating, consistently, and in the right scope. When teams collect screenshots, exports, or point-in-time attestations after the fact, they often end up documenting intent rather than reality. That creates a false sense of assurance, especially when control owners, auditors, and engineering teams are working from different systems of record. Guidance in the NIST Cybersecurity Framework 2.0 reinforces that outcomes depend on repeatable governance and operational measurement, not one-off paperwork.

The practical risk is that evidence becomes detached from enforcement. A policy can exist while access remains over-permissive, logging can be enabled while retention is too short, and segregation of duties can be asserted while exceptions are never reviewed. Mature programmes treat evidence as a by-product of control operation, not a separate exercise. That means designing systems to emit trustworthy records, retaining them for the right period, and making sure the records can be traced back to the control objective. In practice, many security teams encounter broken evidence only after an audit request or incident review exposes that the control had never been producing defensible proof.

How It Works in Practice

The strongest compliance evidence comes from systems that enforce the control and record their own activity. For example, access governance tools should produce entitlement history, approval trails, and periodic review outcomes; cloud platforms should produce immutable configuration and change logs; and detection platforms should preserve alerts, triage actions, and timestamps. This aligns with the control-oriented approach in NIST SP 800-53 Rev 5 Security and Privacy Controls, where evidence should map back to specific control families and be usable for assessment, not merely storage.

• Define each control’s expected evidence before implementation, not after the audit begins.
• Prefer machine-generated records such as logs, policy snapshots, approval trails, and configuration baselines.
• Preserve integrity with time sync, access restrictions, retention controls, and tamper-evident storage.
• Link each evidence item to the control objective, system owner, and review cadence.
• Test whether an independent reviewer can reconstruct the control operation from the evidence alone.

In a well-run programme, evidence is assembled continuously through logging, change management, ticketing, and automated control checks. That approach also supports broader governance systems such as ISO/IEC 27001:2022 Information Security Management and the supporting control catalogue in ISO/IEC 27002:2022 Information Security Controls, both of which depend on demonstrable operation rather than policy statements alone. The same logic applies in identity-heavy environments: if a system grants access, that access should leave a reviewable trail showing who approved it, when it expired, and whether it matched the intended role or risk decision. These controls tend to break down when evidence is scattered across manual spreadsheets and separate ticketing systems because no single source can reliably reconstruct the control lifecycle.

Common Variations and Edge Cases

Tighter evidence requirements often increase operational overhead, requiring organisations to balance audit readiness against the friction introduced for engineering, risk, and operations teams. The tradeoff is real, but current guidance suggests that automation usually reduces burden over time because it removes repeated manual collection and lowers the chance of inconsistent records.

There is no universal standard for every evidence type, so teams should distinguish between regulated proof, internal assurance, and investigative artefacts. For example, finance-linked identity workflows may need stronger traceability than general administrative controls, especially where KYC or AML obligations apply under the FATF Recommendations. In cloud and software supply chains, evidence may need to include pipeline attestations, version history, and deployment records, while in privacy-sensitive environments, access to evidence itself may need tighter restriction than the control it documents. The key is not to create more paperwork, but to make the evidence model proportional to the risk, the regulatory context, and the system’s change rate.

Best practice is evolving for continuous controls monitoring, especially where evidence is generated by policy engines, CI/CD pipelines, or identity systems that change frequently. In those environments, static exports age quickly and can misrepresent the actual control state. Organisations that rely on periodic manual capture usually discover too late that evidence can be complete, neat, and still wrong.

Related resources from NHI Mgmt Group

• What do organisations get wrong about policy waivers in compliance programmes?
• What do organisations get wrong about IAM and compliance evidence?
• What do organisations get wrong about continuous monitoring in compliance programmes?
• What do organisations get wrong about onboarding and offboarding in compliance programmes?