Pull the identity and access logs that show who had access, when it changed, and what activity occurred in the relevant systems. If those records are not centrally available, treat that as a governance gap rather than an audit inconvenience. The immediate need is evidence, not reconstruction from memory.
What teams need to produce first
The fastest useful response is to produce evidence, not an explanation. Teams should pull the access records that show who had access, when access changed, and what activity occurred in the relevant systems, then package them in a way an auditor can trace without manual reconstruction.
This usually means combining access review outputs, authentication or login records, change history for entitlements, and activity logs from the systems in scope. If the records live in separate tools, the immediate task is correlation, not debate about which source is “best.”
When access evidence is ready quickly, the organisation can answer the audit question with a stable record set instead of ad hoc screenshots, emails, or recollection. That is the difference between demonstrating control operation and merely asserting that access was managed.
What counts as access evidence the auditor can use
Useful access evidence has to show an access story end to end: the identity or account, the permission granted, the date it changed, the approval or review trail, and the resulting activity where that activity is relevant to the request. For access questions, the strongest evidence is time-bound and system-generated, not manually assembled after the fact.
In practice, that means the evidence should answer three questions cleanly: who had access, who changed it, and whether the resulting access was actually exercised. If the control is about privileged or sensitive systems, the evidence should be specific enough to show the exact role, entitlement, group, or token scope involved.
Where the environment is cloud, SaaS, or heavily automated, the same principle applies to machine and service access as well as human access. A good evidence package can show the same control pattern across users, service accounts, and application credentials without forcing the auditor to infer how access was granted.
Why missing records should be treated as a control issue
Access evidence only works if it is centrally retrievable and consistently retained. If teams cannot pull it quickly, the problem is not the audit request, it is that the organisation cannot readily prove who had authority over the system at a point in time. The gap is evidentiary, but it is also governance and control design failure.
Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because it ties auditability to access governance, reviewability, and recorded evidence rather than informal reconstruction.
SOC 2 Trust Services Criteria (AICPA) reinforces the same operational point: access controls need evidence of operation, not just policy language.
Where logs are fragmented, missing, or overwritten, the organisation may still be able to explain access manually, but it cannot prove it cleanly. That is why the right response is to surface the gap, preserve what exists, and treat the missing trail as a remediation item for the control owner.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Access evidence depends on recorded events showing who accessed what and when. |
| AC-2 — Account Management | The question is about proving access state, changes, and ownership over time. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Teams must retrieve and present audit records that explain access activity clearly. | |
| Recommendation — Ensure access-relevant events are logged with enough detail to reconstruct the access trail. Maintain account and entitlement records that can be produced on demand for audit evidence. Review and correlate audit records so access evidence is complete and traceable. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access evidence supports proof that access control is operating as intended. |
| Recommendation — Retain access-control evidence that shows who was authorised and when access changed. | ||
| CIS Controls v8 | CIS-5 — Account Management | Immediate access evidence usually comes from account and entitlement records. |
| Recommendation — Centralise account evidence so access changes and ownership can be demonstrated quickly. | ||
Practitioner Guidance
What to prioritise: Start with the source systems that can prove access state and access change, then collect activity evidence only for the systems that are actually in audit scope. Do not spend time building a narrative before the records are secured.
What to verify: Confirm that the evidence covers the full period requested, includes change timestamps, and is traceable to a specific identity, role, or account. If the log set cannot show those three elements, it is not yet audit-ready.
Common mistake: Teams often provide current-access screenshots when the auditor asked for historical access evidence. Current state may help, but it does not replace change history or usage records for the period under review.
Practitioner takeaway: The immediate win is a defensible evidence pack with traceable timestamps and ownership, because the auditor is testing whether access was observable and governable, not whether the team can reconstruct it after the fact.
Related resources from NHI Mgmt Group
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?
- How should security teams prepare access evidence for a first SOC 2 audit?