Access Control Policy Template (Free Word, Excel + PDF)

An access control policy is the written set of rules for who may use your organization's systems and data, how that access is requested, approved, granted, reviewed and removed, and how people prove who they are when they sign in. It turns "IT knows who has access" into rules you can check.

This free template gives you a ready policy in Word and PDF with sample wording for every section: principles, identity and accounts, the joiner, mover and leaver procedure, access requests, role-based access, privileged access, authentication, remote and third-party access, device requirements, access reviews, revocation, shared and break-glass accounts, logging, exceptions and review. It comes with an access request form, a one-page access matrix example, a quarterly review sign-off, a framework mapping to ISO 27001, NIST SP 800-53, SOC 2 and PCI DSS, and an Excel workbook that tracks roles, users, privileged accounts, reviews and exceptions.

Download the template (Word, PDF + Excel)

What the Policy Covers and Who Owns It

The policy is the top layer of your access control documentation. It says what must happen and who decides; procedures and runbooks say how your team does it in each system, and records prove it happened. Many teams call the same document a user access management policy or an identity and access management policy. What matters is that it covers every system that holds company information (SaaS apps, cloud consoles, on-premises systems, networks, databases, source code and the devices people sign in from) and every kind of account, including contractors, third parties and service accounts.

Ownership is where most policies go wrong. The template names a policy owner (usually the IT or security lead), and a system owner for each system who decides which roles get which access and approves requests and reviews for it. Managers request access and confirm it during reviews, HR starts the joiner, mover and leaver steps, IT grants and removes access, and users protect their sign-in details. A RACI table spells out who is responsible, accountable, consulted and informed for each activity.

If you already have an IT security policy, this document sits under it as the topic-specific policy for access. Pair it with a data classification policy: classification tells you which data is confidential, and access control decides who may reach it. That pairing is also the practical answer to a data access policy: classification sets the rules for the data, this policy sets the rules for the people.

Four Principles to Build On

Every rule in the template traces back to four principles. Write them into the policy in plain words, because reviewers and approvers will use them to settle edge cases:

• Least privilege: people and accounts get only the access their current job needs, for as long as they need it. Our guide to the least privilege access model goes deeper.
• Need to know: confidential information is limited to people whose work requires it, even inside a team that has the system.
• Separation of duties: no one person requests, approves and grants their own access, or carries out and approves the same sensitive transaction. See segregation of duties in cybersecurity.
• Default deny: anything not explicitly granted is refused, and a new system starts with no access until its roles are set.

The template uses role-based access control (RBAC) as its model because it is the easiest to explain, approve and audit. Other models exist: attribute-based access control decides by attributes such as department, job level or device, and discretionary and mandatory access control come from file systems and government classification. Our overview of access control types compares them; most companies end up with roles plus a few attribute rules on top.

The User Access Management Procedure: Joiners, Movers and Leavers

Most access problems start at a change of status: someone starts, changes role or leaves, and nobody adjusts their access. The template's user access management procedure gives each stage a trigger, the work that follows and a deadline:

Two rules carry most of the weight. Movers lose their old access. When someone moves from sales to finance, the new manager requests the finance role and the sales access goes, so access does not pile up over a career. Leavers lose everything by the end of the last working day, at once for a dismissal, and any shared credential they knew is changed. HR tells IT the date as soon as it is known.

The template keeps the forms for each step separate so the policy stays short. New accounts start from a user account creation request form, and departures follow an IT offboarding checklist that covers accounts, devices and data hand-over. The workbook's user register records the start date, leaving date and the date access was removed, and flags any leaver whose access is still on after the deadline set in Settings.

Access Requests and Approval

Anything beyond the role (an extra system, write instead of read, a temporary project) goes through a request. The template's access request form asks for the system, the access level, the business reason and an end date for temporary access, and it needs two approvals: the person's manager, who confirms the need, and the system owner, who confirms the access level fits. Privileged access also needs the security lead.

Three rules keep the process honest: nobody approves their own request, IT grants access only after the approvals are recorded, and the request, approvals and grant date are kept as evidence. If you want a more detailed form for application access, with per-app owners and data sensitivity, use our application access request form template; this policy points to it and sets the rules it follows.

Role-Based Access and the Access Matrix

An access control matrix lists your roles down the side and your systems across the top, with an access level in each cell. It answers "what should a person in this job be able to do?", so requests, joiner set-up and reviews all compare against one table. The template uses four levels: none, read, write and admin.

Keep roles broad, usually one per team plus a few for admins, and let each system owner approve their column. Access granted outside the matrix is recorded as an individual grant with an end date, and it gets looked at in every review. The workbook's access matrix tab reads your roles from the Roles tab, offers the four levels as a drop-down and counts admin rights per role, which is a quick way to spot a role that has collected too much. For a step-by-step build, see our guide to role-based access control implementation.

Privileged Access

Privileged accounts can change systems and read everything, so they get stricter rules. Admins use a separate admin account for privileged work and their normal account for email and browsing. Every privileged account uses multi-factor authentication, is approved by the security lead and is reviewed every quarter. Where a system supports it, admin rights are granted for a limited time and removed when the task is done; our post on just-in-time access explains the approach.

A privileged access management policy is often a separate document in larger companies. For a 20 to 1,000 person organization, a section in the main policy plus the workbook's privileged accounts tab is usually enough: it lists every admin, service, break-glass and shared account with its owner, MFA status, whether the credential is in the vault, the last rotation and the last review, and it flags accounts with no MFA, no owner, an overdue review or an overdue rotation. If you need more depth, our privileged access management best practices cover vaulting and session recording.

Authentication: Passwords, MFA and Single Sign-On

The template asks for passphrases of at least 14 characters (set your own value), no reuse across systems, changes when compromise is suspected rather than on a fixed calendar, and a company password manager. If you are in PCI DSS scope, requirement 8.3.6 sets a floor of 12 characters for passwords used as an authentication factor.

Multi-factor authentication is required for remote access, email, cloud and SaaS applications, privileged accounts and any system with confidential information. Single sign-on through your central directory is preferred wherever a system supports it, because one strong sign-in with MFA then protects every connected app and one disabled account cuts off all of them. See our guides to multi-factor authentication and password rotation best practices for the details behind these choices.

Remote, Third-Party and Device Access

Remote access to internal systems goes through an approved remote access service with MFA. Third parties get a named internal sponsor, a contract that covers security duties, the least access needed and an end date, and their accounts are reviewed at every access review. Our remote desktop access policy template covers the rules for remote support sessions in more detail.

Where a person signs in from matters as much as who they are. The template's device section says confidential systems are reached only from company-managed devices, or devices that follow your device standard: a screen lock with a passcode, disk encryption, a supported and updated operating system and no unapproved software. Rules that grant or block a sign-in based on device state or sign-in risk belong in a conditional access policy, which builds on this one. Both are part of a wider zero trust architecture.

Access Reviews and Revocation

Access drifts: temporary access outlives the project and leavers slip through. Periodic reviews catch what the joiner, mover and leaver steps missed. The template sets the cadence by risk:

These cadences are example values; set your own. PCI DSS requirement 7.2.4 asks for a review of all user accounts and their privileges at least every six months, so systems in card data scope need at least the medium tier. Reviewers confirm, change or remove each person's access, sign the review record, and removals are done within a set number of days. The template includes a quarterly access review sign-off, and our user access review template gives you the full review workbook if you want to run reviews in more depth.

Revocation at termination gets its own section because it is the control auditors test most. Access is removed by the end of the last working day and at once for a dismissal, accounts are disabled first and deleted later once data is handed over, shared credentials the leaver knew are changed, and company-owned devices are returned and wiped or reassigned. Late removals are reported to the security lead.

Shared, Service and Break-Glass Accounts

Some accounts don't belong to one person, and they are where audit findings tend to cluster. The template allows shared accounts only where a system offers no alternative, with a named owner and credentials kept in a password vault. Service and API accounts have a named owner, the least access needed, no interactive sign-in and credentials rotated every 12 months or when someone who knew them leaves. Emergency or break-glass accounts exist for the day normal sign-in fails: their credentials are sealed in the vault, every use is logged and reviewed, and the credentials are changed after each use.

Logging, Exceptions and Policy Review

Systems log sign-ins, failed sign-ins, privileged actions and changes to accounts and access rights, and the logs are kept for a set period (PCI DSS 10.5 asks for at least 12 months). The template names who reviews which logs and how often.

No policy fits every case, so exceptions are part of it. Each one records the reason, the risk, compensating controls, a risk owner, the approver and an expiry date of no more than six months, and goes into the exceptions register, which flags exceptions that have expired or will soon. The enforcement section links breaches to your disciplinary policy and handles suspected misuse as a security incident. The policy owner reviews the policy at least every 12 months and after major changes to systems, teams or obligations.

ISO 27001 and NIST Versions of the Policy

You don't need two documents. The template's framework mapping lines each section up with the references auditors use, so the same policy serves an ISO 27001 audit, a SOC 2 report or a NIST-based program:

For an ISO 27001 version, keep the section numbers and add the Annex A references from the mapping to your Statement of Applicability. For a NIST version, AC-1 asks for a written policy and procedures for access control, reviewed and updated on a set schedule, so the document control table and policy review section matter as much as the rules. In both cases auditors test the policy by sampling: they pick joiners, movers and leavers from the audit period and ask for the request, the approvals, the date access was granted and the date it was removed, then compare a sample of accounts against the access matrix. A policy that names the records, plus a tracker that holds them, makes that sample quick to answer.

For the wider audit preparation, see our ISO 27001 checklist and SOC 2 compliance checklist. The mapping is a general guide: your audit scope and your auditor's reading decide what counts.

Access Control Implementation Plan

Writing the policy is the easy part. A realistic rollout for a mid-sized company takes a few weeks:

• Week 1, inventory: list your systems and name an owner for each. Export the user list from your directory and from each important system.
• Week 2, roles and matrix: define roles per team, fill in the access matrix and have each system owner approve their column.
• Week 3, clean-up: compare current access with the matrix, remove what nobody can justify, disable accounts of people who have left and find an owner for every shared and service account.
• Week 4, sign-in: turn on MFA for remote access, email, cloud apps and admins, and connect apps to single sign-on where they support it.
• Then, routine: run the first access review of your high-risk systems, brief managers and HR on the joiner, mover and leaver steps, and put the review dates in the calendar.

The workbook follows the same order, and by the end of the first month its dashboard shows overdue reviews, privileged users without MFA, leavers whose access is still on and roles with no owner.

What's in the Download

• Word policy (Access-Control-Policy-trio.so.docx): the 19-section policy with a RACI table, joiner, mover and leaver steps, review cadence by risk, a fillable access request form, a one-page access matrix example, a fillable quarterly access review sign-off and the framework mapping table, ready to edit.
• PDF version (Access-Control-Policy-trio.so.pdf): the same policy and forms, ready to print or share.
• Excel Access Control Matrix and Review Tracker (Access-Control-Matrix-trio.so.xlsx): roles with owners and risk tiers; an access matrix of roles by systems; a user register that flags overdue reviews, privileged users without MFA and leavers whose access was not removed in time; a privileged accounts tab with MFA, vault, rotation and review checks; an access review log; an exceptions register; a filled-in example; a dashboard; and sources. Formulas only, no macros.

The example shows a made-up company with 6 roles, 12 users, 6 privileged accounts and 5 access reviews, including 3 users with an overdue review, an admin without MFA, a leaver whose access is still on, a leaver removed late, a role with no owner and a service account outside the vault, so you can see every flag before you add your own data.

Get the policy, forms and tracker

Where trio.so Fits

trio.so does not run access request approvals, privileged access vaulting, just-in-time access or access review campaigns: the policy and the workbook carry those. It covers the parts of this policy that live in your identity setup and on your devices. For those parts, trio.so gives you:

• Console roles, built-in and custom, so each IT admin gets only the device management rights their job needs.
• Single sign-on with SAML 2.0 or OpenID Connect (OIDC) and multi-factor authentication at user sign-in, in the Zero Trust plan.
• User and group sync from Microsoft Entra ID and Google Workspace, and SCIM 2.0 provisioning from Entra ID, Okta and OneLogin, so joiners, movers and leavers in your directory carry through to trio.so.
• A CSV export of console members with their roles, status and last-active dates, as evidence when you review who can manage your devices.
• Passcode and disk encryption policies on company devices, with per-device policy status that shows whether each policy applied, failed or is still pending.
• Remote wipe of company-owned devices when someone leaves.

It covers Windows, macOS, Linux, iOS/iPadOS and Android from one console. Plans start at $5 per device.

Start free trial Book a demo

14-day free trial. No credit card required.

Related Templates

• User access review template: run the periodic reviews this policy calls for.
• Application access request form template: a detailed request form with per-app approvals.
• User account creation request form template: the joiner step for new accounts.
• IT offboarding checklist: every step of the leaver process.
• Conditional access policy template: sign-in rules based on device state and risk.
• IT security policy template: the umbrella policy this one sits under.
• Data classification policy template: which data needs the strictest access.

Sources. Last reviewed November 2026. Framework names, control numbers and titles are used as references only; the policy wording, mapping, formulas and example are ours. trio.so is not affiliated with or endorsed by ISO, NIST, the AICPA or the PCI Security Standards Council.

• ISO/IEC 27001:2022 (ISO catalogue page)
• NIST SP 800-53 Rev. 5, Security and Privacy Controls
• AICPA 2017 Trust Services Criteria (with revised points of focus, 2022)
• PCI DSS document library (PCI Security Standards Council)
• 45 CFR 164.312, Technical safeguards (eCFR)