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 low 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 12 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 [AC-02(3) parameter 2 — to be defined], 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 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 at least annually;
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 year. 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-03 — Access Enforcement #

Baselines: Low / Moderate / High 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-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-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 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 zero trust network access (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 Personal Identity Verification (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-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-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-20 — Use of External Systems #

Baselines: Low / Moderate / High 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-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.