Access control policy for small SaaS: what to write and skip

Many access control policy templates assume a company with an IT department: badge readers, a server room, a role matrix with dozens of roles, and passwords that expire every 90 days. A twelve-person SaaS company has none of that. It has an identity provider, a cloud account, a code host, a production database, and a dozen business tools.

This guide covers the access control policy that company should write: eight sections, an example line for each, what to leave out, and the public guidance from NIST behind it. The example lines are written for a fictional company we call Acme. A policy states what you require; it doesn’t prove you do it, and no policy guarantees how a customer or an auditor will judge it. Nothing here is legal advice.

What the policy is for

An access control policy answers one question: who can reach which systems and data, and how that is granted, checked, and taken away. This guide is about logical access, meaning accounts and permissions, which is what a SaaS customer’s security questionnaire asks about. Searches for “access control” also turn up door locks and badge systems. Those are physical access, and for most small SaaS companies they get one sentence (see what to skip).

NIST’s Cybersecurity Framework (CSF 2.0) puts this under Identity Management, Authentication, and Access Control. The category says access should be “limited to authorized users, services, and hardware and managed commensurate with the assessed risk of unauthorized access.” One of its outcomes, PR.AA-05, reads almost like a table of contents for the policy:

“Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties.”

If you are working toward SOC 2, our five-policies guide notes that the criteria in this area include CC6.1 through CC6.3.

What to write: eight sections

One to three pages is enough at this size. This is the outline we would use. Each section ends with an example line for Acme, a fictional company, to show the level of detail: specific enough that someone could check it.

1. Scope and owner. The systems the policy covers, by name, who owns the policy, and when it is next reviewed. “This policy covers every account in Google Workspace, AWS, GitHub, and the production database, and in the business tools listed in the system inventory. The CTO owns it and reviews it each January.”
2. Accounts. One person, one account. No shared logins for people. Accounts that software uses (service accounts and API keys) each have a named owner. “Every person has their own account. Service accounts are listed in the system inventory with an owner, and their keys live in the secrets manager, never in code.”
3. Signing in. Single sign-on where a tool supports it, multi-factor authentication (MFA) everywhere it matters, and a password rule that matches NIST’s current guidance (below). “Staff sign in to company tools through Google Workspace where the tool supports it. MFA is required on Workspace, AWS, GitHub, and the password manager. Administrators use a security key.”
4. Granting access. Who approves a request, where the approval is recorded, and the default: the least access the job needs. “Access beyond a new hire’s role group is requested in the access channel and approved there by the CTO. New staff start with their role group’s access and nothing more.”
5. Admin and production access. Who holds it, by name or by role, how the cloud provider’s root account is protected, and what happens in an emergency. “Two engineers hold production access. Nobody signs in as the AWS root user for daily work; its credentials sit in the password manager, protected by a security key, and any use is reported to the CTO.”
6. Removing access. The window you will meet when someone leaves or changes role, and who does it. “When someone leaves, the CTO suspends their Workspace account and removes them from AWS and GitHub by the end of their last working day, and records it on the offboarding checklist.”
7. Access reviews. How often someone checks who has access, what they check, and where the record goes. “Each quarter, the CTO exports the admin and production access lists, checks them against the staff list, fixes what is wrong, and saves the export with the date.”
8. Exceptions. What happens when a tool can’t do SSO or MFA: a written exception with an owner, a workaround, and an end date. “Exceptions are approved by the CTO, recorded in the risk register with a compensating control, and expire after twelve months.”

Separation of duties, at twelve people

PR.AA-05 names separation of duties, and a small team can’t split every job between different people. In our judgment, a workable version is this: the person who grants admin access is not the only person who ever looks at the admin list. A founder can review the CTO’s grants once a quarter. Write down the version you use, and say plainly where one person holds two roles.

The password rule, from NIST

NIST SP 800-63B-4 (July 2025) is written for federal systems, and it says it “may be used by nongovernmental organizations on a voluntary basis.” Its password rules are a sound public reference for a small company too. In section 3.1.1.2:

• Length. At least 15 characters for a password used on its own. A password used as part of MFA may be shorter, but at least eight characters.
• No composition rules. The systems that check passwords “SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types)”.
• No scheduled changes. They “SHALL NOT require subscribers to change passwords periodically.” They must force a change when there is evidence the password has been compromised.

The same document is plain about MFA methods: “Passwords are not phishing-resistant,” and codes you type in, such as text-message and authenticator-app codes, “SHALL NOT be considered phishing-resistant.” Phishing resistance, it says, “requires single- or multi-factor cryptographic authentication”, which is how security keys and passkeys work. In our view, codes are still far better than a password alone, and a sensible policy for a small team requires MFA everywhere and security keys or passkeys for administrators.

What to skip

A policy that promises something you don’t do is worse than a short one, because a reviewer can lay it next to your questionnaire answers and your records. Our five-policies guide covers that in general. For access control, these are the sections we would cut or shrink:

• Passwords that expire every 60 or 90 days, and rules that demand a capital letter, a number, and a symbol. NIST says not to do either (above).
• Badge readers, visitor logs, and server rooms, if you have no office and no servers of your own. CSF 2.0 asks that physical access be managed “commensurate with risk” (PR.AA-06). One honest sentence can do it: your cloud provider runs the data centers, and laptops are covered by the Acceptable Use Policy.
• A role matrix for roles you don’t have. Write the three or four access groups you actually use (engineering, support, everyone), not a grid built for a company of five hundred.
• Tools you haven’t bought. No privileged access management platform, identity governance suite, or “real-time monitoring of all access” unless you run it.
• An office network section copied from an on-site template: VPN concentrators, firewall rule reviews, and network segments for a network you don’t operate.
• Click-by-click steps. How to remove someone in Google Workspace belongs in a checklist or runbook. The policy states the rule and the window; the checklist can change without a new policy version.
• “Immediately”, “always”, and “all” where they aren’t true. “By the end of their last working day” is a promise you can keep; “immediately” is one somebody will test.

Make every number one you meet

An access control policy commits you to a few numbers: the window for removing a leaver’s access, how often you review access, the minimum password length, and how long an exception lasts. Each one is something a customer or an examiner can test against your records.

Pick the numbers you will hit on a bad week, not a good one. If your review will really happen twice a year, write twice a year, and plan to explain why. Then make your questionnaire answers say the same thing, because those questionnaires ask who has access to what and how you control it.

What a policy doesn’t do

• It doesn’t show that you follow it. The offboarding checklist, the saved review exports, and the exception register do that. A policy without them is a statement of intent.
• It doesn’t satisfy SOC 2 or a customer by itself. An independent CPA firm examines your controls and issues any SOC 2 report, and each customer decides what is enough for them.
• If a control isn’t in place yet, such as MFA on one old tool, don’t write it as if it were. Record the exception, and if a questionnaire asks, our guide to answering when a control is missing shows how to say so.

A sensible order for this week

1. List your systems: identity provider, cloud, code host, production data, password manager, and the business tools that hold customer data.
2. Note who has admin and production access in each, and whether MFA is on.
3. Write the eight sections, with numbers you already meet. Where you don’t meet one yet, write an exception with an end date.
4. Run your first access review now and save the result, so the policy has a record behind it from day one.
5. Put the next review and the policy’s annual review on a calendar, with a name next to each.

If you would rather hand off the writing

Blank Slate Creative, LLC does readiness and documentation only. We never audit or attest. This guide draws on public guidance from NIST and on our own judgment, not on client work.

• The five core policies, Access Control among them. Information Security, Access Control, Incident Response, Acceptable Use, and Data Classification, tailored to your intake answers: your cloud, your identity setup, your team size, and how you work, for a flat $85. Order the five policies, $85.
• Or fill it in yourself. The same five policies as editable templates, with a short guide to filling them in, for $29. Not tailored, and no revisions. See the template bundle.
• Something broader, by quote. A SOC 2 gap analysis, a control matrix, or a policy set beyond the five. Tell us what you need.
• A person reads your policies. Each custom policy set is read before it is sent to you. We can’t promise how a customer or an auditor will judge them.
• See it first. The home page has two full sample policies, written for a fictional company. We have no client work to show yet, and would rather say so.

Sources

All read on 2026-10-06.

• NIST, The NIST Cybersecurity Framework (CSF) 2.0 (NIST CSWP 29, February 26, 2024), Protect function, category Identity Management, Authentication, and Access Control (PR.AA), subcategories PR.AA-05 and PR.AA-06.
• NIST, SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (July 2025), sections 3.1.1, 3.1.1.2, and 3.2.5, and the notice on use by nongovernmental organizations. Read in the NIST PDF.