# Access Control & Least Privilege Policy

**Document owner:** [Owner/Role]  
**Approved by:** [Steering Committee / CISO]  
**Effective date:** [YYYY-MM-DD]  
**Review cadence:** [Annually]

---

## 1. Purpose & Scope
This policy establishes mandatory requirements for granting, reviewing, and revoking access to [Organization] systems and data, based on least privilege and need-to-know. It applies to all employees, contractors, vendors, and service accounts, and complements the account types defined in [Authentication Policy §3](authentication_policy.md).

---

## 2. Roles & Responsibilities
- **Access Owner (system/data owner):** Approves access requests and grants for their system.  
- **Manager:** Approves role-appropriate access for direct reports; initiates leaver/mover requests.  
- **IT/IAM:** Provisions, reviews, and revokes access per this policy.

---

## 3. Policy Statements

### 3.1 Least Privilege & Need-to-Know
- Access **must** be granted at the minimum level required for a person's role.  
- Standing access to TLP:AMBER+STRICT/RED data (per [Data Classification Policy](data_classification_policy.md)) **must** be justified and time-bound where feasible; prefer just-in-time elevation.

### 3.2 Role-Based Access Control
- Access **must** be granted through defined roles mapped to job function, not ad hoc individual grants.  
- Direct/ad hoc grants outside a defined role **must** be logged, time-bound, and reviewed at next access review.  
- Role definitions **must** be documented and owned (see [Authentication Policy §2.14](authentication_policy.md)).

### 3.3 Joiner-Mover-Leaver Lifecycle
- **Joiner:** Access provisioned per role on or after start date; no standing access before identity verification completes.  
- **Mover:** Access **must** be updated within **5 business days** of a role change; prior role's access **must** be removed, not just supplemented.  
- **Leaver:** Access **must** be revoked within **24 hours** of termination (immediately for involuntary termination), consistent with [Vendor Risk Management Policy §3.6](vendor_risk_management_policy.md) for third parties.

### 3.4 Separation of Duties
- Conflicting duties (e.g., payment initiation and approval, code deployment and production access approval) **must not** be held by the same individual without a documented compensating control.  
- A separation-of-duties conflict matrix **must** be maintained for financial and production-critical systems.

### 3.5 Periodic Access Reviews
| Account Type (per Authentication Policy §3) | Review Cadence |
|---|---|
| Privileged/Admin | Quarterly |
| Standard User | Semi-annually |
| Third-party/Vendor | Per contract term, minimum annually |
| Service/Machine | Annually, plus on owner change |

- Reviews **must** be performed by the Access Owner, not solely by IT.  
- Unreviewed access past the cadence **must** be treated as a finding and escalated.

### 3.6 Emergency / Break-Glass Access
- Governed by [Authentication Policy §3](authentication_policy.md) (Break-glass account type) and [§2.13](authentication_policy.md) (drills).

### 3.7 AI Agent Capability Scoping
- For AI Agent (Autonomous) accounts (per [Authentication Policy §3.1](authentication_policy.md)), RBAC role membership alone **is not sufficient** — the tool/plugin/MCP-server allow-list reachable by the agent **is** its privilege boundary and **must** be reviewed and approved with the same rigor as a role grant.  
- A sub-agent's capability set **must** be a subset of its parent's; delegation **must not** widen scope.  
- Agent capability grants **must** be reviewed at the same cadence as Privileged/Admin access (§3.5) given the runtime-decided, non-enumerable nature of agent action sequences.

### 3.8 Enforcement
- Violations **may** result in disciplinary action or revocation of access.  
- Systems unable to support role-based provisioning or timely revocation **must** be remediated or formally excepted with CISO approval.

---

## 4. Antifragility Alignment
This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**.

| Pillar | Applied In | How |
|---|---|---|
| **1. Structural Decoupling** | §3.2 | Role definitions are documented independent of any single IAM vendor's proprietary grouping model |
| **2. Optionality Preservation** | §3.1 | Just-in-time elevation preferred over standing access — preserves the option to say no without an offboarding project |
| **3. Stress-to-Signal Conversion** | §3.5 | Unreviewed access past cadence is a tracked finding, not silence |
| **4. Sovereign Intelligence** | §3.2 | Roles and SoD matrix documented and owned, not held as tribal "ask Dave" knowledge |
| **5. Asymmetric Payoff Design (Barbell)** | §3.5 | Quarterly review concentrated on privileged accounts; standard users get a lighter semi-annual cadence |

---

## 5. References
- **[NIST SP 800-53 Rev. 5, Security and Privacy Controls (AC family)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)**  
- **[CIS Controls v8.1 (Controls 5 & 6)](https://www.cisecurity.org/controls/v8-1)**  
- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)**