AC · Plan wizard

Access Control Plan

Documents how the organization controls who can access the system, what they can do once authenticated, and how that access is reviewed and revoked. Covers the controls of the AC family in NIST SP 800-53 r5 and aligns with NIST SP 800-63 (Digital Identity Guidelines) and NIST SP 800-162 (ABAC).

1
Full official name of the information system.
Short identifier used in headings and references.
Role or named individual accountable for the system.
Describe what falls inside the authorization boundary - components, services, networks, data flows.
2
Determines which controls in this family appear in your plan.
3
Approach basics → §4.x

Identity tooling, access-enforcement model, and the account lifecycle that everything else hangs off.

Authoritative identity source / IAM platform (e.g., Active Directory + Azure AD, Okta, AWS IAM, Keycloak).
Primary access decision model. Most modern systems use RBAC or RBAC+ABAC.
End-to-end JML workflow: how new accounts are requested, approved, provisioned, modified on role change, and deprovisioned on departure. Mention tooling (ServiceNow, ITSM, Okta workflows) and approval thresholds.
How privileged access is governed: standing privileges vs just-in-time, vault-based credential checkout, session recording, etc. Tooling (CyberArk, BeyondTrust, AWS SSO with permission sets, Teleport).
Identity Management → §4.x

Identity sources, lifecycle, federation, and authoritative records.

System of record for identity (e.g., 'Workday HR feeds Active Directory nightly').
    Suggested:
    External identity providers federated with the system. Add each via the Add button or pick from suggestions.
    Distinct populations the system authenticates. Each may have different controls applied.
    Per NIST SP 800-63A. Most federal systems require IAL2; CUI/Secret often require IAL3.
    Per NIST SP 800-63B. Federal systems handling CUI typically require AAL2; privileged or classified often AAL3.
    Access Enforcement → §4.x

    How access decisions are made and enforced at the policy decision and enforcement points.

    Component that evaluates access requests against policy (e.g., 'AWS IAM', 'OPA + Rego policies', 'Application authorization layer').
    Where decisions are enforced — load balancer, application middleware, OS-level (sudo / RBAC), database row-level security, etc.
    Where roles are defined and reviewed (e.g., 'Roles documented in iam-roles repo; reviewed quarterly by ISSO + Engineering Lead').
    If ABAC is in use, where attributes come from (HR system, IdP claims, classification labels) and how they're refreshed.
    Privileged Access → §4.x

    PAM tooling, just-in-time access, separation of duties, and recertification.

    Privileged access management product / approach (e.g., CyberArk, BeyondTrust, AWS SSO permission sets, HashiCorp Vault, Teleport).
    How elevated privileges are requested and time-bound. Standing-privilege exceptions, if any.
    How conflicting role pairs are prevented (e.g., 'Auditor and Production Deploy roles are mutually exclusive; enforced via Okta access policies').
    How often privileged role membership is reviewed and recertified by the role owner.
    Session Management → §4.x

    Idle timeouts, device locking, concurrent session limits.

    Time of inactivity before automatic device lock or session termination (e.g., '15 minutes for non-privileged; 5 minutes for privileged').
    How the lock is implemented (OS screen lock + session unlock requires re-authentication; web-app session timeout).
    Conditions that terminate (not just lock) a session: idle threshold, explicit logout, security event detection, account disable.
    Whether and how concurrent sessions per account are limited (per role / per account-type).
    Remote, Wireless, and Mobile Access → §4.x

    VPN / remote-access mechanisms, wireless policy, mobile device approach.

    How remote users connect (VPN, ZTNA, bastion host, SSH jump host) and what authentication is required (MFA, certificate, hardware token).
    How remote-access sessions are logged and monitored (SIEM rule, anomaly detection).
    Whether the system supports wireless access; if so, encryption requirements (WPA3 Enterprise), authentication, and segmentation.
    Tool managing mobile device policies (e.g., Intune, Workspace ONE, Jamf, Google MDM).
    External System Connections → §4.x

    Inventory of external systems, terms of use, and information-sharing controls.

    Where the inventory of external connections is maintained (e.g., 'Boundary diagram in SSP §4.2 + ISA register in Confluence').
    How users acknowledge terms of use (banner / login click-through / signed AUP). References AC-8 (System Use Notification).
    How information shared with external parties is controlled (DLP, watermarking, attribute-based release, ISA scope).
    Identity Populations & Scopes → §2.x

    Numerical and categorical scope of who accesses this system.

    Order of magnitude is fine (e.g., '~250 active accounts').
    Number of privileged / administrative accounts.
    Contractor / partner / federated user counts.
    Non-human accounts used by automation, applications, or services.
    Account Review & Recertification → §6.x

    Cadence and process for reviewing account inventories and privilege assignments.

    Inactivity duration that triggers disable / removal review (e.g., '30 days for privileged; 90 days for standard').
    How role / privilege owners review and re-attest their members. Tooling and cadence.
    Where the signed / completed review records are stored.
    Access Control Metrics & KPIs → §6.x

    Metrics tracked to demonstrate AC control effectiveness over time.

      Suggested:
      Cross-references to other RMF artifacts → §7

      Where this plan plugs into the broader RMF package.

      Where in the SSP the AC control implementations are summarized (e.g., 'SSP §13.1').
      Convention for AC-related POA&M items (e.g., 'POAM-AC-').
      How authentication / access events are captured for the audit family. Specify SIEM index, log sources, retention.
      AC depends on IA (Identification and Authentication) for the underlying identity proofing and authenticator strength. Reference how the two plans interact.
      Pointer to the CA-7 monitoring strategy document tying AC continuous monitoring (account reviews, privileged-access metrics) to the broader ConMon plan.
      4

      Pick a baseline in section 2 and the applicable controls will appear here. Each control gets a card with the official text, related controls, linked CCIs, and fields for your implementation status, narrative, responsible role, and evidence.

      5