Access Control Policy¶
Document ID: AUL-POL-15 Version: 1.0 Classification: Internal Owner: Chief Technology Officer / ISSM Effective: TBD-YYYY-MM-DD Next Review: TBD-YYYY-MM-DD
1. Purpose¶
This policy establishes access control requirements for all Aulendur Labs information systems. It defines how access is authorized, provisioned, reviewed, and revoked to enforce the principles of least privilege and need-to-know. This policy implements NIST SP 800-171 Rev. 3 controls 03.01.01 (Account Management), 03.01.02 (Access Enforcement), 03.01.04 (Separation of Duties), and 03.01.05 (Least Privilege).
2. Scope¶
This policy applies to:
- Personnel: All employees, contractors, interns, advisors, and service accounts with logical access to Aulendur systems.
- Systems: All Aulendur systems — production (Linode, Cloudflare, AWS, Modal), corporate IT (Google Workspace, GitHub, 1Password, Slack), development environments, and the planned CUI Enclave (AWS GovCloud).
- Data: All classification levels — Public, Internal, Confidential, CUI, and ITAR-controlled technical data.
- Access types: Interactive user accounts, service accounts, API keys, SSH keys, and privileged access.
3. Roles & Responsibilities¶
| Role | Responsibility |
|---|---|
| Chief Executive Officer (CEO) | Approves this policy; authorizes access exceptions for the CTO/ISSM's own access. |
| Chief Technology Officer (CTO) / ISSM | Owns this policy; approves all access requests; conducts quarterly access reviews; maintains the access control baseline. |
| System Owners | Implement access controls within their systems per this policy; report unauthorized access. |
| Data Owners | Authorize access to data under their stewardship based on need-to-know. |
| All Personnel | Request only necessary access; report unauthorized access; cooperate with access reviews. |
4. Policy Statements¶
4.1 Account Management¶
4.1.1 The CTO/ISSM shall manage all user accounts throughout their lifecycle: creation, modification, disabling, and removal (NIST SP 800-171 R3 03.01.01).
4.1.2 Account types used at Aulendur:
| Account Type | Description | Governance |
|---|---|---|
| Individual user account | Named account tied to one person (firstname.lastname) | CTO/ISSM approves; provisioned per Onboarding Policy |
| Privileged account | Account with administrative rights (Google Admin, GitHub Org Owner, root/sudo, AWS IAM admin) | CTO/ISSM approves; logged; reviewed quarterly |
| Service account | Non-interactive account for automated processes (CI/CD, API integrations) | CTO/ISSM approves; named descriptively; no interactive login; credential rotation per Password & Credential Policy (forthcoming) |
| Shared/generic account | PROHIBITED — all accounts shall be individually attributable | N/A |
| Emergency/break-glass account | Account for emergency access when primary authentication is unavailable | CTO/ISSM creates; credentials sealed; usage triggers immediate alert and post-use review |
4.1.3 The CTO/ISSM shall disable accounts within 24 hours of: (a) personnel separation (immediate for involuntary, see Onboarding & Offboarding Policy), (b) account inactivity exceeding 45 calendar days, or (c) direction from the CEO or ITPSO.
4.1.4 The CTO/ISSM shall review all active accounts quarterly to verify: (a) each account corresponds to a current, authorized individual or approved service, (b) entitlements match current role assignments, and (c) no orphaned or dormant accounts exist. Findings shall be remediated within 10 business days.
4.2 Access Enforcement¶
4.2.1 All systems shall enforce access controls that restrict access to authorized users, processes, and devices, and to authorized types of transactions and functions (NIST SP 800-171 R3 03.01.02).
4.2.2 Access enforcement mechanisms at Aulendur:
| System | Access Enforcement Mechanism |
|---|---|
| Google Workspace | Google Admin organizational units, groups, and Drive sharing permissions |
| GitHub (AulendurForge) | Organization teams, repository permissions (Read/Write/Admin), branch protection rules |
| 1Password Business | Vault membership and item-level permissions |
| Slack | Channel membership (public/private), workspace roles |
| Linode | User accounts with role-based access; SSH key authentication |
| AWS | IAM users, roles, and policies; least-privilege IAM policy design |
| Cloudflare | Account roles (Admin, Member); API token scoping |
| Modal | Workspace membership |
| CUI Enclave (planned) | AWS GovCloud IAM with mandatory MFA; US-person verification |
4.2.3 Access to CUI shall require: (a) individual named account, (b) CTO/ISSM authorization, (c) multi-factor authentication (YubiKey FIDO2), (d) verified need-to-know, and (e) US-person status confirmation (for export-controlled CUI).
4.3 Least Privilege¶
4.3.1 All access shall be provisioned on a least-privilege basis: personnel shall receive only the minimum access necessary to perform their assigned duties (NIST SP 800-171 R3 03.01.05).
4.3.2 Default access for new accounts shall be the minimum set defined in the Onboarding & Offboarding Policy. Additional access shall require a documented request with business justification and CTO/ISSM approval.
4.3.3 Privileged access (administrative rights) shall be: (a) granted only when standard access is insufficient for the task, (b) limited to the specific systems and functions requiring elevation, (c) used only for administrative tasks (not routine work — separate accounts for admin vs. daily use where supported), (d) logged and reviewed quarterly.
4.3.4 GitHub branch protection on main shall require at least one approving review for merge. Direct pushes to main are prohibited.
4.4 Separation of Duties¶
4.4.1 Access controls shall enforce separation of duties where feasible at Aulendur's ~5-person scale (NIST SP 800-171 R3 03.01.04). Enforced separations:
- (a) Code author shall not merge their own pull requests to
main(GitHub branch protection). - (b) Access provisioning (CTO/ISSM) shall be independently reviewed (CEO quarterly review).
- (c) Financial transactions shall require dual authorization (CEO + one other).
4.4.2 Where separation of duties cannot be technically enforced due to team size, compensating controls shall be documented per the Roles & Responsibilities Policy and tracked in the Exception Register.
4.5 Access Request and Approval¶
4.5.1 Access requests shall be submitted to the CTO/ISSM via Slack or email, specifying: (a) the system(s) and level of access requested, (b) the business justification, (c) the data classification that will be accessible, and (d) the duration (permanent or time-bounded).
4.5.2 The CTO/ISSM shall verify need-to-know and role appropriateness before approving. Access to CUI or ITAR data additionally requires Data Owner concurrence.
4.5.3 The CTO/ISSM shall provision approved access within 2 business days of approval.
4.6 Access Reviews¶
4.6.1 The CTO/ISSM shall conduct access reviews per the following schedule:
| Review Type | Scope | Frequency |
|---|---|---|
| Privileged account review | All accounts with admin/root/elevated access | Quarterly |
| CUI access review | All accounts with CUI/ITAR data access | Quarterly |
| Full entitlement review | All accounts across all systems | Semi-annually |
| Service account review | All non-interactive accounts, API keys, SSH keys | Quarterly |
4.6.2 Access entitlements not justified by current role assignment shall be revoked within 5 business days of review finding.
4.6.3 Access review results and remediation actions shall be documented and retained as CMMC assessment evidence.
4.7 Temporary and Emergency Access¶
4.7.1 Temporary access (time-bounded) shall be granted with an explicit expiration date. The CTO/ISSM shall implement automated expiration where the system supports it; otherwise, the CTO/ISSM shall manually revoke access on the expiration date.
4.7.2 Emergency (break-glass) access to production systems may be used when normal access paths are unavailable during a critical incident. Emergency access shall be: (a) logged, (b) reported to the CTO/ISSM within 4 hours, and (c) reviewed and documented within 24 hours.
5. Standards & Procedures Referenced¶
The following companion documents implement this policy:
- Roles & Responsibilities Policy
- Onboarding & Offboarding Policy
- Identity & Authentication Policy (forthcoming)
- Password & Credential Policy (forthcoming)
- MFA Policy (forthcoming)
- Privileged Access Management Policy (forthcoming)
- Access Review SOP (forthcoming)
6. Compliance & Enforcement¶
Violations of this policy may result in immediate access revocation and disciplinary action up to and including termination. Unauthorized access to systems or data — regardless of intent — constitutes a policy violation and may trigger incident response procedures. Suspected violations shall be reported to the CTO/ISSM.
7. Exceptions¶
Exceptions to this policy require written approval per the Policy Exception & Waiver Policy. Exceptions to least-privilege requirements for CUI systems require CEO approval and a documented compensating control.
8. Definitions¶
| Term | Definition |
|---|---|
| Least Privilege | The principle that an individual or process shall be granted only the minimum access necessary to perform assigned functions. |
| Need-to-know | A determination that a person requires access to specific information to perform assigned duties. |
| Access Enforcement | Mechanisms that restrict system access to authorized users, processes, and devices. |
| Privileged Account | An account with administrative, root, or elevated permissions beyond standard user access. |
| Service Account | A non-interactive account used by automated processes, applications, or integrations. |
| Break-glass Account | An emergency account used when normal authentication paths are unavailable. |
| CUI | Controlled Unclassified Information, per 32 CFR Part 2002. |
| Entitlement | A specific permission or capability granted to an account on a system. |
9. References¶
- NIST SP 800-171 Rev. 3, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
- NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
- CMMC 2.0 Level 2, Cybersecurity Maturity Model Certification
- DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting
10. Control Mappings¶
| Framework | Control ID | Control Title | Coverage |
|---|---|---|---|
| NIST SP 800-171 R3 | 03.01.01 | Account Management | Full |
| NIST SP 800-171 R3 | 03.01.02 | Access Enforcement | Full |
| NIST SP 800-171 R3 | 03.01.04 | Separation of Duties | Full — combined with AUL-POL-02 |
| NIST SP 800-171 R3 | 03.01.05 | Least Privilege | Full |
| CMMC 2.0 L2 | AC.L2-3.1.1 | Authorized Access Control | Full |
| CMMC 2.0 L2 | AC.L2-3.1.2 | Transaction and Function Control | Full |
| CMMC 2.0 L2 | AC.L2-3.1.4 | Separation of Duties | Full |
| CMMC 2.0 L2 | AC.L2-3.1.5 | Least Privilege | Full |
| NIST SP 800-53 R5 | AC-2 | Account Management | Full |
| NIST SP 800-53 R5 | AC-3 | Access Enforcement | Full |
| NIST SP 800-53 R5 | AC-5 | Separation of Duties | Full |
| NIST SP 800-53 R5 | AC-6 | Least Privilege | Full |
11. Revision History¶
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | TBD-YYYY-MM-DD | J. Gershenson | Initial issue. |
© Aulendur Labs, Inc. 2026. Internal use only unless otherwise classified.