Pentest Today.
Start free
security policy

Access Control Policy

access-control.md·SOC 2 · CC6.1

Pentest Today generates an Access Control Policy tailored to your stack — least-privilege rules, joiner-mover-leaver procedures, and MFA requirements enterprise security reviewers look for, mapped to CC6.1.

Generate this policyBrowse all policies

What's in the policy

Defines how identities are provisioned, authenticated, authorized, and deprovisioned across your systems.

✓Role-based access and least-privilege principles
✓Onboarding, transfer, and offboarding procedures
✓Multi-factor authentication requirements
✓Privileged and administrative access management
✓Periodic access reviews and recertification
✓Remote and third-party access controls
Mapped toSOC 2 (CC6.1)ISO 27001 (A.5.15)HIPAANIST CSF

What the document actually says

These are the standing requirements every generated copy of the document is written from — the clause text itself, not a description of it. The document you receive is drafted on top of them: it expands on them and fills the current-state detail from your intake, and the generator is instructed to keep them, to state them fully, and never to claim a certification or invent a fact you did not supply.

Account management

- Every user is issued a unique, individually attributable account; shared or generic accounts are prohibited except for approved, tightly controlled service accounts. - Access is provisioned only after documented approval from the resource owner or the user's manager, based on role. - Access follows role-based access control (RBAC); entitlements are grouped by role and granted at the group level wherever feasible. - Access is deprovisioned within 24 hours of termination and promptly adjusted on any role change.
SOC 2 CC6.1 · ISO 27001 A.5.16, A.5.18 — every account is attributable to one person, granted by role after a documented approval, and removed on a stated clock.

Authentication standards

- Multi-factor authentication (MFA) is required for all access to production systems, administrative interfaces, source control, cloud consoles, and email, and for all remote access. - Passwords are at least 12 characters, screened against known-breached password lists, and are not subject to mandatory periodic rotation (rotation is required only on suspected compromise), consistent with modern NIST guidance. - Single sign-on (SSO) with an identity provider is used wherever supported, to centralize authentication and enable rapid deprovisioning. …
SOC 2 CC6.1 · ISO 27001 A.5.17, A.8.5 — a second factor on every production and administrative path, and password rules that follow current NIST guidance instead of 90-day rotation.

Access reviews

Access to production systems and sensitive data is reviewed at least quarterly by resource owners; all other access is reviewed at least annually. Reviews confirm that each user's access remains appropriate to their role. Excess or stale access is revoked, and reviews are documented and retained.
SOC 2 CC6.2/CC6.3 · ISO 27001 A.5.18 — entitlements are re-approved on a stated schedule by the person who owns the resource, and the review itself is retained as evidence.
AWS + Okta + GitHub

Filled in for a real stack

Placeholder

Authentication method: To be confirmed. Multi-factor authentication: To be confirmed.

Resolved

Authentication method: Okta SSO (SAML) fronting AWS IAM Identity Center and the GitHub organization; no local passwords on production systems. Multi-factor authentication: enforced in Okta for every user, with WebAuthn security keys required for the accounts holding AWS administrator permission sets and GitHub organization-owner rights.

What the auditor asks for alongside it

A current list of everyone with production access, and the approval behind each one.
A dated export from your identity provider, read against the policy's account-management section. The policy names who approves a grant — the resource owner or the user's manager — and requires the approval to be documented, which is what the sampled rows are checked against.
The systems and data the policy is supposed to protect, and where the trust boundary sits.
The system architecture and data-flow diagram generated from the same intake. It names your authentication provider, your data stores, and the third parties outside the boundary, so the policy's scope is a drawing rather than a sentence.
Evidence that authentication holds up from outside, not only on paper.
The penetration test report. Reachable login, admin, and API surfaces on your approved targets are tested, and every finding is filed under a severity, with evidence and reproduction steps recorded where the finding has them.
Proof that one named leaver actually lost access inside the window the policy promises.
Your deprovisioning ticket and identity-provider log for that person. The policy sets the window and the approver; the ticket is the record an auditor samples against it.

Where these documents go stale

An access control policy is accurate on the day it is approved and drifting by the end of the month. Every hire, contractor, promotion, and departure moves an entitlement. Every new SaaS tool arrives with its own admin console and its own owner, and it is usually adopted by a team rather than granted by IT. Every new production account, CI runner, and service token widens the boundary the document claims to describe. The prose does not go wrong; the reality behind it does. What re-validates it is the quarterly access review the policy already requires, run against a fresh export from your identity provider, plus a regenerated architecture diagram when the stack changes and a new external test after anything changes about who can reach production. Regenerate the document when the intake answers change, not on its anniversary.

From intake to enterprise-ready in three moves
01

Tell us about your stack

Answer a short intake — cloud, data types, tools. No agents to install.

02

We generate a tailored draft

Not a blank template: a document written for your environment and pre-mapped to controls.

03

Review, edit, and share

Export it or attach it straight to an enterprise security review or questionnaire.

Access Control Policy, answered

What is an access control policy?

An access control policy defines how access to systems, applications, and data is requested, approved, provisioned, reviewed, and revoked, so that access is limited to authorized individuals with a legitimate business need. Privileged access is granted sparingly, only to personnel who require it. Auditors read the document early, because every other control assumes it.

What should an access control policy include?

A complete access control policy covers scope, role-based access control, unique attributable accounts, documented approval before provisioning, MFA on production and administrative paths, password standards, privileged-access rules, a review cadence, and a deprovisioning clock. The generated version also carries a roles-and-responsibilities table and an exceptions process, which is what reviewers check when a control cannot be met.

Does SOC 2 require an access control policy?

Yes. Logical access sits at the center of the CC6 Common Criteria, so an auditor asks for the written policy, the approvals behind current access, and evidence that the reviews it promises actually happened. The generated document is written against CC6.1 and mapped to ISO 27001 A.5.15, which is the pairing most reviewers work from.

How often do access reviews have to happen?

Quarterly for production systems and sensitive data, annually for everything else, is the cadence most auditors expect and the one the generated policy sets. The review has to be documented — a dated export, who reviewed it, and what was revoked. A review nobody wrote down counts as no review.

Is multi-factor authentication required for SOC 2?

SOC 2 does not name MFA explicitly; the Trust Services Criteria are principles rather than a checklist. In practice, auditors and enterprise security reviewers treat it as the expected control and write up its absence. The generated policy requires it for production systems, administrative interfaces, source control, cloud consoles, email, and all remote access.

Can I just use a free access control policy template?

A blank template leaves every decision unmade — the review cadence, the deprovisioning window, the password standard — and a reviewer reads an unmade decision as a document nobody owns. A generated Access Control Policy arrives with those decisions already made, and its Current implementation section filled from your real environment rather than left as a bracket.

How does Pentest Today generate the policy?

Answer a short intake about your stack and we generate a tailored draft — not a blank template — pre-mapped to the controls your framework requires. You review, edit, and export it.

Can I edit the generated policy?

Yes. Every document is a starting draft you can edit, brand, and export. It's written to be review-ready but stays fully under your control.

Free · no account

Start your Pentest

Our agent swarm and human experts test your endpoints and deliver an audit, fast.

Start your PentestHow it works

More from the policy library

cryptography.md→

Cryptography Policy

data-handling.md→

Data Handling & Classification Policy

incident-response.md→

Incident Response Policy

business-continuity.md→

Business Continuity & Disaster Recovery Plan

vendor-risk.md→

Vendor Risk Management Policy

change-management.md→

Change Management Policy

Generate your full security policy pack.

Get the access control policy plus everything else an enterprise security review asks for — generated from your real environment.

Get startedBrowse all policies