An access control policy answers a deceptively simple question: who is allowed to reach each system, account and dataset—and why? Without a documented answer, permissions tend to accumulate. Staff change roles, contractors finish projects, shared credentials persist and former employees remain connected to tools nobody remembered they used.
A useful small-business policy does not need to imitate a large enterprise manual. It needs clear ownership, a repeatable approval path, sensible authentication requirements and a reliable way to remove access. The policy should be short enough to use and specific enough to test.
NIST’s Cybersecurity Framework 2.0 places identity management, authentication and access control within its Protect function. CIS Controls 5 and 6 separately emphasize managing accounts and managing the privileges attached to them. The practical distinction matters: knowing that an account exists is not the same as knowing that its access is appropriate.
Key takeaways
• Start with an inventory of people, service accounts, systems and data—not policy prose.
• Grant access for a documented business need, at the least privilege required for the role.
• Use unique accounts and multifactor authentication; sharply limit administrator privileges.
• Connect onboarding, role changes and offboarding to one accountable workflow.
• Review access on a risk-based schedule and measure both coverage and revocation speed.
What an access control policy should accomplish
The policy should convert security principles into everyday decisions. It defines who may request access, who approves it, how identity is verified, which authentication controls apply, when privileges expire and how exceptions are handled.
It also creates evidence. A business should be able to explain why a user has access to a customer database, who approved it and when it was last reviewed. That evidence supports incident response, customer assurance and many compliance programmes, but this template does not itself establish legal or regulatory compliance.
Policy, standard and procedure are different
Document | Purpose | Example
Policy | States the rule and accountability | Access must be based on a documented business need
Standard | Defines a measurable requirement | MFA is required for email, cloud administration and remote access
Procedure | Explains how work is performed | HR opens an offboarding ticket; IT disables accounts and records evidence
Keeping these layers distinct makes maintenance easier. The policy can remain stable while product-specific procedures change.
Use the ACCESS framework
The original ACCESS framework keeps the programme compact:
- A — Account for identities and resources: list employees, contractors, service accounts, applications, devices and important data.
- C — Classify roles and sensitivity: group permissions around job needs and classify resources by business impact.
- C — Control with least privilege: give the smallest practical set of rights and separate routine work from administration.
- E — Enforce strong authentication: use unique identities, MFA and approved recovery methods.
- S — Schedule lifecycle actions: make joiner, mover and leaver events trigger timely access changes.
- S — Scrutinize and record: review access, exceptions and privileged activity; preserve evidence.
The sequence is deliberate. A company cannot confidently apply least privilege until it knows which accounts and resources exist.
Step 1: build the access inventory
Begin with the technology asset inventory, identity provider, email directory, payroll or HR roster, password manager, SaaS billing records and vendor list. Reconcile them rather than trusting one source.
At minimum, record:
- user or service-account name;
- owner and manager;
- employment or contractor status;
- system or dataset;
- role and privilege level;
- business justification;
- approver;
- MFA status;
- grant, expiry and last-review dates;
- disposition when access ends.
Service accounts deserve special attention. They may run integrations without a person signing in, so each needs a named owner, documented purpose, protected credential and review date. “System account” is not an owner.
Find the first high-risk gaps
Prioritize accounts that combine broad privileges, sensitive data and weak oversight. Examples include shared administrator credentials, inactive accounts, accounts without MFA, contractor access with no expiry and integrations owned by departed staff.
Do not wait for a perfect inventory before acting on an obvious exposure. Remove or contain high-risk access through the normal approval and change process, then document what was done.
Step 2: design roles around work
Role-based access control groups permissions around responsibilities such as sales representative, support lead, payroll administrator or website editor. A role should describe what someone needs to do—not their seniority or perceived trustworthiness.
For each role, define:
- systems and data it may access;
- read, create, edit, export, approve or delete rights;
- whether elevated access is ever required;
- who owns the role;
- incompatible permissions;
- review frequency.
Avoid a single “manager” role that quietly unlocks every application. A department manager may need approval authority without needing direct access to all records. Separating approval from execution can reduce error and misuse.
Apply least privilege without blocking work
Least privilege means giving a user only the access needed for assigned tasks. It does not mean making normal work impossible. Start with a workable baseline role, add time-limited elevation for exceptional tasks and use feedback to refine the role.
The FTC advises businesses to limit sensitive information on a need-to-know basis and use separate accounts to control access. NIST and CIS guidance similarly treat access as something to authorize, manage and revoke across its lifecycle.
Step 3: set authentication and administrator rules
Every person should use a unique account. Shared logins weaken accountability and make offboarding harder. Where a legacy system requires a shared credential, treat it as a documented exception: store it in an approved password manager, restrict membership, log use where possible and set a replacement plan.
Require MFA at least for email, remote access, cloud consoles, password managers, source-code systems and administrator accounts. Prefer phishing-resistant methods where supported. Recovery processes also need control; an attacker who can bypass MFA through weak help-desk recovery still has a path in.
Administrators should use separate accounts for elevated work and ordinary activity. Daily email and browsing should not happen from an administrator session. Limit who can create accounts, change MFA methods, issue API keys, alter logs or grant other administrators.
Step 4: connect access to the employee lifecycle
Joiners
Grant a pre-approved baseline role after the person’s identity, manager and start date are confirmed. Access outside the baseline requires a business justification and resource-owner approval. Avoid issuing access “just in case.”
Movers
A promotion, transfer or project change should trigger both additions and removals. Permission accumulation often happens because teams add the new role but never withdraw the old one. The manager and resource owner should review the combined access for conflicts.
Leavers
Disable interactive access at the agreed termination time. Revoke active sessions, remote access, tokens and recovery methods; rotate shared secrets the person knew; transfer file and automation ownership; and preserve records according to the retention policy. Urgent or involuntary departures may require a coordinated, immediate sequence.
Contractors and temporary access
Every temporary grant should have an owner and an expiry. Do not rely on a future reminder alone; use an automatic expiry where the system supports it. Renew only after the business need is confirmed.
Step 5: govern exceptions
An exception is a temporary, approved deviation—not a permanent shortcut. Record the rule being bypassed, business reason, affected resource, risk, compensating control, approver, start date and expiry.
For example, if an older system cannot support MFA, compensating controls might include network restriction, a unique long passphrase, tighter monitoring and a dated replacement plan. Whether those controls are sufficient depends on the system and risk; the policy should not declare every workaround acceptable.
Copyable access control policy template
. Purpose
This policy ensures that access to [Company] systems, devices and information is authorized, appropriate to business need, protected and removed when no longer required.
. Scope
This policy applies to employees, contractors, temporary workers, service accounts, vendors and any other identity that can access company resources.
. Ownership
The [Policy Owner] maintains this policy. Resource owners approve access to their systems and data. Managers validate business need. IT or the designated administrator implements approved changes and retains evidence.
. Core rules
- Access must be linked to a unique identity unless a documented technical exception exists.
- Access must be approved by the user’s manager and the relevant resource owner.
- Permissions must follow least privilege and be based on the user’s current role.
- MFA is required for [list covered services and account types].
- Privileged work must use a separate administrative account where supported.
- Shared, dormant and default accounts are prohibited unless formally approved and controlled.
- Temporary access must have a named owner and expiry date.
- Role changes must trigger removal of access no longer required.
- Departing-user access must be disabled at [defined timing] and sessions and tokens revoked.
- Access reviews must occur at the frequency defined in the review schedule.
. Review schedule
- Privileged and high-impact access: [frequency]
- Access to sensitive customer, employee or financial data: [frequency]
- Standard application access: [frequency]
- Service and integration accounts: [frequency]
Choose frequencies from risk, contractual obligations and applicable law. Do not copy an interval without considering the environment.
. Exceptions
Exceptions require documented risk acceptance by [role], defined compensating controls and an expiry no later than [maximum period]. Expired exceptions are removed or re-approved.
. Monitoring and enforcement
The company may log access and administrative activity for security, operations and compliance, subject to applicable law and internal privacy requirements. Violations are handled under [disciplinary or vendor-management process].
. Review and approval
The policy owner reviews this document at least [frequency] and after significant technology, organizational, contractual or legal change. Approved by [name/role] on [date].
A simple access matrix
Resource | Role | Permission | Approver | MFA | Expiry | Review cadence
Customer support system | Support agent | Read/write assigned cases | Support owner | Yes | Employment end | Risk-based
Website CMS | Editor | Draft/edit, no plugin admin | Content owner | Yes | Employment end | Risk-based
Cloud console | Cloud administrator | Elevated administration | Technology owner | Phishing-resistant where supported | Time-limited or role end | Frequent
Analytics platform | Contractor analyst | Read selected reports | Data owner | Yes | Project end | Before renewal
The table is an example, not a universal entitlement model. Replace it with the business’s actual resources and conflicts.
Review checklist
For every review cycle:
- reconcile active identities with the current workforce and vendor roster;
- confirm each account has a named owner;
- identify inactive, duplicate, default and shared accounts;
- verify MFA for covered accounts;
- check privileged roles and separate admin identities;
- test that temporary grants and exceptions have not expired;
- compare current access with the person’s current role;
- review service accounts, API keys and application integrations;
- confirm recent leavers were disabled and ownership transferred;
- record reviewer, date, decision and remediation owner.
Metrics that reveal control quality
Avoid a single vanity score. Use a small set of operational measures:
Review coverage
accounts reviewed ÷ active accounts in scope × 100
Orphan-account rate
accounts without a valid owner ÷ active accounts × 100
MFA coverage
covered accounts with MFA ÷ all accounts required to use MFA × 100
Revocation latency
Time from the authorized termination or removal point to verified disablement.
Track the denominator and scope with every percentage. A 100% review rate is meaningless if an entire SaaS application was missing from the inventory.
A 30-day rollout plan
Days 1–7: discover
Name the policy owner, compile the workforce and vendor roster, inventory critical systems and surface shared, privileged, inactive and unmanaged accounts.
Days 8–14: design
Define baseline roles, resource owners, approval paths, MFA coverage, administrative-account rules, exception fields and a risk-based review schedule.
Days 15–21: implement
Address urgent gaps, enable MFA where feasible, separate administrative access, add expiry to temporary grants and connect the HR or management workflow to access tickets.
Days 22–30: prove
Run a sample joiner, mover and leaver exercise. Review one critical system from inventory to evidence. Correct gaps, obtain policy approval and schedule the next review.
Frequently asked questions
Is an access control policy only for regulated companies?
No. Any business using email, cloud applications, customer data or shared devices needs a consistent way to grant and remove access. Regulatory and contractual details vary, so seek qualified advice for specific obligations.
How often should access be reviewed?
Use a risk-based schedule. Privileged, sensitive and temporary access usually deserves more frequent scrutiny than low-impact standard access. Also trigger reviews after role changes, reorganizations, incidents and major system changes.
What is the difference between account management and access management?
Account management covers the identity or credential itself. Access management covers what that identity can reach and do. A business needs both: an active account may still have excessive permissions.
Can a small business use a shared administrator account?
Unique administrator identities are preferable because they support accountability and targeted removal. If a system technically requires sharing, document the exception, protect the credential, restrict and log use, rotate it after relevant departures and plan to replace the limitation.
