Appearance
CMS EDE Appendix A Mapping
Evidence register for the CMS Enhanced Direct Enrollment Audit Program, Appendix A controls. EDE Phase 3 audits examine how the entity has operated over a multi-month window — this register is the trail of how individual controls were brought online.
Status
Not yet applying for EDE Phase 3. Register is seeded now so that when we do apply, the operational history is already in place and auditable.
§ 1 — Identity proofing for consumers and agents
| Requirement | Implementation | Evidence | Last updated |
|---|---|---|---|
| Consumer identity proofing for enrollment-eligibility determination | Not yet applicable — consumer enrollment flow ships at Phase 5 (target after 2026-06-15 platform v1). Pre-launch checklist will include: explicit identity-proofing step (vendor TBD — Persona / Stripe Identity / Plaid / Veriff; selection deferred); audit-log row per attempted + completed proofing; failure-mode handling. | Vendor / Subprocessor Register Tier 2 ID-verification row; Agent platform compliance. | 2026-05-11 |
| Agent identity proofing at onboarding | Not yet applicable — agent portal ships at Phase 5. Pre-launch will require: NIPR PDB Detail Report at onboarding (NPN validation; $1.30 per check); monthly NIPR active-license alert subscription; ID-verification vendor lookup (selection per above); fully audit-logged in agent_audit_log. | Agent platform compliance; NIPR vendor row in vendor register. | 2026-05-11 |
§ 2 — Account creation controls
| Requirement | Implementation | Evidence | Last updated |
|---|---|---|---|
| Controlled account-creation path with audit logging | Today (pre-Phase-5): the only accounts created are waitlist submissions (read-only data, not authenticated). At Phase 5 launch: agent account creation will require NIPR-validated NPN + ID proofing + Workforce Confidentiality Agreement (where applicable); consumer account creation will require identity-proofed eligibility verification. Every account-creation event will be logged to agent_audit_log with: actor, target, timestamp, IP, user-agent, verification evidence. | Agent platform compliance; Access Control Policy provisioning section. | 2026-05-11 |
§ 3 — Environment separation
| Requirement | Implementation | Evidence | Last updated |
|---|---|---|---|
| Production data isolated from non-production | Atlas projects are isolated: askflorence-prod-01 (PHI scope) is fully separate from askflorence-staging (public CMS reference data only). No shared allowlist, users, or roles. AWS accounts are isolated: 4-account org with SCPs preventing cross-account access except via explicit IAM. Cross-cluster Atlas reference reads from prod → staging are read-only, AWS-PrivateLink-only, narrow-role-bound; CI guards (staging-collections-guard + staging-cluster-drift) prevent unauthorized scope drift. | ADR 0001 — Atlas project isolation; ADR 0004 — Cross-cluster PrivateLink; infra/envs/management/ (4-account org config). | 2026-05-11 |
| PHI-bearing surfaces isolated from non-PHI marketing surfaces | The prod / staging isolation logic above is extended to the PHI / non-PHI surface boundary via the apex-vs-portal subdomain split. Marketing surfaces (calculator, waitlist, public pages) run on askflorence.health (apex); the member portal (Phase 5+, where PHI lands) runs on app.askflorence.health (working subdomain name). First-party cookies on apex are scoped Domain=askflorence.health (NOT wildcarded), so they cannot follow a user across the boundary. The portal enforces a script-src 'self' CSP — third-party processors (ad pixels, heatmap tools, etc.) cannot execute on PHI-bearing pages by browser-layer enforcement, not by runtime check. Conversion attribution back to ad platforms is forwarded server-side from our backend with SHA-256 hashed PII, so the portal does not need to relax its CSP for attribution to work. Full control documentation: Marketing vs. Portal Analytics. | Marketing vs. Portal Analytics control doc; ENG-187 (portal design scope). | 2026-05-11 |
§ 4 — Data transmission encryption
| Requirement | Implementation | Evidence | Last updated |
|---|---|---|---|
| All data in transit encrypted with FIPS-validated or equivalent | TLS 1.2+ floor at every channel: public → CloudFront (ACM); CloudFront → ALB (ACM); ALB → ECS (ACM); ECS → Atlas (Atlas-enforced floor); cross-cluster reads via AWS PrivateLink (TLS app + AWS-backbone network layer). FIPS-validated cipher suites used at AWS endpoints (FedRAMP Moderate inheritance from AWS Orgs BAA). | Encryption Policy; ACM cert configuration; ADR 0004. | 2026-05-11 |
§ 5 — Data-at-rest encryption
| Requirement | Implementation | Evidence | Last updated |
|---|---|---|---|
| All sensitive data at rest encrypted with FIPS-validated or equivalent | Atlas AES-256 at rest (HIPAA tier on prod cluster); S3 SSE-KMS with project CMKs; Secrets Manager SSE-KMS; EBS AES-256 default; CloudWatch AWS-managed encryption. FIPS-validated when running on AWS FedRAMP Moderate infrastructure. CSFLE field-level encryption with AWS KMS planned before any PHI collection is created (Phase 5). | Encryption Policy; Encryption Policy field-level section; KMS CMK ARNs in Terraform per env. | 2026-05-11 |
§ 6 — Agent NPN validation
| Requirement | Implementation | Evidence | Last updated |
|---|---|---|---|
| Validate agent NPN against the federal NIPR registry at onboarding + ongoing monitoring | Not yet applicable — Phase 5 agent platform. Planned: NIPR PDB Detail Report at onboarding ($1.30 per call) + monthly NIPR active-license alert subscription for all onboarded agents. Failure mode (NPN not found, NPN expired): account creation blocked + audit-logged. Vendor evaluation may consider alternatives but NIPR is the default. | Vendor register NIPR row; Agent platform compliance. | 2026-05-11 |
§ 7 — Session management
| Requirement | Implementation | Evidence | Last updated |
|---|---|---|---|
| Session-level controls: idle timeout, absolute timeout, MFA on auth | Today (pre-Phase-5): AWS SSO sessions are 8h absolute (admin / power_user) or 4h (billing_ro / security_audit). Atlas org sessions per Atlas defaults. Phase 5 agent portal: 15-min idle / 8-hr absolute max session; auth via magic link + TOTP per NIST 800-63B AAL2; super-admin path uses password + TOTP + IP allowlist (Tailscale/static VPN). | Access Control Policy MFA section; Agent platform compliance. | 2026-05-11 |
§ 8 — Role-based access
| Requirement | Implementation | Evidence | Last updated |
|---|---|---|---|
| Access tied to job function; least privilege; periodic review | Narrow-scoped Mongo roles (ADR 0003) — six users, five custom roles, each bound to the minimum collection set for its purpose. AWS SSO permission sets (admin, power_user, billing_ro, security_audit) scope human access. Quarterly access review verifies continued appropriateness. | Access Control Policy; ADR 0003; Atlas access matrix; Access reviews. | 2026-05-11 |
§ 9 — Access Control Logging
| Requirement | Implementation | Evidence | Last updated |
|---|---|---|---|
| Maintain an access control log for records involved in eligibility determination, enrollment, and agent activity | agent_audit_log Mongo collection enforced append-only at the DB permission layer. Retention target 6-10 years (TTL index set in Phase 5 alongside collection creation). | ADR 0002, role JSON, verification probes. | 2026-04-17 |
| AWS API audit trail | CloudTrail organization trail captures every AWS API event across all 4 accounts; 7-year retention in log-archive S3 with KMS encryption. | CloudTrail org-trail config; log-archive S3 bucket lifecycle. | 2026-05-11 |
| Atlas database-layer audit | Atlas database audit logs enabled at DB layer (prod M10 HIPAA tier + staging M30); used for incident-response reconstruction. | Atlas project audit config. | 2026-05-11 |
§ 10 — Incident response and breach notification
| Requirement | Implementation | Evidence | Last updated |
|---|---|---|---|
| Documented incident-response plan with regulatory notification procedure | Formal Incident Response Plan defines roles (IC + Compliance Liaison + Comms Lead), severity classification, 5-step lifecycle (Detect → Contain → Assess → Notify → Remediate), regulatory notification timelines (HIPAA Breach Notification Rule 60-day clock from discovery, state-AG notifications, CMS EDE program notification triggers); operational playbook in security-incident-response runbook; 5 worked-example incidents from 2026 documented. | Incident Response Plan; Security Incident Response runbook. | 2026-05-11 |
§ 11 — Business continuity
| Requirement | Implementation | Evidence | Last updated |
|---|---|---|---|
| Backup + restore + DR procedure | Atlas continuous snapshots (7-day point-in-time + daily snapshots for 30 days on M10 tier); S3 versioning + lifecycle on stateful buckets; CloudTrail org-trail with 7-year retention in log-archive; Terraform-managed infrastructure (IaC) enables rebuild from source; break-glass procedure for emergency mode. | Atlas backup config; Encryption Policy backup encryption; Break-glass runbook. | 2026-05-11 |
| Documented DR-time objectives + tabletop exercise | RTO / RPO targets to be documented in Phase 5 alongside the first PHI collections. First tabletop exercise scheduled for Q2 2026 access review (July 2026) — SEV-1 PHI-breach scenario walkthrough. | Access reviews; Incident Response Plan tabletop section. | 2026-05-11 |
How to add a row
Each session that lands an EDE-relevant change MUST append a row under the appropriate § heading, including a link to the ADR / runbook / session log. Rows are additive and timestamped.
