Assessment, Authorization, and Monitoring Procedure

Approval #

Revision History #

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

1. Purpose #

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

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

2. Scope #

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

2.1 CSF 2.0 Alignment #

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

• GV.OV — Oversight (Govern function)
• ID.IM — Improvements (Identify function)
• DE.CM — Continuous Monitoring (Detect function)

3. Controls Covered #

This procedure covers the following 14 controls in the CA family:

3.1 Derived Governance Requirements #

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

OMB M-25-04: FY 2025 FISMA Guidance

• The organization must implement continuous monitoring programs that provide real-time visibility into security control effectiveness, replacing point-in-time assessments with ongoing assessment and authorization. Deadline: FY 2025. (OMB M-25-04, §3)

NIST SP 800-37: Risk Management Framework

• The organization must apply the seven steps of the Risk Management Framework (Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor) and their tasks to every system and every set of common controls throughout its life cycle. Authorization must be based on risk management decisions, not compliance checklists. (NIST SP 800-37r2, Ch. 2 and Ch. 3)
• The organization must ensure continuous monitoring tracks security control effectiveness on an ongoing basis, with results feeding back into the risk management process. Authorizations must be renewed based on monitoring data, not on a fixed schedule. (NIST SP 800-37r2, §4)

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

• The organization must ensure independent security assessments of designated High Value Assets are conducted (by CISA, agency independent assessors, or approved third parties) using the HVA assessment methodology, and track resulting findings through formal remediation plans. (OMB M-19-03, §C)
• The organization must remediate critical and high-severity weaknesses identified during HVA assessments within 30 days of the final report, or document a remediation plan with milestones when full remediation is not achievable in that window. Deadline: 30 days from final HVA report. (OMB M-19-03, §C.3)

FedRAMP CR26: FedRAMP Consolidated Rules for 2026 (including 20x Key Security Indicators)

• The organization must complete the authorization process for each system that uses a FedRAMP authorized cloud service before the service handles federal information. (FedRAMP Consolidated Rules for 2026, AGU-USE-ABU)
• The organization must review each Ongoing Certification Report from a FedRAMP authorized provider for changes that affect the risk the Authorizing Official accepted. (FedRAMP Consolidated Rules for 2026, CCM-AGM-ROR)
• The organization must notify FedRAMP when a provider’s ongoing reports, Quarterly Review, or other certification data are likely to lead the Authorizing Official to withdraw the authorization. (FedRAMP Consolidated Rules for 2026, AGU-USE-NFC)
• The organization should limit the authorized use of a Class A certified cloud service to 12 months unless the provider is seeking a Class B, C, or D certification. (FedRAMP Consolidated Rules for 2026, AGU-USE-CLA)

OMB Circular A-130: Managing Information as a Strategic Resource

• The organization must have the SAOP review and approve each system’s privacy plan before authorization, reauthorization, or ongoing authorization, and review the authorization package of each system that handles PII before the Authorizing Official decides. (OMB Circular A-130, Appendix I §4(e)(8)-(9))
• The organization must move a system or its common controls to ongoing authorization only when it is eligible and its Authorizing Official formally approves the move. (OMB Circular A-130, Appendix I)
• The organization must define and use a process to designate the systems and common controls that meet the conditions for ongoing authorization. (OMB Circular A-130, Appendix I)

44 U.S.C. §§ 3607-3616: FedRAMP Authorization Act

• The organization must treat the security assessment and authorization package of a FedRAMP-authorized cloud service as presumed adequate, and add only the review the Organization’s own use requires. (44 U.S.C. § 3613(e))
• The organization must send the FedRAMP office a copy of each authorization to operate the Organization issues for a cloud product or service. (44 U.S.C. § 3613)

OMB M-24-15: Modernizing the Federal Risk and Authorization Management Program (FedRAMP)

• The organization must authorize use of a FedRAMP-authorized cloud service by reviewing its FedRAMP package and the Organization’s customer responsibilities, not by repeating the provider’s assessment. (OMB M-24-15, §IV)

OMB M-02-01: Guidance for Preparing and Submitting Security Plans of Action and Milestones

• The organization must never change the original scheduled completion date of a plan of action and milestones item; record any delay as a milestone change. (OMB M-02-01, Attachment)
• The organization must record for each plan of action and milestones item the weakness, owner, resources needed, milestones, and the review that found it. (OMB M-02-01, Attachment)

NIST SP 800-47 Rev 1: Managing the Security of Information Exchanges

• The organization should document each information exchange with an external organization in an agreement, such as an interconnection security agreement, before the exchange starts. (NIST SP 800-47 Rev 1, §2)
• The organization should manage each information exchange through planning, establishment, maintenance, and discontinuation, and update or end the agreement when the exchange changes or stops. (NIST SP 800-47 Rev 1, §§3-5)

NIST SP 800-115: Technical Guide to Information Security Testing and Assessment

• The organization should plan each penetration test with written rules of engagement, approved before testing starts, that set the scope, methods, timing, and contacts. (NIST SP 800-115, §6 and Appendix B)
• The organization should conduct penetration tests in four phases: planning, discovery, attack, and reporting. (NIST SP 800-115, §5.2)

4. Procedure #

4.1 General Implementation Approach #

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

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

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

4.2 Control-Specific Procedures #

CA-01 — Policy and Procedures #

Baselines: Low / Moderate / High / Privacy CSF 2.0: GV.OV (Oversight)

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

1. [Selection (one or more): organization-level; mission/business process-level; system-level — to be defined] assessment, authorization, and monitoring policy that:

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

2. Procedures to facilitate the implementation of the assessment, authorization, and monitoring policy and the associated assessment, authorization, and monitoring controls;

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

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

Procedure:

The CISO keeps the assessment, authorization, and monitoring policy and this procedure as controlled documents. The CISO’s office schedules the review every 3 years and opens the review in the policy library in the document management system. The CISO’s office gathers comments from the Authorizing Official, System Owners, and Information System Security Officers (ISSOs) and records the decision on each comment. The CISO’s office closes the record when the CISO approves the revision. A major change to applicable policy, such as a new the Office of Management and Budget (OMB) direction or a revised framework, opens a review record before the next scheduled review. That review follows the same steps.

The CISO’s office checks each revision against the requirements the program must meet. These are the NIST SP 800-37 lifecycle, the ongoing-authorization expectations in OMB M-25-04, and the High Value Asset assessment obligations in OMB M-19-03. The CISO’s office publishes the approved version and archives the superseded version. It records the distribution to the Authorizing Official, System Owners, ISSOs, and key stakeholders in the review record.

Evidence: the review records with their comment decisions, the version history, the notes of the crosswalk to each requirement, and the distribution records.

CA-02 — Control Assessments #

Baselines: Low / Moderate / High / Privacy CSF 2.0: GV.OV (Oversight), ID.IM (Improvements), DE.CM (Continuous Monitoring)

1. Select the appropriate assessor or assessment team for the type of assessment to be conducted;
2. Develop a control assessment plan that describes the scope of the assessment including:

1. Controls and control enhancements under assessment;
2. Assessment procedures to be used to determine control effectiveness; and
3. Assessment environment, assessment team, and assessment roles and responsibilities;

3. Ensure the control assessment plan is reviewed and approved by the authorizing official or designated representative prior to conducting the assessment;
4. Assess the controls in the system and its environment of operation at least annually to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security and privacy requirements;
5. Produce a control assessment report that document the results of the assessment; and
6. Provide the results of the control assessment to individuals or roles to include FedRAMP PMO.

Procedure:

The ISSO opens each assessment cycle in the governance, risk, and compliance (GRC) system with the selected assessor and a draft plan. The ISSO starts the scope from the controls that the monitoring rotation schedules for the year. The ISSO then adds each control whose plan of action and milestones (POA&M) item closed since the last assessment and each control tied to an audit finding or incident in that period.

For a new system, or before a major change to an existing one, security engineering staff review the security and privacy architecture. A major change includes a new external connection, a change to authentication or encryption, a move to another hosting environment, or adoption of a cloud service. The ISSO attaches the signed review to the record. The Authorizing Official or a designated representative approves the plan in the GRC system after the review is on file and before fieldwork starts.

The team assesses the controls in the system’s operating environment. Its report states what it tested, how, what it found, and the severity of each finding. The ISSO delivers the report to the Authorizing Official and the System Owner. The ISSO turns each weakness into a POA&M entry in the GRC system with an owner and milestone dates. A significant change to the boundary, architecture, or information types triggers an assessment scoped to the change, outside the yearly cycle.

Evidence: the approved assessment plans with their scope, the architecture reviews, the assessment reports, the delivery records, and the POA&M entries traced to the findings.

CA-02(1) — Independent Assessors #

Baselines: Low / Moderate / High

Employ independent assessors or assessment teams to conduct control assessments.

Procedure:

The ISSO establishes independence when selecting the assessor. The assessment record documents the assessor’s place in the organization and confirms that the assessor did not build, does not operate, and does not manage the system under assessment. The Authorizing Official accepts that determination along with the assessment plan. For High Value Assets, the ISSO obtains the assessment from the Cybersecurity and Infrastructure Security Agency (CISA), agency independent assessors, or approved third parties, as OMB M-19-03 requires. When the organizational structure places the assessor close to the system, an independent expert reviews the results, and the ISSO documents that review so the conclusions remain impartial. Evidence: the independence determinations, the acceptance records, and any compensating review reports.

CA-02(3) — Leveraging Results from External Organizations #

Baselines: Moderate / High

Leverage the results of control assessments performed by any FedRAMP Accredited 3PAO on [Assignment: organization-defined system — to be defined] when the assessment meets the conditions of the AO in the FedRAMP Repository.

Procedure:

When someone proposes to reuse an external organization’s assessment results, the ISSO checks them against the Organization’s acceptance requirements. The requirements cover currency, coverage of the controls in question, depth of supporting evidence, and the independence of the assessors who produced them. The ISSO records the analysis. The Authorizing Official records the acceptance decision with the assessment record. The ISSO prepares a coverage mapping that shows which controls the external results satisfy and which still need a local assessment, and the Organization assesses the remaining controls in-house. Evidence: the acceptance analyses, the Authorizing Official’s decisions, and the coverage mappings.

CA-03 — Information Exchange #

Baselines: Low / Moderate / High

1. Approve and manage the exchange of information between the system and other systems using [Selection (one or more): interconnection security agreements; information exchange security agreements; memoranda of understanding or agreement; service level agreements; user agreements; non-disclosure agreements; [organization-defined] — to be defined];
2. Document, as part of each exchange agreement, the interface characteristics, security and privacy requirements, controls, and responsibilities for each system, and the impact level of the information communicated; and
3. Review and update the agreements at least annually and on input from AO.

Procedure:

A System Owner requests each new exchange. The ISSO picks the agreement type under NIST SP 800-47 Rev 1. A system interconnection gets an interconnection security agreement for the technical terms and a memorandum of understanding or agreement for the purpose, authority, and costs. A database, application programming interface, or file exchange with an outside party gets an information exchange agreement and a memorandum of understanding or agreement. The ISSO records an exchange inside one authorization boundary in the System Security and Privacy Plan (SSPP) instead.

Each agreement states the interface characteristics, the controls and obligations on both sides, and the impact level of the data. It also states that either party may suspend the exchange at once after unauthorized use or disclosure of the data, and the notice either party gives to end it. The Authorizing Official approves the agreement before the exchange carries production information.

The ISSO drafts each agreement from the Interconnection and Information Exchange Agreement Templates (TMPL-ISA-001), which also give the steps for each phase. The ISSO registers each executed agreement in the GRC system with its review date and lists it in the SSPP. In the yearly review, the ISSO confirms that the exchange is still needed and that the interface still matches the agreement. A significant change on either side reopens the agreement at once. The ISSO reissues every agreement when the system is reauthorized. When an agreement lapses, the Organization suspends the exchange until the parties renew it.

Evidence: the executed agreements with their approvals, the agreement register, the yearly review dispositions, the reissued agreements, and the suspension actions.

CA-05 — Plan of Action and Milestones #

Baselines: Low / Moderate / High / Privacy CSF 2.0: GV.OV (Oversight)

1. Develop a plan of action and milestones for the system to document the planned remediation actions of the organization to correct weaknesses or deficiencies noted during the assessment of the controls and to reduce or eliminate known vulnerabilities in the system; and
2. Update existing plan of action and milestones at least monthly based on the findings from control assessments, independent audits or reviews, and continuous monitoring activities.

Procedure:

The ISSO keeps POA&M items in the GRC system in the format OMB M-02-01 sets. In each entry, the ISSO records the source, severity, affected system, owner, root cause, planned actions, milestones, and scheduled completion date. The System Owner adds the estimated cost and the budget investment that funds the fix. The ISSO updates the plan at least every month. The ISSO adds new findings from assessments, audits, and continuous monitoring, and marks completed milestones with their dates. The ISSO never edits a scheduled completion date after it is set. The ISSO records a slip as a milestone change with its reason and new date.

The ISSO closes an item only after attaching verification evidence, such as a retest result, a configuration export, or an assessor’s confirmation. For an item from an Inspector General or other external audit, the ISSO also attaches the auditor’s agreement that the weakness is fixed. Critical and high findings on High Value Assets run on a 30-day clock from the final report. When the System Owner cannot finish within 30 days, the ISSO records the milestone plan and tracks it to completion. When the System Owner cannot fix a weakness, the System Owner asks the Authorizing Official to accept the risk. The ISSO files the signed acceptance with the item.

The Authorizing Official receives the plan with the authorization package and the monitoring reports.

Evidence: the POA&M entries with their update history, the cost and budget links, the closure evidence and auditor agreements, the risk acceptances, and the 30-day tracking for High Value Asset findings.

CA-06 — Authorization #

Baselines: Low / Moderate / High / Privacy CSF 2.0: GV.OV (Oversight)

1. Assign a senior official as the authorizing official for the system;
2. Assign a senior official as the authorizing official for common controls available for inheritance by organizational systems;
3. Ensure that the authorizing official for the system, before commencing operations:

1. Accepts the use of common controls inherited by the system; and
2. Authorizes the system to operate;

4. Ensure that the authorizing official for common controls authorizes the use of those controls for inheritance by organizational systems;
5. Update the authorizations in accordance with OMB A-130 requirements or when a significant change occurs.

Procedure:

The System Owner and the ISSO assemble the authorization package and present it to the Authorizing Official. The package holds the system’s plans, the control assessment report, and the POA&M. The Authorizing Official records the decision in writing: authorization to operate, with or without conditions, authorization to use, or denial. The decision also records the acceptance of inherited common controls and the termination date. No system may use production data or connect to a production system before the decision. The Common Control Provider keeps the matching common control authorization current.

For a FedRAMP-authorized cloud service, the Authorizing Official reuses the FedRAMP package, and the ISSO sends the signed authorization to the FedRAMP Program Management Office.

The ISSO tracks each authorization in the GRC system against its required limit and starts reauthorization early enough to finish before the date passes. A significant change starts the review at once. The ISSO sends continuous monitoring results to the Authorizing Official between decisions, consistent with NIST SP 800-37. The Authorization Decisions and Approaches section of that procedure gives the full steps.

Evidence: the signed authorization decisions with their conditions, the inheritance acceptances, the FedRAMP submissions, the package versions, and the reauthorization schedule.

CA-07 — Continuous Monitoring #

Baselines: Low / Moderate / High / Privacy CSF 2.0: GV.OV (Oversight), ID.IM (Improvements), DE.CM (Continuous Monitoring)

Develop a system-level continuous monitoring strategy and implement continuous monitoring in accordance with the organization-level continuous monitoring strategy that includes: a. Establishing the following system-level metrics to be monitored: [Assignment: organization-defined system-level metrics — to be defined]; b. Establishing [Assignment: organization-defined frequencies — to be defined] for monitoring and [Assignment: organization-defined frequencies — to be defined] for assessment of control effectiveness; c. Ongoing control assessments in accordance with the continuous monitoring strategy; d. Ongoing monitoring of system and organization-defined metrics in accordance with the continuous monitoring strategy; e. Correlation and analysis of information generated by control assessments and monitoring; f. Response actions to address results of the analysis of control assessment and monitoring information; and g. Reporting the security and privacy status of the system to include AO [Assignment: organization-defined frequency — to be defined].

Procedure:

Each ISSO maintains the system-level monitoring strategy. It lists the controls under monitoring, the metrics drawn from the Organization’s Continuous Monitoring Plan, the frequency for each metric, and the person who does the work. The ISSO runs the monitoring at those frequencies and records each result when it is produced. A deviation, such as a metric out of bounds or a control that no longer performs, opens a tracked action. When the ISSO confirms a weakness, the ISSO opens a POA&M entry in the GRC system.

At least [CA-07 parameter 7 — to be defined], and after each annual assessment, the ISSO prepares a security status report from the recorded results. The report gives the assessment results, the risks carried forward, open vulnerabilities by severity, POA&M progress, late items, the risks proposed for acceptance, and the trend. The ISSO sends it to the Authorizing Official, the CISO, and the Privacy Officer. The ISSO sends an interim report when results change the risk enough to affect a decision. The Authorizing Official signs the report in the GRC system to accept the stated residual risk.

The ISSO revises the strategy when the system, its environment, or the organization-level strategy changes.

Evidence: the strategy with its revision history, the monitoring results, the deviation and POA&M records, and the signed status reports.

CA-07(1) — Independent Assessment #

Baselines: Moderate / High

Employ independent assessors or assessment teams to monitor the controls in the system on an ongoing basis.

Procedure:

Assessors outside the system’s development, operations, and management chain perform the monitoring activities that judge control effectiveness. The assignment record states the basis for each assessor’s independence. Their conclusions enter the same stream as all other monitoring output: the status reports, the deviation items, and the POA&M entries. Each record names its author, so the Authorizing Official can tell independently produced findings from self-reported ones when deciding. Evidence: the assignment records with their independence notes, and the attributed monitoring results in the reporting chain.

CA-07(4) — Risk Monitoring #

Baselines: Low / Moderate / High / Privacy

Ensure risk monitoring is an integral part of the continuous monitoring strategy that includes the following: (a) Effectiveness monitoring; (b) Compliance monitoring; and (c) Change monitoring.

Procedure:

Risk monitoring runs alongside control monitoring. The ISSO tracks each open risk against the risk tolerance. After each completed risk response, the ISSO verifies that the intended reduction occurred. The ISSO confirms that the required measures remain in place and the requirements are still met. The ISSO evaluates each system or environment change for its risk impact when it happens, not at the next scheduled review. When a finding pushes a risk beyond tolerance, the ISSO escalates it to the Authorizing Official through the status reports and opens a tracked action with an owner in the GRC system. Evidence: the risk monitoring records, the verifications of response effectiveness, the change evaluations with their dispositions, and the escalation reports.

CA-08 — Penetration Testing #

Baselines: Low / Moderate / High CSF 2.0: GV.OV (Oversight), ID.IM (Improvements), DE.CM (Continuous Monitoring)

Conduct penetration testing at least annually on [Assignment: organization-defined system(s) or system components — to be defined].

Procedure:

The yearly cycle starts with scoping. The CISO and the System Owners confirm the covered systems, at a minimum the FIPS-199 High, Mission Essential, High Value Asset, and Financial Systems. They add each internet-facing or high-impact system that is due for initial authorization. The parties sign the rules of engagement before testing starts. The rules set objectives, boundaries, test windows, safety controls, points of contact, and the protection of sensitive information. Before testing, the System Owner backs up the system and notifies the affected cloud and network providers. The Authorizing Official approves any test or scan that an outside party proposes.

The testers follow NIST SP 800-115 and stay within scope. They leave no persistent access and do not alter logs. If they find evidence of a real compromise, they stop testing and report it to the ISSO and the Security Operations Center at once. The testers deliver the report to the System Owner, the ISSO, and the Authorizing Official. The ISSO turns each finding into a POA&M entry in the GRC system with a due date based on severity. A retest verifies each fix before the entry closes.

Evidence: the yearly scope decision, the signed rules of engagement, the backup and provider notices, any outside-party approvals, the test reports, and the finding entries with their verified closures.

CA-08(1) — Independent Penetration Testing Agent or Team #

Baselines: Moderate / High

Employ an independent penetration testing agent or team to perform penetration testing on the system or system components.

Procedure:

The engagement record for each test documents the tester’s independence: the tester’s organizational separation from the people who built, operate, and manage the system. The Authorizing Official or a designated representative accepts that determination before work begins. The testers sign the rules of engagement, including the data protection obligations, as a condition of access. The results go into the standard reporting and POA&M path with the testing team named, so every conclusion traces to an impartial source. Evidence: the engagement records with their independence determinations, the signed rules of engagement, and the test reports with their named testing team.

CA-08(2) — Red Team Exercises #

Baselines: Moderate / High

Employ the following red-team exercises to simulate attempts by adversaries to compromise organizational systems in accordance with applicable rules of engagement: [Assignment: organization-defined red team exercises — to be defined].

Procedure:

Each exercise runs under signed rules of engagement that set the objectives, the boundaries, the safety controls, and the specific social engineering methods the red team may use. The red team uses current adversary techniques. The exercise measures the defense on detection and response as well as on prevention. At the debrief, the red team gives the CISO a findings report that states what succeeded, what the defenders caught, and what should change. The ISSO enters the findings in the GRC system as POA&M items and tracks them to closure. Lessons about human behavior go into the awareness and role-based training content. Evidence: the rules of engagement, the exercise reports, the tracked findings with their closures, and the training updates the exercise produced.

CA-09 — Internal System Connections #

Baselines: Low / Moderate / High

1. Authorize internal connections of [Assignment: organization-defined system components — to be defined] to the system;
2. Document, for each internal connection, the interface characteristics, security and privacy requirements, and the nature of the information communicated;
3. Terminate internal system connections after [Assignment: organization-defined conditions — to be defined]; and
4. Review at least annually the continued need for each internal connection.

Procedure:

A requester submits a connection request in the ticketing system, and the System Owner authorizes the individual connection or confirms that it falls under an existing class authorization. In the record, the System Owner notes the interface details, the requirements that apply, and the information the connection carries. A class authorization covers a population with a common configuration, such as the managed printer fleet or the standard laptop build, so the System Owner can authorize many components with one record. A component that deviates from its class configuration loses its class authorization.

Disconnection follows an event. A component failure, a security incident involving the component, a system failure, or a CISO direction leads to disconnection, and the ISSO records the trigger and the action. Every year, the System Owner reviews the connection inventory, ends any connection without a continued justification, and records the disposition.

Evidence: the authorization records, the class definitions with their configurations, the disconnection actions with their triggers, and the yearly review dispositions.

4.3 Risk Management Framework Steps and Tasks #

The CISO sets out below the seven Risk Management Framework (RMF) steps and the 47 tasks in NIST SP 800-37 Rev. 2. Each step opens with its entry and exit criteria and a table of its tasks. A walk-through of each task follows the table. It names who does the task, who supports, when it starts, the steps, the tools and records, the output, and the controls it supports. The Organization-level Prepare tasks are done once and kept current. Every other task is done for each system and for each set of common controls. The person who does each task keeps its output where the task’s tools and records line says. System-level outputs are kept in the GRC system so the Authorizing Official can see where every system stands.

Step 1: Prepare (Organization level) #

Set up the people, strategy, shared controls, and monitoring strategy that every system relies on.

Entry criteria: The Chief Information Officer (CIO) starts these tasks when the Organization adopts this procedure. The CISO restarts a task when its output is out of date.

Exit criteria: The agency head has approved the risk management strategy. The CISO has published the common controls. The Senior Accountable Official for Risk Management has approved the information security continuous monitoring (ISCM) Strategy, and the Senior Agency Official for Privacy (SAOP) has approved the Privacy Continuous Monitoring Strategy. System-level work may then start.

Task P-1: Risk Management Roles #

Outcome in NIST SP 800-37: Individuals are identified and assigned key roles for executing the Risk Management Framework.

• Who does it: The agency head, the CIO, and the Senior Agency Official for Privacy (SAOP).
• Who supports: The Authorizing Official, the Senior Accountable Official for Risk Management, and the CISO.
• When it starts: When the Organization adopts this procedure, and each time a person leaves an RMF role.

Steps:

1. The CIO lists each RMF role in NIST SP 800-37 Rev. 2, Appendix D, and proposes a person or position for each one.
2. The agency head appoints the Senior Accountable Official for Risk Management and the SAOP in writing. The CIO appoints the CISO in writing.
3. The CIO appoints an Authorizing Official for each system and for each set of common controls.
4. Each System Owner names the ISSO and the Privacy Officer for the system and records them in the System Security and Privacy Plan (SSPP).
5. The CISO’s office keeps the list of role assignments in the GRC system and updates it when a role holder changes.

• Tools and records: Appointment letters in the document management system; the list of RMF role assignments in the GRC system.
• Output: Signed appointments and a current list of who holds each RMF role.
• Controls: PM-02, PM-19, PM-29.

Task P-2: Risk Management Strategy #

Outcome in NIST SP 800-37: A risk management strategy for the organization that includes a determination and expression of organizational risk tolerance is established.

• Who does it: The agency head.
• Who supports: The Senior Accountable Official for Risk Management, the CIO, the CISO, and the SAOP.
• When it starts: After task P-1 names the risk management roles, and on the review schedule for the strategy.

Steps:

1. The CISO drafts the Risk Management Strategy for the Senior Accountable Official for Risk Management. The draft states the Organization’s risk assumptions, constraints, priorities, and trade-offs.
2. The Senior Accountable Official for Risk Management proposes, in the draft’s Risk Appetite and Tolerance Statement, how much security, privacy, and supply chain risk the Organization will accept.
3. The CIO and the SAOP review the draft and send their comments to the CISO.
4. The agency head approves the strategy in writing.
5. The CISO publishes the approved strategy in the document management system. The Senior Accountable Official for Risk Management reviews it [PM-09 parameter 1 — to be defined].

• Tools and records: The strategy and its approval record in the document management system.
• Output: The approved Risk Management Strategy, with its Risk Appetite and Tolerance Statement.
• Controls: PM-09, PM-28.

Task P-3: Risk Assessment—Organization #

Outcome in NIST SP 800-37: An organization-wide risk assessment is completed or an existing risk assessment is updated.

• Who does it: The Senior Accountable Official for Risk Management, the CISO, and the SAOP.
• Who supports: The CIO, the Mission/Business Owners, and the Authorizing Officials.
• When it starts: After the agency head approves the risk management strategy, and when a major threat or mission change occurs.

Steps:

1. The CISO gathers threat information, incident trends, Inspector General findings, and open POA&M items across all systems.
2. The SAOP adds privacy risks, such as new uses of personally identifiable information (PII).
3. The CISO rates each risk against the Risk Appetite and Tolerance Statement, and the Senior Accountable Official for Risk Management reviews the ratings.
4. The CISO records the results in the GRC system and updates them at least every three (3) years.

• Tools and records: The organization-level cybersecurity risk register in the GRC system, in the fields of the Cybersecurity Risk Register Template.
• Output: Organization-level risk assessment results.
• Controls: RA-03, PM-16, PM-28.

Task P-4: Organizationally-Tailored Control Baselines and Cybersecurity Framework Profiles (Optional) #

Outcome in NIST SP 800-37: Organizationally-tailored control baselines and/or Cybersecurity Framework Profiles are established and made available.

• Who does it: The Mission/Business Owner and the Senior Accountable Official for Risk Management.
• Who supports: The CIO, the Authorizing Official, the CISO, and the SAOP.
• When it starts: When the CISO finds that many systems need the same changes to a NIST baseline.

Steps:

1. The CISO decides whether the Organization needs a tailored baseline or a Cybersecurity Framework profile. If it needs neither, the CISO records that decision in the GRC system and the task ends.
2. The CISO drafts the tailored baseline or the current and target profiles. The Mission/Business Owner confirms they meet mission needs.
3. The Senior Accountable Official for Risk Management approves each tailored baseline and profile.
4. The CISO publishes them in the document management system and loads each tailored baseline in the GRC system.

• Tools and records: Tailored baselines and profiles in the document management system and the GRC system.
• Output: Approved tailored control baselines or Cybersecurity Framework profiles, or a recorded decision to skip the task.
• Controls: PL-10, PL-11.

Task P-5: Common Control Identification #

Outcome in NIST SP 800-37: Common controls that are available for inheritance by organizational systems are identified, documented, and published.

• Who does it: The CISO and the SAOP.
• Who supports: The Mission/Business Owners, the Senior Accountable Official for Risk Management, the CIO, the Authorizing Officials, the Common Control Providers, and the System Owners.
• When it starts: After the agency head approves the risk management strategy, and when a common control is added, changed, or retired.

Steps:

1. The CISO lists the security controls that an enterprise service or office provides for many systems. Examples are physical protection, enterprise identity, central logging, and awareness training.
2. The SAOP lists the privacy controls the privacy program provides for many systems.
3. The CISO names a Common Control Provider for each common control.
4. Each Common Control Provider describes the common controls in a common control plan in the GRC system.
5. The CISO publishes the list of common controls, their providers, and their authorization status, and tells System Owners when it changes.

• Tools and records: The list of common controls and the common control plans in the GRC system.
• Output: A published list of common controls and their providers, with a plan for each set of common controls.
• Controls: PL-02, PM-10, CA-06.

Task P-6: Impact-Level Prioritization (Optional) #

Outcome in NIST SP 800-37: A prioritization of organizational systems with the same impact level is conducted.

• Who does it: The Senior Accountable Official for Risk Management.
• Who supports: The CISO, the SAOP, the Mission/Business Owners, the System Owners, the CIO, and the Authorizing Officials.
• When it starts: When the CISO plans the next year’s assessments, and after a new system is categorized.

Steps:

1. The CISO lists the systems at each impact level from the system inventory in the GRC system.
2. The Senior Accountable Official for Risk Management ranks the systems within each level by mission importance, business impact analysis results, and High Value Asset status.
3. The CISO uses the ranking to order assessments and to assign staff and funds.
4. If the CISO decides not to rank the systems, the CISO records that decision in the GRC system instead of a ranking.

• Tools and records: The ranking in the GRC system.
• Output: Systems ranked within each impact level, or a recorded decision to skip the task.
• Controls: RA-02(01).

Task P-7: Continuous Monitoring Strategy—Organization #

Outcome in NIST SP 800-37: An organization-wide strategy for monitoring control effectiveness is developed and implemented.

• Who does it: The Senior Accountable Official for Risk Management, and the SAOP for the Privacy Continuous Monitoring Strategy.
• Who supports: The CIO, the CISO, the Mission/Business Owners, the System Owners, and the Authorizing Officials.
• When it starts: Before any system starts task S-5, and on the strategy’s review schedule.

Steps:

1. The CISO drafts the Information Security Continuous Monitoring (ISCM) Strategy. It sets the metrics, the monitoring and assessment frequencies, and the reporting schedule.
2. The SAOP drafts the Privacy Continuous Monitoring Strategy for privacy controls.
3. The Senior Accountable Official for Risk Management approves the ISCM Strategy. The SAOP approves the Privacy Continuous Monitoring Strategy.
4. The CISO publishes both strategies in the document management system and sets up the reporting views in the GRC system.

• Tools and records: The ISCM Strategy and the Privacy Continuous Monitoring Strategy in the document management system.
• Output: An approved organization-wide continuous monitoring strategy for security and for privacy.
• Controls: CA-07, PM-31.

Evidence: the signed role appointments, the approved risk management strategy, the organization-level risk assessment, the published list of common controls, and the approved continuous monitoring strategies.

Step 2: Prepare (System level) #

Learn what the system is for, what it holds, and where its boundary lies before choosing controls.

Entry criteria: A Mission/Business Owner proposes a new system, or the CISO brings an operating system into this procedure. The Organization-level Prepare tasks are complete.

Exit criteria: The Authorizing Official has approved the authorization boundary. The system risk assessment and requirements are recorded, and the System Owner has registered the system. The System Owner may then start the Categorize step.

Task P-8: Mission or Business Focus #

Outcome in NIST SP 800-37: Missions, business functions, and mission/business processes that the system is intended to support are identified.

• Who does it: The Mission/Business Owner.
• Who supports: The Authorizing Official, the System Owner, the Information Owner, the CIO, the CISO, and the SAOP.
• When it starts: When a Mission/Business Owner proposes a new system or a new use of an existing system.

Steps:

1. The Mission/Business Owner lists the missions, business functions, and business processes the system will support.
2. The Mission/Business Owner adds the business impact analysis results when the system already has one.
3. The System Owner records the list in the SSPP in the GRC system.

• Tools and records: The SSPP in the GRC system.
• Output: The missions, business functions, and business processes the system supports.
• Controls: PM-11.

Task P-9: System Stakeholders #

Outcome in NIST SP 800-37: The stakeholders having an interest in the system are identified.

• Who does it: The Mission/Business Owner and the System Owner.
• Who supports: The CIO, the Authorizing Official, the Information Owner, the CISO, the SAOP, and the Contracting Officer.
• When it starts: After task P-8, and when a stakeholder changes.

Steps:

1. The System Owner lists the users, the owners of connected systems, the service providers, and the oversight offices.
2. The System Owner records each stakeholder’s contact and interest in the system.
3. The System Owner records the list in the SSPP and updates it when a stakeholder changes.

• Tools and records: The SSPP in the GRC system.
• Output: A list of system stakeholders.
• Controls: PL-02.

Task P-10: Asset Identification #

Outcome in NIST SP 800-37: Stakeholder assets are identified and prioritized.

• Who does it: The System Owner.
• Who supports: The Authorizing Official, the Mission/Business Owner, the Information Owner, the CISO, the SAOP, and the System Administrator.
• When it starts: After task P-9.

Steps:

1. The System Administrator lists the hardware, software, firmware, cloud services, and data stores in the asset inventory tool.
2. The System Owner adds the information assets and the people and facilities the system depends on.
3. The ISSO links each component to the system in the asset inventory tool and marks any High Value Asset candidate.

• Tools and records: The component inventory in the asset inventory tool.
• Output: The set of assets the system must protect.
• Controls: CM-08.

Task P-11: Authorization Boundary #

Outcome in NIST SP 800-37: The authorization boundary (i.e., system) is determined.

• Who does it: The Authorizing Official.
• Who supports: The CIO, the System Owner, the Mission/Business Owner, the CISO, the SAOP, and the Enterprise Security Architect.
• When it starts: After task P-10 lists the assets.

Steps:

1. The System Owner draws the proposed boundary. The diagram shows the components, the connections to other systems, and the external and cloud services.
2. The Enterprise Security Architect checks that the boundary does not overlap another system’s boundary and leaves no component out.
3. The Authorizing Official approves the boundary in writing or returns it with the changes needed.
4. The ISSO stores the diagram and the approval in the GRC system.

• Tools and records: The boundary diagram and approval in the GRC system.
• Output: A documented authorization boundary that the Authorizing Official has approved.
• Controls: PL-02, CA-09.

Task P-12: Information Types #

Outcome in NIST SP 800-37: The types of information processed, stored, and transmitted by the system are identified.

• Who does it: The System Owner and the Information Owner.
• Who supports: The Mission/Business Owner, the ISSO, and the Privacy Officer.
• When it starts: After task P-11.

Steps:

1. The Information Owner lists the information types with NIST SP 800-60.
2. The Privacy Officer marks each type that includes PII. The System Owner starts the privacy threshold analysis.
3. The ISSO records each type, with its Controlled Unclassified Information (CUI) category if it has one, in the Risk Assessment and Federal Information Processing Standards (FIPS) 199 Categorization template.

• Tools and records: The Risk Assessment and FIPS 199 Categorization template in the GRC system.
• Output: A list of the system’s information types.
• Controls: RA-02.

Task P-13: Information Life Cycle #

Outcome in NIST SP 800-37: All stages of the information life cycle are identified and understood for each information type processed, stored, or transmitted by the system.

• Who does it: The SAOP, the System Owner, and the Information Owner.
• Who supports: The CIO, the Mission/Business Owner, the Enterprise Security Architect, and the Security Architect.
• When it starts: After task P-12.

Steps:

1. The System Owner and the Security Architect draw a data flow diagram from collection to disposal for each information type.
2. The Privacy Officer maps where PII is collected, used, shared, kept, and destroyed.
3. The SAOP reviews the map and decides whether the system needs a privacy impact assessment. The Privacy Compliance Steps section of the Personally Identifiable Information Processing and Transparency procedure gives the steps.
4. The ISSO stores the diagrams and the privacy threshold analysis in the GRC system.

• Tools and records: Data flow diagrams, the privacy threshold analysis, and any privacy impact assessment in the GRC system.
• Output: Data flow diagrams and a data map for each information type.
• Controls: PT-02, PT-03, RA-08.

Task P-14: Risk Assessment—System #

Outcome in NIST SP 800-37: A system-level risk assessment is completed or an existing risk assessment is updated.

• Who does it: The System Owner, the ISSO, and the Privacy Officer.
• Who supports: The Senior Accountable Official for Risk Management, the Authorizing Official, the Mission/Business Owner, the Information Owner, and the Security Control Assessor (SCA).
• When it starts: After task P-13, after each significant change, and on the risk assessment schedule.

Steps:

1. The ISSO identifies threats and vulnerabilities, using vulnerability scans for a system already in operation.
2. The ISSO rates the likelihood and impact of each threat with the Risk Assessment and FIPS 199 Categorization template.
3. The Privacy Officer assesses privacy risk and feeds the results into the privacy impact assessment.
4. The System Owner reviews each risk against the Organization’s risk tolerance.
5. The ISSO records the results in the GRC system and updates them at least every three (3) years.

• Tools and records: The risk assessment report in the GRC system.
• Output: Security and privacy risk assessment reports.
• Controls: RA-03, RA-08.

Task P-15: Requirements Definition #

Outcome in NIST SP 800-37: Security and privacy requirements are defined and prioritized.

• Who does it: The Mission/Business Owner, the System Owner, and the Information Owner. The Privacy Officer joins them when the system processes PII.
• Who supports: The Authorizing Official, the ISSO, the CISO, the SAOP, the Contracting Officer, and the Security Architect.
• When it starts: After task P-14.

Steps:

1. The System Owner gathers requirements from laws, OMB memoranda, the Organization’s policies, the risk assessment, and the stakeholders.
2. The Privacy Officer adds the privacy requirements from the privacy impact assessment and any system of records notice.
3. For a system the Organization buys, the Contracting Officer puts the requirements in the contract.
4. The System Owner records the requirements in the SSPP.

• Tools and records: The SSPP in the GRC system and the contract file.
• Output: Documented security and privacy requirements.
• Controls: PL-02, SA-04.

Task P-16: Enterprise Architecture #

Outcome in NIST SP 800-37: The placement of the system within the enterprise architecture is determined.

• Who does it: The Mission/Business Owner, the Enterprise Security Architect, and the Security Architect.
• Who supports: The CIO, the Authorizing Official, the CISO, the SAOP, the System Owner, and the Information Owner.
• When it starts: After task P-15.

Steps:

1. The Enterprise Security Architect places the system in the enterprise and security architecture, following the Enterprise Architecture Procedure.
2. The Enterprise Security Architect records which cloud and shared services the system will use, and their FedRAMP authorizations.
3. The Enterprise Security Architect updates the architecture records in the document management system. The Architecture Review Board reviews any departure from the architecture.

• Tools and records: The enterprise architecture records in the document management system.
• Output: An updated enterprise architecture and a plan for cloud and shared services.
• Controls: PL-08, SA-09.

Task P-17: Requirements Allocation #

Outcome in NIST SP 800-37: Security and privacy requirements are allocated to the system and to the environment in which the system operates.

• Who does it: The Security Architect, the ISSO, and the Privacy Officer.
• Who supports: The CIO, the Authorizing Official, the Mission/Business Owner, the CISO, the SAOP, and the System Owner.
• When it starts: After task P-16.

Steps:

1. The Security Architect assigns each requirement to the system, to a part of the system, or to the environment it runs in.
2. For a cloud service, the ISSO uses the provider’s customer responsibility matrix to split each requirement between the provider and the Organization.
3. The ISSO records the allocation in the SSPP.

• Tools and records: The SSPP in the GRC system.
• Output: A list of requirements allocated to the system, its parts, and its environment.
• Controls: PL-02, PL-08.

Task P-18: System Registration #

Outcome in NIST SP 800-37: The system is registered for purposes of management, accountability, coordination, and oversight.

• Who does it: The System Owner.
• Who supports: The Mission/Business Owner, the CIO, the ISSO, and the Privacy Officer.
• When it starts: After task P-17, before the Categorize step starts.

Steps:

1. The System Owner registers the system in the GRC system. The entry gives its name, owner, Authorizing Official, impact level, PII status, High Value Asset status, and cloud services.
2. The CIO’s office confirms the entry for the Federal Information Security Modernization Act (FISMA) system inventory.
3. The ISSO updates the entry after categorization, after each authorization decision, and at retirement.

• Tools and records: The system inventory in the GRC system.
• Output: A registered system.
• Controls: PM-05, PM-05(01).

Evidence: the stakeholder list, the asset list, the approved authorization boundary, the information types and data flows, the privacy threshold analysis, the system risk assessment, the requirements, and the system’s registration.

Step 3: Categorize #

Decide how much harm a loss of the system’s information would cause.

Entry criteria: The System Owner has registered the system. The information types and the system risk assessment are recorded.

Exit criteria: The Authorizing Official has approved the security categorization. For a system that processes PII, the SAOP has also approved it. The System Owner may then start the Select step.

Task C-1: System Description #

Outcome in NIST SP 800-37: The characteristics of the system are described and documented.

• Who does it: The System Owner.
• Who supports: The Authorizing Official, the Information Owner, the ISSO, and the Privacy Officer.
• When it starts: After task P-18.

Steps:

1. The System Owner writes the system description in the SSPP. It covers the purpose, functions, users, components, connections, data flows, location, and life cycle phase.
2. The ISSO checks the description against the asset list in the asset inventory tool and the approved boundary.
3. The System Owner updates the description when the system changes.

• Tools and records: The SSPP in the GRC system.
• Output: A documented system description.
• Controls: PL-02, CM-08.

Task C-2: Security Categorization #

Outcome in NIST SP 800-37: A security categorization of the system, including the information processed by the system represented by the organization-identified information types, is completed. Security categorization results are documented in the security, privacy, and SCRM plans. Security categorization results are consistent with the enterprise architecture and commitment to protecting organizational missions, business functions, and mission/business processes. Security categorization results reflect the organization’s risk management strategy.

• Who does it: The System Owner and the Information Owner.
• Who supports: The Senior Accountable Official for Risk Management, the CIO, the CISO, the SAOP, the Authorizing Official, the ISSO, and the Privacy Officer.
• When it starts: After task C-1.

Steps:

1. The Information Owner assigns an impact level for confidentiality, integrity, and availability to each information type. The Information Owner starts from NIST SP 800-60 and records the reason for each change.
2. The System Owner sets the system’s category at the highest impact level of any information type for each objective.
3. The Privacy Officer confirms which information types include PII and the impact of their loss.
4. The ISSO records the results in the Risk Assessment and FIPS 199 Categorization template and in the SSPP.

• Tools and records: The Risk Assessment and FIPS 199 Categorization template and the SSPP in the GRC system.
• Output: Impact levels for each information type and objective, and the system’s FIPS 199 category.
• Controls: RA-02.

Task C-3: Security Categorization Review and Approval #

Outcome in NIST SP 800-37: The security categorization results are reviewed and the categorization decision is approved by senior leaders in the organization.

• Who does it: The Authorizing Official, and the SAOP for a system that processes PII.
• Who supports: The Senior Accountable Official for Risk Management, the CIO, and the CISO.
• When it starts: When the System Owner submits the categorization in the GRC system.

Steps:

1. The CISO’s staff check the categorization against similar systems and the enterprise architecture.
2. For a system that processes PII, the SAOP reviews the PII determination and approves the categorization.
3. The Authorizing Official approves the categorization or returns it with reasons.
4. The ISSO records the approval and updates the system inventory in the GRC system.

• Tools and records: The approval record and system inventory in the GRC system.
• Output: An approved security categorization.
• Controls: RA-02.

Evidence: the system description in the SSPP, the completed Risk Assessment and FIPS 199 Categorization template, and the signed approval of the categorization.

Step 4: Select #

Choose, tailor, and document the controls the system needs.

Entry criteria: The Authorizing Official has approved the security categorization.

Exit criteria: The Authorizing Official has approved the SSPP and the system’s continuous monitoring strategy. The System Owner may then start the Implement step.

Task S-1: Control Selection #

Outcome in NIST SP 800-37: Control baselines necessary to protect the system commensurate with risk are selected.

• Who does it: The System Owner, or the Common Control Provider for common controls.
• Who supports: The Authorizing Official, the Information Owner, the Security Architect, the ISSO, and the Privacy Officer.
• When it starts: After task C-3.

Steps:

1. The ISSO selects the NIST SP 800-53B baseline that matches the categorization, and the privacy baseline when the system processes PII.
2. The ISSO adds any overlay that applies, such as the High Value Asset overlay or a tailored baseline from task P-4.
3. For a cloud service, the ISSO starts from the FedRAMP baseline at the same impact level.
4. The ISSO loads the baseline in the GRC system.

• Tools and records: The control baseline in the GRC system.
• Output: The controls selected for the system.
• Controls: PL-10.

Task S-2: Control Tailoring #

Outcome in NIST SP 800-37: Controls are tailored producing tailored control baselines.

• Who does it: The System Owner, or the Common Control Provider for common controls.
• Who supports: The Authorizing Official, the Information Owner, the Security Architect, the ISSO, and the Privacy Officer.
• When it starts: After task S-1.

Steps:

1. The ISSO marks the controls the system inherits from the list of common controls.
2. The ISSO applies scoping decisions and chooses compensating controls where a baseline control does not fit.
3. The ISSO adds controls the risk assessment calls for and fills in each parameter from the Organization’s parameter register.
4. The System Owner records the reason for each tailoring decision in the SSPP.

• Tools and records: The SSPP in the GRC system.
• Output: A tailored control baseline with the reason for each decision.
• Controls: PL-11.

Task S-3: Control Allocation #

Outcome in NIST SP 800-37: Controls are designated as system-specific, hybrid, or common controls. Controls are allocated to the specific system elements (i.e., machine, physical, or human elements).

• Who does it: The Security Architect, the ISSO, and the Privacy Officer.
• Who supports: The CIO, the Authorizing Official, the Mission/Business Owner, the CISO, the SAOP, and the System Owner.
• When it starts: After task S-2.

Steps:

1. The ISSO marks each control as system-specific, hybrid, or common in the GRC system.
2. For each hybrid control, the ISSO records which part the system provides and which part the Common Control Provider provides.
3. The Security Architect assigns each control to the machine, physical, or human part of the system that carries it out.
4. The ISSO confirms that each inherited common control has a current authorization.

• Tools and records: The control allocation in the GRC system.
• Output: Each control allocated to the system, its parts, or a common control provider.
• Controls: PL-02, PL-08.

Task S-4: Documentation of Planned Control Implementations #

Outcome in NIST SP 800-37: Controls and associated tailoring actions are documented in security and privacy plans or equivalent documents.

• Who does it: The System Owner, or the Common Control Provider for common controls.
• Who supports: The Authorizing Official, the Information Owner, the Security Architect, the ISSO, and the Privacy Officer.
• When it starts: After task S-3.

Steps:

1. The ISSO writes an implementation statement for each control. Each statement says who acts, what they do, with which tool, how often, and what record they keep.
2. For an inherited control, the ISSO names the provider and the provider’s plan.
3. The System Owner reviews the draft SSPP and signs it.
4. The System Owner reviews the SSPP every year after approval.

• Tools and records: The SSPP in the GRC system.
• Output: A System Security and Privacy Plan for the system.
• Controls: PL-02.

Task S-5: Continuous Monitoring Strategy—System #

Outcome in NIST SP 800-37: A continuous monitoring strategy for the system that reflects the organizational risk management strategy is developed.

• Who does it: The System Owner, or the Common Control Provider for common controls.
• Who supports: The Senior Accountable Official for Risk Management, the CIO, the CISO, the SAOP, the Authorizing Official, the Information Owner, the Security Architect, the ISSO, and the Privacy Officer.
• When it starts: After task S-4, using the ISCM Strategy from task P-7.

Steps:

1. The ISSO sets how each control is monitored. Examples are vulnerability scans, log review in the security information and event management (SIEM) system, configuration checks, and manual review.
2. The ISSO sets a schedule that assesses controls every year and reports to the Authorizing Official on the ISCM Strategy’s schedule.
3. The ISSO sets the time-driven frequency for ongoing authorization reviews.
4. The System Owner records the strategy with the SSPP in the GRC system.

• Tools and records: The system’s continuous monitoring strategy with the SSPP in the GRC system.
• Output: A continuous monitoring strategy for the system, including the time-driven frequency for ongoing authorization.
• Controls: CA-07.

Task S-6: Plan Review and Approval #

Outcome in NIST SP 800-37: Security and privacy plans reflecting the selection of controls necessary to protect the system and the environment of operation commensurate with risk are reviewed and approved by the authorizing official.

• Who does it: The Authorizing Official.
• Who supports: The Senior Accountable Official for Risk Management, the CIO, the Contracting Officer, the CISO, and the SAOP.
• When it starts: When the System Owner submits the SSPP and the monitoring strategy in the GRC system.

Steps:

1. The CISO’s staff check the SSPP against the baseline and the reasons for each tailoring decision.
2. For a system that processes PII, the SAOP reviews the privacy parts of the plan.
3. The Authorizing Official approves the plan or returns it with the changes needed.
4. The ISSO records the approval date and the approved version in the GRC system.

• Tools and records: The approval record in the GRC system.
• Output: An SSPP and continuous monitoring strategy that the Authorizing Official has approved.
• Controls: PL-02.

Evidence: the tailored baseline with its reasons, the allocation of each control, the SSPP, the system’s continuous monitoring strategy, and the approval of the SSPP.

Step 5: Implement #

Put the controls in place and record how they were built.

Entry criteria: The Authorizing Official has approved the SSPP.

Exit criteria: The System Owner has confirmed in writing that the SSPP describes the system as built. The System Owner may then ask for the assessment.

Task I-1: Control Implementation #

Outcome in NIST SP 800-37: Controls specified in the security and privacy plans are implemented. Systems security and privacy engineering methodologies are used to implement the controls in the system security and privacy plans.

• Who does it: The System Owner, or the Common Control Provider for common controls.
• Who supports: The Information Owner, the Security Architect, the Enterprise Security Architect, the ISSO, the Privacy Officer, and the System Administrator.
• When it starts: After task S-6.

Steps:

1. The System Administrator builds and configures each component under the SSPP and the Organization’s secure configuration settings.
2. The System Administrator records each configuration change as a change ticket in the ticketing system.
3. For a system the Organization buys, the System Owner checks that the vendor delivers the security and privacy terms of the contract.
4. The ISSO collects implementation evidence, such as configuration exports and scan results, in the GRC system.
5. The System Administrator runs vulnerability scans and fixes what they find.

• Tools and records: Change tickets in the ticketing system; implementation evidence in the GRC system.
• Output: Controls in place as the SSPP describes them.
• Controls: CM-02, CM-06, SA-08.

Task I-2: Update Control Implementation Information #

Outcome in NIST SP 800-37: Changes to the planned implementation of controls are documented. The security and privacy plans are updated based on information obtained during the implementation of the controls.

• Who does it: The System Owner, or the Common Control Provider for common controls.
• Who supports: The Information Owner, the Security Architect, the Enterprise Security Architect, the ISSO, the Privacy Officer, and the System Administrator.
• When it starts: When the build is complete, before the System Owner asks for the assessment.

Steps:

1. The ISSO compares each control as built with the planned implementation.
2. The ISSO updates each implementation statement that changed, in enough detail for an assessor to test it.
3. The System Administrator records the configuration baseline and updates the inventory in the asset inventory tool.
4. The System Owner confirms that the SSPP is current and tells the Authorizing Official that the system is ready for assessment.

• Tools and records: The SSPP in the GRC system; the configuration baseline and inventory in the asset inventory tool.
• Output: An SSPP updated to the as-built state, and the system’s configuration baseline.
• Controls: PL-02, CM-02.

Evidence: the change tickets, the implementation evidence, the configuration baseline, the updated SSPP, and the System Owner’s readiness notice.

Step 6: Assess #

Find out whether the controls work as intended.

Entry criteria: The System Owner has confirmed that the SSPP describes the system as built.

Exit criteria: The SCA has issued the final assessment reports. The System Owner has finished initial fixes and has prepared the POA&M. The System Owner may then assemble the authorization package.

Task A-1: Assessor Selection #

Outcome in NIST SP 800-37: An assessor or assessment team is selected to conduct the control assessments. The appropriate level of independence is achieved for the assessor or assessment team selected.

• Who does it: The Authorizing Official.
• Who supports: The CIO, the CISO, and the SAOP.
• When it starts: When the System Owner says the system is ready for assessment, and before each ongoing assessment cycle.

Steps:

1. The CISO proposes an SCA or team with the skills the system needs.
2. The Authorizing Official confirms that the assessor is independent enough for the system’s impact level.
3. The SAOP names who assesses the privacy controls.
4. The ISSO records the selection and the independence statement in the GRC system.

• Tools and records: The selection record in the GRC system.
• Output: A selected assessor or assessment team.
• Controls: CA-02, CA-02(01).

Task A-2: Assessment Plan #

Outcome in NIST SP 800-37: Documentation needed to conduct the assessments is provided to the assessor or assessment team. Security and privacy assessment plans are developed and documented. Security and privacy assessment plans are reviewed and approved to establish the expectations for the control assessments and the level of effort required.

• Who does it: The Authorizing Official and the SCA.
• Who supports: The CISO, the SAOP, the System Owner, the Common Control Provider, the Information Owner, the ISSO, and the Privacy Officer.
• When it starts: After task A-1.

Steps:

1. The ISSO gives the SCA the SSPP, the prior assessment reports, the POA&M, and the configuration baseline.
2. The SCA drafts the security and privacy assessment plan (SAP). In the plan, the SCA sets the scope, the NIST SP 800-53A methods, the schedule, the rules for testing, and any results to reuse.
3. The System Owner reviews the plan for access and schedule.
4. The Authorizing Official approves the plan before the assessment starts. The ISSO stores it in the GRC system.

• Tools and records: The approved SAP in the GRC system.
• Output: Security and privacy assessment plans approved by the Authorizing Official.
• Controls: CA-02.

Task A-3: Control Assessments #

Outcome in NIST SP 800-37: Control assessments are conducted in accordance with the security and privacy assessment plans. Opportunities to reuse assessment results from previous assessments to make the risk management process timely and cost-effective are considered. Use of automation to conduct control assessments is maximized to increase speed, effectiveness, and efficiency of assessments.

• Who does it: The SCA.
• Who supports: The Authorizing Official, the System Owner, the Common Control Provider, the Information Owner, the CISO, the SAOP, the ISSO, and the Privacy Officer.
• When it starts: On the start date in the approved plan.

Steps:

1. The SCA examines documents, interviews staff, and tests the controls, as the plan sets out.
2. The SCA reuses results from automated monitoring and prior assessments where the plan allows.
3. The SCA records each determination with its evidence in the GRC system.
4. The SCA tells the System Owner at once about any finding that puts the system at high risk.

• Tools and records: Assessment evidence in the GRC system.
• Output: Completed control assessments and their evidence.
• Controls: CA-02, CA-08.

Task A-4: Assessment Reports #

Outcome in NIST SP 800-37: Security and privacy assessment reports that provide findings and recommendations are completed.

• Who does it: The SCA.
• Who supports: The System Owner, the Common Control Provider, the ISSO, and the Privacy Officer.
• When it starts: When the SCA finishes the assessment.

Steps:

1. The SCA writes the security assessment report (SAR) and the privacy assessment report. Each finding has a risk rating and a recommendation.
2. The System Owner reviews the draft for errors of fact and sends comments to the SCA.
3. The SCA issues the final reports in the GRC system.

• Tools and records: The final reports in the GRC system.
• Output: Security and privacy assessment reports with findings and recommendations.
• Controls: CA-02.

Task A-5: Remediation Actions #

Outcome in NIST SP 800-37: Remediation actions to address deficiencies in the controls implemented in the system and environment of operation are taken. Security and privacy plans are updated to reflect control implementation changes made based on the assessments and subsequent remediation actions.

• Who does it: The System Owner, the Common Control Provider, and the SCA.
• Who supports: The Authorizing Official, the CISO, the SAOP, the Senior Accountable Official for Risk Management, the Information Owner, the Security Architect, the ISSO, and the Privacy Officer.
• When it starts: When the SCA issues the draft or final reports.

Steps:

1. The System Owner decides which findings to fix before the authorization decision, starting with the highest risk.
2. The System Administrator makes each fix through a change ticket in the ticketing system.
3. The SCA retests each fixed control and updates the reports to show the result.
4. The ISSO updates the SSPP for each implementation that changed.

• Tools and records: Change tickets in the ticketing system; the updated reports and SSPP in the GRC system.
• Output: Completed initial fixes, updated assessment reports, and an updated SSPP.
• Controls: CA-02, CA-05.

Task A-6: Plan of Action and Milestones #

Outcome in NIST SP 800-37: A plan of action and milestones detailing remediation plans for unacceptable risks identified in security and privacy assessment reports is developed.

• Who does it: The System Owner, or the Common Control Provider for common controls.
• Who supports: The Information Owner, the ISSO, the Privacy Officer, the CISO, the SAOP, the SCA, and the Contracting Officer.
• When it starts: When the SCA issues the final reports.

Steps:

1. The ISSO enters each finding that is still open as a POA&M item in the GRC system. The Plan of Action and Milestones (POA&M) Management Procedure sets the fields.
2. The System Owner gives each item an owner, milestones, a scheduled completion date, and the resources it needs.
3. The System Owner marks each item proposed for risk acceptance instead of a fix. The Authorizing Official decides those in task R-3.

• Tools and records: The POA&M in the GRC system.
• Output: A POA&M for each finding the System Owner will fix after the decision.
• Controls: CA-05, PM-04.

Evidence: the assessor’s independence statement, the approved assessment plan, the assessment evidence, the final assessment reports, and the POA&M.

Step 7: Authorize #

Have a senior official decide whether the remaining risk is acceptable.

Entry criteria: The SCA has issued the final assessment reports, and the System Owner has prepared the POA&M. For a system that processes PII, the privacy control assessment is complete.

Exit criteria: The Authorizing Official has signed the authorization decision. The ISSO has updated the system inventory. Only then may the system operate, and the Monitor step starts.

Task R-1: Authorization Package #

Outcome in NIST SP 800-37: An authorization package is developed for submission to the authorizing official.

• Who does it: The System Owner or the Common Control Provider, and the SAOP for a system that processes PII.
• Who supports: The ISSO, the Privacy Officer, the CISO, and the SCA.
• When it starts: After task A-6.

Steps:

1. The ISSO assembles the package in the GRC system. The package holds an executive summary, the SSPP, the assessment reports, and the POA&M.
2. The ISSO adds the risk assessment, the contingency plan, the privacy impact assessment, and the interconnection agreements.
3. For a system that processes PII, the SAOP approves the privacy plan and the privacy assessment. The Authorization Decisions and Approaches section of this procedure lists these checks.
4. The System Owner signs the package and submits it to the Authorizing Official.

• Tools and records: The authorization package in the GRC system.
• Output: An authorization package with an executive summary.
• Controls: CA-06.

Task R-2: Risk Analysis and Determination #

Outcome in NIST SP 800-37: A risk determination by the authorizing official that reflects the risk management strategy including risk tolerance, is rendered.

• Who does it: The Authorizing Official.
• Who supports: The Senior Accountable Official for Risk Management, the CISO, and the SAOP.
• When it starts: When the System Owner submits the package.

Steps:

1. The CISO’s staff analyze the remaining risk from the open findings, the threats, and the inherited controls.
2. The Senior Accountable Official for Risk Management advises on risk to other systems and to the Organization.
3. The Authorizing Official compares the risk with the Risk Appetite and Tolerance Statement in the Risk Management Strategy and records a risk determination in the GRC system.

• Tools and records: The risk determination in the GRC system.
• Output: A risk determination.
• Controls: CA-06, RA-03.

Task R-3: Risk Response #

Outcome in NIST SP 800-37: Risk responses for determined risks are provided.

• Who does it: The Authorizing Official.
• Who supports: The Senior Accountable Official for Risk Management, the CISO, the SAOP, the System Owner, the Information Owner, the Security Architect, the ISSO, and the Privacy Officer.
• When it starts: After task R-2.

Steps:

1. The Authorizing Official chooses a response for each risk: accept, avoid, mitigate, share, or transfer.
2. The ISSO turns each mitigation into a POA&M item with a deadline.
3. The Authorizing Official signs each risk acceptance with an end date. For a privacy risk, the SAOP also agrees in writing.
4. The ISSO records each response in the GRC system.

• Tools and records: Risk responses and signed acceptances in the GRC system.
• Output: A response for each risk in the determination.
• Controls: CA-05, PM-04, RA-07.

Task R-4: Authorization Decision #

Outcome in NIST SP 800-37: The authorization for the system or the common controls is approved or denied.

• Who does it: The Authorizing Official.
• Who supports: The Senior Accountable Official for Risk Management, the CIO, the CISO, the SAOP, and the Authorizing Official Designated Representative.
• When it starts: After task R-3.

Steps:

1. The Authorizing Official decides whether the risk is acceptable. The Authorizing Official may not delegate this decision.
2. The Authorizing Official signs one of the decisions in the Authorization Decisions and Approaches section of this procedure.
3. The decision states its terms and conditions and its termination date, or the review frequency under ongoing authorization.
4. The ISSO stores the signed decision in the GRC system, and the System Owner carries out its terms.

• Tools and records: The signed decision in the GRC system.
• Output: An authorization to operate, an authorization to use, a common control authorization, or a denial.
• Controls: CA-06.

Task R-5: Authorization Reporting #

Outcome in NIST SP 800-37: Authorization decisions, significant vulnerabilities, and risks are reported to organizational officials.

• Who does it: The Authorizing Official.
• Who supports: The System Owner, the Information Owner, the ISSO, the Privacy Officer, the CISO, and the SAOP.
• When it starts: When the Authorizing Official (AO) signs the decision.

Steps:

1. The Authorizing Official reports the decision and any significant weaknesses to the CIO, the CISO, the SAOP, and the Senior Accountable Official for Risk Management.
2. The ISSO records the authorization status and termination date in the system inventory in the GRC system.
3. For a common control authorization, the Common Control Provider tells each System Owner that inherits the controls.
4. For a cloud service, the ISSO follows the Report cloud authorizations to FedRAMP part of this procedure.

• Tools and records: The decision report and the system inventory in the GRC system.
• Output: A report of the decision and an updated system inventory.
• Controls: CA-06, PM-05.

Evidence: the authorization package with its executive summary, the risk determination, each signed risk acceptance, the signed decision, and the report of the decision.

Step 8: Monitor #

Keep the authorization current as the system and its threats change.

Entry criteria: The Authorizing Official has signed an authorization.

Exit criteria: The Monitor step continues while the system operates. It ends when the System Owner completes task M-7.

Task M-1: System and Environment Changes #

Outcome in NIST SP 800-37: The information system and environment of operation are monitored in accordance with the continuous monitoring strategy.

• Who does it: The System Owner or the Common Control Provider, the CISO, and the SAOP.
• Who supports: The Senior Accountable Official for Risk Management, the Authorizing Official, the Information Owner, the ISSO, and the Privacy Officer.
• When it starts: When the system is authorized, and with each proposed change.

Steps:

1. The ISSO analyzes each proposed change before the Configuration Control Board decides on it. The Security Impact Analysis and Significant Change section of the Configuration Management procedure gives the steps.
2. The ISSO watches for changes no one approved, using the asset inventory tool and configuration checks.
3. The ISSO tracks new threats, CISA directives, and changes at service providers that affect the system.
4. The ISSO updates the SSPP, the POA&M, and the assessment reports when a change affects them.

• Tools and records: Change tickets in the ticketing system. The updated SSPP and POA&M in the GRC system.
• Output: An updated SSPP, POA&M, and assessment reports.
• Controls: CM-03, CM-04, CA-07.

Task M-2: Ongoing Assessments #

Outcome in NIST SP 800-37: Ongoing assessments of control effectiveness are conducted in accordance with the continuous monitoring strategy.

• Who does it: The SCA.
• Who supports: The Authorizing Official, the System Owner, the Common Control Provider, the Information Owner, the ISSO, the Privacy Officer, the CISO, and the SAOP.
• When it starts: On the schedule in the system’s continuous monitoring strategy.

Steps:

1. The SCA assesses controls every year, following the rotation in the strategy.
2. The SCA uses automated results, such as vulnerability scans and the SIEM system reports, where the strategy allows.
3. The SCA checks that the System Owner follows the terms and conditions of the authorization.
4. The SCA updates the assessment reports in the GRC system.

• Tools and records: The updated assessment reports in the GRC system.
• Output: Updated security and privacy assessment reports.
• Controls: CA-02, CA-07, CA-07(01).

Task M-3: Ongoing Risk Response #

Outcome in NIST SP 800-37: The output of continuous monitoring activities is analyzed and responded to appropriately.

• Who does it: The Authorizing Official, the System Owner, and the Common Control Provider.
• Who supports: The Senior Accountable Official for Risk Management, the SAOP, the Information Owner, the ISSO, the Privacy Officer, and the Security Architect.
• When it starts: When monitoring, an ongoing assessment, or a risk assessment update finds a new risk.

Steps:

1. The ISSO analyzes the monitoring results, the scans, and the open POA&M items.
2. The System Owner fixes the weakness or proposes another response. The Vulnerability Management Procedure sets the deadlines for fixing vulnerabilities.
3. The Authorizing Official decides whether to fix the weakness or accept the risk, and signs any acceptance.
4. The ISSO records the response in the GRC system.

• Tools and records: POA&M items and risk acceptances in the GRC system.
• Output: Fixes or signed risk acceptances, and updated assessment reports.
• Controls: CA-07, RA-05, RA-07.

Task M-4: Authorization Package Updates #

Outcome in NIST SP 800-37: Risk management documents are updated based on continuous monitoring activities.

• Who does it: The System Owner, or the Common Control Provider for common controls.
• Who supports: The Information Owner, the ISSO, the Privacy Officer, the SAOP, and the CISO.
• When it starts: After each monitoring cycle, ongoing assessment, or change.

Steps:

1. The ISSO updates the POA&M every month.
2. The ISSO updates the SSPP when an implementation changes. The System Owner reviews it every year.
3. The ISSO updates the risk assessment at least every three (3) years and after each significant change.
4. The ISSO keeps each version in the GRC system so the AO can see what changed.

• Tools and records: The authorization package and its version history in the GRC system.
• Output: An updated authorization package.
• Controls: CA-05, CA-07, PL-02, RA-03.

Task M-5: Security and Privacy Reporting #

Outcome in NIST SP 800-37: A process is in place to report the security and privacy posture to the authorizing official and other senior leaders and executives.

• Who does it: The System Owner or the Common Control Provider, the CISO, and the SAOP.
• Who supports: The ISSO and the Privacy Officer.
• When it starts: On the reporting schedule in the ISCM Strategy, and at once when the system’s risk rises sharply.

Steps:

1. The ISSO prepares a security status report [CA-07 parameter 5 — to be defined].
2. The report gives the assessment results, open vulnerabilities by severity, POA&M progress, proposed risk acceptances, and the trend.
3. The Privacy Officer adds the privacy status under the Privacy Continuous Monitoring Strategy.
4. The ISSO sends the report to the Authorizing Official, the CISO, and the SAOP. The CISO uses it for FISMA reporting.

• Tools and records: The status reports in the GRC system.
• Output: Security and privacy posture reports.
• Controls: CA-07, PM-31.

Task M-6: Ongoing Authorization #

Outcome in NIST SP 800-37: Authorizing officials conduct ongoing authorizations using the results of continuous monitoring activities and communicate changes in risk determination and acceptance decisions.

• Who does it: The Authorizing Official.
• Who supports: The Senior Accountable Official for Risk Management, the CIO, the CISO, the SAOP, and the Authorizing Official Designated Representative.
• When it starts: When each status report arrives, and when a reauthorization trigger in the Assessment, Authorization, and Monitoring policy occurs.

Steps:

1. The Authorizing Official reviews each status report and decides whether the risk is still acceptable.
2. The Authorizing Official confirms the authorization, orders more risk response, or denies continued operation. The ISSO records the decision in the GRC system.
3. For a system under ongoing authorization, the AO follows the Move a system to ongoing authorization part of this procedure.
4. For a system with a termination date, the System Owner starts reauthorization early enough for a new decision before that date.

• Tools and records: Each ongoing decision in the GRC system.
• Output: A current risk determination and an ongoing authorization or a denial.
• Controls: CA-06, CA-07.

Task M-7: System Disposal #

Outcome in NIST SP 800-37: A system disposal strategy is developed and implemented, as needed.

• Who does it: The System Owner.
• Who supports: The Authorizing Official, the Information Owner, the ISSO, the Privacy Officer, the Senior Accountable Official for Risk Management, the CISO, and the SAOP.
• When it starts: When the Mission/Business Owner decides to retire the system.

Steps:

1. The System Owner writes the disposal strategy. It covers records retention, data migration, media sanitization under NIST SP 800-88, and the end of contracts and connections.
2. The System Administrator sanitizes or destroys the media and records a certificate for each item.
3. The Privacy Officer updates or retires the privacy impact assessment and any system of records notice.
4. The ISSO closes the POA&M items, removes the components from the asset inventory tool, and marks the system retired in the GRC system.
5. The System Owner tells the Authorizing Official that the system is retired, and the authorization ends.

• Tools and records: The disposal strategy and sanitization records in the GRC system; the inventory in the asset inventory tool.
• Output: A disposal strategy, an updated component inventory, and an updated SSPP.
• Controls: MP-06, SR-12, PM-05.

Evidence: the security impact analyses, the ongoing assessment results, the POA&M history, the updated SSPP, the status reports, each ongoing authorization decision, and the disposal records.

RMF Artifacts and Where They Are Kept #

The table below lists each RMF artifact, the task that creates it, who owns it, where it is kept, and what causes an update.

Source: NIST SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations (December 2018), Chapter 3 and Appendix F.

4.4 Authorization Decisions and Approaches #

The Authorizing Official makes each decision after the RMF Assess step. The parts below cover the privacy and cloud checks, the approach, the decision, ongoing authorization, and common controls. The ISSO stores every signed decision in the GRC system.

Part 1: Complete the checks before the decision #

Check privacy, cloud services, and inherited controls before the decision.

Part 2: Choose the authorization approach #

The Authorizing Official picks one approach from NIST SP 800-37 Rev. 2, Appendix F, and names it in the decision.

1. Traditional: one Authorizing Official authorizes one system or one set of common controls.
2. Joint: two or more co-Authorizing Officials authorize a system that serves more than one mission owner.
3. Type: the Authorizing Official authorizes one system design, such as a standard workstation build, for use at more than one site.
4. Facility: the Authorizing Official authorizes the protections of a site, and systems placed there inherit them.
5. Leveraged: the Authorizing Official reuses another agency’s package or a FedRAMP package and issues an authorization to use.

Part 3: Issue the decision #

The Authorizing Official signs one of these decisions.

1. Authorization to operate: the risk is acceptable, and the system may operate for the stated period.
2. Authorization to operate with conditions: the system may operate only while the System Owner meets each condition. Each condition is a POA&M item with a deadline.
3. Common control authorization: the risk of a set of common controls is acceptable, and systems may inherit them.
4. Authorization to use: the Organization may use a system or service that another official has authorized, such as a FedRAMP-authorized cloud service.
5. Denial of authorization: the risk is not acceptable, and the system must not operate.

The ISSO stores the signed decision in the GRC system. No one may load production data or connect the system to a production system before the Authorizing Official signs the decision.

Part 4: Report cloud authorizations to FedRAMP and monitor the provider #

The ISSO does this work under Using FedRAMP and FedRAMP 20x Authorized Cloud Services in this procedure. It has three parts:

1. Notify FedRAMP of the authorization: the ISSO sends FedRAMP a copy of each signed authorization of a cloud service.
2. Monitor the service: the ISSO reviews the provider’s ongoing reports and vulnerability reports.
3. Review significant changes: the ISSO reviews each change notice, and the Authorizing Official decides its effect.

Part 5: Move a system to ongoing authorization #

Replace a fixed reauthorization date with ongoing risk decisions.

Part 6: Assess, authorize, and monitor common controls #

Give common controls the same cycle as systems.

Evidence: the SAOP approval, the common control status reports, the FedRAMP checks, and each signed decision.

Source: NIST SP 800-37 Rev. 2, Appendix F (authorization decisions, approaches, and ongoing authorization); OMB Circular A-130, Appendix I; FedRAMP Authorization Act (44 U.S.C. 3607-3616); OMB M-24-15, Modernizing the Federal Risk and Authorization Management Program (2024).

4.5 Using FedRAMP and FedRAMP 20x Authorized Cloud Services #

The System Owner starts these steps when a system will use a cloud service. The ISSO repeats the monitoring steps until the Organization stops using the service. Where the Rev5 path and the FedRAMP 20x path differ, the task names the path. The ISSO keeps every record in the GRC system.

Stage 1: Check the authorization in the FedRAMP Marketplace #

Confirm that the service holds a FedRAMP authorization that fits the system.

Evidence: the dated Marketplace record, the FedRAMP ID, and the comparison with the system’s category.

Stage 2: Get the authorization package #

Get the provider’s current package through the channel the Marketplace listing names.

Evidence: the signed access request or the trust center access record, and the stored package with its version and date.

Stage 3: Review the package and the customer responsibilities #

Use the provider’s package for the provider’s share and find the Organization’s share.

Evidence: the package review, the list of customer responsibilities, the question log, and any notice to FedRAMP.

Stage 4: Record the Organization’s share in the SSPP #

Write only what the Organization does, and show what it inherits.

Evidence: the SSPP sections for the service, the configuration record, and the test and assessment results.

Stage 5: Decide whether the system may use the service #

The Authorizing Official decides under the Authorization Decisions and Approaches section of this procedure.

Evidence: the decision package, the contract check, the signed decision, and the POA&M items for its conditions.

Stage 6: Notify FedRAMP of the authorization #

FedRAMP keeps a record of every agency authorization of a cloud service.

Evidence: the form submission, FedRAMP’s reply, and the contact record.

Stage 7: Monitor the service #

FedRAMP’s monitoring of the provider does not replace the Organization’s own continuous monitoring.

Evidence: the review record for each report, Quarterly Review notes, POA&M items, incident tickets, and any notice to FedRAMP.

Stage 8: Review significant changes #

Under the 2026 FedRAMP rules, providers notify customers of significant changes instead of asking each customer to approve them.

Evidence: each change notice, the impact review, and the Authorizing Official’s decision.

Stage 9: Review the authorization and decide on reauthorization #

The ISSO reviews each service on the schedule in the system’s continuous monitoring strategy to confirm that it still fits the system and the accepted risk.

1. The provider loses its FedRAMP authorization, or moves to a lower class.
2. A Class A service reaches 12 months of use, and the provider is not seeking a higher class.
3. A transformative change raises the risk above the level the Authorizing Official accepted.
4. The Organization changes how it uses the service or what information it puts in it.
5. The provider moves from the Rev5 path to the FedRAMP 20x path.

FedRAMP stops accepting new Rev5 certifications on June 11, 2027, and keeps existing ones active until at least December 31, 2028. Evidence: the review record, the provider’s transition plan, and each reauthorization decision.

Stage 10: Stop using a service #

End use in an orderly way when the Organization or the provider ends the service.

Evidence: the Marketplace records, the package reviews, the SSPP, the signed authorization, the notice to FedRAMP, the monitoring reviews, the change decisions, and the exit records.

Source: FedRAMP Authorization Act (44 U.S.C. 3607-3616), including the presumption of adequacy in 44 U.S.C. 3613(e); OMB M-24-15, Modernizing the Federal Risk and Authorization Management Program (2024); FedRAMP Consolidated Rules for 2026, version 2026.10.13.01: Agency Use (AGU), Collaborative Continuous Monitoring (CCM), Vulnerability Evaluation and Reporting (VER), Significant Change Notification (SCN), Certification Data Sharing (CDS), and the Key Security Indicators; NIST SP 800-37 Rev. 2.

5. Parameters (ODP Values) #

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

6. Evidence Artifacts #

Carrying out this procedure produces these records:

• Procedure execution records for CA
• Configuration documentation
• Periodic review records
• Evidence for IG FISMA metric CG.01
• Evidence for IG FISMA metric CG.03
• Evidence for IG FISMA metric CG.04

7. Performance Measurement #

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

8. Training Requirements #

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

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

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

9. Governance References #

• OMB Circular A-130: Managing Information as a Strategic Resource, July 28, 2016.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
• FedRAMP Authorization Act (44 U.S.C. §§ 3607-3616 (FY2023 NDAA, Pub. L. 117-263, § 5921)), December 23, 2022.
• FedRAMP Consolidated Rules for 2026 (including 20x Key Security Indicators), June 24, 2026.
• FIPS 199: Standards for Security Categorization, February 2004.
• NIST Cybersecurity Framework 2.0, February 26, 2024.
• NIST SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations, December 2018.
• NIST SP 800-47 Rev. 1: Managing the Security of Information Exchanges, July 2021.
• NIST SP 800-53A Rev. 5: Assessing Security and Privacy Controls, January 2022.
• NIST SP 800-53B: Control Baselines for Information Systems and Organizations, September 2020.
• NIST SP 800-60 Rev. 1: Guide for Mapping Types of Information and Information Systems to Security Categories, August 2008.
• 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.
• OMB M-02-01: Guidance for Preparing and Submitting Security Plans of Action and Milestones, October 17, 2001.
• OMB M-19-03: Strengthening the Cybersecurity of Federal Agencies by Enhancing the High Value Asset Program, December 26, 2018.
• 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.