A CMS audit checklist matters most in the weeks before a review, when an Enhanced Direct Enrollment or State-Based Exchange entity discovers whether the evidence a reviewer expects is staged or scattered. Reviewers tend to ask for the same core items first, so knowing what those are, and having them ready, is the difference between an audit that confirms your program and one that surfaces gaps under time pressure. This checklist sets out the documentation, security evidence, and submission items that EDE and SBE entities should have ready, and points to the deeper guidance for each.
The reason to prepare against a checklist rather than react to an audit is that these reviews are recurring and scheduled, not surprises. An EDE entity’s Operational Readiness Review and the ongoing obligations that follow it run on a known cadence, so the evidence is either maintained continuously or assembled in a scramble. The entities that fare well treat the checklist as a standing state to maintain rather than a task to complete once.
Who Faces a CMS Audit
Two kinds of entity are the focus here. Enhanced Direct Enrollment entities are the web-brokers and issuers that integrate directly with the federal Exchange through its API suite to enroll consumers in marketplace coverage, and they undergo an Operational Readiness Review before they are authorized and remain subject to ongoing oversight afterward. State-Based Exchanges are the marketplaces that states operate themselves, and they carry their own CMS oversight and reporting obligations. Both handle consumer personally identifiable information at scale, which is why CMS holds them to privacy and security requirements and verifies compliance through audit.
The common thread is that these audits test whether an entity protects consumer information the way the requirements demand, and whether it can prove it. Elevate’s CMS EDE services support entities through readiness and audit, and the guide to an upstream EDE entity’s high-level privacy and security obligations covers the obligations these audits verify. The checklist below is what those obligations look like as a set of items to have ready.
The CMS Audit Checklist
The items reviewers look for fall into four categories, and the table maps each to what to have ready and why it draws attention first. It is a starting map rather than the full, entity-specific requirement set, which depends on your role and scope.
| Category | What to have ready | Why reviewers look here first |
|---|---|---|
| Documentation | System Security Plan, policies and procedures, data flow and PII mapping | It defines your scope and how consumer PII is handled |
| Security evidence | Control implementation evidence, penetration test results, vulnerability scans | It shows controls actually operate, not just exist on paper |
| Continuous monitoring | Ongoing monitoring records and periodic evidence | It shows the program is sustained between audits, not revived for them |
| Submission items | Required attestations and submissions by their deadlines | It determines authorization status and timing |
The pattern across these categories is that documentation defines the program, security evidence proves it operates, continuous monitoring proves it persists, and submissions record it with CMS on time. A reviewer who finds strong documentation but no evidence of operation, or evidence that stops after the last audit, has found the gap that most often causes trouble. Preparing each category to stand on its own, rather than leaning on the documentation alone, is what makes a review straightforward.
Documentation to Have Ready
The documentation layer establishes what your system is, how it handles consumer information, and what controls govern it, and it is where a reviewer orients before anything else. The core artifacts are a current System Security Plan that describes the system and its controls, the policies and procedures that govern how the entity operates, and a data flow and PII mapping that shows where consumer information enters, moves, and rests. That mapping is worth particular attention, because a reviewer uses it to understand scope, and gaps in it undermine everything built on top.
The practical test for this layer is whether the documentation matches reality. Documentation that describes controls the entity does not actually run, or omits data flows that exist, creates findings even when the underlying security is sound. The guide to data flow and PII mapping for EDE issuers covers how to build that mapping so it holds up under review.
Security Evidence Reviewers Ask For
Where documentation describes controls, security evidence proves they operate, and this is the layer entities most often underprepare. Reviewers look for evidence that the controls in the System Security Plan are actually implemented and working: results from penetration testing, vulnerability scans and the remediation that followed them, records showing access is controlled and reviewed, and evidence that incidents would be detected and handled. The principle is that a control described but not evidenced is treated as a control not operating.
Building this evidence is not a task to start when an audit is scheduled, because much of it, particularly the record of controls operating over time, cannot be created retroactively. The guide to building controls and evidence for successful CMS audits covers how to stand up that evidence base, and continuous monitoring with quarterly evidence covers how to keep it current between reviews so it is always ready.
Submission Items and Deadlines
The submission layer is where preparation meets the calendar. CMS audits and the obligations around them come with required attestations and submissions that must arrive by specific deadlines, and missing a window can affect authorization regardless of how strong the underlying program is. Knowing what is due and when, and staging the materials in advance, is as much a part of readiness as the security work itself.
Because the deadlines and submission windows are date-specific and change year to year, they are best tracked against a current calendar rather than memory. The CMS audit timeline lays out key deadlines and response timeframes. When a review does surface issues, they are documented and tracked to closure, and the guide to CMS audit reporting, deficiencies, and plans of action and milestones covers how deficiencies and their remediation are handled.
How EDE and SBE Audits Differ
While EDE and SBE entities face similar privacy and security expectations, the audit context differs. For an EDE entity, the review is tied to gaining and keeping authorization to integrate with the federal Exchange, centered on the Operational Readiness Review and the ongoing obligations that follow. For a State-Based Exchange, the oversight comes through the entity’s own relationship with CMS as the operator of a marketplace, with its own reporting obligations. The substance of what is protected, consumer information handled under CMS requirements, is largely shared, but the trigger, cadence, and specific submissions vary by role.
The practical implication is that the checklist categories above apply broadly, but the precise requirements, deadlines, and submission items depend on which kind of entity you are and the specifics of your role. Confirming your exact obligations against your current authorization and CMS guidance, rather than a general checklist, is the necessary final step, and it is where working with an advisor experienced in these reviews removes the guesswork.
The Gaps Reviewers Flag Most
A CMS audit checklist is most valuable when it anticipates the findings that recur, because the same gaps surface across entities, and each one maps to a failure mode of a checklist category. The table below sets out the findings reviewers name most often, the category each belongs to, and how it typically shows up.
| Common finding | Checklist category | How it shows up |
|---|---|---|
| Documentation does not match the system | Documentation | An SSP or policy describes controls the entity does not run, or a data flow omits a real path |
| Control exists but operation is not evidenced | Security evidence | A policy requires access reviews, but there is no record they actually happened |
| Remediation is not shown | Security evidence | A penetration test exists, but no evidence its findings were fixed |
| Monitoring lapsed between audits | Continuous monitoring | The evidence trail is strong up to the last review, then goes quiet |
| Submission missed or late | Submission items | A required attestation arrives after its deadline, affecting standing |
The table shows that almost every recurring finding is a currency or consistency problem rather than an absence of capability, which is why they are so avoidable. In documentation, the recurring finding is a System Security Plan or policy set that describes controls the entity does not actually run, or a data flow that omits a path consumer information really takes; the documentation is complete but does not match reality, and a reviewer who cross-checks it against the system finds the discrepancy quickly. This is why the documentation layer is judged against practice, not on its own.
In security evidence, the most common finding is evidence that a control exists but not that it operates, or evidence that stops after the previous review. An entity can show a policy requiring access reviews yet produce no record that the reviews actually happened, or show a penetration test from long ago with no evidence the findings were remediated. Because a control that cannot be evidenced as operating is treated as not operating, these gaps become findings even where the underlying security is real, which is the single most avoidable category of trouble.
Continuous monitoring produces its own recurring finding: a program that was strong at the last review but went quiet afterward, so the evidence trail has a gap between audits. Submissions add a purely procedural but consequential finding, a missed or late attestation that affects standing regardless of the security behind it. The through-line across all four is that reviewers are testing not just whether an entity built a compliant program once, but whether it is running one now, and the gaps that recur are almost always lapses in currency rather than absences of capability. An entity that treats each checklist category as a living state, and that documents deficiencies and their remediation through CMS audit reporting and plans of action and milestones when they do arise, closes these gaps before a reviewer has to name them.
Conclusion
A CMS audit checklist for EDE and SBE entities comes down to four categories a reviewer looks at first: documentation that defines the program, security evidence that proves it operates, continuous monitoring that proves it persists, and submissions filed with CMS on time. The layer entities most often underprepare is security evidence, because it cannot be created retroactively, which is why continuous readiness beats a pre-audit scramble every time.
Because the precise requirements and deadlines depend on your role and change year to year, the checklist is a starting map to be confirmed against your current obligations rather than a substitute for them. To prepare for a CMS audit with the right evidence staged and the right deadlines tracked, review the CMS audit timeline or book a call with an Elevate advisor.
Key Takeaways
A CMS audit checklist for EDE and SBE entities organizes readiness into four categories a reviewer examines first.
- Documentation defines the program: a current System Security Plan, policies, and data flow and PII mapping orient the reviewer, and they must match what the entity actually does.
- Security evidence proves operation: control evidence, penetration tests, and vulnerability scans show controls work, and this layer is the most commonly underprepared because it cannot be built retroactively.
- Continuous monitoring proves persistence: evidence that the program is sustained between audits, not revived for them, is what a reviewer looks for after documentation and controls.
- Submissions are date-specific: required attestations and submissions must arrive by their deadlines, so they are best tracked against a current timeline rather than memory.
- Requirements depend on your role: EDE and SBE entities share the substance but differ in trigger and cadence, so confirm exact obligations against your authorization rather than a general checklist.
FAQs
Q1. What is a CMS audit checklist? A CMS audit checklist is a structured way for an Enhanced Direct Enrollment or State-Based Exchange entity to prepare for a CMS review by organizing readiness into the categories a reviewer examines first: documentation, security evidence, continuous monitoring, and submission items. It is a starting map rather than the full, entity-specific requirement set, which depends on your role and scope. Used before a review, it confirms that the evidence a reviewer expects is staged and current rather than scattered, which is the difference between a smooth audit and one that surfaces gaps under pressure.
Q2. What do CMS auditors look for first? Reviewers typically orient with documentation, then test whether it reflects reality. The documentation layer includes a current System Security Plan, policies and procedures, and a data flow and PII mapping that shows how consumer information is handled. From there, reviewers look for security evidence that the described controls actually operate, such as penetration test results, vulnerability scans, and records of controls being applied and reviewed. Continuous monitoring evidence and timely submissions follow. A reviewer who finds documentation without evidence of operation has found the most common gap.
Q3. What is the Operational Readiness Review for EDE entities? The Operational Readiness Review is the review an Enhanced Direct Enrollment entity undergoes in connection with gaining and maintaining authorization to integrate with the federal Exchange and enroll consumers. It examines whether the entity meets CMS privacy and security requirements and can evidence that its controls operate. Because it is tied to authorization, preparing for it thoroughly matters directly to an entity’s ability to operate, and the ongoing obligations that follow it continue to be verified after the initial review.
Q4. How is a CMS audit for an SBE different from one for an EDE entity? The substance is largely shared, since both protect consumer information under CMS privacy and security requirements, but the context differs. For an EDE entity, the review is tied to authorization to integrate with the federal Exchange, centered on the Operational Readiness Review and the obligations that follow. For a State-Based Exchange, oversight comes through its relationship with CMS as the operator of a marketplace, with its own reporting obligations. The trigger, cadence, and specific submissions vary by role, so exact requirements should be confirmed against your authorization.
Q5. When should EDE and SBE entities prepare for a CMS audit? Continuously, because these reviews are recurring and scheduled rather than surprises, and because the most important evidence, the record of controls operating over time, cannot be created retroactively. Entities that maintain their documentation, keep security evidence current through continuous monitoring, and track submission deadlines against a current timeline are ready whenever a review comes. Those that wait until an audit is scheduled are preparing at the moment they have the least room to fix what they find, which is why continuous readiness is the dependable approach.