What is the difference between an access policy and CAF-ready access evidence?

Why the distinction matters in practice

An access policy is a decision statement: it defines the intended rules for who or what should have access, under what conditions, and with which limits. CAF-ready access evidence is operational proof: it shows the current access state on the hosts that support essential functions, plus the change history needed to explain how that state came to be.

The gap matters because policy alone can be correct on paper while the live environment drifts. For CAF purposes, practitioners are usually judged on whether the control is real, observable, and tied to the systems that matter, not whether the written rule looks strong.

What access policy covers, and what it does not

An access policy sits at the design and governance layer. It should define allowed account types, approval paths, privilege limits, review cadence, and exceptions. It may also state how access should be requested, provisioned, recertified, and removed, but it does not by itself prove those steps happened on a given host.

That is why policy is necessary but incomplete. A policy can say sudo access must be restricted, SSH keys must be controlled, and service account ownership must be assigned, yet those claims still need verification against actual systems. A strong policy tells you the target state; it does not tell you whether the target state exists today.

What CAF-ready access evidence needs to show

CAF-ready evidence is built from live, host-level facts and traceability. On Linux, that usually means current local and directory-backed accounts, sudoers entries, SSH keys, service account ownership, and the relationship between those accounts and the systems supporting essential functions. It should also show whether changes were authorised, when they occurred, and whether the current state still matches the intended control.

Authorisation Models Guide is useful here because it helps separate the policy model from the operational proof of enforcement. The policy may describe roles, attributes, or rules, but CAF evidence must demonstrate the resulting permissions on real hosts.

Good evidence is specific enough to answer three questions quickly: who has access, why they have it, and whether the access still matches the host’s business function. If you cannot answer those questions from the evidence pack, you probably have a policy document rather than audit-ready proof.

Why auditors and assessors treat them differently

Policy and evidence serve different audit functions. Policy demonstrates governance intent and control design; evidence demonstrates operating effectiveness. For a CAF-style review, the second is usually more persuasive because it reduces reliance on self-attestation and shows that the control operates where the risk actually lives.

This is also why Azure Key Vault Contributor escalation 2024 is a good reminder that access rules can be misleading if live privileges are not reconciled. In that case, the practical problem was not the wording of the policy, but the ability of a role to influence access paths and reach protected material. The lesson generalises: evidence must confirm the effective permission set, not just the documented one.

Practitioner Guidance

What to verify: For each essential Linux host, verify the current account inventory, sudoers grants, SSH authorised keys, and ownership of service accounts against the approved access model. If the host can reach an essential function, treat drift on that host as more important than a clean policy document elsewhere in the estate.

What good looks like: The evidence pack should let a reviewer trace from policy intent to live host state to recent change history without manual interpretation. If a control depends on tribal knowledge, spreadsheets, or one-off explanations, it is not yet CAF-ready evidence.

Common mistake: Teams often submit access policy excerpts, approval tickets, or screenshots of a directory group and assume that is enough. Those artifacts help, but they do not replace a current, host-specific reconciliation of access on the systems that support essential functions.

Practitioner takeaway: Treat policy as the rulebook and evidence as the scoreboard, because only the scoreboard proves the rulebook is actually being followed on the hosts that matter.

Related resources from NHI Mgmt Group

• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between protecting applications and protecting access?
• What is the difference between attack surface management and NHI governance?