# Plan of Action & Milestones (POA&M)

**System:** MarketLink — CMS EDE Platform
**Operator:** Wipro Healthplan Services
**Document Owner:** Platform Security Officer
**Classification:** Controlled Unclassified Information (CUI)
**Last Reviewed:** 2026-04-14
**Review Cadence:** Monthly; immediately after each SAR delivery

---

## 1. Purpose

This POA&M tracks every security or privacy finding that affects MarketLink,
from identification through remediation, in the format CMS expects for
post-audit follow-up. Each entry covers the weakness, its NIST 800-53
control anchor, a remediation plan with intermediate milestones, and the
evidence of completion once closed.

New entries are added by the Platform Security Officer (PSO) when:

- A Security Assessment Report (SAR) finding is received from the
  third-party assessor.
- A vulnerability scan (monthly via `npm run security:audit`) surfaces a
  High or Critical CVE.
- An incident postmortem (per the Incident Response Plan) identifies a
  systemic control gap.
- A self-assessment or internal audit identifies a deviation from the
  System Security and Privacy Plan (SSPP).

## 2. Entry Template

Each POA&M row captures the following columns:

| Field | Description |
|---|---|
| Finding ID | `POAM-NNN` (zero-padded three-digit counter, never reused) |
| Weakness / Vulnerability | One-sentence description of the gap |
| Source | `SAR` / `Scan` / `Self-Assessment` / `Incident` |
| Control Reference | NIST 800-53 control family and ID (e.g. `AC-3`, `RA-5`) |
| Risk Level | `Critical` / `High` / `Moderate` / `Low` |
| Remediation Plan | One paragraph describing the fix |
| Responsible Party | Role title (e.g. Platform Lead, DBA) — never a name |
| Scheduled Completion | `YYYY-MM-DD` |
| Milestones | Intermediate steps with target dates |
| Actual Completion | `YYYY-MM-DD`, filled when closed |
| Status | `Open` / `In Progress` / `Completed` / `Risk Accepted` |
| Evidence of Completion | Link to PR, test run, attestation, or artifact |

## 3. Current Entries

### POAM-001 — Database Row-Level Security not implemented

| | |
|---|---|
| Source | Self-Assessment (pre-audit gap analysis) |
| Control Reference | `AC-3` (Access Enforcement), `AC-4` (Information Flow Enforcement) |
| Risk Level | **High** |
| Remediation Plan | Implement Prisma-level RLS policies that scope every query touching `clients`, `applications`, `policies`, and `consent_records` to the authenticated broker's `brokerId`. Current scoping is enforced per-route in application code; database-level enforcement provides defense-in-depth so a mis-written query cannot leak cross-broker PII. |
| Responsible Party | Platform Lead |
| Scheduled Completion | 2026-06-30 |
| Milestones | (1) Draft RLS policy matrix by 2026-05-15 (2) Write migration + test fixtures by 2026-06-01 (3) Staging validation with cross-broker test users by 2026-06-15 (4) Production rollout by 2026-06-30 |
| Actual Completion | — |
| Status | **Open** |
| Evidence of Completion | Migration file + staging test run + SAR re-scan |

### POAM-002 — No concurrent session prevention

| | |
|---|---|
| Source | Self-Assessment (pre-audit gap analysis) |
| Control Reference | `AC-10` (Concurrent Session Control) |
| Risk Level | **Moderate** |
| Remediation Plan | Store `lastLoginAt` as a generation marker in the JWT on sign-in and verify it against the User row on each authenticated request. Mismatched tokens are invalidated (401 with `reason=session_replaced`). Implementation uses existing schema fields — no migration required. |
| Responsible Party | Platform Lead |
| Scheduled Completion | 2026-04-30 |
| Milestones | (1) JWT + middleware wiring complete 2026-04-20 (2) Internal QA 2026-04-25 (3) Deploy 2026-04-30 |
| Actual Completion | — |
| Status | **In Progress** |
| Evidence of Completion | PR on `feat/cms-compliance-and-ede-test-enablement` + test run |

### POAM-003 — Vulnerability scanning not scheduled

| | |
|---|---|
| Source | Self-Assessment |
| Control Reference | `RA-5` (Vulnerability Monitoring and Scanning) |
| Risk Level | **High** |
| Remediation Plan | Automated `npm audit` + HTML report generator runs monthly via GitLab CI schedule. Reports retained as build artifacts for 30 days and archived quarterly. Critical and High findings open a new POA&M entry automatically. |
| Responsible Party | Platform Security Officer |
| Scheduled Completion | 2026-04-21 |
| Milestones | (1) `security:audit` + `security:report` scripts added 2026-04-14 (2) CI stage configured 2026-04-16 (3) First scheduled run 2026-05-01 |
| Actual Completion | — |
| Status | **In Progress** |
| Evidence of Completion | CI pipeline run + `security-reports/vuln-scan-YYYY-MM-DD.html` artifact |

## 4. Workflow

1. **Open** — PSO enters the finding with ID, source, control, risk, and plan.
2. **In Progress** — Responsible party begins work; milestone dates are
   updated as intermediate steps complete.
3. **Completed** — Remediation is verified by evidence (code review,
   test run, re-scan, or external attestation). PSO signs off and the
   `Actual Completion` date is set.
4. **Risk Accepted** — Used only with written authorization from the
   Platform Lead and only after compensating controls are documented.

All status changes are logged in the AuditLog (`AUDIT_POAM_UPDATE`)
with before/after values for the entry.

## 5. Reporting

- **Monthly** — PSO delivers a one-page POA&M summary to the Platform
  Lead (counts by status, items approaching deadline, items overdue).
- **Quarterly** — Full POA&M plus evidence snapshot archived to the
  compliance artifacts vault.
- **On SAR delivery** — Every SAR finding becomes one POA&M entry
  within five business days of receipt.

## 6. Document Control

| Version | Date | Change |
|---|---|---|
| 1.0 | 2026-04-14 | Initial template with POAM-001..003 pre-populated |
