Continuous monitoring under FedRAMP 20x: Replacing annual assessments with persistent validation

Under legacy Federal Risk and Authorization Management Program (FedRAMP) Rev5, continuous monitoring meant monthly deliverables and annual assessments. Under FedRAMP 20x, it means persistent, automated validation where the status of your security posture is always known. In this post, we operationalize that model using AWS Security Hub, AWS Config conformance packs, Amazon GuardDuty, Amazon Inspector, and Sigma detection rules to build an always-on monitoring architecture.

From annual assessments to persistent validation

FedRAMP 20x defines persistently as “occurring in a firm, steady way that is repeated over a long period of time.” It requires that organizations routinely validate and assess the effectiveness of their security decisions. The FedRAMP Rules (FRR) family CCM (Collaborative Continuous Monitoring) requires maintaining a plan for Ongoing Certification Reports (OCRs) and Quarterly Reviews.

The practical implication is that your monitoring infrastructure must produce evidence continuously, not in response to an annual audit. On Amazon Web Services (AWS), this means combining multiple services into a layered architecture where each layer addresses different key security indicators (KSIs) and different time horizons.

Persistent validation architecture

The persistent validation architecture consists of four complementary layers, each addressing a different aspect of continuous security monitoring. Together, these layers enable validation of every KSI through automated, repeatable processes that produce machine-readable evidence without manual intervention.

Layer 1: Configuration compliance

AWS Config conformance packs provide the foundation for persistent configuration validation. The project includes two conformance packs (low and moderate) with 128 rules each, covering up to 46 KSIs, the full set defined in the current FedRAMP 20x Consolidated Rules. These rules evaluate resource configurations continuously and report compliance status to Security Hub.

The following table outlines the key AWS Config rules mapped to KSIs.

When AWS Config detects drift from the desired state, it generates a NON_COMPLIANT finding that flows to Security Hub and triggers the evidence pipeline described in Building machine-readable FedRAMP 20x evidence on AWS.

Layer 2: Threat detection

GuardDuty provides intelligent threat detection by analyzing CloudTrail management events, Amazon Virtual Private Cloud (Amazon VPC) flow logs, and DNS query logs. GuardDuty findings map to several KSIs:

• KSI-IAM-SUS (Responding to Suspicious Activity) – GuardDuty detects compromised credentials, unusual API calls, and unauthorized access patterns.
• KSI-CNA-MAT (Minimizing Attack Surface) – GuardDuty identifies unexpected network connections and potential data exfiltration.
• KSI-MLA-RVL (Reviewing Logs) – GuardDuty machine learning (ML) models persistently review log data for anomalies.

GuardDuty findings with severity HIGH or CRITICAL trigger the incident communications pipeline, initiating the 1-hour notification workflow to FedRAMP and agency customers.

Layer 3: Vulnerability management

Amazon Inspector provides continuous vulnerability scanning for Amazon Elastic Compute Cloud (Amazon EC2) instances, container images in Amazon Elastic Container Registry (Amazon ECR), and AWS Lambda functions.

Under the FRR family Vulnerability Detection and Response (VDR), Amazon Inspector findings feed into the VDR pipeline with:

• Scanning every 3 days for Class C systems (according to VDR-TFR-PSD)
• Drift detection every 14 days (according to VDR-TFR-PDD)
• Cross-reference against the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) catalog (according to VDR-TFR-KEV)
• Severity-based remediation timelines using Potential Agency Impact (PAIN) N-ratings, from N1 (minimal customer effect) through N5 (debilitating customer effect on more than one federal agency)

Layer 4: Real-time detection

Sigma is an open standard for writing detection rules that can be translated to multiple security information and event management (SIEM) platforms. The project includes 64 Sigma detection rules mapped across all KSI themes. These rules monitor CloudTrail events, VPC flow logs, and Amazon CloudWatch metrics for real-time indicators of KSI violations.

The following table lists some example Sigma rules.

Sigma rules translate to CloudWatch Logs Insights queries or Amazon OpenSearch Service detection rules, providing near real-time alerting on KSI-relevant events.

The following figure shows the continuous monitoring architecture with these four layers.

Figure 1: Continuous monitoring architecture for FedRAMP 20x

Deploying Sigma rules on AWS

Sigma rules are written in a vendor-neutral YAML format and must be translated to the target platform’s query language. For AWS environments, the two primary deployment targets are:

• CloudWatch Logs Insights – Sigma rules translate to Logs Insights queries that run on scheduled intervals against CloudTrail log groups. This approach requires no additional infrastructure and integrates with CloudWatch alarms for alerting.
• Amazon OpenSearch Service – For organizations operating a centralized SIEM, Sigma rules translate to OpenSearch Service detection rules that evaluate events in near real time while they’re ingested.

The project includes 64 Sigma rules organized by KSI theme. Each rule includes metadata documenting the KSI mapping, the detection logic, and the expected alert behavior. When a Sigma rule fires, the resulting alert flows to Security Hub through a custom integration, joining the same aggregation pipeline as AWS Config and GuardDuty findings.

Security Hub as the aggregation point

Security Hub serves as the central aggregation point for all four layers. Findings from AWS Config, GuardDuty, Amazon Inspector, and custom integrations flow into Security Hub in the AWS Security Finding Format (ASFF). This provides the following:

• A single pane of glass for compliance status across all KSIs
• Cross-account and cross-Region aggregation for multi-account environments
• Automated workflows through Amazon EventBridge integration
• Compliance scoring against security standards

Security Hub integration with EventBridge enables automated responses: when a finding meets specific criteria (such as severity, KSI mapping, or resource type), EventBridge routes it to the appropriate pipeline, whether that is the VDR tracker, the incident communications workflow, or the evidence collection pipeline.

Automated dashboards and reporting

The FedRAMP 20x requirement that organizations persistently validate and assess the effectiveness of their security decisions translates to dashboards that display real-time compliance status and automated reports that document compliance over time. To meet this requirement, the architecture uses CloudWatch dashboards for real-time visibility into control health across all four validation layers, combined with automated report generation pipelines that produce quarterly OCRs. Together, these components provide both cloud service providers and authorizing officials with continuous access to current compliance posture without manual data collection or spreadsheet-based tracking.

CloudWatch dashboards display:

• KSI compliance scores aggregated from AWS Config conformance pack results
• Active GuardDuty findings by severity
• Open vulnerabilities by N-rating and remediation deadline
• Evidence pipeline execution status and last-run timestamps

The FRR family Collaborative Continuous Monitoring (CCM) requires quarterly OCRs covering:

• Changes to authorization data since the last report
• Planned changes for the next 3 months
• Accepted vulnerabilities and their justifications
• Transformative changes and their notification status
• Updated security recommendations

The OCR generation pipeline runs quarterly using AWS Step Functions, pulling data from the evidence lake and producing both human-readable and machine-readable reports. The next OCR date is published publicly on the trust center (per CCM-OCR-NRD).

Significant change notification automation

The FRR family Significant Change Notification (SCN) requires classifying and notifying stakeholders about significant changes. The SCN automation pipeline monitors AWS CloudFormation stack events, AWS Config changes, and AWS CodePipeline deployments through EventBridge rules. A classification Lambda function categorizes each change:

• Routine or recurring (such as patching, scaling, and token refresh) – No notification required
• Adaptive (such as configuration changes and minor feature updates) – Notify within 10 business days after completion
• Transformative (such as architecture changes and new service integrations) – Notice of initial plans at least 30 business days before starting (SCN-TRF-NIP), a final update at least 10 business days before starting (SCN-TRF-NFP), a completion notice within 5 business days after finishing (SCN-TRF-NAF), a verification notice within 5 business days after completing verification and validation (SCN-TRF-NAV), and updated service documentation published within 30 business days after finishing (SCN-TRF-UPD)

All change evaluations are logged with 12-month retention (per SCN-CSO-HIS, Historical Notifications), creating an audit trail that also satisfies the audit-record requirement in SCN-CSO-MAR (Maintain Audit Records).

How this replaces traditional continuous monitoring

Under Rev5, continuous monitoring required monthly Plan of Action and Milestones (POA&M) updates, monthly vulnerability scan reports, annual assessments by a third-party assessment organization (3PAO), and significant change requests requiring advance approval. The following table outlines how these are replaced under FedRAMP 20x.

The shift is from periodic human-driven processes to continuous automated systems that produce evidence as a byproduct of normal operations.

What comes next

With the full compliance lifecycle in place, from preventive controls through continuous monitoring, the final post in this series looks ahead. In that post, we capture lessons from the Phase 2 pilot, translate them into preparation guidance for Phase 3 wide-scale adoption, and provide a concrete action plan for organizations that want to start today.

Further reading

• FedRAMP 20x Phase 2 requirements – Completeness requirements for persistent validation
• Prepare for FedRAMP 20x with AWS automation and validation
• Deep dive into FedRAMP 20x Key Security Indicators: Decoding the 63 KSIs
• A governance framework for building trustworthy agentic AI for public sector and regulated organizations
• Preventive controls for FedRAMP 20x: Using SCPs and guardrails to enforce KSIs
• Validating infrastructure as code against FedRAMP 20x: Shift-left compliance
• Building machine-readable FedRAMP 20x evidence on AWS