Continuous Compliance Is Not the Same as Periodic Compliance

AWS-Native Security Operations Series | Part 4 of 6

How AWS Config, conformance packs, InfusionPoints Command Center, and ConMon-as-a-Service replace point-in-time audits with an always-on compliance and security operations posture.

By Alex Erhardt, Associate, InfusionPoints

---

Most compliance programs are built around a moment in time. The assessment window. The deliverable date. The authorization package submission. Everything the organization does is aimed at demonstrating compliance during that window.

The problem is that federal systems do not operate in windows. They operate continuously. Configurations drift. Patches fall behind. New resources get deployed without following the approved hardening baseline. Access rights accumulate. The environment that looked compliant during the assessment may look very different three months later, and nobody knows because nobody is looking between assessment cycles.

That gap is what Operate and Prove, two stages of the InfusionPoints Continuous Trust Platform engine, are designed to close. Operate keeps the running environment aligned to its documented baseline as changes occur. Prove turns that operating state into continuous, automated evidence that controls are working as designed. Together, they move compliance from a periodic proof exercise to a continuously managed operating state.

The distinction matters because continuous compliance is not simply faster evidence collection. It changes the operating model. Instead of preparing for an assessment, teams manage compliance as part of daily operations: configuration changes are evaluated as they happen, exceptions become tickets, remediation is tracked against SLAs, and evidence is generated continuously. AWS native services provide the telemetry and automation layer that makes that model practical.

AWS Config: the configuration compliance engine

AWS Config continuously records the configuration state of AWS resources and evaluates that state against rules. Every time a resource changes, Config captures the new state and re-evaluates it against every applicable rule. Noncompliant findings surface immediately, not at the next scheduled scan.

For ConMon customers, Config is the foundational compliance monitoring layer. It answers the question assessors and agencies care about most: is the environment configured the way the SSP says it is configured, right now?

Our ConMon delivery uses Config in two complementary modes:

Conformance packs tied to compliance frameworks. We deploy Config conformance packs mapped to NIST 800-53, FedRAMP Moderate, FedRAMP High, and CMMC control families. These packs evaluate the environment against the controls that matter for each customer’s authorization baseline. When a Config rule fires a noncompliant finding, it surfaces in InfusionPoints Command Center within minutes and triggers our ConMon workflow.

Custom Config rules beyond the conformance packs. Standard conformance packs cover framework baselines, but federal customers frequently have agency-specific requirements, organizational policies, or SSP commitments that the standard packs do not cover. We build and maintain custom Config rules for those requirements as part of ConMon delivery, ensuring compliance coverage matches the actual authorization scope, not just the published framework.

The ConMon workflow: from finding to closed ticket

Config findings do not live in isolation. They flow into a workflow that turns compliance data into operational action.

1. A Config rule evaluates a resource change and generates a noncompliant finding.
2. The finding surfaces in InfusionPoints Command Center, normalized against the customer’s compliance and security operations context alongside findings from GuardDuty, Inspector, Macie, and IAM Access Analyzer.
3. Command Center aggregates the finding into the customer’s compliance posture view and triggers an event that flows into our ConMon pipeline.
4. Command Center generates a POA&M entry with the affected resource, applicable control, finding detail, and remediation timeline.
5. A vulnerability ticket is automatically opened and assigned to the responsible engineer with the SLA clock running.
6. When the engineer remediates and Config re-evaluates the resource as compliant, the ticket closes and the POA&M updates automatically.

That workflow replaces what used to be a manual process: analyst reviews scan output, manually creates a POA&M entry, sends it to an engineer, follows up, and updates the POA&M on remediation. In a large environment with hundreds of monthly findings, the manual version consumes significant analyst time and introduces errors. The automated version runs continuously and produces a complete, auditable record.

The organizations that treat compliance as a quarterly exercise spend budget proving they were secure three months ago. The ones that treat it as a continuous operating state know whether they are secure right now. Those are fundamentally different programs.

ConMon without a SOC: the gap nobody talks about

Having a ConMon program and having a 24x7 SOC are not the same thing. Confusing the two is one of the most expensive mistakes in federal security.

ConMon tells you what is misconfigured, what is unpatched, and what has drifted from the approved authorization baseline. It answers the compliance question: does this environment still match the documented control expectations? That is valuable, but by itself it does not provide real-time threat detection or response.

A 24x7 SOC answers a different question: is something happening in this environment right now?

An organization with ConMon and no SOC knows their patch status and their open POA&M items. They do not know if an adversary is moving laterally through their environment at this moment. They will not know until the next scan cycle, or until the breach surfaces in a way they cannot ignore.

The organizations most likely to have a security event they do not know about are the ones relying on ConMon alone. Periodic evaluation, by definition, has windows. For a patient adversary, those windows are opportunity.

CR26 and the collapsing boundary between ConMon and security operations

FedRAMP’s Consolidated Rules for 2026 (CR26), published in June 2026, changed the scope of what continuous monitoring means for FedRAMP-authorized CSPs. The new VDR framework explicitly expanded vulnerability detection to include verifying that documented controls are operating as intended. An out-of-date control record in the Security Decision Record is itself a vulnerability under the new framework.

That language collapses the traditional boundary between vulnerability management and operational security monitoring. They have the same function now. Organizations running ConMon and security operations as separate programs, managed by separate teams, with separate reporting cadences, are out of alignment with what the framework now requires.

The December 7, 2026 deadline for VDR/VER compliance is not just a documentation requirement. It is an operational requirement. Every FedRAMP-authorized CSP needs a ConMon program that is integrated with their security operations, not running beside it.

That integration is the design principle behind the Continuous Trust Platform. The Build stage creates the compliant foundation on XBU40. Operate keeps it running in alignment with its documentation. Prove generates the evidence through Command Center and AuditShield. Defend, through VNSOC360°, closes the loop back to Build and Operate when something surfaces that requires a response. The architecture described in this series is how each stage works in practice.

DoW cATO, FedRAMP 20x, and why continuous operations now matter

FedRAMP 20x reinforces the same operating reality this article has been building toward: authorization can no longer be treated as a static package assembled for a point-in-time review. FedRAMP describes 20x as a different model for cloud assurance, one that moves beyond traditional compliance and focuses on the security decisions that matter most, supported by transparency, flexibility, automation-ready evidence, and continuous measurement of security effectiveness.

That shift is also why DoW cATO belongs in the same conversation. DoW cATO is not just a faster ATO. It is an operating model built on continuous monitoring, active cyber defense, secure software delivery, and decision-ready risk visibility. The authorization decision no longer lives only in a package. It lives in the running environment, where security posture, control effectiveness, vulnerability status, configuration drift, risk acceptance, remediation activity, and mission impact can be continuously monitored, continuously evidenced, and continuously available to the Authorizing Official.

This matters because mission systems are changing faster than legacy authorization cycles can evaluate them. Cloud services deploy new capabilities, patch vulnerabilities, rotate infrastructure, adjust access, and respond to threats continuously. If authorization only reflects the last assessment window, the agency or mission owner is making risk decisions from stale information. FedRAMP 20x and DoW cATO move the decision point closer to the operating environment, where the real risk actually lives.

For CSPs, software factories, and defense mission owners, the implication is clear: the evidence pipeline becomes part of the product. Configuration state, vulnerability findings, remediation timelines, POA&M updates, incident notifications, logging, identity controls, software supply chain signals, and change activity must be produced from the running system with enough fidelity to support ongoing authorization decisions. Manual evidence collection, delayed scan cycles, and disconnected compliance workflows will not scale in a FedRAMP 20x or DoW cATO operating model.

This is why the Continuous Trust Platform matters. XBU40 provides the secure AWS foundation. Operate keeps the environment aligned to the authorized baseline. Prove turns live operational state into audit-ready evidence through Command Center and AuditShield. Defend closes the loop through VNSOC360° when threats, vulnerabilities, or control failures require response. Together, those capabilities support the operational discipline that FedRAMP 20x and DoW cATO demand: secure cloud environments that can be built, operated, proven, and defended continuously.

FedRAMP 20x and DoW cATO do not lower the bar for federal and defense cloud security. They raise the expectation that security evidence must be current, operational, mission-aware, and decision-ready at all times.

References

• FedRAMP 20x
• FedRAMP Consolidated Rules for 2026
• Using the FedRAMP Consolidated Rules
• FedRAMP Vulnerability Detection and Response
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk
• Continuous Authorization Implementation Guide
• Continuous Authorization to Operate (cATO) Evaluation Criteria

Next in the series: Part 5: Command Center: The Platform Where the Full Security Lifecycle Comes Together.