Access control is where policy and operations collide most visibly. Auditors do not stop at reading the policy; they pull a list of leavers and check whether accounts were disabled, pull an admin group and ask who approved each member, and compare the last access review against the date the policy promised. A usable access control policy is therefore specific about timings, approvals, and review cycles. This template gives you a starting structure to fill in with the rules your identity team can actually meet.
The principles the policy should establish
- Least privilege. Users get the minimum access needed for their role, and nothing by default.
- Need to know. Access to sensitive data is granted for a business reason, not because someone is senior.
- Segregation of duties. Conflicting functions, such as requesting and approving access or developing and deploying to production, are split (ISO 27001 Annex A 5.3).
- Unique identities. No shared accounts for humans; service accounts have named owners.
- Role-based access where possible. Access is granted by role or group rather than individually, which makes reviews tractable.
Rules across the identity lifecycle
Most audit findings in this area come from the lifecycle, not from the principles. Write each stage as a rule with a trigger, an approver, and a time limit, so it can be tested. The timings below are illustrative starting points; pick values your HR and IT processes can reliably hit.
Joiner, mover, leaver: what to define
Privileged access and authentication
Privileged accounts deserve their own section because they are where a compromise does the most damage. ISO 27001 Annex A 8.2 requires privileged access rights to be restricted and managed. Good policy language separates admin accounts from day-to-day accounts, requires multi-factor authentication for all privileged and remote access, prefers just-in-time elevation over standing admin rights, and logs privileged activity. Break-glass accounts should be documented, vaulted, alerted on use, and have their credentials rotated after each use.
For authentication, reference a separate standard for password and MFA settings rather than hard-coding them here. If you are in PCI DSS scope, Requirement 8 sets specific expectations, including MFA for all access into the cardholder data environment. The access control policy itself should sit beneath, and reference, your top-level information security policy.
Access review cadence
Where the policy maps across frameworks
Terms like control and Annex A are defined in the glossary if you are mapping this for the first time.
How auditors test access control
- Obtain a list of terminations for the period from HR and compare disable dates in the identity provider against the policy's deadline.
- Sample new hires and look for an approval recorded before access was granted.
- Pull membership of admin groups and ask for the justification and approver of each member.
- Inspect the most recent access reviews for completeness, reviewer identity, and follow-through on removals.
- Check MFA enforcement settings in the identity provider rather than relying on a screenshot of the policy.
Much of that evidence can come directly from systems of record. Identity integrations such as Okta, Entra ID, and SailPoint, alongside HR sources like Workday and BambooHR, are part of the integrations catalog, which lets leaver reconciliation become a continuous check rather than a scramble before fieldwork.
Mistakes to avoid
- Promising same-day deprovisioning when HR notifies IT a week late.
- Treating SaaS applications outside SSO as out of scope for reviews.
- No owner for service accounts, so nobody can say whether they are still needed.
- Access reviews that cover the identity provider but not the permissions inside each application.
- Exceptions granted by email with no expiry date.