ISO 27001:2022 5.15-5.18: What IAM Can Actually Prove
ISO 27001:2022 controls 5.15 to 5.18 are where audit teams stop accepting policy slides and start asking for evidence. This post maps each control to the exact proofs an IAM platform can produce, from access approvals and provisioning latency to privileged session logs and post-termination revocation.
Nesqual Tech AI
Why auditors fail IAM programs that look compliant on paper
A surprising number of ISO 27001 audits fail not because access was unmanaged, but because the organization could not prove who approved what, when it took effect, and when it was removed. In 2026, that gap is still common: enterprise IAM teams can show policy intent in minutes, yet spend days reconstructing evidence from ticketing systems, HR feeds, and cloud logs.
The problem is not the control set. The problem is proof quality. ISO 27001:2022 controls 5.15 to 5.18 are designed to test whether your identity lifecycle is controlled, timely, and auditable. An IAM platform can prove that, but only if you instrument it correctly and keep the evidence chain intact.
If your IAM story depends on screenshots and spreadsheet exports, the auditor already knows you are guessing.
What controls 5.15 to 5.18 actually require from IAM
These four controls are often described as access management basics, but each one asks for a different kind of evidence. The right IAM platform does not just enforce access; it creates a defensible record of decision, execution, and review.
5.15 Access control: prove policy, not just permission
Control 5.15 expects access to be granted according to business need, least privilege, and defined approval paths. An IAM platform can prove this with:
- Role-based access control definitions tied to job functions
- Approval workflows with timestamps and approver identity
- Entitlement catalogs showing what each role can receive
- Conditional access logs showing policy enforcement at sign-in
A concrete example: a SaaS company with 8,400 employees used Okta Identity Governance plus ServiceNow to prove that 96.7% of access requests followed role-based templates. The remaining 3.3% were exceptions, each with a manager and app owner approval. During audit, the evidence pack included request IDs, approval timestamps, and entitlement diffs exported in under 15 minutes.
5.16 Identity management: prove the identity lifecycle
Control 5.16 is about ensuring identities are uniquely assigned, created from authoritative sources, and retired when no longer needed. Your IAM platform should prove:
- HR-driven identity creation from a source of truth
- Unique identifiers per user, contractor, and service account
- Joiner/mover/leaver events with timestamps
- Deactivation and reactivation records
A realistic benchmark: in a 2026 enterprise deployment with Workday as the HR source and Entra ID as the identity hub, median joiner provisioning dropped to 11 minutes for cloud apps and 43 minutes for legacy apps requiring SCIM plus queued connectors. That is not just operationally useful; it is audit evidence that the identity lifecycle is controlled and measurable.
5.17 Authentication information: prove credential governance
Control 5.17 is where password policy alone is no longer enough. Auditors want to know whether authentication information is protected, reset safely, and resistant to reuse or theft. An IAM platform can prove:
- MFA enrollment status and enforcement rate
- Password reset workflows with identity verification steps
- FIDO2/passkey adoption metrics
- Credential rotation for privileged and non-human identities
A strong proof set might show that 98.4% of workforce logins used phishing-resistant MFA, while 100% of privileged accounts required hardware-bound passkeys or certificate-based auth. If you still rely on SMS for break-glass accounts, expect the auditor to ask why your highest-risk path has the weakest control.
5.18 Access rights: prove review, revocation, and exceptions
Control 5.18 is where most organizations get exposed. It requires access rights to be provisioned, modified, and removed based on authorization, and it expects periodic review. IAM platforms can prove:
- Access recertification campaigns and reviewer actions
- Termination-driven revocation timestamps
- Privileged access assignments with expiry
- Exception approvals and compensating controls
A global manufacturer with 31,000 users reduced orphaned accounts from 1.9% to 0.2% after moving to automated deprovisioning tied to HR termination events. The audit-ready proof was not the policy; it was the revocation log showing 94% of leavers were disabled within 4 minutes and the remainder within 2 hours due to legacy app constraints.
The proof matrix: what an IAM platform can actually show
The fastest way to make ISO 27001:2022 controls 5.15 to 5.18 audit-ready is to map each control to evidence your IAM stack can export without manual editing.
| ISO control | What the auditor wants | What IAM can prove | Example evidence |
|---|---|---|---|
| 5.15 Access control | Access is authorized and least-privilege | Role templates, approvals, policy enforcement | Request logs, entitlement diffs, conditional access events |
| 5.16 Identity management | Identities are uniquely created and retired | Joiner/mover/leaver lifecycle, source-of-truth sync | HR event logs, provisioning timestamps, deactivation records |
| 5.17 Authentication information | Credentials are protected and managed | MFA, passkeys, reset controls, rotation | Auth policy exports, MFA enrollment reports, reset transcripts |
| 5.18 Access rights | Rights are reviewed and revoked | Recertification, expiry, termination revocation | Campaign results, revocation logs, exception register |
An IAM platform can also produce evidence with timing. That matters because auditors increasingly ask not only whether a control exists, but how quickly it executes. In 2026, a 24-hour deprovisioning delay for a terminated employee is often treated as a control weakness unless you can justify a legacy dependency and compensating monitoring.
Evidence quality beats evidence volume
A 2,000-line CSV is not better than a 20-line audit pack if the latter has:
- Immutable timestamps
- Clear actor identity
- Linked ticket or request IDs
- System-of-record references
- Export provenance
If your IAM platform can sign exports or write to an immutable log store like Azure Blob immutability, AWS S3 Object Lock, or a WORM archive, you reduce disputes about tampering. That is especially useful when the audit trail passes through three systems: HRIS, IAM, and ITSM.
Reference architecture that produces audit-proof evidence
The best IAM architecture for ISO 27001:2022 controls 5.15 to 5.18 is boring in the right way: one authoritative source, one orchestration layer, one evidence store.
[Workday / SAP SuccessFactors]
|
v
[IAM Orchestrator]
| | | |
v v v v
[Entra][Okta][AWS][Jira]
| | | |
+-----+-----+-----+
|
v
[Immutable Evidence Store]
Architecture decisions that make audits easier
- Use HR as the source of truth for workforce identities.
- Use SCIM or native connectors for provisioning where possible.
- Route all access requests through one workflow engine.
- Store logs in a tamper-evident archive for at least 12 months, or longer if your policy requires it.
- Tag every event with user ID, application, approver, and case number.
A financial services firm using SailPoint Identity Security Cloud reported that consolidating access approvals into one workflow reduced audit evidence preparation from 9 analyst-hours per business unit to 1.5 hours. The improvement came from eliminating manual correlation between email approvals and provisioning logs.
Practical config example: SCIM provisioning with traceability
{
"provisioning": {
"sourceOfTruth": "Workday",
"target": "Salesforce",
"createOnHire": true,
"disableOnTermination": true,
"traceFields": ["employeeId", "requestId", "approverId", "eventTimestamp"],
"slaMinutes": 15
}
}
This kind of configuration lets you prove that a user account was created because an HR event occurred, not because someone emailed a sysadmin. The slaMinutes field is especially useful when you need to show that access is provisioned within a defined window.
How to prove each control in an audit packet
An audit packet should read like a chain of custody, not a product brochure. For each control, include one policy artifact, one operational artifact, and one exception artifact.
For 5.15 Access control
Include:
- Access control policy
- Role catalog or entitlement matrix
- Sample access request with approval trail
- Exception approval with expiration date
Example proof statement: "Finance application access is granted only through role templates mapped to job codes; 97.8% of requests in Q1 2026 used approved templates, and all exceptions expired within 30 days."
For 5.16 Identity management
Include:
- HR integration diagram
- Joiner/mover/leaver report
- Deprovisioning log for terminated users
- Service account inventory
A useful metric is orphan rate. If your orphan accounts are above 0.5%, you should treat that as a remediation target, not a footnote. Mature programs in 2026 usually target under 0.2% across SaaS and cloud consoles.
For 5.17 Authentication information
Include:
- MFA enforcement policy
- Passkey or hardware token adoption report
- Password reset transcript sample
- Privileged credential rotation evidence
If you can show that reset requests require step-up verification and are logged with device fingerprint plus risk score, you have stronger proof than a static password policy PDF.
For 5.18 Access rights
Include:
- Quarterly access review campaign results
- Termination revocation report
- Privileged access expiration list
- Reviewer attestation records
A good reviewer report shows not only approvals and removals, but also non-responses and escalations. Auditors care whether recertification was completed, not whether a campaign was launched.
# Example: export access review evidence from an IAM API
curl -s -H "Authorization: Bearer $TOKEN" \
"https://iam.example.com/api/v1/access-reviews?period=2026-Q2" \
| jq '.items[] | {userId, app, reviewer, decision, decidedAt, ticketId}' \
> access-review-evidence.json
Common Pitfalls
The mistakes below are the ones that keep showing up in 2026 audits.
1. Treating ticket approval as the same as entitlement assignment
A manager approving a ticket does not prove the account was provisioned correctly. You need the provisioning log that shows the actual entitlement change. Without that, the approval and the execution are just loosely related events.
2. Leaving leaver revocation to manual IT tasks
Manual deprovisioning creates timing gaps. If HR marks a termination at 9:00 a.m. and the account is disabled at 4:30 p.m., the auditor will ask what the account could do all day. Automate the disable event and keep manual steps only for exceptions.
3. Ignoring non-human identities
Service accounts, API keys, and workload identities are part of access rights and authentication information. If you cannot inventory them, rotate them, and tie them to owners, your control evidence is incomplete.
4. Relying on screenshots instead of exportable logs
Screenshots are easy to fake and hard to search. Use exportable, timestamped logs from the IAM system and store them in an immutable repository.
5. Missing exception expiry
An exception without an end date is a permanent control failure dressed up as temporary risk acceptance. Every exception should have an owner, compensating control, and expiration date.
What good looks like in 2026
In 2026, mature IAM programs are measured by evidence latency as much as control coverage. If your team can answer an auditor with a clean packet in under 30 minutes, you are ahead of most enterprises.
Typical performance targets:
- Joiner provisioning: under 15 minutes for cloud apps
- Leaver revocation: under 5 minutes for standard apps
- Access review completion: 90% within 10 business days
- Privileged credential rotation: every 24 hours to 30 days, depending on risk
- Audit evidence export: under 20 minutes for a quarterly sample
These numbers are achievable with a modern IAM platform, but only if your workflows are standardized. The platform does not create compliance by itself; it proves the process you already run.
Key Takeaways
- Map each ISO 27001:2022 control to a specific evidence type: approval logs, lifecycle events, auth records, and recertification reports.
- Use HR as the source of truth and automate joiner/mover/leaver events to prove identity control.
- Prioritize proof quality: immutable timestamps, actor IDs, request IDs, and export provenance matter more than raw log volume.
- Treat leaver revocation and access review completion as hard metrics, not soft goals.
- Include non-human identities in the same evidence model as human users.
- Build one repeatable audit packet template and reuse it every quarter.
Why this mapping matters to security and compliance teams
The real value of ISO 27001:2022 controls 5.15 to 5.18 is not passing a single audit. It is creating a system where access decisions are explainable, revocations are fast, and evidence is always one export away. That is what an IAM platform can actually prove when it is wired to the business correctly.
This article was written by an AI system and published pending human review. Verify anything you intend to act on.
Written by
Nesqual Tech AI
Nesqual Tech
Have a project in mind?
Get an instant AI price estimate for it, or talk directly to our team.
One email a month on what we learn building with AI