Information System Security Policy (ISSP)

Approval #

Revision History #

Review cycle: Every year.

Mandate. The Federal Information Security Modernization Act of 2014 (FISMA) requires each agency to build an agency-wide information security program, with policies that cover every part of it. Office of Management and Budget (OMB) Circular A-130 and National Institute of Standards and Technology (NIST) SP 800-53 control PM-1 set the same requirement. This policy is the Organization’s top-level information security and privacy policy.

1. Purpose #

The CISO issues this policy to set the rules for protecting the Organization’s information and information systems. In it, the CISO:

• States what each office and person must do to protect the confidentiality, integrity, and availability of the Organization’s information and systems.
• Assigns each duty to a named role.
• Ties the Organization’s family policies and their procedures into one set.

The family policies hold the full requirements for each NIST SP 800-53 control family, and the procedures say how to carry them out. Here, the CISO lists who does what in each family and names the family policy that holds the detail. No part of this policy overrides a law, executive order, or government-wide directive, such as an OMB circular or memorandum.

2. Scope #

This policy covers all of the Organization’s information and information systems. That includes systems that the Organization’s staff or contractors build or run, cloud services, and systems that another agency runs for the Organization.

3. Applicability #

This policy applies to:

• Every office that does the Organization’s business, runs its systems, or collects or keeps information for it.
• Every employee, contractor, consultant, intern, and other person who uses the Organization’s information or systems.
• All digital information, systems, and information technology that support the Organization’s operations and assets, including those that another agency or a contractor provides.

4. Authority #

The Chief Information Officer (CIO) is accountable for the Organization’s information security program under these authorities:

• FISMA 2014 (44 U.S.C. §§ 3551–3558).
• The Clinger-Cohen Act of 1996.
• OMB Circular A-130, Managing Information as a Strategic Resource.
• The agency head’s delegation of information technology authority to the CIO.

The CIO appoints the CISO to carry out the CIO’s security duties under FISMA. The CISO issues this policy, the family policies, and the procedures under that authority.

5. Effective Date and Review #

This policy is in force from the date the CISO signs it until the CISO replaces or withdraws it. The CISO reviews it every year, and sooner after a major change in law, policy, or threat.

6. Roles and Responsibilities #

The roles below carry the duties in this policy. Each role’s duties, family by family, follow under Policy.

7. Risk Management #

The Organization manages risk at three tiers, as NIST SP 800-37 Rev 2 and NIST SP 800-39 describe:

• Tier 1, the Organization: The agency head, the CIO, and the CISO set the risk management strategy and the Organization’s risk tolerance.
• Tier 2, mission and business processes: Senior officials decide which processes each system supports and how much harm a loss would cause.
• Tier 3, information systems: System Owners and ISSOs apply the Risk Management Framework to each system.

For each system, the System Owner and the ISSO follow the seven steps of the Risk Management Framework:

1. Prepare the system and the Organization for risk management.
2. Categorize the system and its information under Federal Information Processing Standards (FIPS) 199.
3. Select the controls.
4. Implement the controls.
5. Assess the controls.
6. Authorize the system. The Authorizing Official decides whether the residual risk is acceptable.
7. Monitor the system and its controls continuously.

The ISSO records each authorization, assessment, and risk decision in the GRC system. The Risk Management Strategy (PLAN-RMS-001) sets the Organization’s risk framing, its Risk Appetite and Tolerance Statement, and who may accept each level of risk. The Information Security Program Plan (ISPP-001) describes how the strategy fits the program.

8. Policy #

Below, each NIST SP 800-53 control family has its own part. Under each role are the duties that role must carry out, with the control each duty comes from in parentheses. The family policy named at the start of each part holds the full requirement for every control.

Users must also follow the General User Rules of Behavior (ROB-GEN-001). Privileged users must follow the Privileged User Rules of Behavior (ROB-PRIV-001) as well. The CISO keeps every policy, procedure, and rule of behavior in the policy library in the document management system.

8.1 Program Management (PM) #

The Program Management Policy (POL-PM) holds the full requirements and the parameter values that apply.

The agency head must:

• approve it (PM-09).
• designate a senior official to lead an insider threat program for the agency (PM-12).
• appoint a Senior Agency Official for Privacy (SAOP) in writing (PM-19).
• when the position is vacant, name an acting SAOP (PM-19).
• establish a Data Governance Body (PM-23).
• establish a Data Integrity Board made up of senior officials (PM-24).
• appoint a Senior Accountable Official for Risk Management in writing (PM-29).

The CIO must:

• designate a Chief Information Security Officer (CISO) to serve as the senior agency information security officer, as FISMA (44 U.S.C. § 3554) requires (PM-02).
• give the CISO authority to issue security policies and procedures and to require System Owners to correct weaknesses (PM-02).
• include the resources needed for the information security and privacy programs in every capital planning and investment request (PM-03).
• stay involved in IT contract decisions, per OMB M-26-10 (PM-03).
• make the planned security and privacy funds available to spend once the Organization receives them (PM-03).
• use the inventory to plan security investments and to report on the agency’s systems as OMB Circular A-130 requires (PM-05).
• maintain an enterprise architecture that includes security and privacy requirements for all organizational systems (PM-07).
• place high value assets in the architecture and in the risk management program, as OMB M-19-03 requires (PM-07).
• make sure the agency critical infrastructure and key resources protection plan addresses security and privacy (PM-08).
• start an update when the high value asset list changes, when a supporting system changes its boundary, or when federal direction changes the requirement (PM-08).
• run one authorization process for all systems and common controls, built on the Risk Management Framework (PM-10).
• take part in IT contract decisions, as OMB M-26-10 requires (PM-30).

The CISO must:

• develop and maintain an Information Security Program Plan that covers the whole Organization (PM-01).
• review and update the plan [PM-01 parameter 1 — to be defined] and after [PM-01 parameter 2 — to be defined] (PM-01).
• protect the plan from unauthorized disclosure and change by limiting edit rights in the document management system to the CISO’s staff (PM-01).
• head an office with the staff and funds to develop, run, and maintain the information security program across the Organization (PM-02).
• coordinate security and privacy planning, monitoring, and reporting with the Senior Agency Official for Privacy (SAOP), per OMB M-25-04 (PM-02).
• brief the CIO and the Senior Accountable Official for Risk Management on program risk and resource needs (PM-02).
• run a plan of action and milestones (POA&M) process that covers the information security, privacy, and supply chain risk management programs and every system (PM-04).
• keep a program-level POA&M in the GRC system for weaknesses in common controls, the security program, and supply chain risk management (PM-04).
• review all items against the risk tolerance and priorities in the Risk Management Strategy (PLAN-RMS-001), per NIST SP 800-39 (PM-04).
• report POA&M status as FISMA reporting requires (PM-04).
• maintain one inventory of all organizational systems in the GRC system and update it [PM-05 parameter 1 — to be defined] (PM-05).
• review and update the strategy [PM-09 parameter 1 — to be defined] and after a major organizational change (PM-09).
• connect authorizations to continuous monitoring so each decision reflects the current security and privacy state, as FISMA requires (PM-10).
• use them to set the Target Profile in the Cybersecurity Framework Organizational Profile Template (TMPL-CSF-001) (PM-11).
• before anyone shares Organization information with a group, approve the release (PM-15).
• use threat trends to update the organization-wide risk assessment (PM-16).
• review this policy [PM-17 parameter 1 — to be defined] and the procedure [PM-17 parameter 2 — to be defined] (PM-17).
• also update both after a change in federal Controlled Unclassified Information (CUI) rules (PM-17).
• develop an organization-wide supply chain risk management (SCRM) strategy: the Supply Chain Risk Management Strategy and Implementation Plan (PLAN-SCRM-001) (PM-30).
• review and update the strategy on [PM-30 parameter 1 — to be defined], and sooner when the Organization’s structure or mission changes (PM-30).
• keep an organization-wide information security continuous monitoring strategy (PM-31).
• combine and analyze assessment and monitoring results across systems (PM-31).
• keep the Organization’s POA&M at the program level (PM-31).
• apply this analysis first to High Value Assets, as OMB M-19-03 requires (PM-32).

Authorizing Officials must:

• base each decision on current assessment results and the risk tolerance in the agency risk management strategy (PM-10).

The Senior Agency Official for Privacy (SAOP) must:

• also approve any item that concerns privacy (PM-15).
• list the federal privacy requirements the program meets and the program-level and common privacy controls that meet them (PM-18).
• state the program’s goals and describe how privacy staff work with the Chief Information Security Officer (CISO), System Owners, Information Owners, and General Counsel (PM-18).
• distribute the approved plan to all staff with privacy duties (PM-18).
• update the plan on this schedule: [PM-18 parameter 1 — to be defined] (PM-18).
• also update it after a change in federal privacy law or policy, an organizational change, or a problem found in a privacy control assessment (PM-18).
• report privacy risk directly to the agency head (PM-19).
• approve the privacy program plan and each privacy impact assessment (PIA) (PM-19).
• agree to the privacy risk in each authorization decision for a system that handles personally identifiable information (PII) (PM-19).
• also publish privacy impact assessments, system of records notices (SORNs), and computer matching notices and agreements (PM-20).
• list a public email address and a phone line that reach the privacy office (PM-20).
• decide each appeal or name an official who took no part in the first decision (PM-22).
• confirm that the use fits the purpose for which the Organization collected the PII, and consults General Counsel when the answer is unclear (PM-25).
• also give the reports to [PM-27 parameter 3 — to be defined] and to other personnel who monitor privacy program compliance (PM-27).
• review and update the reports [PM-27 parameter 4 — to be defined] (PM-27).
• also submit any other privacy report that a law or OMB requires (PM-27).

System Owners must:

• state the security and privacy costs of their systems in each investment request (PM-03).
• record each system weakness as a POA&M item in the GRC system (PM-04).
• register a system in the inventory before any authorization work for that system begins (PM-05).
• draw the system boundary around resources that share common management control, a common mission, similar security needs, and the same operating environment (PM-05).
• record a subsystem under its parent system rather than as a separate entry (PM-05).
• use these needs when they categorize systems and select controls (PM-11).
• identify each outside system that will hold CUI and record it with the related system in the GRC system (PM-17).
• keep each entry for five years after the disclosure or for the life of the record, whichever is longer (PM-21).
• check the quality of PII when they collect it and before a system uses it to decide something about a person (PM-22).
• protect approved PII in a test, training, or research environment the same way they protect it in production (PM-25).
• respond to each result that shows a weakness (PM-31).
• either fix it or record it as a plan of action and milestones (POA&M) item in the GRC system (PM-31).
• check that [PM-32 parameter 1 — to be defined] are used only for their intended purpose (PM-32).
• record the intended mission or business purpose of the system in the System Security and Privacy Plan (SSPP) (PM-32).
• when a system supports a function outside its stated purpose, remove that use or get the Authorizing Official’s approval to keep it (PM-32).
• if the use stays, update the SSPP and the system’s risk assessment (PM-32).

ISSOs must:

• compare the system’s actual use with that purpose at each reauthorization and before any significant change (PM-32).

The Security Operations Center (SOC) must:

• analyze each report and send relevant warnings to the System Owners and Information System Security Officers (ISSOs) whose systems are exposed (PM-16).
• also share what the Organization learns with federal partners and sharing groups (PM-16).

Contracting Officers must:

• include threat-sharing terms in contracts for IT services (PM-16).
• before a contractor or partner receives CUI, include CUI safeguarding and incident reporting terms in the contract or agreement (PM-17).

Supervisors must:

• assign role-based security training and role-based privacy training to each person in a security or privacy role (PM-13).
• also support career paths that prepare staff for roles with more responsibility (PM-13).

Other requirements:

• The plan must summarize the security requirements the Organization must meet under FISMA (44 U.S.C. § 3554) (PM-01).
• It must list the program management controls and common controls that are in place or planned (PM-01).
• It must name the roles and responsibilities for the program and state management’s commitment to it (PM-01).
• It must describe how the CIO, the Senior Agency Official for Privacy (SAOP), System Owners, and other offices coordinate on security (PM-01).
• The plan must refer to the risk management strategy, which sets the Organization’s risk tolerance and priorities, per NIST SP 800-39 (PM-01).
• The Senior Accountable Official for Risk Management must approve the plan (PM-01).
• Information security must be the CISO’s primary duty (PM-02).
• The CISO and the Senior Agency Official for Privacy (SAOP) must add program-level costs and confirm that each request covers its security and privacy needs (PM-03).
• If a request leaves out these resources, the System Owner must document the exception and the reason, and the CIO must approve it (PM-03).
• Per OMB M-25-04, the CIO and the CISO must give priority to zero trust architecture, continuous monitoring, and modernizing legacy systems (PM-03).
• Each item must show an owner, the planned fix, the resources needed, milestones, and a completion date (PM-04).
• The Senior Agency Official for Privacy (SAOP) must keep the privacy program items (PM-04).
• In that case, the CISO and the CIO must send the proposal to the Senior Accountable Official for Risk Management (PM-04).
• When a system transfers to another owner or merges with another system, the System Owner must update the inventory entry, and the Authorizing Official must reopen the authorization (PM-05).
• The CISO and the Senior Agency Official for Privacy (SAOP) must each set measures of performance for the security program and the privacy program (PM-06).
• Each measure must state what it counts, its data source, its target, and its owner (PM-06).
• The targets must reflect the risk tolerance in the agency risk management strategy, as NIST SP 800-39 directs (PM-06).
• The CISO and SAOP must track results against targets and report them to the CIO and to the Senior Accountable Official for Risk Management (PM-06).
• They must use the results in the annual report that FISMA requires (PM-06).
• When a measure misses its target, the measure owner must record the gap and a corrective action as a program-level POA&M item (PM-06).
• The CISO must define the security architecture and the Senior Agency Official for Privacy (SAOP) must define the privacy architecture at the enterprise level (PM-07).
• Each system architecture must stay consistent with them (PM-07).
• The CIO, CISO, and SAOP must consider the risk to operations, assets, individuals, other organizations, and the Nation when they approve architecture changes (PM-07).
• The architecture must support zero trust goals and the replacement of legacy systems, as OMB M-25-04 directs (PM-07).
• The CISO must supply the security content and the Senior Agency Official for Privacy (SAOP) must supply the privacy content for the first version of the plan and for each update (PM-08).
• The plan must name the systems and high value assets that support critical infrastructure and state how the agency protects them (PM-08).
• It must set protection priorities from the importance of those assets, as OMB M-19-03 directs for high value assets (PM-08).
• The Senior Accountable Official for Risk Management must lead a risk executive function and recommend one strategy for managing security risk and privacy risk across the agency (PM-09).
• As NIST SP 800-39 directs, the strategy must state risk assumptions, constraints, priorities, and risk tolerance (PM-09).
• It must also state how the agency assesses, responds to, and monitors risk (PM-09).
• The CISO must draft the security content and the Senior Agency Official for Privacy (SAOP) must draft the privacy content (PM-09).
• All officials must apply the strategy in authorization, investment, and acquisition decisions (PM-09).
• When an Authorizing Official proposes to accept a risk that exceeds the stated tolerance, the decision must go through the CISO and CIO to the risk executive function (PM-09).
• The agency head or a delegate must name an Authorizing Official for each system and each set of common controls (PM-10).
• The agency head or the delegate must also name the System Owner, the ISSO, and any Common Control Provider for each system (PM-10).
• The Senior Agency Official for Privacy (SAOP) must review privacy risk in each authorization for a system that processes personally identifiable information (PM-10).
• Each Mission/Business Owner must define the mission and business processes in their area and state the security and privacy risk each one creates (PM-11).
• The definition must name the information each process uses and the personally identifiable information (PII) it handles (PM-11).
• The Mission/Business Owner must work with the CISO and the Senior Agency Official for Privacy (SAOP) to set protection needs and PII processing needs for each process (PM-11).
• Each Mission/Business Owner must review and revise their process definitions [PM-11 parameter 1 — to be defined] and whenever a process changes (PM-11).
• The senior official must form a team with members from the CISO’s staff, the Security Operations Center, Human Resources, General Counsel, and the Senior Agency Official for Privacy (SAOP) (PM-12).
• The team must handle insider threat referrals, combine technical and personnel information, and recommend actions (PM-12).
• The senior official must keep a written program plan and give all personnel insider threat awareness training (PM-12).
• General Counsel and the SAOP must approve any monitoring that uses personnel records, so the team stays within the law and protects privacy (PM-12).
• Team members must share case information only with those who need it for the case (PM-12).
• The CISO and the Senior Agency Official for Privacy (SAOP) must run a workforce program for staff who hold security and privacy roles (PM-13).
• The program must define the knowledge, skills, and abilities each role needs (PM-13).
• Human Resources must use those definitions in position descriptions, job postings, and hiring (PM-13).
• The CISO and SAOP must report workforce gaps to the CIO, so the CIO can plan resources as FISMA requires (PM-13).
• The Chief Information Security Officer (CISO) must maintain an organization-wide plan for security testing, training, and monitoring (PM-14).
• The Senior Agency Official for Privacy (SAOP) must maintain the matching plan for privacy, including role-based privacy training and breach response exercises (PM-14).
• Each plan must name every activity, its owner, and its schedule (PM-14).
• System Owners and Common Control Providers must carry out the activities the plans assign to them and report the results to the plan owner (PM-14).
• The CISO and the SAOP must compare both plans with the risk management strategy and the current priorities for risk response, as NIST SP 800-39 requires (PM-14).
• They must make this comparison whenever the strategy changes and as part of the annual FISMA reporting cycle (PM-14).
• If a plan no longer matches the strategy, the plan owner must revise it before the next round of activities starts (PM-14).
• Per OMB M-25-04, the CISO and the SAOP must coordinate the two plans so that security and privacy activities share schedules and results (PM-14).
• The Chief Information Security Officer (CISO) must choose the security groups and professional associations the Organization joins (PM-15).
• The Senior Agency Official for Privacy (SAOP) must choose the privacy groups (PM-15).
• Each choice must rest on the Organization’s mission and the threats it faces (PM-15).
• The CISO and the SAOP must keep a list of each membership, its purpose, and the staff member who serves as point of contact (PM-15).
• Points of contact must use these memberships for staff training, for learning current security and privacy methods, and for exchanging threat, vulnerability, and incident information (PM-15).
• Staff must never share personally identifiable information (PII) through a group (PM-15).
• Per Executive Order (EO) 14028, the CISO must remove internal barriers that keep staff from sharing threat information with federal partners (PM-15).
• The Chief Information Security Officer (CISO) must run a threat awareness program for the whole Organization (PM-16).
• The Security Operations Center (SOC) must receive threat intelligence from federal and industry sources the CISO approves (PM-16).
• The CISO must approve each release, and General Counsel must review any release that contains legally restricted information (PM-16).
• Per EO 14028, the CISO must remove contract and policy barriers that keep threat information from reaching the people who need it (PM-16).
• The Chief Information Security Officer (CISO) must keep a policy and a procedure for protecting controlled unclassified information (CUI) that contractors and partners handle on systems the Organization does not operate (PM-17).
• Information Owners must mark CUI before release and release it only to the parties an agreement covers (PM-17).
• Contractors and partners must report any suspected loss or misuse of CUI to the Security Operations Center (PM-17).
• The Senior Agency Official for Privacy (SAOP) must prepare and approve a privacy program plan that covers the whole Organization (PM-18).
• In the plan, the SAOP must describe how the privacy office is organized and the budget and staff assigned to it (PM-18).
• The plan must name the SAOP, the Privacy Officer, and every other privacy role, with the duties of each (PM-18).
• Per OMB M-25-04, the SAOP and the CISO must align this plan with the security program plan (PM-18).
• The appointment must give the SAOP the authority, staff, and budget to run the privacy program across the Organization (PM-19).
• The SAOP must lead the privacy part of the annual FISMA report and must serve on the Data Integrity Board and the Data Governance Body (PM-19).
• Per OMB M-25-04, the SAOP and the Chief Information Security Officer (CISO) must coordinate security and privacy planning, monitoring, and reporting (PM-19).
• The Senior Agency Official for Privacy (SAOP) must keep a privacy page on the Organization’s main public website (PM-20).
• On that page, the SAOP must publish the Organization’s privacy policies and privacy reports (PM-20).
• The page must explain how a person asks to see or correct a record about them (PM-20).
• Privacy staff must answer questions and complaints that arrive through them (PM-20).
• The Privacy Officer must post each new or revised privacy document when it takes effect (PM-20).
• The Privacy Officer must remove a document from the page when it is withdrawn (PM-20).
• Each System Owner of a system of records must log every disclosure of personally identifiable information (PII) from that system (PM-21).
• Each log entry must show the date, what the Organization disclosed and why, and the recipient’s name and address or other contact information (PM-21).
• When a person asks, the Privacy Officer must give that person the entries about their own records, unless federal law allows the Organization to withhold them (PM-21).
• The Senior Agency Official for Privacy (SAOP) must oversee this process and confirm it works during privacy control assessments (PM-21).
• The Senior Agency Official for Privacy (SAOP) must keep policies and procedures that keep personally identifiable information (PII) accurate, relevant, current, and complete from collection through disposal (PM-22).
• The Privacy Officer must publish how a person asks the Organization to correct or delete PII (PM-22).
• Information Owners must correct or delete PII that is wrong or out of date (PM-22).
• They must then notify the person and every party that received the old data (PM-22).
• If the Organization denies a request, the Privacy Officer must explain the reasons in writing and record the person’s statement of disagreement (PM-22).
• The Privacy Officer must also tell the person how to appeal (PM-22).
• The members must carry out these duties: [PM-23 parameter 2 — to be defined] (PM-23).
• The Senior Agency Official for Privacy (SAOP) must lead the body and keep its charter current (PM-23).
• The body must confirm that each system holding personally identifiable information (PII) has a privacy impact assessment and, where needed, a published system of records notice (SORN) (PM-23).
• Each SORN must include the routine uses that let the Organization share data to respond to a breach (PM-23).
• The body must set records retention and consent notice requirements for PII (PM-23).
• It must review each request to release PII-based data outside the Organization (PM-23).
• Per OMB M-25-04, the SAOP must invite the Chief Information Security Officer (CISO) and the Chief Information Officer (CIO) when a decision affects security (PM-23).
• The Senior Agency Official for Privacy (SAOP) and the Inspector General must serve on the board (PM-24).
• The board must approve each proposed computer matching program before the Organization signs a matching agreement or releases any records for a match (PM-24).
• Program offices must not start, renew, or change a matching program without board approval (PM-24).
• Each calendar year, the board must review every matching program the Organization took part in during that year (PM-24).
• For each program, the board must decide whether it should continue, change, or end (PM-24).
• The board must report its findings to the agency head (PM-24).
• Personnel who plan internal testing, training, or research must use data that contains no personally identifiable information (PII) whenever that data meets the purpose (PM-25).
• If real PII is needed, the requester must get written approval from the Senior Agency Official for Privacy (SAOP) before anyone copies or uses it (PM-25).
• The SAOP must approve only the data elements and records the purpose needs, and must set an end date for the use (PM-25).
• The Privacy Officer must review and update this policy [PM-25 parameter 1 — to be defined] (PM-25).
• The Privacy Officer must review and update the related procedures [PM-25 parameter 3 — to be defined] (PM-25).
• The Senior Agency Official for Privacy (SAOP) must run a process for receiving and answering complaints, concerns, and questions from the public about the Organization’s privacy and security practices (PM-26).
• The Privacy Officer must post on the Organization’s public website the ways to file a complaint, the information a complaint should include, and the contact details of the official who receives complaints (PM-26).
• The filing methods must be easy for any member of the public to find and use (PM-26).
• The Privacy Officer must log every complaint, concern, or question and review it within [PM-26 parameter 1 — to be defined] (PM-26).
• The assigned owner must address each item within [PM-26 parameter 2 — to be defined] (PM-26).
• The Privacy Officer must acknowledge receipt within [PM-26 parameter 3 — to be defined] and send the individual a response within [PM-26 parameter 4 — to be defined] (PM-26).
• Personnel who handle complaints must protect any personally identifiable information (PII) the complaints contain (PM-26).
• The Senior Agency Official for Privacy (SAOP) must prepare [PM-27 parameter 1 — to be defined] and submit them to [PM-27 parameter 2 — to be defined] (PM-27).
• The reports must show how the Organization meets the privacy requirements set by statute, regulation, and federal policy (PM-27).
• The SAOP and the CISO must coordinate their reporting so that security and privacy figures agree, as OMB M-25-04 directs (PM-27).
• The Senior Accountable Official for Risk Management must lead the risk executive function in framing risk for the Organization, as NIST SP 800-39 directs (PM-28).
• The resulting risk framing statement must record the assumptions, constraints, priorities and trade-offs, and risk tolerance that guide how the Organization assesses, responds to, and monitors risk (PM-28).
• The CISO and the Senior Agency Official for Privacy (SAOP) must contribute the security and privacy views (PM-28).
• Mission/Business Owners and System Owners must give input on their missions and systems (PM-28).
• The Senior Accountable Official for Risk Management must send the approved statement to [PM-28 parameter 1 — to be defined] (PM-28).
• The risk executive function must review and update the statement [PM-28 parameter 2 — to be defined] (PM-28).
• An Authorizing Official who proposes to accept a risk above the stated tolerance must send the proposal through the CISO and the CIO to the risk executive function (PM-28).
• That official must align information security and privacy risk management with the Organization’s strategic, operational, and budget planning (PM-29).
• Security and privacy investment decisions must follow the risk management strategy, as NIST SP 800-39 requires (PM-29).
• The Senior Accountable Official for Risk Management must lead a risk executive function (PM-29).
• Its members must include the CIO, the CISO, the Senior Agency Official for Privacy (SAOP), and Mission/Business Owners the official selects (PM-29).
• The risk executive function must look at risk across all systems and missions and keep risk decisions consistent across the Organization (PM-29).
• It must decide on any risk an Authorizing Official proposes to accept above the Organization’s risk tolerance (PM-29).
• It must also make sure security and privacy planning, monitoring, and reporting work together, as OMB M-25-04 directs (PM-29).
• The Senior Accountable Official for Risk Management must approve it (PM-30).
• The strategy must cover the risks that arise when the Organization develops, buys, maintains, or disposes of systems, system components, and system services (PM-30).
• It must state the Organization’s supply chain risk tolerance, the mitigations the Organization accepts, how the Organization evaluates and monitors supply chain risk, and who does what (PM-30).
• The CIO, System Owners, and Contracting Officers must apply the strategy in every system and every IT acquisition (PM-30).
• Each system-level supply chain risk management plan must follow it (PM-30).
• The strategy must address software supply chain security, as Executive Order (EO) 14028 directs (PM-30).
• The Senior Agency Official for Privacy (SAOP) must keep a privacy continuous monitoring strategy that works with it (PM-31).
• Both strategies must track [PM-31 parameter 1 — to be defined] (PM-31).
• Control owners must monitor these metrics at [PM-31 parameter 2 — to be defined] (PM-31).
• Assessors must check control effectiveness at [PM-31 parameter 3 — to be defined] (PM-31).
• The metrics must reflect the risk tolerance in the Organization’s risk management strategy (PM-31).
• The CISO and SAOP must report the security and privacy status of systems to [PM-31 parameter 4 — to be defined] (PM-31).
• The check must cover the services, connections, users, and data the system supports (PM-32).

8.2 Access Control (AC) #

The Access Control Policy (POL-AC) and its procedures (PROC-AC) hold the full requirements and the parameter values that apply.

The Organization must:

• for every type of wireless access, set the configuration standards, the connection conditions, and the implementation guidance before it allows the first connection (AC-18).
• set the configuration standards, connection conditions, and implementation guidance for the mobile devices it controls, including their use outside controlled areas (AC-19).
• establish an interconnection security agreement (ISA), memorandum of understanding (MOU), or service level agreement (SLA) with an external party before an authorized individual uses the party’s system to access Organization systems (AC-20).

The CISO must:

• issue the access control policy for the whole Organization and distribute it through the policy library to the Authorizing Official, System Owners, ISSOs, and key stakeholders (AC-01).
• review the policy every 3 years, and sooner after a major change to a law, a directive, or the Organization’s operating environment (AC-01).
• review the procedures on the same cycle (AC-01).
• publish the approved banner text in the document management system, with a short form for devices with small screens (AC-08).
• approve an app for the list only after a security review under NIST SP 800-163 Rev. 1 (AC-19).

System Owners must:

• keep an inventory of service, system, and other non-person accounts (AC-02).
• enforce approved authorizations at every point where their systems decide whether to grant access (AC-03).
• make sure the technical enforcement in their systems matches the authorizations approved under AC-02 (AC-03).
• treat any difference between the two as a defect and correct it (AC-03).
• enforce information flow authorizations under the Organization Access Control Policy within each system and between connected systems (AC-04).
• keep the approved flows for their systems documented so an assessor can trace every ruleset line to a decision (AC-04).
• grant each user and each process only the access its function requires, and nothing more (AC-06).
• define role-based permission sets so that access follows the job, not the individual (AC-06).
• where members of the public register for an account, show the terms of use at registration (AC-08).
• identify the specific user actions their system allows without identification or authentication (AC-14).
• keep that list as short as the mission allows and document every entry, with its rationale, in the System Security and Privacy Plan (SSPP) (AC-14).
• re-justify the list whenever the system’s function changes (AC-14).
• authorize each wireless access type before any device uses it (AC-18).
• withdraw the designation of anyone who publishes content without the review (AC-22).

ISSOs must:

• treat repeated lockouts on one account, or lockouts across many accounts, as a possible credential attack (AC-07).
• confirm that what the system allows matches what the SSPP says it allows (AC-14).
• treat the discovery of an unauthorized access point or connection as an incident (AC-18).

Supervisors must:

• make sure the personnel they manage know which parts of this policy apply to their daily work (AC-01).
• request a reduction in access when a user’s duties change (AC-06).

Other requirements:

• Anyone who needs to deviate from a requirement must use the exception process in this policy (AC-01).
• Every account must have a current, recorded justification (AC-02).
• System Owners, or the designees they name, must approve a new account only when it has an approved access request, completed training, and a recorded expiration date where one applies (AC-02).
• Group and role membership must match the holder’s clearance, need for access, and job responsibilities (AC-02).
• Account managers and the System Owner must receive notice within 24 hours when an account is no longer needed, when the holder leaves or transfers, or when the holder’s need to know changes (AC-02).
• The ISSO and System Owners must review all non-privileged accounts at least every year and all privileged accounts every quarter (AC-02).
• In each review, the Information Owner must confirm that each user’s role and privileges still fit the information the user may reach (AC-02).
• The inventory must record each account’s purpose, the systems it reaches, its privileges, and the named person accountable for the account and its credentials (AC-02).
• Account managers must disable any account that fails review (AC-02).
• Export-controlled information must leave Organization-controlled networks only under approved encryption (AC-04).
• Boundary devices must drop inbound traffic that presents an internal source address (AC-04).
• Web requests bound for the Internet must leave only through the internal web proxy path that the secure web gateway provides (AC-04).
• A firewall rule that appears without that approval is a configuration incident, and the CISO must treat it as one (AC-04).
• Privileged functions must stay separate from standard duties (AC-06).
• Under OMB M-22-09, privileged access must use phishing-resistant Personal Identity Verification (PIV) or hardware security key credentials (AC-06).
• Every system must limit a user to [AC-07 parameter 1 — to be defined] consecutive invalid logon attempts within a [AC-07 parameter 2 — to be defined] window (AC-07).
• When a user exceeds the limit, the system must lock the account until an administrator releases it, or delay the next logon prompt by at least [AC-07 parameter 3 — to be defined] (AC-07).
• Lockout events are security signals that the ISSO must review (AC-07).
• Every system must display the CISO-approved system use banner before it grants access (AC-08).
• The banner must make four statements (AC-08).
• System Owners must not remove or reword any part of the banner, and the CISO must approve any system-specific wording (AC-08).
• The banner must stay on screen until the user acknowledges it and acts to log on (AC-08).
• The Organization must authorize each type of remote access before anyone uses it and must document its usage restrictions and permitted configurations (AC-17).
• All remote sessions must route through zero trust network access (AC-17).
• An administrator who performs privileged functions remotely must authenticate with phishing-resistant PIV or hardware security key credentials, and the system must log the session (AC-17).
• Endpoints must receive their wireless settings through managed configuration, not manual setup, so devices join approved networks on approved terms (AC-18).
• Network Administrators must scan each Organization facility for unauthorized wireless access points at least once a quarter (AC-18).
• These rules must follow NIST SP 800-124 Rev. 2 (AC-19).
• A device that is not enrolled, or is enrolled but out of compliance, must not reach Organization resources (AC-19).
• The mobile device management (MDM) tool must block jailbroken or rooted devices and devices that run an out-of-date operating system (AC-19).
• Every managed device must run mobile threat defense (AC-19).
• Users must keep their devices under personal control outside controlled areas and must report a lost or stolen device without delay (AC-19).
• The agreement must identify, at minimum, the external party’s access controls, security and privacy protections, and incident response capabilities (AC-20).
• A user must not connect a device to any other network remotely while it is connected to an Organization information system (AC-20).
• On such a device, Organization data must stay in a managed, encrypted work container that the Organization can wipe remotely (AC-20).
• The user must agree in the rules of behavior to report a lost device at once and to provide the device for incident response (AC-20).
• Each designated individual must complete training on recognizing nonpublic information before the designation takes effect (AC-22).
• A designated reviewer must review every piece of proposed content before posting to confirm that it contains no nonpublic information (AC-22).
• Designated reviewers must review the existing public content at least every quarter and must remove any nonpublic information they find at once (AC-22).

The approved system use banner #

Every system that requires a login must show this banner before it grants access (AC-08). The CISO approves any system-specific wording, and that wording must keep all four statements.

WARNING: You are accessing a U.S. Government information system. You may use it only for purposes the U.S. Government authorizes. The Government monitors, records, and audits the use of this system. The Government prohibits unauthorized use, which may lead to criminal and civil penalties under 18 U.S.C. 1030. By using this system, you consent to this monitoring and recording.

On a device with a small screen, the system may show this short version:

WARNING: U.S. Government system. The Government monitors and records its use. Unauthorized use may lead to criminal and civil penalties under 18 U.S.C. 1030. Use of this system means you consent to monitoring and recording.

A public website that members of the public use without logging in does not show the banner. Instead, it carries on every page the links that OMB M-23-22 requires, including the link to the Organization’s privacy policy. A public site where members of the public create accounts shows its terms of use when they register.

8.3 Awareness and Training (AT) #

The Awareness and Training Policy (POL-AT) and its procedures (PROC-AT) hold the full requirements and the parameter values that apply.

The Organization must:

• keep an organization-level awareness and training policy and the procedures that put it into practice (AT-01).
• document every literacy and role-based training activity: who was assigned, who completed it, when, and with what result (AT-04).

The CISO must:

• designate the officials accountable for developing, publishing, and maintaining both documents (AT-01).
• add lessons learned from internal and external incidents while they are still current (AT-02).
• keep a role catalog that maps each role group in 5 CFR 930.301 to Organization roles (AT-03).
• own the training record system, the learning management system (LMS), and the completion reporting that feeds FISMA metrics under OMB M-25-04 (AT-04).

Supervisors must:

• not let staff whose training has lapsed keep their access (AT-02).
• be able to see their staff’s training status at any time (AT-04).

Other requirements:

• Those officials must distribute the documents to the Authorizing Official, System Owners, ISSOs, and the other stakeholders who carry their obligations (AT-01).
• The designated officials must review and update the policy and the procedures at least every year (AT-01).
• They must also review both documents sooner when a major incident or a major change to applicable policy exposes a gap (AT-01).
• Every system user, from senior executives to contractors, must complete security and privacy literacy training before receiving access to Organization information and systems (AT-02).
• Every user must repeat the training every year and must retrain when a system change alters what safe behavior looks like (AT-02).
• The CISO must own the curriculum and must refresh it every year and after a major change to applicable policy (AT-02).
• Between courses, the program must reinforce awareness through broadcast announcements, physical signage, internal digital resources, and awareness events (AT-02).
• People in these roles must complete role-based security and privacy training before they take on the duty or the access it carries (AT-03).
• They must repeat the training every year (AT-03).
• When a system change alters a role’s responsibilities, the affected role holders must retrain without waiting for the yearly cycle (AT-03).
• The CISO must update the content every year and after a major change to applicable policy, and must build incident lessons learned into the material (AT-03).
• The CISO must monitor those records so that they stay current, and must not simply file them away (AT-04).
• The CISO must retain individual training records for the periods that the Organization Records Control Schedules set and must dispose of them under the schedule, not for convenience (AT-04).

8.4 Audit and Accountability (AU) #

The Audit and Accountability Policy (POL-AU) and its procedures (PROC-AU) hold the full requirements and the parameter values that apply.

The Organization must:

• keep an audit and accountability policy and the procedures that put it into practice (AU-01).
• allocate audit log storage for at least [AU-04 parameter 1 — to be defined] of active, rapidly searchable data and a further 18 months in cold storage, for 30 months of coverage in total (AU-04).
• protect audit information and the tools that manage logging from unauthorized access, modification, and deletion (AU-09).
• keep audit evidence that ties each covered action to the person who performed it, or to the process acting for that person (AU-10).
• retain audit records for a time period in compliance with OMB M-26-14 in active, rapidly searchable storage and a further 18 months in cold storage, for 30 months in total (AU-11).

The CISO must:

• review and update each document at least every 3 years, and sooner after a major incident or a major change to applicable policy (AU-01).
• when law enforcement, an intelligence source, or another credible source reports a higher threat, direct deeper and more frequent analysis (AU-06).
• not wait for the next cycle (AU-06).

System Owners must:

• document what their system can log, what it does log, and why that selection is enough to reconstruct an incident afterward (AU-02).
• review the selections every year (AU-02).
• also review them whenever OMB or the Cybersecurity and Infrastructure Security Agency (CISA) changes the logging baseline or maturity model, or the system’s threat environment changes (AU-02).
• make sure their components produce records complete enough for an analyst to reconstruct the activity without access to the machine (AU-03).
• declare the expected log volume when a system onboards, so the SOC can plan central capacity in advance (AU-04).
• configure each system to capture the following actions with the actor’s identity attached, [AU-10 parameter 1 — to be defined] (AU-10).
• protect these records from change or deletion and forward them to the security information and event management (SIEM) system (AU-10).
• not dispose of audit records early for cost or convenience (AU-11).
• when a High Value Asset or other system sends audit information to an outside organization, or receives it from one, agree with that organization on how they share it (AU-16).
• write these terms into the information exchange agreement for the connection (AU-16).

ISSOs must:

• coordinate event selections with the SOC and the other offices that depend on audit data (AU-02).
• verify record completeness when a source onboards to the SIEM system and whenever a system change alters a log format (AU-03).
• where record content could expose information about individuals beyond the audit purpose, limit the content (AU-03).
• verify timestamp accuracy and format when a source onboards and when someone suspects drift (AU-08).
• confirm that each system meets this requirement before authorization and after each major change (AU-10).
• verify that no component enters service, or stays in service, without logging (AU-12).
• confirm that shared logs still meet the retention and timestamp rules in this policy, as OMB M-26-14 requires (AU-16).

Administrators must:

• build the alerting into the pipeline, so detection does not depend on a person noticing a quiet dashboard (AU-05).
• where the Agency defines additional response actions for a failure type, carry them out as defined (AU-05).
• synchronize those clocks so timestamps are accurate to within 10 milliseconds (AU-08).
• configure time synchronization on every component they operate (AU-08).
• correct a drift finding with the urgency of a security defect (AU-08).
• enable audit record generation on every system component, including servers, endpoints, network devices, cloud services, and applications (AU-12).

The Security Operations Center (SOC) must:

• assess every outage to determine what the Organization could not see while it lasted (AU-05).
• review and analyze audit records every week for moderate-impact and high-impact systems and every week for low-impact systems (AU-06).
• report findings to the System/Application Owner, the ISSO, and the System/Application Administrators (AU-06).
• not reduce their coverage (AU-06).
• treat the event as hostile until an investigation shows otherwise (AU-09).

Other requirements:

• The policy must state the obligations the Organization answers for outside the agency (AU-01).
• Every system must log the events the OMB M-26-14 minimum baseline requires (AU-02).
• The records must hold enough detail to size an incident and trace its attack path from initial access through lateral movement (AU-02).
• Logged events must stream to the SIEM system in near real time (AU-02).
• Every audit record must capture what happened, when it happened, where it happened, the source that produced it, how it ended, and the identity of the user or process behind it (AU-03).
• The SIEM system is the central repository, and the SOC must keep its retention configuration matched to those periods (AU-04).
• The SOC must monitor consumption against capacity and must act before the storage runs out (AU-04).
• Every system must detect a failure in its audit logging process, including a failed agent, a broken transport, storage exhaustion, or a stalled pipeline (AU-05).
• The system must alert the System/Application Owner, the ISSO, and the System/Application Administrators in near real time (AU-05).
• At a minimum, the review must cover system and service starts and stops, network connection changes and failures, and changes or attempted changes to security settings (AU-06).
• It must also cover logon activity and what followed it, account and privilege changes, use of privileged accounts, and application authentication, configuration, and transaction anomalies (AU-06).
• Every system must stamp its audit records using its internal system clocks (AU-08).
• Timestamps must use Coordinated Universal Time (UTC) or carry a fixed, recorded offset from it, so records from different components line up without interpretation (AU-08).
• The SOC must limit access to the SIEM system workspace and the underlying log stores to authorized roles, and the workspace must log every change to the logging configuration (AU-09).
• When a system detects unauthorized access to audit information or tampering with it, the system must alert the System/Application Owner, the ISSO, and the System/Application Administrators (AU-09).
• Each record must use the actor’s own authenticated identity, never a shared or generic account (AU-10).
• Records must stay searchable for at least 6 months and retrievable for at least 12 months, per OMB M-26-14 (AU-10).
• Each record must carry an accurate timestamp from the Organization’s designated time source (AU-10).
• Release from a hold must be a documented decision (AU-11).
• When the retention period ends, disposal must follow the records schedule and must leave a record of its own (AU-11).
• Each component must be able to produce records for the event types its system must cover (AU-12).
• The records must carry the full content this policy requires of audit records (AU-12).
• An unlogged component found in operation is a deficiency, and the System/Application Owner must correct it (AU-12).
• The agreement must use [AU-16 parameter 1 — to be defined] and cover [AU-16 parameter 2 — to be defined] (AU-16).
• Each side must record the identity behind each request at the system where the request starts (AU-16).
• Systems further along the path must record that the request came from that authorized person or process (AU-16).
• The agreement must also say how each side protects the shared logs and how fast it hands them over for an incident (AU-16).

8.5 Assessment, Authorization, and Monitoring (CA) #

The Assessment, Authorization, and Monitoring Policy (POL-CA) and its procedures (PROC-CA) hold the full requirements and the parameter values that apply.

The Organization must:

• keep an organization-level assessment, authorization, and monitoring policy and the procedures that put it into practice (CA-01).
• select assessors who match the assessment type and hold the skills the system’s technology requires (CA-02).
• approve and manage every information exchange between its systems and other systems through a written agreement (CA-03).
• suspend any exchange that operates without a current agreement (CA-03).
• assign a senior official as the Authorizing Official for each system and for the common controls that systems inherit (CA-06).
• run a penetration test at least every year against, at a minimum, FIPS-199 High, Mission Essential, High Value Asset, and Financial Systems (CA-08).
• disconnect a component after a component failure, a security incident, or a system failure, or when the CISO directs it (CA-09).

The CISO must:

• review and update each document at least every 3 years, and sooner after a major change to applicable policy (CA-01).

Authorizing Officials must:

• when the System Owner cannot correct a weakness, accept the remaining risk in writing (CA-05).
• issue one of the decisions in NIST SP 800-37 Rev 2: authorization to operate, common control authorization, authorization to use, or denial (CA-06).
• update each authorization under OMB A-130 requirements or when a significant change occurs and after a significant change to the system (CA-06).
• sign each report to accept the residual risk it states (CA-07).

System Owners must:

• for High Value Assets, remediate critical and high weaknesses within 30 days of the final assessment report, as OMB M-19-03 requires (CA-05).
• build the strategy around the metrics and monitoring frequencies in the Organization’s Continuous Monitoring Plan (CA-07).
• authorize each internal connection of a component to a system before it connects (CA-09).

ISSOs must:

• arrange an assessment of the controls in each system at least every year (CA-02).
• also arrange one sooner when a significant change affects the system’s boundary, its architecture, or the types of information it handles (CA-02).
• enter every weakness in the POA&M with an owner (CA-02).
• choose the agreement type under NIST SP 800-47 Rev 1 (CA-03).
• review each agreement at least every year and after a significant change on either side (CA-03).
• reissue each agreement when the system is reauthorized (CA-03).
• enter every weakness found by a control assessment, an audit, or continuous monitoring in the system’s plan of action and milestones (POA&M) (CA-05).
• update it at least every month (CA-05).
• record each slip as a milestone change with its reason (CA-05).
• close an item from an Inspector General or other external audit only after the auditor agrees that the weakness is fixed (CA-05).
• carry it out (CA-07).
• send a security status report to the Authorizing Official, the CISO, and the Privacy Officer at least [CA-07 parameter 7 — to be defined], and at once when the security posture changes (CA-07).
• turn each finding into a POA&M entry and verify each fix by a retest (CA-08).

Other requirements:

• The policy must describe how the program operates (CA-01).
• The policy must state plainly that authorization decisions rest on risk judgment, not on a completed checklist (CA-01).
• Each assessment must follow a written plan that names the controls, procedures, environment, and team roles (CA-02).
• Each yearly assessment must include every control whose POA&M item closed since the last assessment (CA-02).
• It must also include every control tied to an audit finding or a security incident in that period, in addition to the controls the monitoring rotation schedules (CA-02).
• For a new system or a major change, security engineering staff who are independent of the System Owner must review the security and privacy architecture first (CA-02).
• The Authorizing Official or a designated representative must approve the plan only after that review is on file, and before any testing starts (CA-02).
• The assessment team must send its report to at least the Authorizing Official, the System Owner, and the ISSO (CA-02).
• Each agreement must record how the interface works, the controls and duties on each side, and the impact level of the information (CA-03).
• Each agreement must also state when either party may suspend the exchange and how either party may end it (CA-03).
• Each entry must follow the format in OMB M-02-01 (CA-05).
• It must name an owner, the root cause, the planned corrective actions, the milestones, and the scheduled completion date (CA-05).
• It must also give the estimated cost and the budget investment that pays for the fix (CA-05).
• Once set, the scheduled completion date must not change (CA-05).
• If the System Owner cannot meet that window, the entry must hold a remediation plan with milestones (CA-05).
• Before a system enters operation, its Authorizing Official must accept the common controls it inherits and must authorize the system (CA-06).
• Each condition on an authorization must have a POA&M item and a deadline (CA-06).
• A cloud service within the scope of Federal Risk and Authorization Management Program (FedRAMP) must hold a FedRAMP authorization before it handles federal information, as OMB M-24-15 requires (CA-06).
• Every system must operate under a system-level continuous monitoring strategy that is consistent with the organization-level strategy (CA-07).
• The report must give the assessment results, the risks carried forward, open vulnerabilities by severity, and POA&M progress with late items (CA-07).
• It must also list the risks proposed for acceptance and say whether the trend is improving or getting worse (CA-07).
• Each internet-facing system and each high-impact system must also receive a penetration test before its initial authorization (CA-08).
• Testers must follow the planning, discovery, attack, and reporting phases in NIST SP 800-115 (CA-08).
• Every test must run under rules of engagement that both sides sign before testing starts (CA-08).
• The rules must cover scope, constraints, safety measures, and the handling of any protected information the test exposes (CA-08).
• Testers must not change or delete logs and must not leave persistent access (CA-08).
• Testers who find signs of a real compromise must stop and report it to the ISSO and the Security Operations Center at once (CA-08).
• Each authorization must document how the interface works, the security and privacy requirements it must meet, and the type of information that crosses it (CA-09).
• System Owners must review the continued need for every internal connection at least [CA-09 parameter 3 — to be defined] and must remove any connection that no one can justify (CA-09).

8.6 Configuration Management (CM) #

The Configuration Management Policy (POL-CM) and its procedures (PROC-CM) hold the full requirements and the parameter values that apply.

The Organization must:

• keep an organization-level configuration management policy and the procedures that put it into practice (CM-01).
• deliver each approved version to the Authorizing Official, System Owners, ISSOs, and the key stakeholders who follow it (CM-01).
• track software protected by quantity licenses to control copying and distribution (CM-10).
• enforce installation rules technically, at a minimum through the approved whitelist and blacklist (CM-11).

The CISO must:

• approve those restrictions before anyone enforces them (CM-05).
• make sure the Organization monitors compliance continuously (CM-11).

System Owners must:

• develop and maintain a current baseline configuration for each system and keep it under configuration control (CM-02).
• review and update the baseline every year (CM-02).
• also update it when the system boundary or architecture changes significantly, when applicable policy directs, and when someone installs or upgrades a component (CM-02).
• define and document the physical and logical access restrictions that govern who may modify each system (CM-05).
• configure every system component to the most restrictive settings that still meet explicit mission and business requirements (CM-06).
• implement the approved settings (CM-06).
• identify and document each deviation, and get it approved under that standard before it exists in production (CM-06).
• configure each system to provide only the capabilities its mission requires (CM-07).
• document the permitted ports, protocols, software, and services in the System Security and Privacy Plan (SSPP) and the authorization package (CM-07).
• keep a component inventory for each system that accurately reflects the system and includes every component in it (CM-08).
• review and update the inventory at least every month and after each significant system change (CM-08).
• include software bill of materials (SBOM) data that meets the CISA 2026 SBOM Minimum Elements (CM-08).
• not permit deployment beyond the entitlements the Organization holds (CM-10).
• treat an unauthorized installation as a configuration incident: they remove it, open a ticket, and trace it to the control that should have prevented it (CM-11).

ISSOs must:

• analyze each proposed configuration-controlled change for its security and privacy impact before anyone implements it, following NIST SP 800-128 (CM-04).
• coordinate with the Privacy Officer when the change affects personal information (CM-04).
• also decide whether the change counts as significant under NIST SP 800-37 Rev 2, and the Authorizing Official decides whether a significant change needs reauthorization (CM-04).

Administrators must:

• bring each new or rebuilt component to the approved baseline and the current patch level before it joins a production network (CM-02).
• apply the baseline settings and current patches to each new or rebuilt component, and confirm them with a compliance scan, before it joins a production network (CM-06).

Users must:

• use software and its documentation under the contract agreements and copyright law that govern it (CM-10).

Other requirements:

• The policy must state why the program exists, what it covers, who owns each duty, how organizational units coordinate, and what compliance requires (CM-01).
• It must stay consistent with the laws, executive orders, directives, and regulations that apply to the Organization (CM-01).
• The designated officials must review and update the policy and the procedures every year (CM-01).
• They must also review both documents after a major incident or a major change to applicable policy (CM-01).
• The baseline must list the system’s components, their placement in the architecture, and the settings the system depends on (CM-02).
• In the analysis, the ISSO must find the change’s vulnerabilities, assess the risk, identify the affected controls, and plan safeguards (CM-04).
• Any person who can alter a system without an approved restriction that covers them is a gap the System Owner must close (CM-05).
• Each record must carry, at a minimum, the hostname, Internet Protocol (IP) address, manufacturer, type, model, name, serial number, version number, and logical location (CM-08).
• Physical hardware records must also carry the item and barcode (CM-08).
• Under CISA Binding Operational Directive (BOD) 23-01, the inventory must reflect the network as scanned (CM-08).
• Under OMB M-21-30, System Owners must flag each product that meets NIST’s definition of critical software under Executive Order 14028 (CM-08).
• Where the Organization authorizes peer-to-peer file sharing, it must control and document that use so no one distributes copyrighted work without authorization (CM-10).
• The Organization Rules of Behavior govern how users install software, and every user must accept them before receiving access (CM-11).
• A user who needs software the list does not cover must request it (CM-11).

8.7 Contingency Planning (CP) #

The Contingency Planning Policy (POL-CP) and its procedures (PROC-CP) hold the full requirements and the parameter values that apply.

The Organization must:

• keep a contingency planning policy and the procedures that put it into practice (CP-01).
• keep alternate telecommunications services and the agreements needed to resume the systems and services defined in each system’s business impact analysis (BIA) and information technology contingency plan (ITCP) (CP-08).
• recover and reconstitute each system to a known state within a time that meets the system’s Recovery Time Objective (RTO) and Recovery Point Objective (RPO) (CP-10).
• for every Mission Essential System, recover within the [CP-10 parameter 1 — to be defined] Maximum Tolerable Downtime that Federal Continuity Directive 1 sets (CP-10).

The CISO must:

• review and update the policy and the procedures every year, and sooner after a major incident or a major change to applicable policy (CP-01).

System Owners must:

• complete a business impact analysis (BIA) for every system, low-impact systems included, before writing the plan and again after each significant change (CP-02).
• review the plan every year (CP-02).
• test each system’s contingency plan every 3 years (CP-04).
• review the test results with the ISSO (CP-04).
• confirm that the alternate arrangements cover both the data paths and the voice paths the essential functions depend on (CP-08).
• run backups for each system on the schedule its recovery objectives require (CP-09).
• back up system documentation, including security and privacy documentation, every day or when the documents change (CP-09).
• protect the confidentiality, integrity, and availability of backup information wherever the Organization stores it (CP-09).
• run the recovery against the clock (CP-10).
• inform the Authorizing Official when reconstitution requires a reauthorization decision (CP-10).

Supervisors must:

• not leave a contingency role with a person whose training is overdue (CP-03).

Other requirements:

• The policy must state its purpose and scope, assign roles and responsibilities, record management’s commitment, and describe how organizational units coordinate during planning and during a disruption (CP-01).
• It must also state what compliance requires (CP-01).
• The policy must stay consistent with the laws, executive orders, directives, and regulations that apply to the Organization (CP-01).
• Every system must have an Information System Contingency Plan (ISCP) (CP-02).
• The plan must identify the system’s essential mission and business functions (CP-02).
• It must set recovery objectives and restoration priorities from the BIA (CP-02).
• It must name the contingency roles and the people who fill them, with current contact information (CP-02).
• The plan must describe how the Organization sustains essential functions through a disruption, compromise, or failure (CP-02).
• It must describe how the Organization restores the system fully without weakening its controls, and how it shares contingency information (CP-02).
• The Authorizing Official or a designated representative and the System Owner must review and approve each plan (CP-02).
• The System Owner must send copies to the key contingency personnel listed in the approved ISCP and must upload the plan to the GRC system (CP-02).
• The System Owner must update it for organizational and system changes and for problems found during execution or testing, and must protect it from unauthorized disclosure and modification (CP-02).
• The Organization must train every person who holds a contingency role, and the training must match the role’s duties (CP-03).
• The person must complete the training within [CP-03 parameter 1 — to be defined] of taking the role, again when a system change alters the role’s duties, and every year after that (CP-03).
• The CISO must review and update the training content every year and after a major incident or a major change, and must add the lessons from tests and real activations (CP-03).
• Each test plan must set objectives for notification, recovery from backup on an alternate platform, internal and external connectivity, performance on alternate equipment, and return to normal operations (CP-04).
• The test scenarios must include a destructive cyberattack, such as ransomware that encrypts or deletes data (CP-04).
• Where the test found a weakness, the System Owner must start corrective action and must revise the plan (CP-04).
• The alternate services must restore the systems within the Recovery Time Objectives (RTOs) and the business-function Maximum Tolerable Downtimes (MTDs) those approved documents specify (CP-08).
• The CISO must confirm that contingency tests validate the arrangements, and must not accept contract language alone as proof (CP-08).
• The backups must capture the user-level information on the components needed to restore full function, and the system-level information (CP-09).
• The schedule is daily incremental and daily full backups, and it must meet the system’s Recovery Time Objective (RTO) and Recovery Point Objective (RPO) (CP-09).
• System Owners must monitor backup execution and must correct a failure within the window the RPO allows (CP-09).
• A system that still runs on an improvised configuration remains a risk, and the System Owner must not declare it recovered (CP-10).

8.8 Identification and Authentication (IA) #

The Identification and Authentication Policy (POL-IA) and its procedures (PROC-IA) hold the full requirements and the parameter values that apply.

The Organization must:

• keep an identification and authentication policy and the procedures that put it into practice (IA-01).
• stay consistent with the laws, executive orders, directives, and standards that apply to the Organization, including the phishing-resistant authentication requirements in OMB M-22-09 (IA-01).

System Owners must:

• confirm at provisioning that every account maps to exactly one person (IA-02).
• define in the SSPP which device types require authentication and the mechanism each type uses (IA-03).
• ensure that every interface, whether workstation, web, or application, masks credential entry and returns a generic failure message (IA-06).
• not weaken masking for usability without the CISO’s approval (IA-06).
• ensure that operator authentication to each cryptographic module meets the federal laws, directives, and standards that govern such modules (IA-07).
• procure and deploy only modules that support compliant operator authentication (IA-07).
• not set up local account stores for individual applications (IA-08).
• select the assurance level for external access from the risk of the transaction, under NIST SP 800-63-4 (IA-08).
• confirm that the session settings of their applications match this policy (IA-11).

ISSOs must:

• treat a credential that two people use as a security incident (IA-02).
• verify that the enforcing configuration matches the SSPP (IA-03).
• audit identifier records for uniqueness and premature reuse (IA-04).
• verify module authentication settings at deployment and after any change to the module or its host (IA-07).
• confirm external authentication paths during assessment (IA-08).

Administrators must:

• access modules with individual credentials, using PIV or a hardware security key where the module supports hardware factors, and never with a shared module password (IA-07).

Users must:

• authenticate with that identity before they receive access (IA-02).
• safeguard the authenticators in their possession, report loss or suspected compromise at once, and never share them (IA-05).
• re-authenticate when a session or connection ends, when a virtual private network (VPN) disconnects, and at device lock (IA-11).
• re-authenticate when an application session closes or times out for idleness (IA-11).
• also re-authenticate when their role changes, when an authenticator or credential is replaced, or when a system’s security category changes (IA-11).
• re-authenticate before they run privileged functions (IA-11).
• also re-authenticate when a session reaches the limit for the system’s authentication assurance level (AAL) (IA-11).

Other requirements:

• Every organizational user, employee or contractor, must hold one unique identity that the Organization manages centrally under OMB M-22-09 (IA-02).
• The identity team must not issue shared credentials for interactive use (IA-02).
• Devices of the types that each System Security and Privacy Plan (SSPP) designates must identify and authenticate themselves before a local, remote, or network connection is established (IA-03).
• The identity team must not assign an identifier without authorization from, at minimum, the System Owner, ISSO, or System Administrator (IA-04).
• Each identifier must designate exactly one individual, group, role, service, or device, and it stays with that subject for the life of the account (IA-04).
• The identity team must not reassign a retired identifier for at least 2 years, so logs, records, and investigations never point to the wrong party (IA-04).
• The identity team must verify the recipient’s identity before it issues any authenticator (IA-05).
• The identity team must change every default credential before a component enters service (IA-05).
• The identity team must change or refresh authenticators [IA-05 parameter 1 — to be defined] (IA-05).
• The identity team must replace any authenticator immediately when compromise is confirmed or when indicators of compromise suggest it (IA-05).
• The identity team must revoke an authenticator when the need for it ends (IA-05).
• Before the service desk resets a password or binds a new authenticator, it must verify the person’s identity (IA-05).
• The service desk must never ask for a password, personal identification number (PIN), or one-time code and must not use knowledge-based questions, as NIST SP 800-63B-4 directs (IA-05).
• Systems must obscure authentication information as the user enters it, so a person who watches the display sees neither the credential nor its pattern (IA-06).
• Systems must return a failure message that does not reveal which part of a failed logon was wrong (IA-06).
• The mechanism must confirm both the operator’s identity and the role the operator may assume (IA-07).
• Non-organizational users, and processes that act on their behalf, must identify and authenticate themselves uniquely before they access a system (IA-08).
• External access must go through the enterprise identity providers, the single sign-on (SSO) service and the cloud directory (IA-08).
• A system assessed under the earlier revision of NIST SP 800-63 must move to NIST SP 800-63-4 at its next reassessment or major change (IA-08).
• The identity team must implement these triggers in the SSO service and the cloud directory session policies and in the on-premises directory logon enforcement (IA-11).

8.9 Incident Response (IR) #

The Incident Response Policy (POL-IR) and its procedures (PROC-IR) hold the full requirements and the parameter values that apply.

The Organization must:

• keep an incident response policy and the procedures that put it into practice (IR-01).
• operate an incident handling capability that carries out the incident response plan through every phase: preparation, detection and analysis, containment, eradication, and recovery (IR-04).
• provide an incident response support resource, as part of the response capability, that gives system users advice and help with handling and reporting incidents (IR-07).
• keep an incident response plan (IR-08).

The CISO must:

• build each test on a likely threat scenario, such as ransomware, credential compromise, or a breach of PII (IR-03).
• approve the [IR-03 parameter 1 — to be defined] test schedule (IR-03).
• when criminal or civil action is possible, bring in General Counsel before anyone collects evidence (IR-04).
• coordinate incident handling with contingency planning so that recovery decisions use both (IR-04).
• apply the same rigor to incidents of the same severity, wherever they occur (IR-04).
• bring the SAOP into the response from the start of any breach that involves PII (IR-04).
• review incident trends and use them to direct the program (IR-05).
• promptly notify the Office of Inspector General of any incident that may involve criminal activity, misuse by an authorized user, or theft of equipment (IR-06).
• coordinate any law enforcement referral with General Counsel (IR-06).
• also inform the insider threat program of incidents that involve a trusted insider, and the Contracting Officer of incidents that involve a contractor or a supplier’s product (IR-06).
• keep the support resource staffed, reachable, and known to the workforce (IR-07).
• assign incident response responsibility in the plan to the System Owner, ISSO, SOC Manager, and CISO (IR-08).
• review and approve the plan at least every year and after any major incident (IR-08).

System Owners must:

• test the incident response capability of each system [IR-03 parameter 1 — to be defined] (IR-03).

The Security Operations Center (SOC) must:

• keep a chain-of-custody record for each item of evidence, following NIST SP 800-86 (IR-04).
• track and document every incident from the first report to closure (IR-05).
• update each record while the incident runs, so that no one has to reconstruct it afterward (IR-05).
• keep each incident record, its evidence, and its follow-up documents for 3 years after all follow-up actions are complete, as National Archives and Records Administration (NARA) General Records Schedule (GRS) 3.2 requires (IR-05).

Supervisors must:

• make sure their personnel complete training on schedule (IR-02).

Users must:

• complete incident response training that matches their assigned roles (IR-02).
• complete it within 10 days of taking on an incident response role or gaining system access, again when a system change alters what response requires, and every year after that (IR-02).
• report a suspected incident to the Organization IT Service Desk or the SOC within 1 hour of discovery (IR-06).

Other requirements:

• The policy must stay consistent with the laws, directives, and standards that apply to the Organization (IR-01).
• The CISO reviews and updates the policy and the procedures every year, and sooner when a newly identified threat or attack method changes what the documents must say (IR-01).
• The CISO owns the curriculum and must review and update its content every year and when new adversary tactics and tools appear (IR-02).
• The combined test must still exercise detection, reporting to CISA, containment, and the major incident and breach decisions (IR-03).
• System Owners must run the tests for their systems and must record every finding as a corrective action with an owner and a due date (IR-03).
• First responders must isolate an affected system from the network but must not log in, reboot, or power it off until the Incident Response Team approves (IR-04).
• The CISO must feed lessons from incident handling into procedures, training, and testing, and must make sure the resulting changes are put in place (IR-04).
• The record must show what happened, who acted, and when (IR-05).
• The SOC Manager must report to CISA each incident that may have compromised the confidentiality, integrity, or availability of federal information or a federal information system (IR-06).
• The report must reach CISA within 1 hour of the time the SOC identifies the incident, as CISA’s Federal Incident Notification Guidelines set (IR-06).
• The SOC Manager must submit it through the CISA Incident Reporting Form and record the CISA incident ID in the incident ticket (IR-06).
• Each CISA report must classify the incident by functional impact, information impact, recoverability, and attack vector, in CISA’s current terms (IR-06).
• The SOC Manager must update the report as facts change and when the incident closes (IR-06).
• The CISO’s office must send copies to all members of the computer emergency response team (CERT), senior executives, the CIO, the CISO, ISSOs, System Owners, and Information Owners (IR-08).
• The CISO’s office must tell the same people about changes (IR-08).
• The CISO’s office must protect the plan from unauthorized disclosure and modification (IR-08).

8.10 Maintenance (MA) #

The Maintenance Policy (POL-MA) and its procedures (PROC-MA) hold the full requirements and the parameter values that apply.

The Organization must:

• keep an organization-level maintenance policy and the procedures that implement it (MA-01).
• schedule, document, and review maintenance, repair, and replacement of system components against manufacturer and vendor specifications and organizational requirements (MA-02).
• keep a record of every nonlocal session: who connected, when, what they did, and to which components (MA-04).
• run an authorization process for maintenance personnel (MA-05).

System Owners must:

• ensure that all information is sanitized from associated media before the equipment leaves (MA-02).

ISSOs must:

• after the work, verify that every control the action could have affected still functions (MA-02).
• treat a repair that disabled a control as a new incident (MA-02).
• maintain the current list of authorized maintenance organizations and individuals (MA-05).

Other requirements:

• The designated policy owner must distribute them to the Authorizing Official, System Owners, ISSOs, and key stakeholders (MA-01).
• The designated policy owner must review and update both documents at least every 3 years and after a major change to applicable policy (MA-01).
• The policy must include the lifecycle requirement in CISA BOD 26-02 (MA-01).
• The System Owner, ISSO, or a designated representative must approve all maintenance before it happens and monitor it while it happens (MA-02).
• The System Owner, ISSO, or a designated representative must explicitly approve any removal of equipment from organizational facilities for off-site repair or replacement (MA-02).
• Maintenance records must capture the dates and times, who performed the work, what they did, and which components they removed or replaced (MA-02).
• The System Owner or ISSO must approve nonlocal maintenance and diagnostic activity before the session is established and must monitor it while it runs (MA-04).
• Nonlocal maintenance must use only the tools that organizational policy allows and the system’s System Security and Privacy Plan (SSPP) documents (MA-04).
• Every session must start with strong authentication that is multi-factor and resistant to replay (MA-04).
• When the work is complete, the technician must end the session and close its network connections (MA-04).
• Before non-escorted maintenance begins, the ISSO or a designated representative must verify that the technician holds the access authorizations the work requires (MA-05).
• Vendor personnel who arrive on short notice must use temporary credentials scoped to the job that expire when it ends (MA-05).
• They must never use borrowed accounts (MA-05).

8.11 Media Protection (MP) #

The Media Protection Policy (POL-MP) and its procedures (PROC-MP) hold the full requirements and the parameter values that apply.

System Owners must:

• before anyone sanitizes or destroys media that holds federal records, confirm with the records officer that the records schedule allows disposal (MP-06).
• keep sanitization records for 3 years, as NARA General Records Schedule (GRS) 3.1, item 020, requires (MP-06).
• enforce these restrictions on their systems (MP-07).

ISSOs must:

• before the Organization contracts out sanitization or destruction, document due diligence on the vendor, such as an independent audit or a third-party certification (MP-06).

Users must:

• give up media access they no longer require instead of keeping it for convenience (MP-02).
• sanitize digital and non-digital media before disposal, before release out of the Organization’s control, and before release for reuse (MP-06).
• use approved techniques and procedures under NIST SP 800-88 Rev. 2 (MP-06).
• when sanitization cannot be assured, destroy the media (MP-06).
• not connect personally owned media to Organization systems (MP-07).

Other requirements:

• The Organization must keep an organization-level media protection policy and the procedures that implement it, and must distribute both to the Authorizing Official, System Owners, ISSOs, and key stakeholders (MP-01).
• Those same officials must manage the development, documentation, and distribution of the policy and the procedures (MP-01).
• They must keep both documents consistent with applicable laws, directives, and standards (MP-01).
• The policy must state its purpose and scope, assign roles and responsibilities, record management’s commitment, and set expectations for coordination and compliance (MP-01).
• The designated officials must review and update the policy every 3 years and after a major change to applicable policy (MP-01).
• They must review and update the procedures on the same cycle (MP-01).
• The owner must record each authorization on an approved access control list (MP-02).
• Owners must keep their lists current and must remove individuals whose need has ended (MP-02).
• The strength of the method must match the security category or classification of the information on the media (MP-06).
• A second person who did not do the work must validate each sanitization (MP-06).
• Each record must name the final disposition of the media: reused internally, reused externally, returned, or destroyed (MP-06).
• Anyone who needs removable media must request it through the approval workflow, so that every approved device has a named owner on record (MP-07).
• Personnel who find media must hand it to the ISSO and must not test it (MP-07).

8.12 Physical and Environmental Protection (PE) #

The Physical and Environmental Protection Policy (POL-PE) and its procedures (PROC-PE) hold the full requirements and the parameter values that apply.

The Organization must:

• keep a physical and environmental protection policy and the procedures that put it into practice (PE-01).
• stay consistent with federal law and directives (PE-01).
• issue an access credential, a badge or equivalent, only to individuals on that list (PE-02).
• recover or deactivate their credentials (PE-02).
• enforce access authorizations at every physical access point (PE-03).
• keep audit logs for every access point where it enforces authorizations (PE-03).
• monitor physical access to the facilities that house its systems so that it detects and responds to physical security incidents (PE-06).
• keep visitor access records for every facility that houses its systems (PE-08).
• retain those records for at least 1 year (PE-08).
• keep a record of every component movement: what came or went, when, and under whose authorization (PE-16).

System Owners must:

• develop, approve, and maintain the list of individuals authorized to enter the facility that houses the system (PE-02).
• secure keys, combinations, and other access devices and inventory them at least once a year (PE-03).
• change combinations and keys at least once a year, and immediately when a key is lost, a combination is exposed, or a holder transfers or leaves (PE-03).
• confirm that the spaces holding its equipment are within detection and suppression coverage (PE-13).
• verify through provider documentation that these ranges and continuous monitoring are in force for the Organization’s equipment (PE-14).
• make sure the valve locations for spaces that hold organizational equipment are identified and that the responsible on-site personnel are briefed on them (PE-15).
• approve component deliveries and removals for its systems (PE-16).

ISSOs must:

• review the access list every year and confirm that every entry still has a business reason to enter (PE-02).
• promptly remove individuals whose duties no longer require facility access (PE-02).
• review physical access logs at least every month for low- and moderate-impact systems and monthly for high-impact systems (PE-06).
• also review them immediately when there is an indication of suspicious activity (PE-06).
• coordinate findings from log reviews and any resulting investigation with the Organization’s incident response capability (PE-06).
• review the visitor records at least every month for entries that do not match legitimate business (PE-08).
• report it to the ISSM and to the facility security staff, including the Federal Protective Service where it holds protective responsibility for the building (PE-08).
• record that verification and revisit it when the facility or provider changes (PE-13).
• record the verification (PE-14).
• record the verification and refresh it when the facility or the occupied footprint changes (PE-15).
• reconcile movement records against asset records so that the records match the physical inventory (PE-16).

Other requirements:

• The physical access control system must verify each PIV credential electronically by validating its certificates, not by visual inspection (PE-03).
• For areas open to the public, the System Owner or supporting contractor must recommend the boundary controls, and the CISO and AO must approve them before they take effect (PE-03).
• Through the same approval path, the CISO and AO decide when staff must escort visitors and monitor their activity (PE-03).
• Anyone who finds an anomaly must report it to the ISSO (PE-08).
• Facilities where the Organization’s systems and personnel operate must have automatic emergency lighting that activates on power loss and covers exit paths and evacuation routes (PE-12).
• The System Owner must confirm coverage of the spaces its personnel and equipment occupy, and the ISSO must record the verification (PE-12).
• Anyone who observes an emergency lighting failure during an outage, a drill, or an inspection must report it to the facility provider, and the ISSO must track it until repaired (PE-12).
• Fire detection and suppression systems must protect every facility that houses system equipment (PE-13).
• Those systems must run on an energy source independent of the one that powers the rest of the facility, so that the protection survives a failure or isolation of building power (PE-13).
• The facility provider operates the detection and suppression infrastructure, and the Organization must verify it (PE-13).
• Anyone who finds a coverage gap or an out-of-service protection system must report it, and the Organization treats it as an unacceptable exposure until the protection is restored (PE-13).
• Data center spaces that house system equipment must hold temperature and humidity within the operating ranges that the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) recommends (PE-14).
• Server-inlet temperature must stay between 18 and 27 degrees Celsius (PE-14).
• Humidity, measured by dew point, must stay between 5.5 and 15 degrees Celsius (PE-14).
• The monitoring of environmental levels must be continuous, not sampled, so that the Organization catches drift while it is still a maintenance issue (PE-14).
• Anyone who observes a sustained excursion beyond the ranges must report it (PE-14).
• Facilities that house system equipment must have master shutoff and isolation valves that protect against water leakage (PE-15).
• The valves must be reachable, in working order, and known to the personnel expected to use them (PE-15).
• The facility provider maintains the plumbing infrastructure and its valves, and the Organization must know where its shutoffs are and who turns them (PE-15).
• Anyone who sees a leak near equipment must report it immediately, because the valve only helps if someone reaches it in time (PE-15).
• The System Owner must authorize every system component that enters or leaves the facility in advance, and the Organization must control each movement through the delivery and removal process (PE-16).
• Delivery areas must stay separate from spaces that hold system equipment so that an unescorted courier is never next to production hardware (PE-16).

8.13 Planning (PL) #

The Planning Policy (POL-PL) and its procedures (PROC-PL) hold the full requirements and the parameter values that apply.

The Organization must:

• keep a planning policy at the organization level and the system level, and the procedures that put it into practice (PL-01).
• stay consistent with the governance structures that OMB Circular A-130 requires (PL-01).
• give the rules to every individual before it authorizes that individual’s access (PL-04).

The CISO must:

• develop, document, and distribute both documents to the AO, System Owners, ISSOs, and key stakeholders (PL-01).
• review and update the policy and the procedures every year, and sooner when a major change to applicable policy requires it (PL-01).
• establish rules of behavior that describe each person’s responsibilities and expected conduct for information and system use, security, and privacy (PL-04).
• review and update the rules every 3 years and whenever changes require it (PL-04).
• manage the following controls and processes centrally for the whole Organization: [PL-09 parameter 1 — to be defined] (PL-09).
• assign each centrally managed control to a Common Control Provider (PL-09).
• decide which controls to add to central management when a baseline or overlay changes (PL-09).
• keep the list of centrally managed controls in the policy library in the document management system (PL-09).

Authorizing Officials must:

• concur with the baseline selection as part of authorization (PL-10).
• accept the tailored control set through the authorization decision (PL-11).

System Owners must:

• develop a System Security and Privacy Plan (SSPP) for each system (PL-02).
• identify in the SSPP any activity that needs coordination with the CISO, ISSM, or Privacy Officer (PL-02).
• review the SSPP at least every year, and sooner after a significant change to the boundary, architecture, PIA, or information types (PL-02).
• update the SSPP when the system or its assessment results require it (PL-02).
• protect the SSPP from unauthorized disclosure and modification (PL-02).
• develop a security architecture and a privacy architecture for each system (PL-08).
• review and update the architectures at least every year, and sooner when the boundary, system architecture, PIA, or information types change significantly (PL-08).
• carry planned architecture changes into the System Security and Privacy Plan (SSPP), the concept of operations (CONOPS), the criticality analysis, organizational procedures, and procurements (PL-08).
• inherit a centrally managed control where it covers their system (PL-09).
• for a hybrid control, document only the part the system implements (PL-09).
• select a control baseline for every system based on the system’s FIPS 199 security categorization (PL-10).
• base the selection on the information types the system handles, the harm their compromise would cause, and the results of the risk assessment (PL-10).
• for a system designated as a high value asset, apply the CISA High Value Asset (HVA) Control Overlay on top of the baseline as the starting point for enhanced protection (PL-10).
• apply further overlays when a threat or regulation requires them (PL-10).
• record the selection and its rationale in the System Security and Privacy Plan (SSPP) (PL-10).
• tailor the selected baseline with the established tailoring actions (PL-11).
• document every tailoring action with its rationale in the System Security and Privacy Plan (SSPP) (PL-11).

ISSOs must:

• review the tailoring to confirm that it is defensible (PL-11).

Other requirements:

• The procedures must make each planning control executable (PL-01).
• The SSPP must fit the enterprise architecture and define the system’s components and boundary (PL-02).
• It must describe the operational and threat context, name the role holders, and list the information types (PL-02).
• It must record the security categorization with its rationale, and it must include the privacy risk assessment when the system processes personally identifiable information (PL-02).
• It must explain the controls selected, including tailoring decisions, against the requirements they satisfy (PL-02).
• The AO or designated representative must approve the SSPP before implementation begins (PL-02).
• Distribution of the SSPP must include, at minimum, the AO, the System Owner, and the ISSO (PL-02).
• Every person must acknowledge the rules again [PL-04 parameter 3 — to be defined], when completing the annual security awareness training, and again whenever the CISO revises the rules (PL-04).
• The architectures must describe how the system protects the confidentiality, integrity, and availability of organizational information (PL-08).
• They must describe how the system handles personally identifiable information so privacy risk to individuals stays as low as possible (PL-08).
• They must show how the system’s design fits into and supports the enterprise architecture (PL-08).
• The Enterprise Architecture Policy sets the enterprise security architecture each system must fit (PL-08).
• They must state what the system assumes about the external services and interconnected systems it depends on (PL-08).
• The Common Control Provider must document that control once in the GRC system so that systems can inherit it (PL-09).
• The ISSO for each system must record each inherited control in the System Security and Privacy Plan (SSPP) in the GRC system (PL-09).
• Common Control Providers must keep each common control’s description, assessment results, and plan of action and milestones (POA&M) items current in the GRC system (PL-09).
• As NIST SP 800-18 Rev 2 directs, the SSPP and these records must stay current through the authorization cycle (PL-09).
• The selection must stay consistent with the governance that OMB Circular A-130 establishes for security and privacy programs (PL-10).
• Every departure from the baseline is a risk decision, and it must stay visible (PL-11).

8.14 Personnel Security (PS) #

The Personnel Security Policy (POL-PS) and its procedures (PROC-PS) hold the full requirements and the parameter values that apply.

The Organization must:

• keep an organization-level personnel security policy and the procedures that put the PS controls into practice (PS-01).
• assign a risk designation to every position (PS-02).
• set screening criteria for each position that match its designation, including explicit requirements for positions with information security roles (PS-02).
• when a screening result changes, change the individual’s access without delay (PS-03).
• recover the other property it issued, including tokens, building passes, and equipment (PS-04).
• keep access to the information the individual controlled, so the work continues after the departure (PS-04).
• develop and document access agreements for its systems, including non-disclosure agreements, acceptable use agreements, and related commitments (PS-06).
• set personnel security requirements for external providers, including the security roles and responsibilities their personnel hold (PS-07).
• apply a formal sanctions process to individuals who fail to comply with its information security and privacy policies and procedures (PS-08).
• include security and privacy roles and responsibilities in its position descriptions (PS-09).
• defer hiring against an outdated description until the description is corrected (PS-09).

The CISO must:

• review both documents every 3 years, and again after a major incident or a major change to applicable policy (PS-01).
• review and update the agreements at least every year (PS-06).

System Owners must:

• when an agreement expires or is missing, suspend the access it supported (PS-06).

Users must:

• sign the agreements again every year and whenever the agreements change, so that the signature on file always matches the terms in force (PS-06).

Other requirements:

• The personnel security function must designate each position with the Office of Personnel Management (OPM) Position Designation Tool (PS-02).
• Supervisors, with the personnel security function, must review and update position risk designations at least every 3 years and whenever a position changes materially (PS-02).
• The personnel security function must screen each individual before the Organization authorizes access to its systems, at the depth the risk designation of the person’s position requires (PS-03).
• It must accept a prior favorable investigation that meets the position’s requirements under OPM reciprocity rules, instead of starting a new one (PS-03).
• Account managers must not provision an account on the promise that screening will follow later (PS-03).
• The personnel security function must enroll covered personnel in continuous vetting, as Executive Order 13764 and the Trusted Workforce 2.0 reforms require (PS-03).
• It must rescreen anyone not yet enrolled at least every five years, and sooner when the individual changes position, under the conditions the Organization Security Handbook defines (PS-03).
• System Owners and account managers must not grant access before a favorable determination exists (PS-03).
• When an individual’s employment ends, account managers must disable the individual’s system access within 4 hours (PS-04).
• Account managers must also revoke the authenticators and credentials tied to the individual (PS-04).
• The supervisor or Contracting Officer’s Representative must collect the individual’s PIV card (PS-04).
• The identity team must then revoke the card’s certificates and destroy the card (PS-04).
• Human Resources must notify the insider threat program before an involuntary or adverse separation (PS-04).
• The supervisor must hold an exit interview (PS-04).
• The interview must cover non-disclosure obligations, succession for the roles the individual held, retention of Organization records, and any limits on future employment (PS-04).
• For a termination for cause, the System Owner and the supervisor must coordinate so that access ends at or before the time the individual is notified (PS-04).
• When the Organization reassigns or transfers an individual, the gaining and losing supervisors must review the individual’s logical and physical access against the needs of the new position (PS-05).
• They must confirm which access remains justified (PS-05).
• The losing supervisor must submit an Account Change Request and start any required training updates within 4 hours of the transfer (PS-05).
• Account managers must change the access to match the new duties by reducing it, adding to it, or ending it (PS-05).
• Within the same 4 hours, the Organization must notify Human Resources, Personnel Security, the IT Help Desk, and every network and system administrator that the change affects (PS-05).
• The Contracting Officer (CO) must put those requirements in the governing contracts and agreements and must require providers to follow the Organization’s personnel security policies and procedures (PS-07).
• The CO must include Federal Acquisition Regulation (FAR) clause 52.204-9, Personal Identity Verification of Contractor Personnel, in every contract that requires routine access to a federally controlled facility or information system (PS-07).
• Providers must notify the CO or the Contracting Officer’s Representative (COR) within 4 hours when one of their personnel transfers or leaves (PS-07).
• The COR, with the ISSO, must monitor provider compliance and report a notification failure to the CO as a contract performance issue (PS-07).
• When the Organization starts a formal sanctions process against an employee, the initiating office must notify the individual’s supervisor and the managers of the affected business units within [PS-08 parameter 2 — to be defined] (PS-08).
• Where a Contracting Officer’s Representative or an employee representative is the appropriate party, the initiating office must notify them in the same window (PS-08).
• The notification must name the individual and the reason (PS-08).
• Sanctions must be proportionate to the violation and consistent across cases (PS-08).
• The initiating office must keep the CISO informed of security-driven sanctions, so that the CISO can review them for the policy or control gaps they expose (PS-08).
• Every position description must state the protection duties the position carries, from the baseline obligations all personnel share to the specific duties of ISSOs, System Owners, and other designated roles (PS-09).
• Supervisors, with the personnel security function, must update a description when its security or privacy duties are added or changed (PS-09).

8.15 Risk Assessment (RA) #

The Risk Assessment Policy (POL-RA) and its procedures (PROC-RA) hold the full requirements and the parameter values that apply.

The Organization must:

• keep a risk assessment policy at the organization level and the system level, with the procedures that put it into practice (RA-01).
• detect vulnerabilities continuously (RA-05).
• also scan when someone reports a new vulnerability that could affect its systems (RA-05).

The CISO must:

• manage the development, documentation, and distribution of both documents and deliver each approved version to the AO, System Owners, ISSOs, and key stakeholders (RA-01).
• review and update the policy and the procedures every year (RA-01).
• also review them sooner after a change in mission, business processes, information technologies, system architectures, or the threat environment (RA-01).
• not allow the exposure while a critical finding, or a high finding past its due date, remains open (RA-05).
• monitor response decisions and their execution across systems so the Organization’s total exposure reflects deliberate choices (RA-07).

Authorizing Officials must:

• not grant an authorization until the SAOP has approved the PIA and agreed to the remaining privacy risk (RA-08).

System Owners must:

• categorize each system and the information it processes, stores, and transmits under FIPS 199 (RA-02).
• use the information types in NIST SP 800-60 (RA-02).
• document the categorization and its rationale in the System Security and Privacy Plan (SSPP) (RA-02).
• revisit the categorization when the system’s information types, mission use, or architecture change (RA-02).
• for every system, make sure a risk assessment takes place (RA-03).
• coordinate that privacy analysis with the SAOP (RA-03).
• document the results in the Risk Assessment Report (RA-03).
• review the results every year or whenever a significant change to the system occurs, and distribute them at a minimum to the AO, System Owner, and ISSO (RA-03).
• update the assessment every year as part of continuous monitoring and ongoing authorization (RA-03).
• also update it whenever a change to the system, its environment, or other conditions alters its security or privacy posture (RA-03).
• propose the response for findings on their systems (RA-07).
• complete a privacy threshold analysis before they develop or buy information technology that will handle personally identifiable information (PII), and before they start a new collection of PII (RA-08).
• if the analysis shows that the system or collection handles PII, complete a privacy impact assessment (PIA) before work continues (RA-08).
• update the PIA whenever a change to the system, its data, or its business practices changes the privacy risk (RA-08).

ISSOs must:

• analyze the findings for their systems (RA-05).
• share critical and high findings with the Security Operations Center as soon as they are identified (RA-05).
• when the System Owner chooses mitigation but cannot complete it immediately, create a POA&M item with milestones and track it to closure (RA-07).

Other requirements:

• The policy must fix its purpose and scope, assign roles, record management’s commitment, and set expectations for coordination and compliance in how the Organization identifies and weighs risk (RA-01).
• It must stay consistent with the multi-tier risk management approach in NIST SP 800-39 (RA-01).
• The AO, or the AO’s designated representative, must approve each categorization before anyone relies on it for control selection or authorization (RA-02).
• The categorization must also inform the Organization’s identification of High Value Assets under OMB M-19-03 (RA-02).
• Under NIST SP 800-30r1, the Organization must integrate system-level results with risk decisions at the organization tier and the mission and business process tier (RA-03).
• Detection content must be no more than 24 hours behind the vendor’s latest release (RA-05).
• Before a system or component is exposed to the internet, the vulnerability management team must scan it (RA-05).
• Owning administrators must fix each legitimate finding by its due date (RA-05).
• Results must reach the AO, System Owners, and ISSOs so a weakness fixed on one system is checked on the rest (RA-05).
• Every finding from a security or privacy assessment, from monitoring, or from an audit must receive a deliberate response within the Organization’s risk tolerance (RA-07).
• The Risk Management Strategy (PLAN-RMS-001) sets which official may accept each level of risk and who must concur (RA-07).
• The Senior Agency Official for Privacy (SAOP) must approve each PIA (RA-08).

8.16 System and Services Acquisition (SA) #

The System and Services Acquisition Policy (POL-SA) and its procedures (PROC-SA) hold the full requirements and the parameter values that apply.

The Organization must:

• keep a system and services acquisition policy and the procedures that put it into practice (SA-01).
• show information security and privacy as a separate line item in its programming and budgeting documents (SA-02).
• acquire, develop, and manage every system under the Organization system development life cycle (SDLC) standard operating procedure (SOP) (SA-03).
• place its security and privacy requirements in every acquisition contract for a system, system component, or system service (SA-04).
• apply its adopted engineering principles to the specification, design, development, implementation, and modification of every system and component (SA-08).
• stop using a provider that cannot show its controls through independent reporting (SA-09).

The CIO must:

• make sure the Organization identifies, documents, and allocates the resources needed to protect each system (SA-02).
• return any investment request that arrives without security and privacy resourcing to the System Owner for correction (SA-02).

The CISO must:

• review and update the policy and the procedures every year (SA-01).
• also update them sooner when the Organization identifies a new supply chain risk or when a federal requirement changes how it buys services or material (SA-01).
• confirm that the allocation covers the documented protection requirements (SA-02).
• integrate the Organization’s security and privacy risk management process into life cycle activities (SA-03).
• use the systems security engineering approach in NIST SP 800-160v1r1 (SA-03).
• review every engineering deviation from the principles (SA-08).

System Owners must:

• define the high-level information security and privacy requirements for each system or service during mission and business process planning (SA-02).
• do this before the Organization issues a solicitation (SA-02).
• define and document the security and privacy roles for their systems at every life cycle stage (SA-03).
• name the person who fills each role, so that no role is left empty between phases (SA-03).
• for every system, component, and service, obtain or develop administrator documentation (SA-05).
• cover secure setup and operation, the use and upkeep of security and privacy functions, and the known weaknesses around administrative and privileged functions (SA-05).
• also obtain or develop user documentation (SA-05).
• explain the security and privacy functions available to users, how to use the system securely, and what users are responsible for (SA-05).
• distribute the documentation at minimum to the AO, the System Owner, the ISSO, and the System/Application Administrator (SA-05).
• protect it according to the sensitivity of what it reveals (SA-05).
• make sure engineers document, for each engineering decision, which principles they applied and how (SA-08).
• not accept a deliverable until the ISSO has reviewed its assessment plan and results (SA-11).
• when developer, vendor, or manufacturer support for a system component ends, replace the component (SA-22).
• if the Organization cannot replace it at once, arrange continued support (SA-22).
• remove from service any unsupported component that has no approved support arrangement (SA-22).
• track end-of-support dates in advance, so that the Organization plans each replacement, funds it through the ordinary acquisition process, and completes it before support ends (SA-22).

ISSOs must:

• not clear a phase gate until the security roles for that phase are staffed and its risk activities are complete (SA-03).

Contracting Officers must:

• build the contract in the contract writing system and confirm before award that the Federal Acquisition Regulation (FAR) clauses that apply are present (SA-04).
• require, in each contract, that developers develop and follow a security and privacy assessment plan at every stage after design (SA-11).

Other requirements:

• The request must not compete for funds until the System Owner corrects it (SA-02).
• The CISO and the System Owner must define the requirements for each acquisition (SA-04).
• Each acquisition must start as a request in the IT intake system, which the IT Intake Team reviews with the CISO’s office, the Privacy Officer, the Section 508 Program Manager, IT Operations, and the Application Development Team (SA-04).
• The program office must write the requirements into the statement of work (SA-04).
• Under OMB M-26-05, the CISO must set the risk-based assurance evidence each software or hardware purchase must carry, including secure development evidence aligned to NIST SP 800-218 where the risk warrants it (SA-04).
• Each contract must require machine-processable SBOMs that meet the CISA 2026 SBOM Minimum Elements, on request for cloud platforms (SA-04).
• Contracts must also carry the terms that apply to the purchase (SA-04).
• If the System Owner cannot obtain the documentation, the System Owner must record each attempt and must have the material developed in-house or by a third party (SA-05).
• For existing systems, System Owners must apply the principles to upgrades and modifications as far as the installed base allows and must document the limits (SA-08).
• A service that collects or keeps Organization information for the Organization must hold a FedRAMP authorization when it is a cloud service, and the Authorizing Official must authorize its use (SA-09).
• Providers of authorized services must comply with the Organization’s security and privacy requirements and implement the controls that the CISO and the System Owner select (SA-09).
• At the same interval, the System Owner must confirm in writing that the service is still in use, its data types have not changed, and the provider’s assessment is current (SA-09).
• The developer must test and evaluate the system at installation and at least twice a month after that (SA-11).
• The testing must include vulnerability scanning and security configuration benchmark scanning (SA-11).
• The developer must deliver evidence that it carried out the plan and what the testing found (SA-11).
• The developer must run a verifiable flaw remediation process that corrects what the testing finds (SA-11).
• The Contracting Officer’s Representative must report it to the Contracting Officer, who must use the contract’s remedies (SA-11).
• The CISO must approve the arrangement and must document the residual risk (SA-22).

8.17 System and Communications Protection (SC) #

The System and Communications Protection Policy (POL-SC) and its procedures (PROC-SC) hold the full requirements and the parameter values that apply.

The Organization must:

• keep a system and communications protection policy at the organization level and at the system level, with procedures that put each requirement into practice (SC-01).
• protect its systems against denial-of-service attacks (SC-05).
• monitor and control traffic at every external interface and at key internal interfaces (SC-07).
• place publicly accessible components in subnetworks kept physically or logically apart from internal networks (SC-07).
• protect the confidentiality and integrity of all transmitted information, on internal paths as well as external ones (SC-08).
• manage cryptographic keys under NIST SP 800-57 Part 1 (SC-12).
• define which mobile code and mobile code technologies are acceptable and which are not (SC-18).
• authorize, monitor, and control the mobile code that runs within its systems (SC-18).
• protect the confidentiality and integrity of information at rest (SC-28).

The CISO must:

• manage the development, documentation, and distribution of both documents (SC-01).
• review and update the policy and the procedures every year (SC-01).
• also review them sooner whenever the components or technologies that carry communications functions change (SC-01).
• approve a new external connection before it carries traffic (SC-07).
• approve a deviation only when it has compensating protections and a remediation date (SC-13).

System Owners must:

• separate user functions, including user-facing interfaces, from the functions that administer the system (SC-02).
• keep administrative interfaces off the network paths that serve end users (SC-02).
• keep security functions separate from functions that do not enforce security (SC-03).
• where a product cannot separate a security function, document the gap and the compensating safeguards in the system security and privacy plan (SC-03).
• host public-facing services on the cloud platform infrastructure with the capacity and layout to absorb traffic surges (SC-05).
• keep internal applications unreachable from the open internet by publishing them only through the zero trust network access (ZTNA) service (SC-05).
• configure every Transport Layer Security (TLS) server to NIST SP 800-52 Rev 2, with TLS 1.2 at minimum and no Secure Sockets Layer (SSL), Rivest Cipher 4 (RC4), or 3DES (SC-08).
• if a legacy interface cannot yet comply, document the exposure, apply compensating protections, and set a remediation date that the CISO accepts (SC-08).
• generate and hold keys for cloud workloads in FIPS-validated modules within the cloud platform (SC-12).
• identify each place where their system uses cryptography, and record each module and its validation certificate (SC-13).
• keep a module whose FIPS 140-2 certificate has moved to the historical list only under a POA&M item with a replacement date and a written risk acceptance by the Authorizing Official (SC-13).
• configure conferencing and collaboration equipment to these settings (SC-15).
• permit only the approved technologies (SC-18).
• make sure that resolution paths validate answers and do not simply forward them (SC-21).
• run redundant instances placed so that no single failure stops resolution (SC-22).
• encrypt storage in the cloud platform at rest wherever covered information lives, including volumes, object stores, databases, and backups (SC-28).
• if anyone finds storage that holds covered information without encryption, treat it as a security finding and correct it (SC-28).
• not disable or weaken the isolation features (SC-39).

ISSOs must:

• verify the separation whenever a system’s architecture changes (SC-02).
• verify the settings when equipment is installed or changed (SC-15).

Administrators must:

• protect secret and private keys inside the cryptographic module against unauthorized disclosure, modification, and substitution (SC-12).
• protect public keys against unauthorized modification and substitution (SC-12).
• store keys apart from the data they protect (SC-12).
• back up keys needed to recover encrypted data, but not private signing keys (SC-12).

Other requirements:

• The policy and the procedures must stay consistent with the laws, executive orders, directives, and standards that apply to the Organization (SC-01).
• Management plane access must stay separate from data plane access, as CISA BOD 23-02 directs (SC-02).
• In the cloud platform, System Owners must place administrative interfaces in their own network segments (SC-02).
• These functions must run in separate processes, accounts, or environments that general application code cannot change (SC-03).
• Only privileged administrators must be able to change security function settings or code (SC-03).
• In the cloud platform, management interfaces must stay separate from production traffic, as CISA BOD 23-02 directs (SC-03).
• The Chief Information Security Officer (CISO) must approve each documented gap (SC-03).
• At a minimum, the protections must cover SYN floods, Internet Control Message Protocol (ICMP) and ping floods, teardrop and ping-of-death malformed-packet attacks, peer-to-peer abuse, application-level floods, and distributed attacks (SC-05).
• The safeguards must follow SANS denial-of-service guidance or an alternative that the CISO approves (SC-05).
• Anyone who suspects a denial-of-service attack must report it to the ISSO immediately, and the ISSO must handle it as a security incident (SC-05).
• Systems must connect to outside networks only through managed interfaces that fit the approved security architecture (SC-07).
• The network engineering team must map each external connection to a Trusted Internet Connections (TIC) 3.0 use case the CISO approves under OMB M-19-26 (SC-07).
• Under OMB M-19-03 and the CISA HVA overlay, High Value Assets must sit behind boundary protections at the perimeter and at tiered points inside it (SC-07).
• In the cloud platform, System Owners must segment networks by application and by environment (SC-07).
• Outbound web traffic must leave only through the secure web gateway (SC-07).
• Before a rule opens a system to the internet, the security operations team must scan it and confirm that no critical finding and no past-due high finding remain (SC-07).
• The perimeter must not allow cleartext administrative or file-transfer protocols, such as Telnet and File Transfer Protocol (SC-07).
• Under OMB M-22-09, systems must encrypt traffic with FIPS-validated cryptographic modules and must encrypt Domain Name System (DNS) queries (SC-08).
• Every public website and web service must use Hypertext Transfer Protocol Secure (HTTPS) only and send the Strict Transport Security (HSTS) header, as OMB M-15-13 and CISA BOD 18-01 require (SC-08).
• User traffic to applications must use ZTNA tunnels (SC-08).
• Staff must send sensitive PII or Controlled Unclassified Information outside the Organization only through channels the CISO approves (SC-08).
• The Security Operations Center must run data loss prevention on outbound email and web traffic (SC-08).
• The CISO must set a cryptoperiod for each key type using that guideline, and administrators must replace each key before its cryptoperiod ends (SC-12).
• Each key must have a named owner (SC-12).
• Anyone who suspects a key compromise must report it as a security incident (SC-12).
• Under OMB M-23-02, the ISSO must keep an inventory of cryptographic systems for the move to quantum-resistant cryptography (SC-12).
• Wherever cryptography protects the Organization’s information, each module must hold an active FIPS 140-3 validation under the Cryptographic Module Validation Program (SC-13).
• The authorization must name the permitted mechanism, its purpose, and the specific system on which it may operate (SC-15).
• Collaborative devices and applications must give the people physically present a clear signal when they are active, so that no one is recorded without knowing it (SC-15).
• The secure web gateway filtering must block content in the barred categories at the web boundary (SC-18).
• The ISSO must watch for unauthorized mobile code in use and must open a remediation ticket for each instance (SC-18).
• The Organization’s authoritative name service must attach origin authentication and integrity verification data to every answer it returns to an external query (SC-20).
• DNS administrators must sign the public zones so that resolvers can validate what they receive (SC-20).
• DNS administrators must publish the delegation records that let parent and child domains form a chain of trust that resolvers can verify (SC-20).
• System Owners for the public zones hosted in the cloud platform must keep the zones signed and must manage signing keys under change control (SC-20).
• DNS administrators must handle a lapsed or broken signature as an operational incident, not as routine maintenance (SC-20).
• Recursive and caching resolvers that serve Organization clients must request origin authentication and integrity verification data on every answer from an authoritative source (SC-21).
• The resolver must verify that data before it uses the answer (SC-21).
• A resolver must reject an answer that fails validation; it must not use the answer with a warning (SC-21).
• The systems that together provide name and address resolution must keep resolving when a component fails (SC-22).
• The service must separate internal and external roles: the servers that answer the internet must not also serve internal clients, and internal resolution must not be reachable from outside (SC-22).
• System Owners must host the external authoritative service on redundant cloud platform infrastructure and must keep internal resolution separate behind the boundary (SC-22).
• Under OMB M-22-09, the protection must be cryptographic and must use FIPS-validated modules (SC-28).
• Security-relevant system information, such as configurations and credentials, must receive the same protection (SC-28).
• Systems must keep a separate execution domain for every running process (SC-39).

8.18 System and Information Integrity (SI) #

The System and Information Integrity Policy (POL-SI) and its procedures (PROC-SI) hold the full requirements and the parameter values that apply.

The Organization must:

• keep a system and information integrity policy at the organization level and at the system level, with procedures that put each requirement into practice (SI-01).
• run signature-based and behavior-based malicious code protection at system entry and exit points and on every endpoint (SI-03).
• monitor its systems to detect attacks and signs of attack (SI-04).
• have a legal opinion that covers the scope of its monitoring (SI-04).
• receive security alerts, advisories, and directives on an ongoing basis from at least the Enterprise Security Operations Center, the agency incident response team, CISA, OMB, and product vendors (SI-05).

The CISO must:

• review and update both documents every two years, and sooner when the Organization’s technology, enterprise architecture, or data types change (SI-01).
• raise the level of monitoring when the risk to operations, assets, or individuals rises (SI-04).
• when the Organization cannot comply in time, notify the issuing organization of the degree of noncompliance (SI-05).

System Owners must:

• identify, report, and correct flaws in their systems (SI-02).
• install each update by the finding’s due date: the earliest of the CISA BOD 26-04 Table 1 timeline and the RA-05 timeframe for its severity (SI-02).
• remediate flaws through the configuration management process, so that each fix is a tracked and verifiable change (SI-02).
• manage and retain the information in their systems and the information those systems produce (SI-12).
• follow the laws, executive orders, directives, regulations, standards, guidelines, and operational requirements that apply, and the NARA-approved records schedules (SI-12).
• apply the retention period each information type requires and coordinate with records management personnel (SI-12).
• when the retention period ends, dispose of the information deliberately and document the disposal (SI-12).
• never leave disposal to storage defaults (SI-12).
• check the personally identifiable information (PII) in their systems for accuracy [SI-18 parameter 1 — to be defined], for relevance [SI-18 parameter 2 — to be defined], for timeliness [SI-18 parameter 3 — to be defined], and for completeness [SI-18 parameter 4 — to be defined] (SI-18).
• correct or delete any PII they find to be wrong or out of date (SI-18).
• keep a record of each change (SI-18).
• approve each de-identified data set before its release (SI-19).
• if a test shows that people can be identified, withdraw the data set and fix the method (SI-19).

Administrators must:

• test security-relevant software and firmware updates for effectiveness and side effects before they install them (SI-02).
• accept updates only from authorized sources (SI-02).
• keep the protection content updating automatically as vendors release it, under the configuration management process (SI-03).
• configure the tools to scan each system at least every week (SI-03).

The Security Operations Center (SOC) must:

• assess each suspected false positive and tune the tools, so that the protection does not disrupt availability (SI-03).
• monitor for the irregularities and anomalies that signal a malfunction or a compromise, and for unauthorized local, network, and remote connections (SI-04).
• analyze the events these tools detect (SI-04).
• send alerts, log entries, and artifacts of potential or actual cybersecurity events to the SOC Manager, the incident response team, the System Owner, the ISSO, and the CISO (SI-04).
• send them [SI-04 parameter 5 — to be defined], after a significant change in the threat environment, and as events require (SI-04).
• issue internal alerts and advisories when conditions call for them (SI-05).
• when the scope requires, also send them to the IT office, the wider workforce, contract vendors, and the Organization’s FedRAMP cloud service providers (SI-05).

Other requirements:

• The policy and procedures must stay consistent with the laws, directives, and standards that apply to the Organization (SI-01).
• The tools must also scan files from external sources in real time, at endpoints and at network entry and exit points, as users download, open, or run them (SI-03).
• The SOC must send alerts, advisories, and directives to the System Owners, ISSOs, and system administrators who must act on them (SI-05).
• The owner of each security directive must implement it within the timeframe the directive sets (SI-05).
• Every directive must have an owner, a deadline, and a tracked status (SI-05).
• Systems that support decisions about a person’s rights, benefits, or privileges must receive the most thorough checks (SI-18).
• The Privacy Officer must review the results and report problems to the Senior Agency Official for Privacy (SAOP) (SI-18).
• Before staff share or reuse a data set for a purpose that does not need identities, they must remove these elements: [SI-19 parameter 1 — to be defined] (SI-19).
• The Privacy Officer must test the effectiveness of de-identification [SI-19 parameter 2 — to be defined] (SI-19).
• The test must consider new data sets and new analysis methods that could let someone link records back to a person (SI-19).
• The Senior Agency Official for Privacy (SAOP) must approve any change to the de-identification method (SI-19).

8.19 Supply Chain Risk Management (SR) #

The Supply Chain Risk Management Policy (POL-SR) and its procedures (PROC-SR) hold the full requirements and the parameter values that apply.

The Organization must:

• keep a supply chain risk management policy and the procedures that put it into practice (SR-01).
• stay consistent with the software supply chain protections that EO 14028 directs (SR-01).
• not return a confirmed counterfeit to the supply chain (SR-11).
• dispose of PII, of information and systems that support primary mission essential functions, of High Value Assets, and of critical software using approved techniques and procedures (SR-12).

The CISO must:

• review and update the policy and the procedures every year, and sooner after a major change to applicable policy (SR-01).
• review and update the plan every year, and sooner when a threat, organizational, or environmental change requires it (SR-02).
• limit access to the plan to people who need it for their work (SR-02).
• document the processes and controls the Organization selects in the Supply Chain Risk Management Strategy and Implementation Plan (PLAN-SCRM-001) (SR-03).
• review every IT purchase request, including purchase-card buys, for supply chain risk before award (SR-05).
• define where the Organization receives notifications so that they reach security response staff without delay (SR-08).
• share relevant supply chain risk information with the Federal Acquisition Security Council, as the Federal Acquisition Supply Chain Security Act of 2018 provides (SR-08).
• maintain anti-counterfeit measures that detect counterfeit components and prevent them from entering the Organization’s systems (SR-11).

System Owners must:

• document them in the system’s System Security and Privacy Plan (SSPP) (SR-03).
• make sure disposal follows those procedures at every life cycle stage, whether prototype, operations, or retirement (SR-12).

Administrators must:

• inspect the Organization’s IT systems to detect tampering (SR-10).
• report suspected tampering to the CISO and the ISSO immediately (SR-10).
• hold the asset out of service until the inspection resolves the question (SR-10).
• verify each component at receipt (SR-11).
• report a counterfeit or suspect component to the personnel and roles defined in the Organization Incident Response Standard and to the Contracting Officer (SR-11).
• not install a suspect component (SR-11).
• carry out each disposal and record it (SR-12).
• document each disposal well enough that an assessor can trace the asset from service to its sanitized end (SR-12).

Contracting Officers must:

• not award until the CISO records in writing that the risk is acceptable (SR-05).
• include notification terms in every agreement with an entity in the supply chain for systems, components, and services (SR-08).
• confirm the terms before award (SR-08).

Other requirements:

• The CISO, with support from the SCRM team, must keep a supply chain risk management plan that covers all of the Organization’s systems, system components, and system services, including external applications (SR-02).
• The plan must address supply chain risk from research and development through acquisition, operations, and disposal (SR-02).
• The plan must state the Organization’s supply chain risk tolerance, its mitigation approaches, and the roles that carry them out (SR-02).
• The SCRM team must keep a list of critical suppliers, drawn from the system inventories and acquisition spending, and review it at the same interval (SR-02).
• Each contractor-operated system must have a system-level SCRM plan, or inherit one from the contractor’s organization-level plan, as NIST SP 800-161 Rev 1 describes (SR-02).
• That plan must say how the contractor handles supply chain events and reports them to the Organization (SR-02).
• The CISO team, Mission/Business Owners, and the Office of Acquisitions must jointly run processes that identify and address weaknesses and deficiencies in the supply chain (SR-03).
• To limit exposure from supply chain events, the Office of Acquisitions must buy through federal-wide acquisition vehicles (SR-03).
• The CISO team must address every weakness it finds (SR-03).
• The Office of Acquisitions must complete all IT supply purchases through compliant Government-wide contract vehicles, such as the General Services Administration (GSA) Schedules and the National Aeronautics and Space Administration (NASA) Solution for Enterprise-Wide Procurement (SEWP) (SR-05).
• The Office of Acquisitions must treat any purchase outside these vehicles as an exception that needs a documented justification and the approval of the CISO and the Contracting Officer (SR-05).
• The terms must require the entity to notify the Organization of a supply chain compromise and to share the results of relevant assessments or audits (SR-08).
• The entity must identify the affected systems, components, or services, the supply chain risk involved, and the extent of any compromise (SR-08).
• It must also report the remediation status or a remediation plan with milestones and deadlines (SR-08).
• During deployment, the System/Application Administrator must inspect each asset to confirm that its components match the purchase order (SR-10).

8.20 Personally Identifiable Information Processing and Transparency (PT) #

The Personally Identifiable Information Processing and Transparency Policy (POL-PT) holds the full requirements and the parameter values that apply.

The Organization must:

• give people a privacy notice when they first deal with the Organization and again [PT-05 parameter 1 — to be defined] (PT-05).
• not process a special category without approved conditions (PT-07).

The Senior Agency Official for Privacy (SAOP) must:

• report each new or significantly changed system of records notice to OMB and Congress under OMB Circular A-108 (PT-01).
• also post a website privacy policy that meets OMB M-10-22 and M-10-23 (PT-01).
• send this policy and its procedures to [PT-01 parameter 1 — to be defined] (PT-01).
• review and update the policy [PT-01 parameter 5 — to be defined] and after [PT-01 parameter 6 — to be defined] (PT-01).
• review and update the procedures [PT-01 parameter 7 — to be defined] and after [PT-01 parameter 8 — to be defined] (PT-01).
• apply the same limit to [PT-02 parameter 3 — to be defined] of PII by contractors and partners through contracts and written sharing agreements (PT-02).
• publish each purpose in the Organization’s privacy notices, system of records notices, and website privacy policy, as OMB M-03-22 requires for the posted policy (PT-03).
• update a notice whenever the authority, purposes, or disclosures change (PT-05).
• send each new or significantly changed notice to OMB and to Congress at least 30 days before submitting it to the Federal Register, as Circular A-108 requires (PT-06).
• list and link every current notice on the Organization’s privacy program web page (PT-06).
• review the conditions when the system changes or the privacy impact assessment is updated (PT-07).
• publish a matching notice in the Federal Register before the first match runs (PT-08).

System Owners must:

• complete a privacy threshold analysis, and then a privacy impact assessment where needed, before they develop or buy IT that handles PII, as OMB M-03-22 requires (PT-01).
• complete a privacy threshold analysis, and a privacy impact assessment when the analysis requires one, before they develop or buy a system that handles PII, as OMB M-03-22 requires (PT-02).
• state each purpose for which a system handles personally identifiable information (PII) as [PT-03 parameter 1 — to be defined] (PT-03).
• report any planned change in processing to the Privacy Officer before the change goes into effect (PT-03).
• before a system collects personally identifiable information (PII), give each person a way to agree or decline through [PT-04 parameter 1 — to be defined] (PT-04).
• when a person declines, stop the collection for that person and keep a record of the choice (PT-04).
• honor the withdrawal for any further processing (PT-04).
• place the notice where people provide their data (PT-05).
• tell the Privacy Officer about any change that affects a notice’s accuracy or scope (PT-06).
• identify any special category of personally identifiable information (PII) a system handles (PT-07).
• record these categories in the privacy threshold analysis and privacy impact assessment (PT-07).
• apply those conditions and record them in the System Security and Privacy Plan (SSPP) (PT-07).

Other requirements:

• The Senior Agency Official for Privacy (SAOP) must coordinate it with the CISO so security and privacy requirements agree (PT-01).
• The Senior Agency Official for Privacy (SAOP) must keep a written record of the legal authority for each program and system that handles PII (PT-02).
• The General Counsel must confirm each authority before the processing starts (PT-02).
• Each system must limit its [PT-02 parameter 2 — to be defined] of PII to the uses the documented authority allows (PT-02).
• Staff must not use PII for any purpose outside that authority (PT-02).
• The Senior Agency Official for Privacy (SAOP) must approve each stated purpose before the system collects any PII (PT-03).
• Each system must limit its [PT-03 parameter 2 — to be defined] of PII to uses that match an approved purpose (PT-03).
• Staff must not use PII for an unrelated purpose (PT-03).
• The Privacy Officer must review each change through [PT-03 parameter 3 — to be defined] and must confirm the change meets [PT-03 parameter 4 — to be defined] (PT-03).
• The consent request must state in plain words what the Organization collects, why, who receives it, and what happens if the person declines (PT-04).
• The Senior Agency Official for Privacy (SAOP) must approve the wording of each consent request (PT-04).
• The person must decide before the system collects the data (PT-04).
• A person who agreed must be able to withdraw that agreement later (PT-04).
• People who prove identity online under OMB M-21-04 may give consent digitally, and the Organization must accept that consent (PT-04).
• Each notice must use plain language and must name the legal authority for the processing and each purpose (PT-05).
• Each notice must also include[PT-05 parameter 2 — to be defined] (PT-05).
• The Privacy Officer must post a privacy policy on the Organization’s main website, at major entry points, and on any page that collects a large amount of personal data, as OMB M-03-22 requires (PT-05).
• The privacy policy must name any web measurement tools and describe each third-party website or application the Organization uses, as OMB M-10-22 and M-10-23 require (PT-05).
• The Senior Agency Official for Privacy (SAOP) must make sure each Privacy Act system of records has a current system of records notice (PT-06).
• The Privacy Officer must draft each notice under OMB Circular A-108 (PT-06).
• The Privacy Officer must then publish the notice in the Federal Register (PT-06).
• Each notice that covers applicants for or recipients of federal funds must keep the Do Not Pay routine use, as OMB M-25-32 requires (PT-06).
• The Senior Agency Official for Privacy (SAOP) must set [PT-07 parameter 1 — to be defined] for each special category before the system processes it (PT-07).
• The Senior Agency Official for Privacy (SAOP) must decide whether each proposed comparison of records with another agency is a matching program under the Privacy Act (PT-08).
• If it is, the program office must not start the match until the Data Integrity Board approves it (PT-08).
• The Privacy Officer must prepare a written computer matching agreement with each partner, and General Counsel must review it before signature (PT-08).
• Disclosures to Treasury’s Do Not Pay system must include only the data needed to find or recover improper payments, under a written agreement that states security procedures, per OMB M-25-32 (PT-08).
• The program office must also give the individual notice of the findings and a chance to contest them before acting (PT-08).
• The Data Integrity Board must review each calendar year’s matching programs and report the results to the agency head and OMB, as OMB Circular A-108 directs (PT-08).

9. Violations and Penalties #

A person who does not follow this policy may face disciplinary action under the Organization’s personnel rules and the law. Depending on the violation, the action can include:

• A written reprimand.
• Suspension or removal of system access.
• Reassignment to other duties.
• Suspension or removal from duty, or removal from a contract for contractor staff.
• Civil or criminal prosecution.

Anyone who sees a violation must report it to their supervisor or to the CISO. The supervisor refers it to Human Resources, the Office of the General Counsel, or the Office of Inspector General, as the case requires.

10. Exceptions and Waivers #

An exception lets a system meet a requirement in another way, through a compensating control. A waiver lets a system go without meeting a requirement for a set time while the System Owner works toward it. A waiver lasts no more than one year.

The steps for both are:

1. The System Owner sends the CISO a written request in the GRC system. The request gives the business justification, a risk assessment, the compensating controls, and the proposed end date.
2. The CISO assesses the risk and decides the request in coordination with the Authorizing Official. A request that involves privacy risk also needs the agreement of the SAOP.
3. The Authorizing Official accepts the residual risk of an approved request. The ISSO records the decision in the GRC system as a risk acceptance.
4. The System Owner records the approved exception or waiver in the system’s SSPP. For a waiver, the ISSO tracks the remaining work as a POA&M item.
5. The CISO re-evaluates each exception and waiver when it comes up for renewal, and at least once a year.

11. Cancellations #

This policy replaces any earlier version of the Organization’s Information System Security Policy. The family policies, procedures, and plans that this policy names stay in force.

12. Related Documents #

• Information Security Program Plan (ISPP-001).
• Policy and Procedure Management Policy (POL-DOC-001).
• General User Rules of Behavior (ROB-GEN-001) and Privileged User Rules of Behavior (ROB-PRIV-001).
• The family policies and procedures:

References #

• Federal Information Security Modernization Act of 2014, 44 U.S.C. §§ 3551–3558.
• Clinger-Cohen Act of 1996, 40 U.S.C. § 11101 et seq.
• OMB Circular A-130, Managing Information as a Strategic Resource (2016).
• NIST SP 800-53 Rev 5, Security and Privacy Controls for Information Systems and Organizations.
• NIST SP 800-37 Rev 2, Risk Management Framework for Information Systems and Organizations.
• NIST SP 800-39, Managing Information Security Risk.
• FIPS 199, Standards for Security Categorization of Federal Information and Information Systems.
• FIPS 200, Minimum Security Requirements for Federal Information and Information Systems.
• 5 CFR § 930.301: Information Systems Security Awareness Training Program — role-based training for personnel with significant security responsibilities, June 17, 2004.
• CISA BOD 18-01: Enhance Email and Web Security, October 16, 2017.
• CISA BOD 23-02: Mitigating the Risk from Internet-Exposed Management Interfaces, June 13, 2023.
• CISA BOD 26-02: Mitigating Risk From End-of-Support Edge Devices, February 5, 2026.
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk, June 10, 2026.
• CISA Incident Reporting System: Incident Reporting Form (CISA Services Portal): Incident Reporting Form (CISA Services Portal), August 29, 2024.
• Executive Order 13764: Amending the Civil Service Rules, Executive Order 13488, and Executive Order 13467 To Modernize the Executive Branch-Wide Governance Structure and Processes for Security Clearances, Suitability and Fitness for Employment, and Credentialing, and Related Matters, January 17, 2017.
• Executive Order 14028: Improving the Nation’s Cybersecurity, May 12, 2021.
• Federal Incident Notification Guidelines, April 1, 2017.
• Superseded source, kept for its history: FIPS 140-2: Security Requirements for Cryptographic Modules, May 25, 2001. Replaced by FIPS 140-3.
• FIPS 140-3: Cryptographic Module Security Requirements, March 22, 2019.
• NIST SP 800-18 Rev. 2: Developing System Plans (system security plans, system privacy plans, C-SCRM plans), June 30, 2026.
• NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments, September 2012.
• NIST SP 800-47 Rev. 1: Managing the Security of Information Exchanges, July 2021.
• NIST SP 800-52 Rev. 2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations, August 2019.
• NIST SP 800-57 Part 1 Rev. 5: Recommendation for Key Management: Part 1 - General, May 2020.
• NIST SP 800-60 Rev. 1: Guide for Mapping Types of Information and Information Systems to Security Categories, August 2008.
• NIST SP 800-63-4: Digital Identity Guidelines, July 31, 2025.
• NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response, August 2006.
• NIST SP 800-88 Rev. 2: Guidelines for Media Sanitization, September 2025.
• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment, September 2008.
• NIST SP 800-124 Rev. 2: Guidelines for Managing the Security of Mobile Devices in the Enterprise, May 2023.
• NIST SP 800-128: Guide for Security-Focused Configuration Management of Information Systems, August 2011.
• NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, November 1, 2024.
• NIST SP 800-163 Rev. 1: Vetting the Security of Mobile Applications, April 2019.
• NIST SP 800-218: Secure Software Development Framework (SSDF), February 2022.
• OMB Circular A-108: Federal Agency Responsibilities for Review, Reporting, and Publication under the Privacy Act, December 23, 2016.
• OMB Circular A-123: Management’s Responsibility for Internal Control, March 10, 2026.
• OMB M-02-01: Guidance for Preparing and Submitting Security Plans of Action and Milestones, October 17, 2001.
• OMB M-03-22: OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002, September 26, 2003.
• OMB M-10-22: Guidance for Online Use of Web Measurement and Customization Technologies, June 25, 2010.
• OMB M-10-23: Guidance for Agency Use of Third-Party Websites and Applications, June 25, 2010.
• OMB M-15-13: Policy to Require Secure Connections across Federal Websites and Web Services, June 8, 2015.
• OMB M-19-03: Strengthening the Cybersecurity of Federal Agencies by Enhancing the High Value Asset Program, December 26, 2018.
• OMB M-19-26: Update to the Trusted Internet Connections (TIC) Initiative, September 12, 2019.
• OMB M-21-04: Modernizing Access to and Consent for Disclosure of Records Subject to the Privacy Act, November 12, 2020.
• OMB M-21-30: Protecting Critical Software Through Enhanced Security Measures, August 10, 2021.
• OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022.
• OMB M-23-02: Migrating to Post-Quantum Cryptography, November 18, 2022.
• OMB M-23-22: Delivering a Digital-First Public Experience, September 22, 2023.
• OMB M-24-15: Modernizing the Federal Risk and Authorization Management Program (FedRAMP), July 25, 2024.
• OMB M-25-04: FY 2025 Guidance on Federal Information Security and Privacy Management Requirements, January 15, 2025.
• OMB M-25-32: Preventing Improper Payments and Protecting Privacy Through Do Not Pay, August 20, 2025.
• OMB M-26-05: Adopting a Risk-based Approach to Software and Hardware Security, January 23, 2026.
• OMB M-26-10: Reinforcing Transparency, Accountability, and Oversight of Federal Technology, March 31, 2026.
• OMB M-26-14: Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats, May 22, 2026.
• Privacy Act of 1974 (5 U.S.C. § 552a), December 31, 1974.
• Strengthening and Enhancing Cyber-capabilities by Utilizing Risk Exposure Technology Act (SECURE Technology Act) — Federal Acquisition Security Council (Pub. L. 115-390, Title II; 41 U.S.C. §§ 1321–1328; 41 U.S.C. § 4713), December 21, 2018.