Join our Newsletter — 33% off our NHI Course

What should auditors ask for when access governance spans multiple application types?

They should ask for evidence that each in-scope app enforces access controls, records approvals, and supports session and authentication logging. The question is not whether a central platform exists, but whether the application estate can prove control coverage end to end.

What auditors should expect from each in-scope application

Auditors should not accept an access governance answer that is framed only at the platform layer. The control evidence has to sit in the applications themselves, because that is where approvals, enforcement and logging either happen or fail. In practice, the audit test is whether each application can prove who approved access, what was granted, and how access activity is recorded.

That expectation becomes more important in estates with a mix of SaaS, custom apps and legacy systems. A central workflow may coordinate requests, but it does not prove that a target application actually honours the decision, captures the right events, or preserves traceability for later review.

What “control coverage end to end” means in audit terms

End to end coverage means the auditor can follow the request from intake through approval, provisioning, use and review without a broken evidence chain. For access governance, the practical question is whether the control is enforced at the application boundary, not only documented in a policy or dashboard.

A useful way to test this is to ask for artefacts that show the application can enforce access controls, store approval evidence, and generate session and authentication logs that are tied back to the relevant identity or account. That is the difference between a process that exists on paper and a control that is actually operating.

Where access is mediated by roles, entitlements or group membership, the auditor should expect the application to show how those decisions map to effective access. NHIMG’s IAM and IGA Basics is a useful reference for the distinction between request, authorization and enforcement, and the Access Reviews and Certification Guide gives a practical lens on review evidence and closed-loop remediation.

Why multi-application estates create audit blind spots

Multi-application environments often fail at the seams: one system records the approval, another provisions the account, and a third produces the logs. If those systems are not linked cleanly, auditors may see a “completed” workflow without being able to prove that the right application permissions were actually enforced or monitored.

The usual weak point is inconsistent coverage across the application estate. Some apps support native access logs and approval trails, while others rely on manual spreadsheets, email sign-off or indirect evidence. That is why auditors should challenge assumptions about coverage by application type and ask whether the organisation can demonstrate the same minimum evidence set across SaaS, custom and on-premises platforms. The IGA Buyer’s Guide is helpful here because it highlights connector coverage, disconnected applications and proof-of-control testing. For broader control design, Ultimate Guide to NHIs, Regulatory and Audit Perspectives shows how auditability depends on evidence trails rather than platform claims.

For estates with complex role structures or conflicting duties, auditors should also ask whether the application can support segregation checks and role-based evidence. Where those checks are absent, approval alone is not enough to demonstrate governance.

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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
NIST SP 800-53 Rev 5 AC-2 — Account Management Access governance across apps depends on account and entitlement lifecycle evidence.
AC-6 — Least Privilege Auditors need proof that access granted in each app is limited to required privilege.
AU-2 — Event Logging Session and authentication logging are central to proving control operation end to end.
Recommendation — Verify each application can show account provisioning, changes, and removal with approver traceability. Check each application enforces least privilege at the entitlement and role level. Confirm each in-scope application records the access events needed for audit traceability.
ISO/IEC 27001:2022 A.5.15 — Access control The question is fundamentally about application-level access control evidence.
A.8.15 — Logging Auditability requires logs from the application layer, including authentication and session activity.
Recommendation — Confirm access control is enforced consistently within each application and not only centrally. Validate that each application generates and retains logs sufficient for audit review.

Practitioner Guidance

What to verify: Ask for one sample control chain per application type, not one sample per programme. The sample should show the request, approver, effective entitlement, and the log source that proves the control operated as intended.

What to prioritise: Start with the applications that are highest risk, highest privilege, or hardest to integrate. Those are the places where a central governance tool most often overstates actual coverage.

Common mistake: Treating the existence of an access request workflow as proof of enforcement. If the application cannot produce its own approval and session evidence, the governance story is incomplete.

Practitioner takeaway: In a multi-application estate, auditors should test evidence at the application boundary, because that is where approval, enforcement and logging must converge for access governance to be credible.