Access Control Procedure

Approval #

Revision History #

Review cycle: Every year, under the Policy and Procedure Management Policy.

1. Purpose #

The people named in this procedure use it to carry out the AC control family policy (POL-AC). It covers every control in the access control family. The steps, the people responsible, and the evidence below show how the Organization meets those National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5 controls. They also support the Inspector General (IG) Federal Information Security Modernization Act (FISMA) reporting metrics.

This general procedure covers every control in the AC family. A system that departs from it, or adds to it, has its own system-specific procedure for those controls.

2. Scope #

This procedure applies to every information system that the Organization operates, or that others operate for it, under the moderate security baseline.

2.1 CSF 2.0 Alignment #

The steps in this procedure support these NIST Cybersecurity Framework (CSF) 2.0 categories:

• PR.AA — Identity Management, Authentication, and Access Control (Protect function)
• PR.DS — Data Security (Protect function)

3. Controls Covered #

This procedure covers the following 44 controls in the AC family:

3.1 Derived Governance Requirements #

The requirements below come from federal governance sources and apply to the AC control family. They add to the NIST SP 800-53 control requirements that the Procedure section carries out.

OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles

• The organization must implement a zero trust architecture where every access request is fully authenticated, authorized, and encrypted before granting access. Access decisions must be based on dynamic risk assessment, not static network location. Deadline: FY 2024. (OMB M-22-09, §2)
• The organization must employ multi-factor authentication (MFA) for all users, with phishing-resistant MFA for all privileged accounts and all remote access. Password-based authentication alone is insufficient. Deadline: FY 2024. (OMB M-22-09, §3(a)(i))
• The organization must implement continuous authorization for access sessions, periodically re-evaluating user identity, device posture, and behavioral context throughout the session, not just at initial login. Deadline: FY 2024. (OMB M-22-09, §3)
• The organization must designate a zero trust strategy implementation lead within 30 days of the memorandum’s publication. This lead is responsible for Government-wide coordination and OMB engagement on planning and implementation. Deadline: 30 days from issuance. (OMB M-22-09, §2)

NIST SP 800-207: Zero Trust Architecture

• The organization must ensure all access to resources is authenticated and authorized on a per-session basis, regardless of network location. Trust must never be granted implicitly based on network proximity. (NIST SP 800-207, §3.1)
• The organization must make access policies dynamic, using device security posture, user behavior analytics, and threat intelligence to make real-time authorization decisions. (NIST SP 800-207, §3.2)

CISA BOD 25-01: Implementing Secure Practices for Cloud Services

• The organization must ensure cloud service provider (CSP) access to agency environments is monitored, logged, and restricted to authorized personnel only. CSP management plane access must follow least-privilege principles. (CISA BOD 25-01, §3)

CISA BOD 23-02: Mitigating the Risk of Internet-Exposed Management Interfaces

• The organization must identify and remove internet-exposed management interfaces from public-facing networks. Management interfaces must be accessible only through internal networks or via VPN with MFA. (CISA BOD 23-02, §1)

NIST SP 800-63-4: Digital Identity Guidelines

• The organization must require multi-factor authentication at AAL2 and AAL3, and at AAL3 require a phishing-resistant authenticator with a non-exportable private key. (NIST SP 800-63B-4, §2)
• The organization must set each system’s session limits from its authentication assurance level: no more than 30 days at AAL1; 24 hours, or 1 hour of inactivity, at AAL2; and 12 hours, or 15 minutes of inactivity, at AAL3. (NIST SP 800-63B-4, §2 (reauthentication at each AAL))

OMB M-19-03: Strengthening Cybersecurity through the High Value Asset Program

• The organization must apply enhanced access safeguards to High Value Assets, including privileged access management and network segmentation commensurate with the asset’s value and the threats it faces, informed by the CISA HVA control overlay. (OMB M-19-03, §B)

CISA High Value Asset (HVA) Control Overlay v1.0

• The organization must control and limit access for HVA users through the overlay’s least-privilege selections (AC-6 and enhancements), ensuring privileged access to HVAs receives elevated scrutiny and restriction. (CISA HVA Control Overlay v1.0, AC-6)

OMB M-23-22: Delivering a Digital-First Public Experience

• The organization must link every page of each public website to the privacy policy and the other notices OMB M-23-22 requires. (OMB M-23-22, §III)

CISA Zero Trust Maturity Model v2.0

• The organization should progress through the maturity levels (Traditional, Initial, Advanced, Optimal) for the identity, device, network, application, and data pillars, moving access control from static roles to dynamic, risk-based decisions. (CISA ZTMM v2.0, §5)

NIST SP 800-124 Rev 2: Guidelines for Managing the Security of Mobile Devices in the Enterprise

• The organization should manage organization-issued mobile devices with enterprise mobility management, and use mobile threat defense to detect device, app, and network threats. (NIST SP 800-124 Rev 2, §§3-4)

NIST SP 800-163 Rev 1: Vetting the Security of Mobile Applications

• The organization should vet each mobile app against the Organization’s security requirements before approving it for organization devices, and vet it again when it is updated. (NIST SP 800-163 Rev 1, §§2-3)

NIST SP 800-153: Guidelines for Securing Wireless Local Area Networks (WLANs)

• The organization should monitor for rogue wireless access points and other unauthorized wireless devices, and remove or block any that are found. (NIST SP 800-153, §3)

CISA: Mobile Communications Best Practice Guidance

• The organization should give highly targeted staff, such as senior officials, approved end-to-end encrypted messaging, and do not let them use text messages as a sign-in factor. (CISA Mobile Communications Best Practice Guidance)

4. Procedure #

4.1 General Implementation Approach #

Access control in the Organization runs as a daily process. It starts in the personnel systems. A human resources (HR) action, such as a hire, a transfer, or a separation, starts the joiner-mover-leaver workflow in the single sign-on (SSO) service. The SSO service provisions or adjusts the account and its group claims, synchronizes the change with the cloud directory and the on-premises directory, and opens a ticketing system record that serves as the audit trail. Supervisors and the Information System Security Officer (ISSO) approve what the workflow cannot decide on its own. Privilege requests go through cloud directory privileged identity management for just-in-time activation with a fixed expiration. The identity providers log every approval, activation, and expiration and forward the logs to the security information and event management (SIEM) system.

The review calendar and the exception queue set the pace of the work. Every month, the ISSO reconciles the inactivity report and disables any user account that has been inactive for 90 days, pending justification. The ISSO also verifies that every separation in the HR feed produced a disablement within 24 hours. Each gap becomes a ticketing system ticket, not an email. Every quarter, the ISSO runs privileged access recertification as an SSO and cloud directory access-review campaign. Each certifier attests to or revokes each access, and the campaign export is the evidence. Bi-annually, the same review covers the general user population. Changes to conditional access and group policy follow normal change management. The requester proposes the change in the ticketing system, the change receives a security impact analysis, and the Configuration Control Board (CCB) approves it before deployment. The configuration that enforces this procedure is therefore under the same control as the rest of the family.

Failures in this family are usually quiet. Typical examples are a service account no one rotated, a transfer whose old group memberships remained, and an emergency account that stayed active after the emergency ended. For that reason, the evidence comes from normal operation: identity provider deprovisioning logs, campaign exports, the SIEM system correlation alerts, and Privileged Identity Management (PIM) activation history. The CISO’s staff trend those records every month in the performance measures. When a measure drifts, the ISSO opens the corrective action before an assessor or an adversary finds the gap.

The Organization implements the AC controls in two ways: as organization-wide common controls that systems inherit, and as system-specific implementations where a system needs them. The control-specific procedures below cover each control in the Access Control family.

The Common Control Provider (CCP) implements controls marked inherited for the whole Organization. The CCP and each System Owner share the work for controls marked hybrid. Each System Owner implements controls marked customer-configured for the system.

Responsible party: The Account Manager / ISSO carries out the steps in this procedure unless a control-specific procedure names someone else. The System Owner is accountable for funding and completing the work. The CISO oversees the procedure and receives its performance measures. See the AC policy (POL-AC) for the role definitions.

4.2 Control-Specific Procedures #

AC-01 — Policy and Procedures #

Baselines: Low / Moderate / High / Privacy CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

1. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles — to be defined]:

1. [Selection (one or more): organization-level; mission/business process-level; system-level — to be defined] access control policy that:

1. Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
2. Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and

2. Procedures to facilitate the implementation of the access control policy and the associated access controls;

2. Designate an [Assignment: organization-defined official — to be defined] to manage the development, documentation, and dissemination of the access control policy and procedures; and
3. Review and update the current access control:

1. Policy at least every 3 years and following significant changes; and
2. Procedures at least annually and following [Assignment: organization-defined events — to be defined].

Procedure:

The CISO’s policy team keeps this policy and its procedures as controlled documents in the Organization’s policy library. The team opens the review in the policy library in the document management system every 3 years, and sooner when a major change to applicable policy takes effect. In the record, the team lists the reasons for the change, such as new the Office of Management and Budget (OMB) direction, audit findings, or changes in the architecture. The team sends the draft to the Authorizing Official, the affected System Owners, and the ISSOs for comment.

The CISO decides each comment and signs the revision. The team publishes the signed version in the policy library, updates the revision history table, and sends the distribution notice to every named stakeholder group. The team removes superseded versions from circulation so no one works from old direction.

Evidence: the review record with its dates, the comment decisions, the signed revision with its history entry, and the distribution notice.

AC-02 — Account Management #

Baselines: Low / Moderate / High / HVA overlay CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

1. Define and document the types of accounts allowed and specifically prohibited for use within the system;
2. Assign account managers;
3. Require [Assignment: organization-defined prerequisites and criteria — to be defined] for group and role membership;
4. Specify:

1. Authorized users of the system;
2. Group and role membership; and
3. Access authorizations (i.e., privileges) and [Assignment: organization-defined attributes (as required) — to be defined] for each account;

5. Require approvals by [Assignment: organization-defined personnel or roles — to be defined] for requests to create accounts;
6. Create, enable, modify, disable, and remove accounts in accordance with [Assignment: organization-defined policy, procedures, prerequisites, and criteria — to be defined];
7. Monitor the use of accounts;
8. Notify account managers and [Assignment: organization-defined personnel or roles — to be defined] within:

1. twenty-four (24) hours when accounts are no longer required;
2. eight (8) hours when users are terminated or transferred; and
3. eight (8) hours when system usage or need-to-know changes for an individual;

1. Authorize access to the system based on:

1. A valid access authorization;
2. Intended system usage; and
3. [Assignment: organization-defined attributes (as required) — to be defined];

10. Review accounts for compliance with account management requirements quarterly for privileged access, annually for non-privileged access;
11. Establish and implement a process for changing shared or group account authenticators (if deployed) when individuals are removed from the group; and
12. Align account management processes with personnel termination and transfer processes.

Procedure:

Account management follows the joiner-mover-leaver workflow. An access request in the ticketing system records the sponsor, the role, the completed training, and the expiration date where one applies. The System Owner or designee approves the request before anyone provisions the account. The SSO service then creates the account and its application assignments. The cloud directory group membership holds the authorizations, and the on-premises directory holds the domain account for Windows resources.

An HR separation or transfer action starts the leaver workflow. The workflow disables access and notifies account managers and the System Owner within 24 hours of the separation, the transfer, or a change in need to know. For an emergency disablement, the identity team disables the account first and opens the ticketing system ticket afterward.

Account managers create, change, or remove a service or other non-person account only through an approved the ticketing system request. The System Owner records the account in the non-person account inventory with a named accountable person. When that person leaves or transfers, the System Owner names a new owner, and the account manager changes the account’s credential.

The ISSO reviews privileged accounts every quarter and all other accounts at least every quarter. The ISSO exports the account population. Each Information Owner validates the roles, privileges, and group memberships that reach their information. Each System Owner attests that every account, including each non-person account, still has a justification. Account managers disable any account that no owner attests to.

Evidence: approved access requests, the SSO service provisioning and deprovisioning logs, the non-person account inventory, Information Owner validations, review attestations, and disablement records for accounts that failed review.

AC-02(1) — Automated System Account Management #

Baselines: Moderate / High

Support the management of system accounts using [Assignment: organization-defined automated mechanisms — to be defined].

Procedure:

The SSO service lifecycle workflows provision accounts, change roles, and deprovision accounts from HR triggers. The cloud directory dynamic groups adjust a user’s authorizations when the user’s recorded attributes change. Identity administrators check the workflow queues every day. When a workflow fails, they correct the source data and run the workflow again; they do not edit the account directly. An administrator who takes an emergency account action outside the workflows opens a ticketing system ticket and reconciles the action with the automated record before closing the ticket. Evidence: workflow configuration exports, execution logs, and the reconciliation tickets for every manual exception.

AC-02(2) — Automated Temporary and Emergency Account Management #

Baselines: Moderate / High

Automatically Selection: disables temporary and emergency accounts after no more than 96 hours from last use.

Procedure:

A temporary or emergency account starts with a ticketing system request. The request records the justification, the System Owner’s approval, and the expiration date. In a true emergency, the account manager provisions the account first and completes the ticket right after. The account manager sets the expiration date when creating the account. When the period ends, the SSO service workflow automation or the on-premises directory account expiration attribute removes or disables the account without a manual step. If an AC-02 account review finds an expired account still enabled, the account manager disables it on discovery and opens an investigation. Evidence: the approving ticket, the provisioning record that shows the expiration value, and the platform log entry for the automatic removal or disablement.

AC-02(3) — Disable Accounts #

Baselines: Moderate / High

Disable accounts within 24 hours for user accounts when the accounts: (a) Have expired; (b) Are no longer associated with a user or individual; (c) Are in violation of organizational policy; or (d) Have been inactive for ninety (90) days (See additional requirements and guidance.).

Procedure:

Disablement triggers come from three sources. The SSO service, the cloud directory, and the on-premises directory report expired accounts and user accounts inactive for 90 days. The leaver workflow reports separations and transfers, and the ISSO reports violations. For every trigger, the account manager disables the account within 24 hours. The account manager records the trigger and the timestamps in the ticketing system ticket, so an assessor can check the interval later. Every month, the ISSO compares the inactivity report with the list of enabled user accounts and opens a ticket for any account past the limit. Non-person accounts follow a separate process. In each account review, the System Owner and the ISSO check each one against the non-person account inventory and disable any account without a confirmed need.

Evidence: disablement tickets with trigger and completion times, identity platform logs, the monthly inactivity reconciliations, and the non-person account review records.

AC-02(4) — Automated Audit Actions #

Baselines: Moderate / High

Automatically audit account creation, modification, enabling, disabling, and removal actions.

Procedure:

The SSO service system log, the cloud directory audit log, and the on-premises directory security event log record each account action as it happens. No one needs to log the action by hand. During each account review, the ISSO compares a sample of log entries with the ticketing system tickets that approved them. The ISSO investigates any account action that has no matching request as a possible unauthorized action. When an identity platform changes, the ISSO verifies that log capture still works, so a migration does not lose the record. Evidence: platform audit log exports, the ticket-to-log reconciliation from account reviews, and investigation records for unmatched actions.

AC-02(5) — Inactivity Logout #

Baselines: Moderate / High

Require that users log out when for privileged users, it is the end of a user’s standard work period.

Procedure:

Every user acknowledges the rules of behavior before receiving access. The rules tell users to end the session before an absence longer than the time period of expected inactivity or description of when to log out listed for AC-02(5) parameter 1 in the parameter table. Users must also end the session before stepping away from a system that no one can watch, and whenever they cannot shield the display. Because this control depends on user behavior, people verify it. Supervisors correct a user who leaves sessions open. The ISSO records each session found running unattended as a finding with a corrective action. Evidence: signed rules of behavior acknowledgments and the ISSO’s unattended-session findings with their resolutions.

AC-02(7) — Privileged User Accounts #

Baselines: Moderate / High

1. Establish and administer privileged user accounts in accordance with [Selection: a role-based access scheme; an attribute-based access scheme — to be defined];
2. Monitor privileged role or attribute assignments;
3. Monitor changes to roles or attributes; and
4. Revoke access when privileged role or attribute assignments are no longer appropriate.

Procedure:

Cloud directory privileged identity management (PIM) is the system of record for privileged roles. Account managers make assignments there, and PIM logs every change. Where the platform allows, users hold eligibility for a role and activate it just in time instead of holding standing membership. The on-premises directory privileged groups carry the same role definitions for on-premises systems. The ISSO compares assignment and change events with the approved ticketing system requests. The mover and leaver workflows remove privileged roles when a user’s duties change. The ISSO uses the quarterly privileged account review to find any assignment the workflows missed. Evidence: PIM assignment and change logs, the reconciliation records, revocation tickets, and quarterly review attestations.

AC-02(9) — Restrictions on Use of Shared and Group Accounts #

Baselines: Moderate / High

Only permit the use of shared and group accounts that meet organization-defined need with justification statement that explains why such accounts are necessary.

Procedure:

A request for a shared or group account starts in the ticketing system and states the mission or business need. The System Owner either validates the need and authorizes the account or denies the request. The account manager keeps the roster of holders current as people join and leave. At each AC-02 account review, the System Owner re-validates the justification, and the account manager attaches the membership export from the SSO service or the on-premises directory. The account manager disables any account whose justification has lapsed. Evidence: the authorization ticket, the holder roster, membership exports, and the review outcomes.

AC-02(12) — Account Monitoring for Atypical Usage #

Baselines: Moderate / High

1. Monitor system accounts for [Assignment: organization-defined atypical usage — to be defined]; and
2. Report atypical usage of system accounts to at a minimum, the ISSO and/or similar role within the organization.

Procedure:

The platforms that see the activity produce the alerts. The SSO service and the cloud directory report failed sign-ins and sign-ins from unexpected locations. The secure web gateway flags requests to prohibited sites and unusual outbound data volumes. The on-premises directory records domain activity outside business hours. The ISSO reviews these alerts, closes the ones with a clear explanation, and reports the atypical usage to the CISO in a ticketing system record that tracks the response. The ISSO also reports to Physical Security when the pattern suggests a facility or physical presence concern. Evidence: the alert records, the ISSO’s review dispositions, and the escalation tickets to the CISO or Physical Security.

AC-02(13) — Disable Accounts for High-risk Individuals #

Baselines: Moderate / High

Disable accounts of individuals within one (1) hour of discovery of [Assignment: organization-defined significant risks — to be defined].

Procedure:

Discovery comes from the atypical-usage monitoring under AC-02(12), or from a supervisor, the ISSO, or a conduct report. The person who discovers the risk opens a priority ticketing system ticket. The account manager disables the account in the SSO service, the cloud directory, or the on-premises directory within the 1-hour window and records the start and completion times in the ticket. The CISO receives the triggering facts, coordinates with the System Owner on the scope of the disablement, and is the only person who can approve reinstatement. Evidence: the triggering alert or report, the disablement ticket with its timestamps, and the reinstatement approval where one exists.

AC-03 — Access Enforcement #

Baselines: Low / Moderate / High / HVA overlay CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control), PR.DS (Data Security)

Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.

Procedure:

Access enforcement is a matter of configuration, so this procedure covers configuration control and verification. Identity administrators implement approved authorizations as cloud directory conditional access policies, the on-premises directory security groups and access control lists, and the cloud platform identity policies. When the AC-02 workflow approves an access request, the automated lifecycle applies the assignment to the enforcing group or policy. Administrators do not edit the group or policy directly.

Identity administrators change an enforcement configuration only through change control, with the System Owner’s approval, and record the change in the ticketing system. During the account reviews under AC-02, the ISSO samples effective permissions and compares them with the approved authorizations. The ISSO opens a remediation ticket for each mismatch.

Evidence: conditional access policy exports, group and access control list reports, cloud policy documents, change records, and the mismatch remediation tickets.

AC-03(14) — Individual Access #

Baselines: Privacy

Provide [Assignment: organization-defined mechanisms — to be defined] to enable individuals to have access to the following elements of their personally identifiable information: [Assignment: organization-defined elements — to be defined].

Procedure:

An individual asks for their records through [AC-03(14) parameter 1 — to be defined]. The Privacy Officer logs the request, confirms the requester’s identity, and identifies each system that holds records about the person. The System Owner of each system retrieves [AC-03(14) parameter 2 — to be defined] and sends the records to the Privacy Officer.

If a record may fall under a legal exemption, the Privacy Officer asks General Counsel to review it before release. The Senior Agency Official for Privacy (SAOP) decides any denial or partial release. The Privacy Officer then sends the individual a written response with the released records and the reasons for anything withheld.

Evidence: the request log entry, the identity confirmation record, the copies of released records, the General Counsel review notes for any exemption, and the written response to the individual.

AC-04 — Information Flow Enforcement #

Baselines: Moderate / High / HVA overlay CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control), PR.DS (Data Security)

Enforce approved authorizations for controlling the flow of information within the system and between connected systems based on [Assignment: organization-defined information flow control policies — to be defined].

Procedure:

The network team changes flow enforcement only through the CCB/the Change Advisory Board (CAB). The network team documents a proposed flow rule, the CCB/CAB approves it, and the network team then implements it in the firewall rulesets. The change ticket references the approval.

The secure web gateway is the internal web proxy path. All outbound web traffic routes through the secure web gateway for inspection, and the secure web gateway blocks and logs any request that tries to bypass it. Boundary devices discard inbound packets that claim an internal source address. In the cloud platform, the network team deploys workload network rules only through the same change process. When export-controlled information must leave Organization-controlled networks, the transmitting system applies approved encryption, and the ISSO verifies the configuration before the network team enables the flow.

Evidence: CCB/CAB approvals with their change tickets, firewall ruleset exports, the secure web gateway policy exports and block logs, and the ISSO’s encryption verifications.

AC-04(21) — Physical or Logical Separation of Information Flows #

Baselines: Moderate / High

Separate information flows logically or physically using [Assignment: organization-defined mechanisms and/or techniques — to be defined] to accomplish [Assignment: organization-defined required separations — to be defined].

Procedure:

The System Owner records the required flow separations and their mechanisms in the System Security and Privacy Plan (SSPP). The network team implements them through boundary and routing configuration under change control. Where workloads run in the cloud platform, the environment’s network segmentation applies the same separations. After each relevant change, the ISSO compares the implemented configuration with the documented design. The ISSO opens a ticketing system ticket for each mismatch, and the ticket stays open until someone corrects the configuration or the SSPP, whichever was wrong. Evidence: the SSPP entries, change approvals, configuration exports, and the mismatch tickets with their resolutions.

AC-05 — Separation of Duties #

Baselines: Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control), PR.DS (Data Security)

1. Identify and document [Assignment: organization-defined duties of individuals — to be defined]; and
2. Define system access authorizations to support separation of duties.

Procedure:

System Owners document the duties that require separation for their systems, along with the access authorizations that enforce them. The identity team builds those separations into the group and role structures in the cloud directory and the on-premises directory, so ordinary provisioning cannot give one identity conflicting duties. When an access request would combine conflicting roles, the ticketing system routes it to the System Owner for a decision instead of approving it automatically.

A team other than the one that administers access control administers the audit logs, and the ISSO tests the security of the system. The AC-02 account reviews also serve as separation checks. Reviewers look for identities that have collected conflicting roles as duties changed, and the identity team removes the conflicting roles through the standard removal workflow.

Evidence: the documented duty separations, role structure exports, conflict-routing records from the access workflow, and review findings with their corrections.

AC-06 — Least Privilege #

Baselines: Moderate / High / HVA overlay CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control), PR.DS (Data Security)

Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.

Procedure:

Administrators receive privilege just in time; they do not hold it. An administrator who needs elevated rights activates an eligible role in cloud directory privileged identity management and gives a justification. The activation requires approval, runs for a fixed time, and ends automatically when the window closes. For on-premises work, administrators use separate privileged accounts in the on-premises directory, distinct from their standard identities, and sign in with Personal Identity Verification (PIV) or a hardware security key.

System Owners define the role-based permission sets, and the identity team implements them as groups and role assignments. When a user’s duties change, the mover workflow adjusts group membership, and the supervisor confirms that the reduction took effect.

During the quarterly privileged account review, the ISSO re-validates every privilege assignment against the holder’s current duties. Evidence: activation logs with justifications and approvals, role assignment exports, and the review attestations.

AC-06(1) — Authorize Access to Security Functions #

Baselines: Moderate / High

Authorize access for [Assignment: organization-defined individuals and roles — to be defined] to: (a) [Assignment: organization-defined security functions (deployed in hardware, software, and firmware) — to be defined]; and (b) [Assignment: organization-defined security-relevant information — to be defined].

Procedure:

The System Owner approves each person’s access to specific security functions through the ticketing system access workflow, and the approval names one of the authorized roles. The identity team implements the grant as membership in a dedicated administrative group in the cloud directory and the on-premises directory, separate from the general-user groups. Where the function supports just-in-time activation, the administrator elevates through privileged identity management. At the quarterly privileged account review, the ISSO re-validates every security-function grant against the holder’s current duties. The identity team removes any grant that fails re-validation through the standard workflow. Evidence: approval tickets, administrative group membership exports, PIM assignment records, and the quarterly review attestations.

AC-06(2) — Non-privileged Access for Nonsecurity Functions #

Baselines: Moderate / High

Require that users of system accounts (or roles) with access to all security functions use non-privileged accounts or roles, when accessing nonsecurity functions.

Procedure:

Every administrator holds two identities: a standard account for daily work and a privileged account or eligible role for tasks that need it. The on-premises directory keeps the two accounts separate. Cloud directory privileged identity management activates the privileged role for the task and expires it afterward, so elevation is a deliberate act. Privileged accounts have no productivity services, so mail and web access under an administrative identity fails. The ISSO reviews privileged-account sign-in logs for use of nonsecurity services and reports each finding to the supervisor and the System Owner. Evidence: paired-account records, PIM activation logs, and the sign-in review findings.

AC-06(5) — Privileged Accounts #

Baselines: Moderate / High

Restrict privileged accounts on the system to [Assignment: organization-defined personnel or roles — to be defined].

Procedure:

The System Owner vets each candidate, validates the need for privileged access, and records the authorization. The ISSO adds the person to the privileged account roster. The identity team then creates a separate privileged identity in the on-premises directory or the cloud directory that requires PIV or hardware security key authentication. The team never elevates the user’s standard account. At the quarterly privileged account review, the ISSO reconciles the roster with the live accounts. The identity team disables any unrostered account on the day of discovery, and the ISSO investigates it through a ticketing system ticket. Evidence: the authorization records, the roster, reconciliation results, and disablement tickets.

AC-06(7) — Review of User Privileges #

Baselines: Moderate / High

1. Review at a minimum, annually the privileges assigned to all users with privileges to validate the need for such privileges; and
2. Reassign or remove privileges, if necessary, to correctly reflect organizational mission and business needs.

Procedure:

The ISSO runs the review cycle. Every year, and whenever a user’s duties change, the ISSO exports the privilege assignments for all users from the SSO service, the cloud directory, and the on-premises directory. The ISSO sends the exports to supervisors and System Owners, who validate each privilege against the user’s current responsibilities. The identity team removes any privilege that no one confirms, and the ISSO verifies the removal in a follow-up export. Privileged roles receive the same review every quarter as part of the privileged account review. Evidence: the review exports, validation responses, removal tickets, and the follow-up exports that show the corrections took effect.

AC-06(9) — Log Use of Privileged Functions #

Baselines: Moderate / High

Log the execution of privileged functions.

Procedure:

Privileged operations write to the native audit logs as they run. The cloud directory logs role activations and directory changes. The on-premises directory records privileged use in its security event log. The cloud platform captures administrative activity in its audit logging. The ISSO reviews the privileged-function records during the account review cycle and matches each significant action to an approved change in the ticketing system. The ISSO opens an investigation for any privileged activity that has no matching authorization. Whenever the Organization adds or upgrades a platform, the ISSO checks the logging configuration so coverage does not shrink. Evidence: platform audit log exports, reconciliation records, configuration checks, and investigation tickets for unmatched activity.

AC-06(10) — Prohibit Non-privileged Users from Executing Privileged Functions #

Baselines: Moderate / High

Prevent non-privileged users from executing privileged functions.

Procedure:

Enforcement comes from the structure of the roles. Privileged functions belong to administrative roles and groups in the cloud directory and the on-premises directory, and an identity outside those groups has no way to run them. Group policy locks security-relevant settings and script execution on Windows endpoints, so a standard user cannot reach them locally. The platform audit logs record denied attempts. The ISSO reviews the denied attempts for signs of probing and opens an incident immediately if a privileged action ever succeeds from a non-privileged identity. Evidence: role and group configuration exports, the group policy settings, denied-attempt log entries, and any incident records with their analysis.

AC-07 — Unsuccessful Logon Attempts #

Baselines: Low / Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

1. Enforce a limit of [Assignment: organization-defined number — to be defined] consecutive invalid logon attempts by a user during a [Assignment: organization-defined time period — to be defined]; and
2. Automatically [Selection (one or more): lock the account or node for [organization-defined]; lock the account or node until released by an administrator; delay next logon prompt per [organization-defined]; notify system administrator; take other [organization-defined] — to be defined] when the maximum number of unsuccessful attempts is exceeded.

Procedure:

Group policy sets the account lockout threshold at [AC-07 parameter 1 — to be defined] invalid attempts in [AC-07 parameter 2 — to be defined] for all domain accounts. The SSO service authentication policy enforces the matching lockout for federated access. The Organization keeps both configurations under change control and exports them for the record.

After a lockout, the service desk verifies the requester’s identity, performs the unlock, and closes the ticketing system ticket with the verification method recorded. An account that the delay releases needs no action, but the lockout stays in the log.

The ISSO reviews lockout trends. Repeated lockouts on a single account, or many lockouts across accounts in a short window, start a security investigation rather than a service ticket. Evidence: the group policy and the SSO service policy exports, unlock tickets with verification records, and lockout event logs.

AC-08 — System Use Notification #

Baselines: Low / Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

1. Display see additional Requirements and Guidance to users before granting access to the system that provides privacy and security notices consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines and state that:

1. Users are accessing a U.S. Government system;
2. System usage may be monitored, recorded, and subject to audit;
3. Unauthorized use of the system is prohibited and subject to criminal and civil penalties; and
4. Use of the system indicates consent to monitoring and recording;

2. Retain the notification message or banner on the screen until users acknowledge the usage conditions and take explicit actions to log on to or further access the system; and
3. For publicly accessible systems:

1. Display system use information see additional Requirements and Guidance, before granting further access to the publicly accessible system;
2. Display references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities; and
3. Include a description of the authorized uses of the system.

Procedure:

The banner deploys as managed configuration. Group policy places the approved text on the interactive logon path of every domain-joined system, and the mobile device management (MDM) tool delivers the short form to managed mobile devices. The configuration stops the logon until the user acknowledges the banner. For a system that cannot inherit the enterprise configuration, the System Owner sets up the banner locally and records where and how.

For a public website, the System Owner places links to the privacy policy and the website security notice on every page, as OMB M-23-22 directs. Where members of the public register for an account, the System Owner shows the terms of use during registration.

The ISSO checks that the banner is present, with the exact approved text, during configuration checks and after system changes. If the banner is missing or altered, the ISSO opens a ticketing system ticket, and the System Owner corrects it.

Evidence: group policy and the MDM tool configuration exports, local implementation records, public website link checks, verification results, and correction tickets.

AC-11 — Device Lock #

Baselines: Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

1. Prevent further access to the system by [Selection (one or more): initiating a device lock after [organization-defined] of inactivity; requiring the user to initiate a device lock before leaving the system unattended — to be defined]; and
2. Retain the device lock until the user reestablishes access using established identification and authentication procedures.

Procedure:

Group policy applies the 15-minute inactivity lock to domain-joined desktop systems, and the MDM tool applies the [AC-11 parameter 1 — to be defined] lock to managed portable devices. Web applications and remote access sessions hold their [AC-11 parameter 1 — to be defined] threshold in session configuration. A locked device accepts nothing except re-authentication with the user’s established credentials before the session returns.

The Organization controls the timers centrally, and users cannot adjust them. A deviation requires documented approval from the CISO, and the ISSO tracks each approved deviation to its expiration. The MDM tool compliance reporting shows endpoints whose lock configuration has drifted, and each drifted device gets a ticketing system ticket for remediation. After a baseline change, the ISSO samples configurations to confirm the timers survived the update.

Evidence: the group policy and the MDM tool policy exports, deviation approvals, compliance reports, and remediation tickets.

AC-11(1) — Pattern-hiding Displays #

Baselines: Moderate / High

Conceal, via the device lock, information previously visible on the display with a publicly viewable image.

Procedure:

The managed configuration that sets the lock timers also sets the lock display. Group policy gives domain-joined systems a neutral lock screen and suppresses application content and message previews. The MDM tool enforces the same setting on managed mobile devices, so notifications reveal nothing while the device is locked. Users cannot replace the managed lock-screen behavior with their own. The ISSO verifies the settings in configuration exports during baseline checks, opens a ticket for each deviation, and confirms the correction. Evidence: the group policy and the MDM tool configuration exports and the correction tickets.

AC-12 — Session Termination #

Baselines: Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

Automatically terminate a user session after [Assignment: organization-defined conditions or trigger events — to be defined].

Procedure:

The identity team sets the session limits in the SSO service from the authentication assurance level (AAL) recorded in each system’s SSPP. The limits are the reauthentication limits in NIST SP 800-63B-4. A level 1 (AAL1) session ends after 30 days. A level 2 (AAL2) session ends after 24 hours or 1 hour of inactivity. A level 3 (AAL3) session ends after 12 hours or 15 minutes of inactivity. The zero trust network access (ZTNA) service applies the same inactivity limit to remote application sessions. When a session ends, the user must complete the full authentication path through the identity provider before ZTNA brokers a new session. The session settings are under change control, and the change record shows the CISO’s approval of any change.

The ISSO reviews session logs to confirm that sessions end at the limits. The ISSO investigates any session that persists past a limit as a configuration failure. After a change, Application Owners confirm that their systems treat an ended session as closed, not as one they can resume.

Evidence: the SSO service and ZTNA session policy exports, the AAL and session limits recorded in each SSPP, change records with approvals, session logs, and investigation tickets.

AC-14 — Permitted Actions Without Identification or Authentication #

Baselines: Low / Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

1. Identify [Assignment: organization-defined user actions — to be defined] that can be performed on the system without identification or authentication consistent with organizational mission and business functions; and
2. Document and provide supporting rationale in the security plan for the system, user actions not requiring identification or authentication.

Procedure:

When the Organization plans a system or changes it materially, the System Owner reviews the system’s functions and identifies any action that may proceed without identification or authentication. Usually the only such action is reading content already approved for public release. The System Owner enters each permitted action in the System Security and Privacy Plan (SSPP) with its rationale.

The ISSO then tests the system from the outside. Any function reachable without authentication that is not on the documented list is a configuration defect. The ISSO opens a ticketing system ticket for it, and the System Owner closes the ticket by securing the function or by documenting and justifying it. The ISSO repeats the check after any change to the system’s exposed surface.

Evidence: the SSPP entries with their rationale, the ISSO’s verification records, and the tickets for undocumented anonymous functions found and corrected.

AC-17 — Remote Access #

Baselines: Low / Moderate / High / HVA overlay CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

1. Establish and document usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and
2. Authorize each type of remote access to the system prior to allowing such connections.

Procedure:

Remote access starts with enrollment: the user’s device enrolls in the MDM tool and passes its compliance check, the device has the ZTNA client, and the user authenticates through the SSO service with multi-factor authentication. The ZTNA service brokers each session to a single application, so a user reaches only the applications their role authorizes. Cloud directory conditional access blocks a noncompliant device until the user remediates it.

Administrators who perform privileged work remotely authenticate with PIV or a hardware security key, and the platforms log their sessions from start to finish. The ISSO reviews remote session logs and blocked-session reports for anomalies, such as unfamiliar locations, repeated compliance failures, and access attempts outside a user’s normal pattern. The ISSO escalates each confirmed anomaly in a ticketing system incident ticket.

Evidence: enrollment and compliance records, the ZTNA service session logs, conditional access policy exports, and the blocked-session reports with their dispositions.

AC-17(1) — Monitoring and Control #

Baselines: Moderate / High

Employ automated mechanisms to monitor and control remote access methods.

Procedure:

The ZTNA service brokers and inspects every remote session. The ZTNA service authenticates the session, checks it against policy, and logs it as it runs. When a connection violates policy, the ZTNA service configuration cuts it off; no one has to request the cutoff. Cloud directory conditional access makes the entry decision by weighing the user, the device state, and the sign-in risk before a session begins. The ISSO reviews session and block logs for anomalies, such as unexpected origins, odd hours, and repeated policy violations, and escalates each confirmed concern to the CISO through a ticketing system ticket. Evidence: the ZTNA service session and block logs, conditional access policy exports and sign-in records, and the ISSO’s review escalations.

AC-17(2) — Protection of Confidentiality and Integrity Using Encryption #

Baselines: Moderate / High

Implement cryptographic mechanisms to protect the confidentiality and integrity of remote access sessions.

Procedure:

The ZTNA service carries each remote session inside an encrypted Transport Layer Security (TLS) tunnel from the endpoint to the application. The cryptographic settings belong to the controlled configuration, and the Organization disables weak protocol and cipher options centrally so individual clients cannot choose them. Every change to that configuration goes through change control. After each change, the ISSO reviews the exported settings against the approved cryptography and confirms that no unencrypted remote path exists. The ISSO also checks the application-side settings when a system becomes reachable remotely. Evidence: the ZTNA service configuration exports, change records, and the ISSO’s verification notes.

AC-17(3) — Managed Access Control Points #

Baselines: Moderate / High

Route remote accesses through authorized and managed network access control points.

Procedure:

The ZTNA service is the managed entry point. Remote users connect to the ZTNA service, and the ZTNA service brokers the onward connection, so no system accepts a direct remote connection. Administrators close every other path. The cloud platform workloads accept administrative traffic only from the managed path. The Organization identifies and removes any management interface exposed to the internet, as Cybersecurity and Infrastructure Security Agency (CISA) Binding Operational Directive (BOD) 23-02 requires. Whenever an architecture changes, the ISSO checks for remote access that bypasses the brokered path. The ISSO handles a confirmed bypass as an incident. Evidence: the ZTNA service configuration and session logs, network and cloud configuration exports, and the bypass findings with their incident records.

AC-17(4) — Privileged Commands and Access #

Baselines: Moderate / High

1. Authorize the execution of privileged commands and access to security-relevant information via remote access only in a format that provides assessable evidence and for the following needs: [Assignment: organization-defined needs — to be defined]; and
2. Document the rationale for remote access in the security plan for the system.

Procedure:

An administrator who needs privileged access remotely activates the role through cloud directory privileged identity management and writes a justification. The session runs through the ZTNA-brokered path, and the administrator authenticates with phishing-resistant PIV or hardware security key credentials, as OMB M-22-09 requires. The activation record, the session log, and the related change or incident ticket together form the assessable trail for every remote privileged action. The Chief Information Officer (CIO)’s approval of the standing operational-support and monitoring needs stays on file. The System Owner keeps the rationale current in the System Security and Privacy Plan (SSPP). Evidence: PIM activation logs with justifications, remote session records, the CIO approvals, and the SSPP entries.

AC-18 — Wireless Access #

Baselines: Low / Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

1. Establish configuration requirements, connection requirements, and implementation guidance for each type of wireless access; and
2. Authorize each type of wireless access to the system prior to allowing such connections.

Procedure:

A proposed wireless access type goes through the change process. The System Owner documents its configuration standards, connection conditions, and implementation guidance, and records the authorization before any device connects. The MDM tool delivers the approved wireless profiles to endpoints, and group policy delivers them to domain-joined Windows systems, so devices join approved networks with approved settings and users change nothing.

The ISSO keeps the register of authorized wireless access types. When a configuration changes, the ISSO checks the implementation against its documented requirements. Network Administrators scan each facility for rogue access points and other unauthorized wireless devices at least once a quarter. Where a wireless intrusion detection system covers a facility, it watches for them continuously instead. Network Administrators compare each detected access point with the register. The ISSO reports unauthorized wireless devices and connections as incidents and opens a ticketing system ticket for each correction.

Evidence: the recorded authorizations, the documented requirements for each type, the MDM tool and group policy profile exports, quarterly scan results or wireless intrusion detection alerts, and incident records for unauthorized wireless.

AC-18(1) — Authentication and Encryption #

Baselines: Moderate / High

Protect wireless access to the system using authentication of [Selection (one or more): users; devices — to be defined] and encryption.

Procedure:

The MDM tool sends each managed device a wireless profile that holds the device credential and the approved security settings. At connection time, the on-premises directory and the cloud directory verify the user’s identity. A device without the deployed credential cannot join, no matter what its user knows. The profile fixes the encryption settings, and users cannot change them. When a baseline changes, the ISSO examines the profile exports to confirm that no open or downgraded wireless configuration has appeared. Evidence: the MDM tool profile exports, authentication logs from the identity platforms, and the ISSO’s configuration checks.

AC-18(3) — Disable Wireless Networking #

Baselines: Moderate / High

Disable, when not intended for use, wireless networking capabilities embedded within system components prior to issuance and deployment.

Procedure:

When a device enters provisioning, the endpoint engineering team applies the rule automatically. Group policy and the Windows configuration baselines disable unused wireless interfaces on issued systems. The MDM tool profiles switch off unneeded radios on managed mobile and portable devices before the devices leave provisioning. A component that needs a wireless capability has a documented exception in its assigned configuration. When the MDM tool compliance reporting shows a device whose radio state differs from the assigned profile, the ISSO opens a ticketing system ticket and the endpoint engineering team remediates the device. Evidence: baseline and profile exports that show the disabled interfaces, the exception authorizations, compliance reports, and remediation tickets.

AC-19 — Access Control for Mobile Devices #

Baselines: Low / Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

1. Establish configuration requirements, connection requirements, and implementation guidance for organization-controlled mobile devices, to include when such devices are outside of controlled areas; and
2. Authorize the connection of mobile devices to organizational systems.

Procedure:

Mobile access starts with enrollment. The user registers the device in the MDM tool, the device receives the Organization’s configuration baseline, and the MDM tool evaluates it against the compliance policy. The compliance policy treats a jailbroken or rooted device, a device with an out-of-date operating system, and a device with a threat that mobile threat defense reports as noncompliant. Cloud directory conditional access refuses sign-ins from unenrolled or noncompliant devices. A device that falls out of compliance loses access, and the remediation runs through a ticketing system ticket.

The CISO approves an app for the approved mobile app list only after a security review under NIST SP 800-163 Rev. 1. When a device is lost or stolen, the Service Desk clears Organization data from it through the MDM tool at the direction of the Security Operations Center. The Mobile Device Procedure (PROC-MOB-001) gives the steps for issuing and enrolling devices, approving apps, travel abroad, lost or stolen devices, and separation.

Evidence: enrollment and compliance records, the approved app list with its review records, mobile threat defense reports, conditional access sign-in logs that show refusals, remediation tickets, and loss reports with the device actions taken.

AC-19(5) — Full Device or Container-based Encryption #

Baselines: Moderate / High

Employ [Selection: full-device encryption; container-based encryption — to be defined] to protect the confidentiality and integrity of information on [Assignment: organization-defined mobile devices — to be defined].

Procedure:

The MDM tool compliance policy requires encryption on every enrolled mobile device and checks the state the device reports, not what the user says. The MDM tool marks a device that fails the encryption check as noncompliant, and cloud directory conditional access refuses it access until the device passes. Where container-based protection applies, the MDM tool manages the encrypted container that keeps Organization data separate from personal content. The ISSO reviews compliance reporting for encryption failures and confirms that the policy still covers each device type as new types enter service. Evidence: the MDM tool policy export, device compliance reports, conditional access refusal records, and the ISSO’s coverage reviews.

AC-20 — Use of External Systems #

Baselines: Low / Moderate / High / HVA overlay CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

1. [Selection (one or more): establish [organization-defined]; identify [organization-defined] — to be defined], consistent with the trust relationships established with other organizations owning, operating, and/or maintaining external systems, allowing authorized individuals to:

1. Access the system from external systems; and
2. Process, store, or transmit organization-controlled information using external systems; or

2. Prohibit the use of [Assignment: organization-defined prohibited types of external systems — to be defined].

Procedure:

Use of an external system starts with the agreement. The System Owner establishes the interconnection security agreement (ISA), memorandum of understanding (MOU), or service level agreement (SLA), and the CISO reviews it. Before enabling any access or data flow, the System Owner records the external party’s access controls, security and privacy protections, and incident response capabilities. The System Owner keeps the executed agreement and its list of controls with the system’s authorization records and reviews it again when the relationship or the external system changes.

The Organization enforces the no-bridging rule on the endpoints it manages. The MDM tool and group policy configurations route traffic through the ZTNA service and block a simultaneous remote connection to another network.

A user who wants to use a personal device submits a ticketing system request and signs the personal device terms in the rules of behavior. The user then enrolls the device in the MDM tool under app-level management, which keeps Organization apps and data in an encrypted work container. Cloud directory conditional access allows access only from enrolled devices of an approved type. When the user reports a loss or leaves, the identity team wipes the work container and records the action. Anyone who suspects use of an unapproved external system or device reports it to the ISSO.

Evidence: executed agreements with their lists of controls, endpoint configuration exports, personal device requests and enrollment records, rules of behavior acknowledgments, container wipe records, and the ISSO’s reports.

AC-20(1) — Limits on Authorized Use #

Baselines: Moderate / High

Permit authorized individuals to use an external system to access the system or to process, store, or transmit organization-controlled information only after: (a) Verification of the implementation of controls on the external system as specified in the organization’s security and privacy policies and security and privacy plans; or (b) Retention of approved system connection or processing agreements with the organizational entity hosting the external system.

Procedure:

Before anyone uses an external system, the System Owner gathers the basis for confidence: an independent assessment, a written attestation, or the executed agreement that documents the controls the external party runs. The System Owner records the decision in the ticketing system and attaches the supporting material. No one provisions access until the record exists; verification comes before connection. A material change to the external system or the relationship reopens the decision before continued use. Evidence: the recorded decisions with their assessments or attestations attached, the executed agreements, and the provisioning records that show access followed the approval.

AC-20(2) — Portable Storage Devices — Restricted Use #

Baselines: Moderate / High

Restrict the use of organization-controlled portable storage devices by authorized individuals on external systems using [Assignment: organization-defined restrictions — to be defined].

Procedure:

Every user acknowledges the rules of behavior, which state the prohibition, before receiving access. On the technical side, group policy restricts removable storage on domain-joined systems to explicitly authorized devices. The audit logs record connection and mount events, which gives the ISSO a record of where Organization storage devices appear. Anyone who suspects that someone used an Organization-controlled portable storage device on an external system reports it to the ISSO. The ISSO handles the report as an incident and assesses what the device held. Evidence: signed acknowledgments, the group policy device restriction export, connection audit logs, and incident records with their assessments.

AC-21 — Information Sharing #

Baselines: Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

1. Enable authorized users to determine whether access authorizations assigned to a sharing partner match the information’s access and use restrictions for [Assignment: organization-defined information-sharing circumstances — to be defined]; and
2. Employ [Assignment: organization-defined automated mechanisms — to be defined] to assist users in making information sharing and collaboration decisions.

Procedure:

The System Security and Privacy Plan (SSPP) documents the sharing process for each system. It lists the categories of restricted information the system handles, what a user must confirm about a partner’s authorization and need before release, and who resolves doubt. Before sharing, the user checks the information’s restrictions against the partner’s documented authorization, including any agreement or nondisclosure instrument the release depends on. The user shares only when the two match.

A user with a question asks the ISSO. The ISSO records each decision in the ticketing system and reuses it for similar cases. The System Owner updates the documented process when the system takes on new information types, and adds clarifications to the SSPP when the same question comes up repeatedly.

Evidence: the SSPP process documentation, the ISSO’s recorded decisions, and the escalation records with their resolutions.

AC-22 — Publicly Accessible Content #

Baselines: Low / Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

1. Designate individuals authorized to make information publicly accessible;
2. Train authorized individuals to ensure that publicly accessible information does not contain nonpublic information;
3. Review the proposed content of information prior to posting onto the publicly accessible system to ensure that nonpublic information is not included; and
4. Review the content on the publicly accessible system for nonpublic information at least quarterly and remove such information, if discovered.

Procedure:

The System Owner maintains the roster of individuals authorized to publish and the record of the training each completed before designation. Proposed content goes through pre-publication review: an authorized individual examines it for nonpublic information and records the approval in the ticketing system before anything goes live. Content that fails the review goes back to the author with the reason noted.

Every quarter, the designated reviewers check the existing public content for nonpublic information that earlier reviews missed or that later events made sensitive. The reviewer removes anything found immediately, records the removal, and informs the ISSO. The ISSO traces the cause to a review gap or a designation problem.

Evidence: the designation roster, training records, pre-publication approvals, the quarterly review records, and removal tickets with their cause notes.

5. Parameters (ODP Values) #

The following organization-defined parameters apply to controls in this family:

6. Evidence Artifacts #

Carrying out this procedure produces these records:

• Account management policy and procedures
• Account inventory report (privileged and non-privileged)
• Access review and recertification records
• Account termination/modification logs
• Evidence for IG FISMA metric IDAM.17
• Evidence for IG FISMA metric IDAM.18
• Evidence for IG FISMA metric IDAM.19
• Evidence for IG FISMA metric IDAM.20
• Evidence for IG FISMA metric DPP.01
• Evidence for IG FISMA metric DPP.02
• Evidence for IG FISMA metric DPP.23

7. Performance Measurement #

The CISO measures this procedure with the indicators below, which meet IG FISMA Level 4 (Managed and Measurable). The ISSO collects the data, and the CISO trends and reports it. When a measure moves away from its target, the CISO starts corrective action through the plan of action and milestones (POA&M) process.

8. Training Requirements #

Before they carry out the steps in this procedure, and every year after, the people who perform them must complete:

• General security awareness training, which all personnel take under POL-AT.
• Role-based training on this procedure’s steps, tools, and evidence.
• Training on the technology platforms listed under Technology Implementation, matched to their duties.

Completion is a condition of continued access. The Agency Learning Management System (LMS) holds the completion records.

9. Governance References #

• OMB Circular A-130: Managing Information as a Strategic Resource, July 28, 2016.
• Executive Order 14028: Improving the Nation’s Cybersecurity, May 12, 2021.
• FIPS 201-3: Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• OMB M-19-17: Enabling Mission Delivery through Improved Identity, Credential, and Access Management (ICAM), May 21, 2019.
• OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022.
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
• CISA BOD 23-02: Mitigating the Risk from Internet-Exposed Management Interfaces, June 13, 2023.
• CISA BOD 25-01: Implementing Secure Practices for Cloud Services, December 17, 2024.
• CISA High Value Asset (HVA) Control Overlay v1.0, November 1, 2017.
• CISA Zero Trust Maturity Model, April 11, 2023.
• Mobile Communications Best Practice Guidance, December 18, 2024.
• NIST Cybersecurity Framework 2.0, February 26, 2024.
• NIST SP 800-63-4: Digital Identity Guidelines, July 31, 2025.
• NIST SP 800-124 Rev. 2: Guidelines for Managing the Security of Mobile Devices in the Enterprise, May 2023.
• NIST SP 800-153: Guidelines for Securing Wireless Local Area Networks (WLANs), February 2012.
• NIST SP 800-163 Rev. 1: Vetting the Security of Mobile Applications, April 2019.
• NIST SP 800-207: Zero Trust Architecture, August 2020.
• OMB M-19-03: Strengthening the Cybersecurity of Federal Agencies by Enhancing the High Value Asset Program, December 26, 2018.
• OMB M-23-22: Delivering a Digital-First Public Experience, September 22, 2023.