📝 The FedRAMP Board:

The Federal Risk and Authorization Management Program (FedRAMP®) is the U.S. government’s standardized process for assessing the security of cloud products and services. If your system will store, process, or transmit federal government data, it must meet FedRAMP requirements. No agency can use your cloud service without it.

FedRAMP ensures that cloud providers meet consistent, rigorous government security standards. It’s not optional. If you’re a cloud-based startup looking to work with U.S. government customers, FedRAMP compliance is a prerequisite.

Rather than apply a one-size-fits-all model, FedRAMP defines three security baselines — Low, Moderate, and High — based on how sensitive the data is and how disruptive a breach would be. Most cloud-based products align with the Moderate baseline, but the right fit depends on your product’s role in your customer’s mission.

Whether you’re building something new or adapting an existing platform, understanding FedRAMP early can save time, reduce cost, and prevent strategic rework.

tl;dr - If you want your cloud product to serve the federal market, FedRAMP is the gate.

The Federal Risk and Authorization Management Program (FedRAMP®) defines three security baselines—Low, Moderate, and High—based on how sensitive a system’s data is and how disruptive it would be if the system were compromised.

Each baseline includes a specific set of security and privacy controls from the National Institute of Standards and Technology (NIST) Special Publication 800-53, Revision 5. NIST 800-53 is the U.S. government’s authoritative source for evaluating the security posture of cloud systems.

Here’s how the FedRAMP baselines compare:

• FedRAMP Low: 156 controls

• FedRAMP Moderate: 323 controls

• FedRAMP High: 410 controls
  
  

FedRAMP uses the Federal Information Processing Standards (FIPS) Publication 199 to determine which baseline a system must meet. FIPS 199 assesses impact levels across three key areas: confidentiality, integrity, and availability.

If you don’t feel like reading FIPS 199, you can get a general sense of what security baseline most likely applies to your cloud service offering by answering three core questions:

1. What happens if your system goes down?

• Low: Minor inconvenience—users can wait or find workarounds

• Moderate: Significant disruption—operations are impaired, but the organization can still function

• High: Mission-critical failure—the organization cannot perform essential functions, or safety could be affected
  
  

2. What’s the impact if sensitive data is leaked?

• Low: Limited harm—some embarrassment, minor financial loss, or exposure of routine information

• Moderate: Serious consequences—financial loss, competitive harm, or privacy violations

• High: Severe damage—reputational fallout, legal exposure, or risk to public safety
  
  

3. What if someone maliciously alters your data?

• Low: Minor impact—issues are easily detected and corrected

• Moderate: Significant problems—business decisions are affected, or regulatory issues arise

• High: Severe consequences—mission failure, safety risks, or major financial loss

FIPS 199 uses the “high-water mark” method. That means your overall baseline is determined by the highest impact level across confidentiality, integrity, and availability. If even one area is rated High, your system must meet the FedRAMP High baseline.

Choosing the correct FedRAMP baseline early is critical. It helps you scope the right level of effort, estimate timelines more accurately, and avoid costly rework later.

If your company wants to sell cloud products or services to the U.S. government, achieving FedRAMP authorization is non-negotiable. But before you get there, you might want to consider an optional—but strategic—step: FedRAMP Ready.

FedRAMP Ready is not a full authorization. Instead, it’s a formal recognition that your system has the foundational elements in place to begin the FedRAMP authorization process. Think of it as a public signal that you're serious about compliance and prepared to move forward.

This designation gets your product listed in the FedRAMP Marketplace as “FedRAMP Ready,” increasing visibility to customers searching for compliant or near-compliant cloud solutions, and investors or opportunities in GovTech.

To earn the FedRAMP Ready designation, your system must undergo an evaluation by a Third Party Assessment Organization (3PAO). The 3PAO assesses your implementation against a specific subset of FedRAMP security controls, defined by the government in the Readiness Assessment Report (RAR).

• The RAR is only required for Moderate and High baselines — FedRAMP Low does not require it.

• The RAR covers core technical capabilities, such as data encryption, boundary protection, identity and access controls, and multi-tenancy risk management.

• The 3PAO submits an attestation to FedRAMP indicating whether your system is technically ready to proceed with a full security authorization package.

If approved, your product receives the FedRAMP Ready status and is listed on the FedRAMP Marketplace for 12 months. If you don’t progress to “FedRAMP In Process” or “FedRAMP Authorized” during that time, the designation will expire.

The cost of a FedRAMP Readiness Assessment from a 3PAO can easily exceed $30,000. And if your system isn’t prepared, you’ll likely spend more on technical rework or consulting to fill the gaps.

That’s why we recommend reviewing the RAR requirements internally before engaging a 3PAO. Identify gaps, address them proactively, and save time and money during the formal evaluation.

To help startups and small teams prepare, NYLE offers a completely free FedRAMP Moderate Readiness Assessment. Just answer 14 short questions and you’ll receive a personalized email report showing where you stand.

This isn’t a replacement for a 3PAO evaluation, but it’s a zero-cost first step to understanding what’s ahead and where to focus your efforts.

If you're aiming to sell your tech to the federal government, achieving FedRAMP In Process status is a critical milestone that shows your product or service is actively working through the complete FedRAMP authorization pipeline.

It means you've committed to submitting a complete authorization package, you're working with a Third Party Assessment Organization (3PAO), and you're partnered with a federal government agency that will "sponsor" you to get it done.

Some organizations first pursue FedRAMP Ready as a way to show intent and gain early visibility. Others move directly into the In Process phase once they've secured an agency sponsor that agrees to evaluate your system and, if successful, issue an Authority to Operate (ATO). Either way, this is where the hardest work begins.

Your system will be evaluated against the complete set of required FedRAMP security controls for your selected baseline—Low, Moderate, or High. Your team will need to fully implement and document:

• 156 controls for FedRAMP Low

• 323 controls for FedRAMP Moderate

• 410 controls for FedRAMP High

The 3PAO will assess your implementation and gather evidence to support your authorization package—including your System Security Plan (SSP), security scanning and penetration test results, and risk analysis documentation.

You'll also need to coordinate closely with your federal agency sponsor to address any findings, manage timelines, and finalize deliverables. This partnership is essential throughout the FedRAMP In Process phase.

To gain official FedRAMP In Process designation, your sponsoring agency submits an In Process Request (IPR) letter to the FedRAMP Board formally confirming their partnership with your organization for initial FedRAMP Authorization. They also submit a Work Breakdown Structure (WBS) outlining project timelines. Submission of the IPR and WBS is what triggers your listing as "FedRAMP In Process" on the FedRAMP Marketplace, and officially initiates the authorization process.

There's no fixed time limit for how long you can be in the FedRAMP In Process phase, but timelines must be agreed upon between you and your government sponsoring agency.

FedRAMP In Process demonstrates serious commitment to federal compliance and differentiates you from competitors still in FedRAMP Ready phase.

FedRAMP Authorized is the final designation in the FedRAMP process that means your cloud service has passed the complete security assessment, received an Authority to Operate (ATO) from a federal agency, and is now formally approved for use by the U.S. government.

Reaching this milestone requires implementing and documenting all required FedRAMP security controls for your baseline:

• 156 controls for FedRAMP Low

• 323 controls for FedRAMP Moderate

• 410 controls for FedRAMP High

You'll also complete extensive vulnerability scans, penetration testing, and evidence reviews while producing hundreds of pages of comprehensive documentation.

The ATO package you submit includes all required documents:

1. System Security Plan (SSP)

2. Information Security Policies and Procedures

3. System User Guide

4. Digital Identity Worksheet

5. Privacy Threshold Analysis (PTA)

6. Privacy Impact Assessment (PIA)

7. Rules of Behavior (RoB) for the System

8. Information System Contingency Plan (ISCP)

9. Configuration Management Plan (CMP)

10. Incident Response Plan (IRP)

11. Control Implementation Summary (CIS) Workbook

12. Federal Information Processing Standard (FIPS) 199

13. Separation of Duties Matrix

14. Laws and Regulations

15. Integrated Inventory Workbook

16. Plan of Action and Milestones (POA&M)

17. Continuous Monitoring Strategy

These documents demonstrate your security posture meets federal standards.

Your system and complete package undergo rigorous review, testing, and validation by a Third Party Assessment Organization (3PAO). The 3PAO produces a comprehensive security assessment report that determines whether you meet FedRAMP standards for your respective baseline. After review and acceptance, your federal agency sponsor issues an ATO Letter formally attesting that you've met all FedRAMP requirements and are hereby authorized for government use.

FedRAMP Authorization isn't a one-time achievement. You must maintain it through continuous monitoring, including monthly vulnerability scans, regular security assessments, and ongoing compliance reporting. If your system falls out of compliance or you stop meeting monitoring requirements, your authorization can be revoked and your listing removed from the FedRAMP Marketplace.

The significant benefit is that once you achieve and maintain your FedRAMP Authorized status, your authorization is reusable across all federal agencies. As long as you maintain your security posture, meet continuous monitoring requirements, and conduct regular system assessments, your authorization remains valid for government-wide use, opening doors to substantial federal contracting opportunities.

The Access Control (AC) family ensures that only authorized people can access your systems and data. It covers managing user accounts, enforcing the principle of least privilege, and monitoring who has access. These controls are your first line of defense against both external attackers and insider threats by making sure the right people have the right level of access at the right time.

Security controls are written in a way that's unnecessarily complex and difficult to understand. We took the time to simplify the FedRAMP Moderate security controls so you don't have to. Here's a straightforward list of everything you need to do to implement the AC family:

(Download checklist here)

Access Control Family Implementation Checklist

Policy and Documentation (AC-1)

•  Develop and document access control policy at organization, mission/business process, and/or system levels

•  Create procedures for implementing access control policy and controls

•  Designate an official to manage access control policy and procedures

•  Review and update policy at least every 3 years and after significant events

•  Review and update procedures at least annually and after significant changes

•  Disseminate policy and procedures to relevant personnel

Account Management (AC-2)

•  Define and document allowed and prohibited account types

•  Assign account managers for all systems

•  Establish prerequisites and criteria for group and role membership

•  Document authorized users, group/role memberships, and access privileges

•  Require approvals for account creation requests

•  Implement processes to create, enable, modify, disable, and remove accounts

•  Monitor account usage continuously

•  Notify account managers within 24 hours when accounts are no longer needed

•  Notify relevant personnel within 8 hours when users are terminated or transferred

•  Notify relevant personnel within 8 hours when user access needs change

•  Review accounts for compliance at least annually

•  Establish process for changing shared/group account authenticators when members are removed

•  Align account management with personnel termination/transfer processes

Account Management Enhancements

•  AC-2(1): Implement automated system account management tools

•  AC-2(2): Automatically disable temporary and emergency accounts after 30 days from last use

•  AC-2(3): Disable expired, unassociated, policy-violating accounts within 24 hours; inactive accounts within 90 days

•  AC-2(4): Automatically audit all account creation, modification, enabling, disabling, and removal actions

•  AC-2(5): Require users to log out after defined periods of inactivity

•  AC-2(7): Establish privileged accounts using role-based or attribute-based access schemes

•  AC-2(7): Monitor privileged role assignments and changes

•  AC-2(7): Revoke access when privileged assignments are no longer appropriate

•  AC-2(9): Only allow shared/group accounts with documented business justification

•  AC-2(12): Monitor accounts for atypical usage patterns

•  AC-2(12): Report atypical usage to ISSO and similar security roles

•  AC-2(13): Disable high-risk individual accounts within 1 hour of risk discovery

Access Control Enforcement (AC-3, AC-4, AC-5, AC-6)

•  AC-3: Enforce approved authorizations for logical access to information and system resources

•  AC-4: Control information flow within and between systems per organizational policies

•  AC-5: Identify duties requiring separation and define supporting access authorizations

•  AC-6: Implement least privilege principle for all users and processes

Least Privilege Enhancements

•  AC-6(1): Authorize specific individuals/roles for security function access

•  AC-6(2): Require users with security function access to use non-privileged accounts for non-security tasks

•  AC-6(5): Restrict privileged accounts to designated personnel/roles only

•  AC-6(7): Review all user privileges at least annually and adjust as needed

•  AC-6(9): Log execution of all privileged functions

• AC-6(10): Prevent non-privileged users from executing privileged functions

Session Controls (AC-7, AC-8, AC-11, AC-12)

•  AC-7: Limit invalid logon attempts to maximum 3 consecutive attempts within 15 minutes

•  AC-7: Lock accounts/nodes for minimum 30 minutes or until administrator unlocks after exceeded attempts

•  AC-8: Display system use notification banner before granting access

•  AC-8: Require user acknowledgment of usage conditions before system access

•  AC-8: Configure appropriate notifications for publicly accessible systems

•  AC-11: Initiate device lock after 15 minutes of inactivity

•  AC-11: Require users to initiate device lock when leaving system unattended

•  AC-11(1): Conceal information on locked displays with publicly viewable images

•  AC-12: Automatically terminate user sessions based on defined conditions/events

Remote and Wireless Access (AC-14, AC-17, AC-18)

•  AC-14: Identify and document actions allowed without authentication

•  AC-14: Provide rationale in security plan for unauthenticated actions

•  AC-17: Document usage restrictions and requirements for each remote access type

•  AC-17: Authorize each remote access type before allowing connections

•  AC-17(1): Use automated mechanisms to monitor and control remote access

•  AC-17(2): Implement cryptographic protection for remote access sessions

•  AC-17(3): Route remote access through authorized network access control points

•  AC-17(4): Restrict privileged remote access and document rationale in security plan

•  AC-18: Establish requirements and guidance for each wireless access type

•  AC-18: Authorize wireless access types before allowing connections

•  AC-18(1): Implement authentication and encryption for wireless access

•  AC-18(3): Disable unused wireless networking capabilities before deployment

Mobile Device Management (AC-19)

•  AC-19: Establish configuration and connection requirements for mobile devices

•  AC-19: Define implementation guidance for mobile devices outside controlled areas

• AC-19: Authorize mobile device connections to organizational systems

• AC-19(5): Implement full-device or container-based encryption on mobile devices

External System Controls (AC-20, AC-21, AC-22)

•  AC-20: Establish terms/conditions or identify required controls for external systems

•  AC-20: Allow authorized access from external systems per established trust relationships

•  AC-20: Prohibit use of unauthorized external system types

•  AC-20(1): Verify external system controls or maintain connection agreements

•  AC-20(2): Restrict use of organization-controlled portable storage on external systems

•  AC-21: Enable users to verify sharing partner access authorizations match information restrictions

•  AC-21: Implement mechanisms to assist with information sharing decisions

•  AC-22: Designate individuals authorized to make information publicly accessible

•  AC-22: Train authorized individuals on protecting nonpublic information

•  AC-22: Review content before posting to publicly accessible systems

•  AC-22: Review publicly accessible content at least quarterly and remove nonpublic information

The Awareness and Training (AT) family ensures that all personnel understand their security and privacy responsibilities through regular education and training programs. It covers general security awareness training for all users, specialized role-based training for personnel with security responsibilities, and maintaining records of all training activities. These controls are essential for creating a security-conscious culture and reducing human error, which is one of the leading causes of security incidents.

Security controls are written in a way that's unnecessarily complex and difficult to understand. We took the time to simplify the FedRAMP Moderate security controls so you don't have to. Here's a straightforward list of everything you need to do to implement the AT family:

(Download checklist here)

Awareness & Training Control Family Implementation Checklist

Policy and Documentation (AT-1)

•  Develop and document awareness and training policy at organization, mission/business process, and/or system levels

•  Create procedures for implementing awareness and training policy and controls

•  Designate an official to manage awareness and training policy and procedures

•  Review and update policy at least every 3 years and after organization-defined events

•  Review and update procedures at least annually and after significant changes

•  Disseminate policy and procedures to relevant personnel

Security and Privacy Literacy Training (AT-2)

•  Provide security and privacy literacy training to all system users (managers, senior executives, contractors)

•  Deliver initial training to all new users before granting system access

•  Conduct literacy training at least annually for all users

•  Provide training when required by system changes

•  Provide training following organization-defined significant events

•  Implement organization-defined awareness techniques to increase security and privacy awareness

•  Update literacy training and awareness content at least annually

•  Update training content following organization-defined events

•  Incorporate lessons learned from internal or external security incidents into training

•  Incorporate lessons learned from security breaches into awareness techniques

Literacy Training Enhancements

•  AT-2(2): Provide training on recognizing potential indicators of insider threats

•  AT-2(2): Provide training on reporting potential indicators of insider threats

•  AT-2(3): Provide training on recognizing social engineering attempts

•  AT-2(3): Provide training on recognizing social mining attempts

•  AT-2(3): Provide training on reporting social engineering and social mining incidents

Role-Based Security and Privacy Training (AT-3)

•  Identify all roles and responsibilities requiring specialized security training

•  Develop role-based training content for each identified role

•  Provide role-based training before authorizing access to systems or information

•  Provide role-based training before personnel perform assigned duties

•  Conduct role-based training at least annually for all personnel with defined roles

•  Provide additional training when required by system changes

•  Update role-based training content at least annually

•  Update role-based training following organization-defined events

•  Incorporate lessons learned from security incidents into role-based training

•  Incorporate lessons learned from security breaches into role-based training

Training Records (AT-4)

•  Document all information security training activities

•  Document all privacy training activities

•  Document security and privacy awareness training completion

•  Document role-based security and privacy training completion

•  Monitor training activities to ensure compliance

•  Retain individual training records for at least one (1) year after training completion

•  Establish system for tracking training completion and currency

•  Maintain records accessible for audit and compliance verification

Key Timeframes to Remember

• Policy reviews: Every 3 years minimum

• Procedure reviews: Annually minimum

• Literacy training: Annually for all users

• Role-based training: Annually for all personnel with security roles

• Content updates: Annually minimum

• Training record retention: At least 1 year after completion

The Audit and Accountability control family ensures organizations create, protect, and review detailed records of system activities and user actions. These controls establish what events must be logged, how long records must be kept, who can access audit data, and how often logs must be analyzed for security incidents. The primary purpose is to enable organizations to detect security breaches, investigate incidents after they occur, hold users accountable for their actions, and meet compliance requirements for record retention and system monitoring.

Security controls are written in a way that's unnecessarily complex and difficult to understand. We took the time to simplify the FedRAMP Moderate security controls so you don't have to. Here's a straightforward list of everything you need to do to implement the AU family:

(Download checklist here)

Audit and Accountability Implementation Checklist

Policy and Documentation

• AU-01: Develop, document, and disseminate organization-level, mission/business process-level, and system-level audit and accountability policy

• AU-01: Ensure audit and accountability policy addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance

• AU-01: Verify audit and accountability policy is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines

• AU-01: Document procedures to facilitate implementation of the audit and accountability policy and associated controls

• AU-01: Designate an official to manage the development, documentation, and dissemination of audit and accountability policy and procedures

• AU-01: Review and update audit and accountability policy at least every 3 years or as required by federal or organizational policy changes

• AU-01: Review and update audit and accountability procedures at least every 3 years or as required by federal or organizational policy changes

Event Identification and Logging Configuration

• AU-02: Identify all event types the system is capable of logging for audit functions

• AU-02: Configure logging for successful and unsuccessful account logon events

• AU-02: Configure logging for account management events

• AU-02: Configure logging for object access events

• AU-02: Configure logging for policy change events

• AU-02: Configure logging for privilege function events

• AU-02: Configure logging for process tracking events

• AU-02: Configure logging for system events

• AU-02: For web applications, configure logging for all administrator activity

• AU-02: For web applications, configure logging for authentication checks

• AU-02: For web applications, configure logging for authorization checks

• AU-02: For web applications, configure logging for data deletions

• AU-02: For web applications, configure logging for data access

• AU-02: For web applications, configure logging for data changes

• AU-02: For web applications, configure logging for permission changes

• AU-02: Coordinate event logging function with other organizational entities requiring audit-related information

• AU-02: Specify event types for logging within the system along with frequency or situations requiring logging for each type

• AU-02: Document rationale for why selected event types are adequate to support after-the-fact investigations of incidents

• AU-02: Review and update event types selected for logging at least annually or whenever there is a change in the threat environment

Audit Record Content and Generation

• AU-03: Ensure audit records capture what type of event occurred

• AU-03: Ensure audit records capture when the event occurred

• AU-03: Ensure audit records capture where the event occurred

• AU-03: Ensure audit records capture the source of the event

• AU-03: Ensure audit records capture the outcome of the event

• AU-03: Ensure audit records capture identity of any individuals, subjects, or objects/entities associated with the event

• AU-03(01): Generate audit records containing session, connection, transaction, or activity duration

• AU-03(01): Generate audit records containing number of bytes received and bytes sent for client-server transactions

• AU-03(01): Generate audit records containing additional informational messages to diagnose or identify the event

• AU-03(01): Generate audit records containing characteristics that describe or identify the object or resource being acted upon

• AU-12: Provide audit record generation capability for event types defined in AU-2a on all information system and network components where technically feasible

• AU-12: Allow organization-defined personnel or roles to select event types to be logged by specific system components

• AU-12: Generate audit records for event types defined in AU-2c that include audit record content defined in AU-3

Audit Storage and Capacity Management

• AU-04: Allocate audit log storage capacity to accommodate retention requirements in accordance with AU-11

• AU-11: Retain audit records for at least 90 days

• AU-11: Provide support for on-demand audit review, analysis, and reporting for at least one year

• AU-11: Ensure audit record retention is consistent with records retention policy

• AU-11: Ensure audit record retention supports after-the-fact investigations of incidents

• AU-11: Ensure audit record retention meets regulatory and organizational information retention requirements

Audit Processing Failure Response and Alerts

• AU-05: Alert organization-defined personnel or roles within a real-time or near-real-time period in the event of audit logging process failure

• AU-05: Configure system to overwrite oldest audit records when audit logging failures occur, OR

• AU-05: Configure system to shut down when audit logging failures occur

Audit Review, Analysis, and Reporting

• AU-06: Review and analyze system audit records at least weekly for indications of organization-defined inappropriate or unusual activity

• AU-06: Assess potential impact of inappropriate or unusual activity identified during audit review

• AU-06: Report audit review findings to organization-defined personnel or roles

• AU-06: Adjust level of audit record review, analysis, and reporting when there is a change in risk based on law enforcement information, intelligence information, or other credible sources

• AU-06(01): Integrate audit record review, analysis, and reporting processes using organization-defined automated mechanisms

• AU-06(03): Analyze and correlate audit records across different repositories to gain organization-wide situational awareness

• AU-07: Provide and implement audit record reduction capability that supports on-demand audit record review, analysis, and reporting requirements

• AU-07: Provide and implement audit record reduction capability that supports after-the-fact investigations of incidents

• AU-07: Ensure audit record reduction and report generation capability does not alter original content of audit records

• AU-07: Ensure audit record reduction and report generation capability does not alter time ordering of audit records

• AU-07(01): Provide and implement capability to process audit records for events of interest based on organization-defined fields within audit records

• AU-07(01): Provide and implement capability to sort audit records for events of interest based on organization-defined fields within audit records

• AU-07(01): Provide and implement capability to search audit records for events of interest based on organization-defined fields within audit records

Time Stamp Generation and Synchronization

• AU-08: Use internal system clocks to generate time stamps for audit records

• AU-08: Record time stamps for audit records that meet one second granularity of time measurement

• AU-08: Configure time stamps to use Coordinated Universal Time, have a fixed local time offset from Coordinated Universal Time, or include local time offset as part of the time stamp

Audit Information Protection

• AU-09: Protect audit information from unauthorized access, modification, and deletion

• AU-09: Protect audit logging tools from unauthorized access, modification, and deletion

• AU-09: Alert organization-defined personnel or roles upon detection of unauthorized access to audit information

• AU-09: Alert organization-defined personnel or roles upon detection of unauthorized modification of audit information

• AU-09: Alert organization-defined personnel or roles upon detection of unauthorized deletion of audit information

• AU-09(04): Authorize access to management of audit logging functionality to only an organization-defined subset of privileged users or roles

• AU-09(04): Document and maintain list of privileged users or roles authorized to manage audit logging functionality

Key Timeframes Summary

• Policy Review: At least every 3 years or when federal/organizational policy changes occur

• Event Type Review: At least annually or whenever threat environment changes

• Audit Record Review: At least weekly

• Audit Record Retention: Minimum 90 days with one year of on-demand access capability

• Failure Alerts: Real-time or near-real-time

The Security Assessment and Authorization control family ensures that organizations systematically evaluate security controls, authorize systems to operate based on acceptable risk levels, and continuously monitor those systems for ongoing compliance. These controls establish requirements for conducting regular security assessments using independent assessors, maintaining plans of action and milestones to track remediation efforts, formally authorizing systems through senior officials, and implementing continuous monitoring programs that provide real-time visibility into security posture. The primary purpose is to provide accountability and assurance that security controls are working as intended, risks are understood and accepted at appropriate levels, and security status is continuously validated throughout the system lifecycle.

Security controls are written in a way that's unnecessarily complex and difficult to understand. We took the time to simplify the FedRAMP Moderate security controls so you don't have to. Here's a straightforward list of everything you need to do to implement the CA family:

(Download checklist here)

Security Assessment and Authorization Implementation Checklist

Policy and Documentation

• CA-01: Develop, document, and disseminate organization-level, mission/business process-level, and system-level assessment, authorization, and monitoring policy

• CA-01: Ensure assessment, authorization, and monitoring policy addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance

• CA-01: Verify assessment, authorization, and monitoring policy is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines

• CA-01: Document procedures to facilitate implementation of the assessment, authorization, and monitoring policy and associated controls

• CA-01: Designate an official to manage the development, documentation, and dissemination of assessment, authorization, and monitoring policy and procedures

• CA-01: Review and update assessment, authorization, and monitoring policy at least every 3 years or as required by federal or organizational policy changes

• CA-01: Review and update assessment, authorization, and monitoring procedures at least every 3 years or as required by federal or organizational policy changes

Control Assessment Planning and Execution

• CA-02: Select appropriate assessor or assessment team for the type of assessment to be conducted

• CA-02: Develop control assessment plan that describes controls and control enhancements under assessment

• CA-02: Develop control assessment plan that describes assessment procedures to be used to determine control effectiveness

• CA-02: Develop control assessment plan that describes assessment environment, assessment team, and assessment roles and responsibilities

• CA-02: Ensure control assessment plan is reviewed and approved by authorizing official or designated representative prior to conducting assessment

• CA-02: Assess controls in the system and its environment of operation at least annually

• CA-02: Determine extent to which controls are implemented correctly, operating as intended, and producing desired outcome with respect to security and privacy requirements

• CA-02: Produce control assessment report that documents results of the assessment

• CA-02: Provide results of control assessment to FedRAMP PMO and JAB

• CA-02(01): Employ independent assessors or assessment teams to conduct control assessments

System Interconnections and Information Exchange

• CA-03: Approve and manage exchange of information between the system and other systems using appropriate agreements (interconnection security agreements, information exchange security agreements, memoranda of understanding or agreement, service level agreements, user agreements, nondisclosure agreements, or organization-defined type of agreement)

• CA-03: Document interface characteristics as part of each exchange agreement

• CA-03: Document security and privacy requirements as part of each exchange agreement

• CA-03: Document controls as part of each exchange agreement

• CA-03: Document responsibilities for each system as part of each exchange agreement

• CA-03: Document impact level of information communicated as part of each exchange agreement

• CA-03: Review and update agreements at least annually and on input from FedRAMP

Plan of Action and Milestones

• CA-05: Develop plan of action and milestones for the system to document planned remediation actions to correct weaknesses or deficiencies noted during control assessments

• CA-05: Develop plan of action and milestones to reduce or eliminate known vulnerabilities in the system

• CA-05: Update existing plan of action and milestones at least monthly based on findings from control assessments

• CA-05: Update existing plan of action and milestones at least monthly based on findings from independent audits or reviews

• CA-05: Update existing plan of action and milestones at least monthly based on findings from continuous monitoring activities

Security Authorization

• CA-06: Assign a senior official as the authorizing official for the system

• CA-06: Assign a senior official as the authorizing official for common controls available for inheritance by organizational systems

• CA-06: Ensure authorizing official for the system accepts use of common controls inherited by the system before commencing operations

• CA-06: Ensure authorizing official for the system authorizes the system to operate before commencing operations

• CA-06: Ensure authorizing official for common controls authorizes use of those controls for inheritance by organizational systems

• CA-06: Update authorizations at least every three years or when a significant change occurs

Continuous Monitoring

• CA-07: Develop system-level continuous monitoring strategy in accordance with organization-level continuous monitoring strategy

• CA-07: Establish system-level metrics to be monitored as defined in the applicable FedRAMP and organization-defined continuous monitoring strategy

• CA-07: Establish continuous monitoring for malicious code protection mechanisms

• CA-07: Establish continuous monitoring for log record review

• CA-07: Establish continuous monitoring for account management activities

• CA-07: Establish continuous monitoring for remote access management activities

• CA-07: Establish continuous monitoring for verification of ongoing identification and authentication

• CA-07: Establish continuous monitoring for configuration settings

• CA-07: Establish at least annual assessment frequencies for all other control assessment activities

• CA-07: Conduct ongoing control assessments in accordance with the continuous monitoring strategy

• CA-07: Conduct ongoing monitoring of system and metrics as defined in the applicable FedRAMP and organization-defined continuous monitoring strategy

• CA-07: Perform correlation and analysis of information generated by control assessments and monitoring

• CA-07: Implement response actions to address results of the analysis of control assessment and monitoring information

• CA-07: Report security and privacy status of the system to FedRAMP PMO and JAB in accordance with the applicable FedRAMP and organization-defined continuous monitoring strategy

• CA-07(01): Employ independent assessors or assessment teams to monitor controls in the system on an ongoing basis

Internal System Connections

• CA-09: Authorize internal connections of organization-defined system components or classes of components to the system

• CA-09: Document interface characteristics for each internal connection

• CA-09: Document security and privacy requirements for each internal connection

• CA-09: Document nature of information communicated for each internal connection

• CA-09: Terminate internal system connections after organization-defined conditions

• CA-09: Review at least annually the continued need for each internal connection

Key Timeframes Summary

• Policy Review: At least every 3 years or when federal/organizational policy changes occur

• Control Assessments: At least annually

• System Interconnection Agreement Review: At least annually and on input from FedRAMP

• POA&M Updates: At least monthly

• Authorization Updates: At least every three years or when significant change occurs

• Continuous Monitoring: Continuous for specific activities (malicious code protection, log review, account management, remote access management, identification and authentication verification, configuration settings); at least annually for all other control assessment activities

• Internal Connection Review: At least annually

The Configuration Management control family ensures that organizations establish and maintain secure baseline configurations for systems, control changes to those configurations, and continuously track system components and information throughout their lifecycle. These controls establish requirements for documenting baseline configurations using government-approved security standards, implementing formal change control processes with security representatives involved and both pre- and post-implementation testing, restricting systems to essential functions only, maintaining accurate inventories of all hardware and software components with automated detection of unauthorized items, tracking information locations and user access, and preventing unauthorized changes or installations. The primary purpose is to maintain system integrity and security by ensuring all changes are intentional, analyzed for security impact, properly authorized and documented, verified after implementation, while preventing configuration drift that could introduce vulnerabilities or reduce security posture.

Security controls are written in a way that's unnecessarily complex and difficult to understand. We took the time to simplify the FedRAMP Moderate security controls so you don't have to. Here's a straightforward list of everything you need to do to implement the CM family:

(Download checklist here)

Configuration Management Implementation Checklist

Policy and Documentation

• CM-01: Develop, document, and disseminate organization-level, mission/business process-level, and system-level configuration management policy

• CM-01: Ensure configuration management policy addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance

• CM-01: Verify configuration management policy is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines

• CM-01: Document procedures to facilitate implementation of the configuration management policy and associated controls

• CM-01: Designate an official to manage the development, documentation, and dissemination of configuration management policy and procedures

• CM-01: Review and update configuration management policy at least every 3 years or as required by federal or organizational policy changes

• CM-01: Review and update configuration management procedures at least every 3 years or as required by federal or organizational policy changes

Baseline Configuration Management

• CM-02: Develop, document, and maintain under configuration control a current baseline configuration of the system

• CM-02: Review and update baseline configuration at least annually

• CM-02: Review and update baseline configuration when required due to organization-defined circumstances

• CM-02: Review and update baseline configuration when system components are installed or upgraded

• CM-02(02): Maintain currency, completeness, accuracy, and availability of baseline configuration using organization-defined automated mechanisms

• CM-02(03): Retain at least one previous version of baseline configurations to support rollback

• CM-02(07): Issue organization-defined systems or system components with organization-defined configurations to individuals traveling to locations deemed to be of significant risk

• CM-02(07): Apply organization-defined controls to systems or components when individuals return from travel to high-risk locations

Configuration Change Control

• CM-03: Determine and document types of changes to the system that are configuration-controlled

• CM-03: Review proposed configuration-controlled changes and approve or disapprove with explicit consideration for security and privacy impact analyses

• CM-03: Document configuration change decisions associated with the system

• CM-03: Implement approved configuration-controlled changes to the system

• CM-03: Retain records of configuration-controlled changes for at least 1 year

• CM-03: Monitor and review activities associated with configuration-controlled changes

• CM-03: Coordinate and provide oversight for configuration change control activities through organization-defined configuration change control element

• CM-03: Convene configuration change control element as required by the CCB or for changes identified by the organization

• CM-03(02): Test, validate, and document changes to the system before finalizing implementation

• CM-03(04): Require organization-defined security and privacy representatives to be members of the configuration change control element

Security and Privacy Impact Analysis

• CM-04: Analyze changes to the system to determine potential security and privacy impacts prior to change implementation

• CM-04(02): After system changes, verify that impacted controls are implemented correctly

• CM-04(02): After system changes, verify that impacted controls are operating as intended

• CM-04(02): After system changes, verify that impacted controls are producing desired outcome with regard to meeting security and privacy requirements

Access Restrictions for Change

• CM-05: Define physical and logical access restrictions associated with changes to the system

• CM-05: Document physical and logical access restrictions associated with changes to the system

• CM-05: Approve physical and logical access restrictions associated with changes to the system

• CM-05: Enforce physical and logical access restrictions associated with changes to the system

• CM-05(01): Enforce access restrictions using organization-defined automated mechanisms

• CM-05(01): Automatically generate audit records of the enforcement actions

• CM-05(05): Limit privileges to change system components and system-related information within production or operational environment

• CM-05(05): Review and reevaluate privileges at least annually

Configuration Settings

• CM-06: Establish and document configuration settings for system components that reflect most restrictive mode consistent with operational requirements

• CM-06: Use United States Government Configuration Baseline (USGCB) for the applicable technology

• CM-06: Implement configuration settings

• CM-06: Identify, document, and approve any deviations from established configuration settings for organization-defined system components

• CM-06: Base deviations on organization-defined operational requirements

• CM-06: Monitor and control changes to configuration settings in accordance with organizational policies and procedures

• CM-06(01): Manage configuration settings for organization-defined system components using organization-defined automated mechanisms

• CM-06(01): Apply configuration settings for organization-defined system components using organization-defined automated mechanisms

• CM-06(01): Verify configuration settings for organization-defined system components using organization-defined automated mechanisms

Least Functionality

• CM-07: Configure system to provide only organization-defined mission essential capabilities

• CM-07: Prohibit or restrict use of organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services

• CM-07(01): Review system at least monthly to identify unnecessary and/or nonsecure functions, ports, protocols, software, and services

• CM-07(01): Disable or remove organization-defined functions, ports, protocols, software, and services deemed unnecessary and/or nonsecure

• CM-07(02): Prevent program execution in accordance with organization-defined policies, rules of behavior, and/or access agreements regarding software program usage and restrictions

• CM-07(02): Prevent program execution in accordance with rules authorizing terms and conditions of software program usage

• CM-07(05): Identify organization-defined software programs authorized to execute on the system

• CM-07(05): Employ deny-all, permit-by-exception policy to allow execution of authorized software programs

• CM-07(05): Review and update list of authorized software programs at least annually

System Component Inventory

• CM-08: Develop and document inventory of system components that accurately reflects the system

• CM-08: Ensure inventory includes all components within the system

• CM-08: Ensure inventory does not include duplicate accounting of components or components assigned to any other system

• CM-08: Ensure inventory is at level of granularity deemed necessary for tracking and reporting

• CM-08: Include organization-defined information deemed necessary to achieve effective system component accountability

• CM-08: Review and update system component inventory at least monthly

• CM-08(01): Update inventory of system components as part of component installations, removals, and system updates

• CM-08(03): Detect presence of unauthorized hardware, software, and firmware components using organization-defined automated mechanisms continuously where practical, and at least monthly otherwise

• CM-08(03): Disable network access by unauthorized components when detected

• CM-08(03): Isolate unauthorized components when detected

• CM-08(03): Notify organization-defined personnel or roles when unauthorized components are detected

Configuration Management Plan

• CM-09: Develop configuration management plan that addresses roles, responsibilities, and configuration management processes and procedures

• CM-09: Establish process for identifying configuration items throughout system development life cycle

• CM-09: Establish process for managing configuration of configuration items

• CM-09: Define configuration items for the system

• CM-09: Place configuration items under configuration management

• CM-09: Ensure configuration management plan is reviewed and approved by organization-defined personnel or roles

• CM-09: Protect configuration management plan from unauthorized disclosure and modification

• CM-09: Document configuration management plan

• CM-09: Implement configuration management plan

Software Usage Restrictions

• CM-10: Use software and associated documentation in accordance with contract agreements and copyright laws

• CM-10: Track use of software and associated documentation protected by quantity licenses to control copying and distribution

• CM-10: Control and document use of peer-to-peer file sharing technology

• CM-10: Ensure peer-to-peer file sharing technology is not used for unauthorized distribution, display, performance, or reproduction of copyrighted work

User-Installed Software

• CM-11: Establish organization-defined policies governing installation of software by users

• CM-11: Enforce software installation policies through organization-defined methods

• CM-11: Monitor policy compliance at least monthly

Information Location

• CM-12: Identify and document location of organization-defined information and specific system components on which the information is processed and stored

• CM-12: Identify and document users who have access to system and system components where the information is processed and stored

• CM-12: Document changes to the location (i.e., system or system components) where the information is processed and stored

• CM-12(01): Use automated tools to identify organization-defined information by information type on organization-defined system components

• CM-12(01): Ensure controls are in place to protect organizational information and individual privacy through automated information location tracking

Key Timeframes Summary

• Policy Review: At least every 3 years or when federal/organizational policy changes occur

• Baseline Configuration Review: At least annually, when circumstances require, or when system components are installed or upgraded

• Configuration Change Records Retention: At least 1 year

• System Review for Unnecessary Functions: At least monthly

• Authorized Software List Review: At least annually

• Component Inventory Review: At least monthly

• Unauthorized Component Detection: Continuously where practical, at least monthly otherwise

• Software Installation Policy Compliance Monitoring: At least monthly

• Privilege Review for Changes: At least annually

The Contingency Planning family ensures organizations can maintain or quickly resume critical mission and business operations during and after a disruption, compromise, or failure of their information systems. These controls establish comprehensive planning, testing, and implementation of backup strategies, alternate sites, telecommunications services, and recovery procedures to minimize operational downtime and data loss. The family emphasizes proactive preparation through documented plans, regular training and testing, and establishing redundant infrastructure to support business continuity and disaster recovery objectives aligned with the organization's risk tolerance and operational requirements.

Security controls are written in a way that's unnecessarily complex and difficult to understand. We took the time to simplify the FedRAMP Moderate security controls so you don't have to. Here's a straightforward list of everything you need to do to implement the CP family:

(Download checklist here)

Contingency Planning Implementation Checklist

Policy and Documentation

• CP-1: Develop, document, and disseminate contingency planning policy at organization-level, mission/business process-level, or system-level that addresses purpose, scope, roles, responsibilities, management commitment, coordination, and compliance

• CP-1: Ensure contingency planning policy is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines

• CP-1: Develop and document procedures to facilitate implementation of contingency planning policy and associated controls

• CP-1: Designate an official to manage development, documentation, and dissemination of contingency planning policy and procedures

• CP-1: Review and update contingency planning policy at least every 3 years and following significant changes

• CP-1: Review and update contingency planning procedures at least annually and following significant changes

Contingency Plan Development and Maintenance

• CP-2: Develop a contingency plan that identifies essential mission and business functions and associated contingency requirements

• CP-2: Include recovery objectives, restoration priorities, and metrics in the contingency plan

• CP-2: Document contingency roles, responsibilities, and assigned individuals with contact information

• CP-2: Address maintaining essential mission and business functions despite system disruption, compromise, or failure

• CP-2: Address eventual full system restoration without deterioration of originally planned controls

• CP-2: Address sharing of contingency information in the plan

• CP-2: Obtain review and approval of contingency plan from organization-defined personnel or roles

• CP-2: Distribute copies of contingency plan to key contingency personnel and organizational elements

• CP-2: Coordinate contingency planning activities with incident handling activities

• CP-2: Review the contingency plan for the system at least annually

• CP-2: Update contingency plan to address organizational, system, or environmental changes

• CP-2: Update contingency plan based on problems encountered during implementation, execution, or testing

• CP-2: Communicate contingency plan changes to key contingency personnel and organizational elements

• CP-2: Incorporate lessons learned from testing, training, or actual contingency activities

• CP-2: Protect contingency plan from unauthorized disclosure and modification

• CP-2 (1): Coordinate contingency plan development with organizational elements responsible for related plans

• CP-2 (3): Plan for resumption of all mission and business functions within time period defined in service provider and organization SLA

• CP-2 (8): Identify critical system assets supporting all or essential mission and business functions

Contingency Training

• CP-3: Provide contingency training to system users consistent with assigned roles and responsibilities within ten (10) days of assuming a contingency role

• CP-3: Provide contingency training when required by system changes

• CP-3: Provide contingency training at least annually after initial training

• CP-3: Review and update contingency training content at least annually

• CP-3: Update contingency training content following organization-defined events

Contingency Plan Testing

• CP-4: Test the contingency plan at least annually using functional exercises

• CP-4: Determine effectiveness of the plan through testing

• CP-4: Determine readiness to execute the plan through testing

• CP-4: Review contingency plan test results

• CP-4: Initiate corrective actions based on test results when needed

• CP-4 (1): Coordinate contingency plan testing with organizational elements responsible for related plans

Alternate Storage Site

• CP-6: Establish an alternate storage site with necessary agreements for storage and retrieval of system backup information

• CP-6: Ensure alternate storage site provides controls equivalent to the primary site

• CP-6 (1): Identify an alternate storage site sufficiently separated from primary site to reduce susceptibility to same threats

• CP-6 (3): Identify potential accessibility problems to alternate storage site during area-wide disruption or disaster

• CP-6 (3): Outline explicit mitigation actions for alternate storage site accessibility problems

Alternate Processing Site

• CP-7: Establish an alternate processing site with necessary agreements for transfer and resumption of system operations

• CP-7: Ensure alternate processing site supports essential mission and business functions within defined time period when primary processing is unavailable

• CP-7: Make available required equipment and supplies at alternate processing site or establish contracts for delivery

• CP-7: Provide controls at alternate processing site equivalent to primary site

• CP-7 (1): Identify an alternate processing site sufficiently separated from primary site to reduce susceptibility to same threats

• CP-7 (2): Identify potential accessibility problems to alternate processing site during area-wide disruption or disaster

• CP-7 (2): Outline explicit mitigation actions for alternate processing site accessibility problems

• CP-7 (3): Develop alternate processing site agreements with priority-of-service provisions in accordance with availability requirements and recovery time objectives

Telecommunications Services

• CP-8: Establish alternate telecommunications services with necessary agreements for resumption of system operations

• CP-8: Ensure alternate telecommunications services support essential mission and business functions when primary capabilities are unavailable

• CP-8 (1): Develop primary and alternate telecommunications service agreements with priority-of-service provisions

• CP-8 (1): Request Telecommunications Service Priority for all services used for national security emergency preparedness if provided by common carrier

• CP-8 (2): Obtain alternate telecommunications services to reduce likelihood of sharing single point of failure with primary services

System Backup

• CP-9: Conduct daily incremental and weekly full backups of user-level information in organization-defined system components

• CP-9: Conduct daily incremental and weekly full backups of system-level information

• CP-9: Conduct daily incremental and weekly full backups of system documentation, including security- and privacy-related documentation

• CP-9: Ensure all backup frequencies are consistent with recovery time and recovery point objectives

• CP-9: Protect confidentiality, integrity, and availability of backup information

• CP-9 (1): Test backup information at least annually to verify media reliability and information integrity

• CP-9 (8): Implement cryptographic mechanisms to prevent unauthorized disclosure and modification of all backup files

System Recovery and Reconstitution

• CP-10: Provide for recovery and reconstitution of the system to a known state within organization-defined time period after disruption, compromise, or failure

• CP-10: Ensure recovery time period is consistent with recovery time and recovery point objectives

• CP-10 (2): Implement transaction recovery for systems that are transaction-based

Key Timeframes Summary

• Policy review: At least every 3 years and following significant changes

• Procedure review: At least annually and following significant changes

• Contingency plan review: At least annually

• Contingency training: Within 10 days of assuming role, then at least annually

• Contingency plan testing: At least annually using functional exercises

• Backup frequency: Daily incremental and weekly full backups

• Backup testing: At least annually

• CP-2 (3) resumption timeframe: As defined in service provider and organization SLA

The Identification and Authentication (IA) control family ensures that systems can accurately identify and verify users, devices, and processes before granting access to organizational resources. This family establishes requirements for managing digital identities, authenticators (such as passwords, tokens, and certificates), multi-factor authentication, and identity proofing processes. The controls focus on preventing unauthorized access by ensuring that only verified entities can authenticate to systems and that authentication mechanisms are properly managed, protected, and maintained throughout their lifecycle.

Security controls are written in a way that's unnecessarily complex and difficult to understand. We took the time to simplify the FedRAMP Moderate security controls so you don't have to. Here's a straightforward list of everything you need to do to implement the IA family:

(Download checklist here)

Identification and Authentication Implementation Checklist

Policy and Documentation

•  IA-1: Develop organization-level, mission/business process-level, and system-level identification and authentication policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination, and compliance

•  IA-1: Ensure identification and authentication policy is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines

•  IA-1: Document procedures to facilitate implementation of the identification and authentication policy and associated controls

•  IA-1: Disseminate identification and authentication policy and procedures to organization-defined personnel or roles

•  IA-1: Designate an organization-defined official to manage the development, documentation, and dissemination of the identification and authentication policy and procedures

•  IA-1: Review and update identification and authentication policy at least every 3 years or when a significant change occurs

•  IA-1: Review and update identification and authentication procedures at least annually or when a significant change occurs

User Identification and Authentication

•  IA-2: Implement unique identification for all organizational users

•  IA-2: Implement authentication for all organizational users

•  IA-2: Associate unique user identifications with processes acting on behalf of those users

•  IA-2(1): Implement multi-factor authentication for access to privileged accounts

•  IA-2(2): Implement multi-factor authentication for access to non-privileged accounts

•  IA-2(5): When shared accounts or authenticators are employed, require users to be individually authenticated before granting access to the shared accounts or resources

•  IA-2(6): Implement multi-factor authentication for local access to privileged and non-privileged accounts

•  IA-2(6): Implement multi-factor authentication for network access to privileged and non-privileged accounts

•  IA-2(6): Implement multi-factor authentication for remote access to privileged and non-privileged accounts

•  IA-2(6): Ensure one authentication factor is provided by a device separate from the system gaining access

•  IA-2(6): Ensure the separate authentication device meets FIPS 140-2 validated or NSA-approved cryptography strength requirements

•  IA-2(8): Implement replay-resistant authentication mechanisms for access to privileged accounts

•  IA-2(8): Implement replay-resistant authentication mechanisms for access to non-privileged accounts

•  IA-2(12): Accept and electronically verify Personal Identity Verification (PIV)-compliant credentials

Device Identification and Authentication

•  IA-3: Define devices and/or types of devices that require unique identification and authentication

•  IA-3: Uniquely identify organization-defined devices before establishing local connections

•  IA-3: Uniquely identify organization-defined devices before establishing remote connections

•  IA-3: Uniquely identify organization-defined devices before establishing network connections

•  IA-3: Authenticate organization-defined devices before establishing local connections

•  IA-3: Authenticate organization-defined devices before establishing remote connections

•  IA-3: Authenticate organization-defined devices before establishing network connections

Identifier Management

•  IA-4: Define personnel or roles authorized to assign individual, group, role, service, or device identifiers

•  IA-4: Receive authorization from organization-defined personnel or roles before assigning identifiers

•  IA-4: Select identifiers that uniquely identify individuals, groups, roles, services, or devices

•  IA-4: Assign identifiers to the intended individual, group, role, service, or device

•  IA-4: Prevent reuse of identifiers for at least 2 years

•  IA-4(4): Manage individual identifiers by uniquely identifying each individual according to organization-defined characteristics identifying individual status

Authenticator Management

•  IA-5: Verify the identity of the individual, group, role, service, or device receiving the authenticator as part of initial authenticator distribution

•  IA-5: Establish initial authenticator content for any authenticators issued by the organization

•  IA-5: Ensure that authenticators have sufficient strength of mechanism for their intended use

•  IA-5: Establish administrative procedures for initial authenticator distribution

•  IA-5: Establish administrative procedures for lost, compromised, or damaged authenticators

•  IA-5: Establish administrative procedures for revoking authenticators

•  IA-5: Implement administrative procedures for initial authenticator distribution

•  IA-5: Implement administrative procedures for lost, compromised, or damaged authenticators

•  IA-5: Implement administrative procedures for revoking authenticators

•  IA-5: Change default authenticators prior to first use

•  IA-5: Define time periods for changing or refreshing authenticators by authenticator type

•  IA-5: Define events that trigger authenticator changes or refreshes

•  IA-5: Change or refresh authenticators according to organization-defined time periods by authenticator type or when organization-defined events occur

•  IA-5: Protect authenticator content from unauthorized disclosure

•  IA-5: Protect authenticator content from unauthorized modification

•  IA-5: Require individuals to take specific controls to protect authenticators

•  IA-5: Configure devices to implement specific controls to protect authenticators

•  IA-5: Change authenticators for group or role accounts when membership to those accounts changes

Password-Based Authentication (IA-5(1))

•  IA-5(1): Maintain a list of commonly-used, expected, or compromised passwords

•  IA-5(1): Update the password list at least annually

•  IA-5(1): Update the password list when organizational passwords are suspected to have been compromised directly or indirectly

•  IA-5(1): Verify that passwords are not found on the commonly-used, expected, or compromised password list when users create passwords

•  IA-5(1): Verify that passwords are not found on the commonly-used, expected, or compromised password list when users update passwords

•  IA-5(1): Transmit passwords only over cryptographically-protected channels

•  IA-5(1): Store passwords using an approved salted key derivation function, preferably using a keyed hash

•  IA-5(1): Require immediate selection of a new password upon account recovery

•  IA-5(1): Allow user selection of long passwords and passphrases

•  IA-5(1): Allow users to include spaces in passwords and passphrases

•  IA-5(1): Allow users to include all printable characters in passwords and passphrases

•  IA-5(1): Employ automated tools to assist users in selecting strong password authenticators

•  IA-5(1): Define password composition and complexity rules

•  IA-5(1): Enforce organization-defined password composition and complexity rules

Public Key-Based Authentication (IA-5(2))

•  IA-5(2): Enforce authorized access to the corresponding private key for public key-based authentication

•  IA-5(2): Map the authenticated identity to the account of the individual or group for public key-based authentication

•  IA-5(2): When using PKI, validate certificates by constructing and verifying a certification path to an accepted trust anchor

•  IA-5(2): When using PKI, check certificate status information during certificate validation

•  IA-5(2): When using PKI, implement a local cache of revocation data to support path discovery and validation

Additional Authenticator Controls

•  IA-5(6): Protect authenticators commensurate with the security category of the information to which use of the authenticator permits access

•  IA-5(7): Ensure that unencrypted static authenticators are not embedded in applications

•  IA-5(7): Ensure that unencrypted static authenticators are not embedded in other forms of static storage

Authentication Feedback and Cryptographic Modules

•  IA-6: Obscure feedback of authentication information during the authentication process to protect from exploitation

•  IA-6: Obscure feedback of authentication information during the authentication process to protect from use by unauthorized individuals

•  IA-7: Implement mechanisms for authentication to cryptographic modules that meet the requirements of applicable laws

•  IA-7: Implement mechanisms for authentication to cryptographic modules that meet the requirements of applicable executive orders, directives, policies, regulations, standards, and guidelines

Non-Organizational User Authentication

•  IA-8: Uniquely identify non-organizational users

•  IA-8: Authenticate non-organizational users

•  IA-8: Uniquely identify processes acting on behalf of non-organizational users

•  IA-8: Authenticate processes acting on behalf of non-organizational users

•  IA-8(1): Accept Personal Identity Verification (PIV)-compliant credentials from other federal agencies

•  IA-8(1): Electronically verify Personal Identity Verification (PIV)-compliant credentials from other federal agencies

•  IA-8(2): Accept only external authenticators that are NIST-compliant

•  IA-8(2): Document a list of accepted external authenticators

•  IA-8(2): Maintain a list of accepted external authenticators

•  IA-8(4): Define identity management profiles for identity management

•  IA-8(4): Conform to organization-defined identity management profiles for identity management

Re-Authentication Requirements

•  IA-11: Define circumstances or situations that require user re-authentication

•  IA-11: Require users to re-authenticate when organization-defined circumstances or situations occur

Identity Proofing

•  IA-12: Identity proof users that require accounts for logical access to systems based on appropriate identity assurance level requirements as specified in applicable standards and guidelines

•  IA-12: Resolve user identities to a unique individual

•  IA-12: Collect identity evidence

•  IA-12: Validate identity evidence

•  IA-12: Verify identity evidence

•  IA-12(2): Require evidence of individual identification be presented to the registration authority

•  IA-12(3): Define methods of validation and verification for presented identity evidence

•  IA-12(3): Require that presented identity evidence be validated through organization-defined methods

•  IA-12(3): Require that presented identity evidence be verified through organization-defined methods

•  IA-12(5): Deliver registration code or notice of proofing through an out-of-band channel to verify the user's address of record

•  IA-12(5): Support verification of physical addresses of record through out-of-band delivery

•  IA-12(5): Support verification of digital addresses of record through out-of-band delivery

Key Timeframes Summary

• Policy review: At least every 3 years or when significant changes occur

• Procedure review: At least annually or when significant changes occur

• Password list updates: At least annually and when compromise is suspected

• Identifier reuse prevention: At least 2 years

• Authenticator changes: Organization-defined by authenticator type

The Incident Response (IR) control family establishes the policies, procedures, and capabilities necessary to prepare for, detect, respond to, and recover from security incidents. These controls ensure organizations can effectively handle security events through a structured approach that includes incident prevention, detection and analysis, containment, eradication, and recovery. The family emphasizes the importance of maintaining trained incident response personnel, conducting regular testing, implementing automated incident management tools, and reporting incidents to appropriate authorities in accordance with federal guidelines. By implementing these controls, organizations create a consistent, predictable, and effective incident response capability that minimizes the impact of security incidents and supports continuous improvement through lessons learned.

Security controls are written in a way that's unnecessarily complex and difficult to understand. We took the time to simplify the FedRAMP Moderate security controls so you don't have to. Here's a straightforward list of everything you need to do to implement the IR family:

(Download checklist here)

Incident Response Implementation Checklist

Policy and Documentation

•  IR-1: Develop organization-wide incident response policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance

•  IR-1: Ensure incident response policy is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines

•  IR-1: Document procedures to facilitate implementation of the incident response policy and associated controls

•  IR-1: Disseminate incident response policy and procedures to organization-defined personnel or roles

•  IR-1: Designate the ISSO or equivalent to manage the development, documentation, and dissemination of the incident response policy and procedures

•  IR-1: Review and update incident response policy at least every 3 years or when changes occur

•  IR-1: Review and update incident response procedures at least annually or when changes occur

•  IR-8: Develop an incident response plan that provides the organization with a roadmap for implementing its incident response capability

•  IR-8: Describe the structure and organization of the incident response capability in the plan

•  IR-8: Provide a high-level approach for how the incident response capability fits into the overall organization

•  IR-8: Ensure the incident response plan meets the unique requirements of the organization related to mission, size, structure, and functions

•  IR-8: Define reportable incidents in the incident response plan

•  IR-8: Provide metrics for measuring the incident response capability within the organization

•  IR-8: Define the resources and management support needed to effectively maintain and mature an incident response capability

•  IR-8: Address the sharing of incident information in the incident response plan

•  IR-8: Have the incident response plan reviewed and approved by the ISSO or equivalent at least every 3 years or when changes occur

•  IR-8: Explicitly designate responsibility for incident response to the ISSO or equivalent

•  IR-8: Distribute copies of the incident response plan to the incident response team and those with incident response roles and responsibilities

•  IR-8: Update the incident response plan to address system and organizational changes or problems encountered during plan implementation, execution, or testing

•  IR-8: Communicate incident response plan changes to the incident response team and those with incident response roles and responsibilities

•  IR-8: Protect the incident response plan from unauthorized disclosure and modification

Training and Testing

•  IR-2: Provide incident response training to system users consistent with assigned roles and responsibilities within 10 days of assuming an incident response role or responsibility or acquiring system access

•  IR-2: Provide incident response training when required by system changes

•  IR-2: Provide incident response training at least annually to personnel with incident response roles and responsibilities

•  IR-2: Review and update incident response training content at least annually or when changes occur

•  IR-3: Test the effectiveness of the incident response capability for the system at least annually using test scenarios based on current threat information

•  IR-3(2): Coordinate incident response testing with organizational elements responsible for related plans

Incident Handling and Response

•  IR-4: Implement an incident handling capability for incidents that is consistent with the incident response plan and includes preparation, detection and analysis, containment, eradication, and recovery

•  IR-4: Coordinate incident handling activities with contingency planning activities

•  IR-4: Incorporate lessons learned from ongoing incident handling activities into incident response procedures, training, and testing, and implement the resulting changes accordingly

•  IR-4: Ensure the rigor, intensity, scope, and results of incident handling activities are comparable and predictable across the organization

•  IR-4(1): Support the incident handling process using an online incident management system

•  IR-5: Track and document incidents

•  IR-7: Provide an incident response support resource, integral to the organizational incident response capability, that offers advice and assistance to users of the system for the handling and reporting of incidents

•  IR-7(1): Increase the availability of incident response information and support using automated mechanisms for real-time support

Incident Reporting

•  IR-6: Require personnel to report suspected incidents to the organizational incident response capability within US-CERT incident reporting timelines as specified in the US-CERT Federal Incident Notification Guidelines

•  IR-6: Report incident information to US-CERT and other organization-defined personnel or roles

•  IR-6(1): Report incidents using automated mechanisms supporting reporting of incidents

•  IR-6(3): Provide incident information to the provider of the product or service and other organizations involved in the supply chain or supply chain governance for systems or system components related to the incident

Key Timeframes Summary

• Policy review: At least every 3 years or when changes occur

• Procedure review: At least annually or when changes occur

• Training: Within 10 days of role assumption, then at least annually

• Testing: At least annually

• Incident reporting: Per US-CERT Federal Incident Notification Guidelines