# Access Control & Least Privilege

**Organization:** {{COMPANY_LEGAL_NAME}}
**Document owner:** {{POLICY_OWNER_ROLE}}
**Approved by:** {{APPROVER_NAME}}, {{APPROVER_TITLE}}
**Version:** {{VERSION}} · **Effective:** {{EFFECTIVE_DATE}} · **Next review:** {{REVIEW_DATE}}
**Classification:** Internal

---

## 1. Purpose

This policy makes sure people at {{COMPANY_LEGAL_NAME}} hold only the access they need and that access adjusts quickly as roles change, protecting {{DATA_TYPES}} on workloads in {{CRITICAL_SYSTEMS}} and across {{GEO_SCOPE}}.

## 2. Scope

This policy covers all workforce accounts, service accounts, and system roles across SaaS, cloud, and on-premise resources used by the {{LOCATION}} workforce. Only managed {{DEVICE_TYPES}} may reach production resources in {{CRITICAL_SYSTEMS}}.

## 3. Policy statements

### 3.1 Joiner-mover-leaver

Access is provisioned through a ticket with manager approval and a defined role. Privileges change promptly when a role changes, and accounts are disabled by the end of the final workday with tokens, keys, and badges collected. Identity-provider accounts follow HR status, so sign-in and access to {{CRITICAL_SYSTEMS}} and {{DATA_TYPES}} end at termination.

### 3.2 Role-based access control

We define standard roles per system and assign people to roles or groups rather than granting entitlements directly. Role definitions carry least-privilege permissions and named owners. Service accounts have an owner, a documented purpose, restricted scope, and no interactive login.

### 3.3 Privilege elevation

Temporary administrative rights need a documented business justification and expire automatically after a short window. Permanent administrative assignments need senior-management approval. Where available we use just-in-time elevation, and elevated actions on {{CRITICAL_SYSTEMS}} are logged.

### 3.4 Periodic access review

System owners review user lists at least quarterly and remove stale or excessive rights, reconciling identity-provider groups, application roles, and resource policies that affect {{CRITICAL_SYSTEMS}} and {{DATA_TYPES}}. The review date, reviewers, findings, and actions are recorded, with evidence stored in {{GEO_SCOPE}} where residency applies, and findings are tracked to closure.

### 3.5 Strong authentication

High-risk permissions and elevated sessions are protected with strong authentication so that sensitive access is both harder to abuse and fully auditable.

## 4. Roles and responsibilities

| Role | Responsibility |
|---|---|
| Executive sponsor | Accountable for the program; approves this policy |
| {{POLICY_OWNER_ROLE}} | Maintains this policy and its procedures |
| Managers | Enforce the policy within their teams |
| All personnel | Comply; report issues promptly |

## 5. Compliance and exceptions

A quarterly review should show very few orphaned accounts, and every administrative right should have an approval record; for teams larger than {{EMPLOYEE_COUNT}} we widen sampling and add random checks of privileged access to {{CRITICAL_SYSTEMS}}. Unapproved elevated access or dormant accounts are escalated to management and remediated quickly. Non-compliance may result in disciplinary action. Emergency access is time-boxed and logged with its reason, scope, and approver, and closed at the next review; exceptions require documented risk acceptance by {{APPROVER_TITLE}}, noting any residual risk to {{DATA_TYPES}}.

## 6. Review

This policy is reviewed at least annually and when significant change occurs. We use review findings to refine role definitions and automate provisioning and deprovisioning, taking into account {{INDUSTRY}} needs and obligations in {{GEO_SCOPE}}.

---

*Aligned to ISO/IEC 27001:2022. {{COMPANY_LEGAL_NAME}} is not affiliated with or endorsed by the relevant standards body; full standard text is copyrighted and is not reproduced here.*