Access Control Evidence: From Policy to Testable Proof

Define the objective and evidence chain

Write the objective in observable terms. For example: “Only approved members of the Finance Operations role can export customer billing data from Production, and access is removed within one business day after the role ends.” Then record the system boundary, identity provider, application, privileged roles, data class, review period, and accountable owner.

The NIST SP 800-53 Revision 5.1 control catalog distinguishes account management, access enforcement, separation of duties, and least privilege. Use the relevant control concepts to decompose the objective, but retain the organization's own risk context and implementation choices.

Build a five-link evidence chain:

Each artifact needs a source system, extraction timestamp, covered period, custodian, and integrity note. A policy without operational records stops at the first link. An entitlement export without an approved rule cannot show whether the listed access is appropriate.

• Rule: approved policy, role definition, and prohibited combinations;
• Authorization: named approver, ticket, business reason, and validity period;
• Configuration: role-to-permission export and enforcement settings;
• Operation: identity events, access logs, periodic review results, and revocations;
• Exception: deviation, owner, compensating measure, expiry, and closure evidence.

Sources: [1]

Test with examine, interview, and verify procedures

The NIST SP 800-53A Revision 5 assessment guide provides customizable procedures for assessing security and privacy controls. Translate that structure into three practical passes.

First, examine the rule, role catalog, joiner-mover-leaver procedure, access-review record, exception register, and configuration export. Confirm versions and effective dates. Second, interview the control owner and one operator to compare the documented workflow with actual practice; record discrepancies as evidence, not as edits to the interview notes. Third, verify selected cases against source records.

Choose samples from meaningful populations rather than convenient screenshots: new grants, role changes, terminated access, privileged accounts, rejected requests, expired exceptions, and periods with known incidents. For every sample, test approval before grant, permission alignment with the approved role, enforcement in the application, and timely removal. Record the population query and sampling rule so another reviewer can reproduce the selection.

Sources: [2]

Worked evidence matrix

Consider the Finance Operations export objective for the quarter ending 30 September. The identity platform shows 23 users in the role. The application configuration maps that role to billing.export. The ticket system contains 24 approvals during the quarter: three new grants, two removals, and 19 continuing-access recertifications.

The reviewer creates this matrix:

Testing finds that both departed users lost access within the objective's one-business-day window. One continuing user lacks a current recertification ticket because the manager changed during the review. The evidence pack reports 18 of 19 continuing memberships with current approval and one unresolved exception. It does not describe the entire control as effective until the owner resolves the missing authorization and the reviewer evaluates the result.

• AC-01, role policy v4, supports the approved membership rule, effective 1 July;
• AC-02, identity export at 30 September, supports the 23-member population;
• AC-03, application configuration export, supports role-to-permission enforcement;
• AC-04, approval-ticket export, supports authorization and recertification events;
• AC-05, termination log, supports removal timing;
• AC-06, exception register, records one service account with a time-limited exception.

Review boundaries and maintenance

Date every conclusion and tie it to the tested population. Do not extrapolate evidence from one application, role, or quarter to another. Automated exports can reduce collection error, but they still require validation of query logic, time zones, deleted identities, service accounts, and synchronization delays. Screenshots should supplement, not replace, machine-readable exports when an export is available.

Schedule evidence refreshes around control frequency and system change: a quarterly access review needs a quarterly result, while a major identity-provider migration requires a new boundary and configuration assessment. Preserve failed tests and late removals alongside remediation evidence. The exception history is part of the control story.

Two Prune can present a participant with synthetic access records, tickets, and policies to assess how they navigate evidence, test claims, and communicate limitations. That assessment describes observed work in a simulation. It is not a security audit, proof of regulatory conformity, or an automated employment decision.