The common mistake is assuming a plan to implement controls is equivalent to actual security. In practice, a plan only shows intent, while compliance requires proof that controls exist, operate consistently, and support the required outcome. Organisations also miss the need for independent review, which is what turns internal assertions into a credible certification basis.
Why plans are weaker than evidence in compliance
A plan describes intent, sequence, and ownership, but it does not prove control operation. For compliance, the organisation must show that the control exists in the live environment, works repeatedly, and produces an outcome that can be independently verified. That distinction matters because assessors, auditors, and certification schemes judge operating reality, not project status.
The practical failure is treating delivery readiness as control evidence. Teams often point to policies, roadmaps, tickets, or implementation milestones and assume these demonstrate compliance maturity. They do not. A valid evidence set normally includes artefacts such as configuration states, logs, screenshots, test results, exception records, and review outputs that show the control was active over time, not merely approved on paper.
This is especially visible in identity and secret governance, where organisations may have a policy for rotation or offboarding but still lack proof that keys were revoked, privileges were reduced, or access was reviewed. NHIMG’s Ultimate Guide to NHIs, regulatory and audit perspectives and The State of Non-Human Identity Security both reinforce the gap between stated governance and demonstrable operating control.
What credible compliance evidence has that plans do not
Credible evidence is specific, time-bound, and independently inspectable. It should show what was controlled, when it was controlled, who owned the action, and how the organisation verified the outcome. For example, a control narrative may say access is reviewed quarterly, but evidence is the completed review, the reviewer’s sign-off, the exceptions raised, and the remediation record showing those exceptions were resolved or formally accepted.
That is why good compliance evidence is usually layered. One artefact proves design, another proves execution, and another proves oversight. A plan can support the design story, but it cannot replace execution evidence or independent assurance. In practice, the strongest evidence sets combine operational records with audit trails, because that combination turns an internal assertion into something testable by a third party.
For organisations dealing with secrets, API keys, and service accounts, the evidence bar is often higher than teams expect. The most relevant proof is not a policy statement about rotation, but actual rotation history, revocation records, vault usage, and proof that exposed credentials were removed from code or pipeline systems. NHIMG’s 2024 State of Secrets Management Survey is useful background for why plans alone fail to close that gap.
How practitioners should judge the difference in practice
What matters most is whether the evidence can survive challenge. If an assessor asked, “Show me the control working last month,” the organisation should be able to produce artefacts that answer that question without relying on promises or future milestones. If it cannot, the control is still aspirational, even if the implementation plan is detailed and well managed.
What to verify: confirm the evidence demonstrates operation, not just design. That means looking for repeatable control execution, timestamps, reviewer identity, exception handling, and linkage to the requirement being tested. If the evidence only proves that a task was assigned or that a project was approved, it is not enough for compliance purposes.
Decision rule: if the control can materially affect access, exposure, or regulated outcome, treat the absence of operating evidence as a compliance failure until proven otherwise. This is the point where organisations should escalate from project management into assurance, because “in progress” is not a defensible substitute for “effective.”
Practitioner takeaway: compliance confidence comes from observable control performance, not documented intent; the question is always whether the organisation can prove the control worked, not whether it planned to make it work.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.35 — Independent review of information security | Independent review turns internal claims into verifiable assurance evidence. |
| Recommendation — Require independent review to validate control operation before claiming compliance. | ||
| CIS Controls v8 | 8.1 — Establish and Maintain Audit Log Management | Audit logs are core evidence for proving control activity over time. |
| Recommendation — Centralise and retain audit logs that substantiate compliance evidence. | ||
Related resources from NHI Mgmt Group
- What do organisations get wrong when they rely on separate identity systems for compliance and fraud prevention?
- What do organisations get wrong when they rely on policy alone for privacy compliance?
- What do organisations get wrong when they rely on manual access reviews instead of intelligent identity analytics?
- What do organisations get wrong when they rely on compliance alone to secure payment infrastructure?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
