Post‑Deployment Review (30‑Day)

21. Post‑Deployment Review (30‑Day) #

21.1 Purpose #

The 30‑day Post‑Deployment Review (PDR) confirms that the release is stable, secure, compliant, and meeting business and operational objectives. It captures lessons learned and converts gaps into tracked actions.

21.2 Timing and participants #

Hold the PDR within 30 calendar days of Go‑Live (or sooner if material issues arise). Required participants: Product/Process Owner, ISO, IT Operations, Vendor technical lead; invite Legal/Privacy if privacy risks or incidents occurred. PENDING: Standing calendar slot and host (role)

21.3 Inputs (minimum) #

Release record: gate approvals, evidence bundle, deployment/rollback logs, acceptance and smoke‑test results.
Telemetry summary: availability, latency, error rates, WAF blocks, auth/MFA failures, AV detections, top alerts, queue depths.
Security posture: open findings and POA&M status, any waivers and compensating controls, new vulnerabilities since Go‑Live.
Incidents/problems: Sev1/Sev2 tickets, RCAs, subprocessor advisories, emergency changes.
Business outcomes: UAT deltas, user feedback, support trends (ticket volume/types), adoption metrics if applicable.
Cost/capacity snapshot: resource usage and notable anomalies (optional).
PENDING: Standard dashboard/report links to pull for the PDR

21.4 Review agenda #

1. Overview: scope of the release and goals. #

2. Stability and performance: KPIs vs expectations; notable spikes or regressions; actions taken. #

4. Incidents and changes: any Sev1/Sev2 incidents, emergency changes, or rollbacks; RCA highlights and preventive actions; subprocessor impacts. #

5. Operations: runbook adequacy, on‑call responsiveness, backup/restore observations, monitoring gaps; access review outcomes for admin/support roles. #

6. Business feedback: user experience/product issues, workflow gaps, training/docs needs. #

7. Actions and owners: finalize improvements, due dates, and success criteria. #

21.5 Outcomes and actions #

Record all corrective and preventive actions with owners and target dates:

Security: close or re‑justify waivers (with new expiry), accelerate high‑risk POA&M items, adjust WAF rules/rate limits, fix logging gaps or redaction issues.
Operations: tune alerts and dashboards, refine runbooks, schedule restore tests, adjust on‑call targets, fix noisy alerts.
Product: backlog items for usability, training, or workflow refinements.
Vendor/subprocessor: request advisories, evidence, or remediation timelines where third‑party issues contributed.

21.6 Metrics and KPIs #

Capture a concise metrics snapshot for the 30‑day window:

Availability/SLO attainment: PENDING: target SLO or uptime
Mean time to detect/respond/restore (MTTD/MTTR) for incidents (if any)
Error rate and top error classes
Security: number of Critical/High/Medium findings opened/closed; SLA adherence; waivers count and aging
Support: ticket volume by category; time to first response; top drivers
Cost/capacity: notable spikes (optional)

Store this snapshot with the PDR record to trend across releases.

21.7 Documentation updates #

Update artifacts impacted by the release and review: data‑flow diagrams, runbooks, dashboards/alerts, API docs, user/admin guides, and the subprocessor register if anything changed. Note updates in the PDR record and link to locations. PENDING: Repository/path for PDR records and updated artifacts

21.8 Escalation and follow‑up #

If high‑risk items remain (e.g., unresolved Critical/High findings, recurring incidents, residency deviations), escalate to the Executive Sponsor with a remediation plan and timeline. Schedule an interim check‑in before the next release if needed. Track all actions in the POA&M or backlog and verify closure at the next gate or PDR.

21.9 Records and retention #

Store the PDR agenda, attendance, input reports, decisions, actions, and metrics snapshot with the release record. Retain per the Records Management and Retention Schedule. PENDING: Retention period and storage path

21.10 Exceptions #

If the PDR cannot be completed within 30 days, document the reason, interim risk controls, the new date, and obtain ISO concurrence. High‑risk releases must not be repeated without completing the prior PDR unless an ISO‑approved exception with Executive Sponsor approval is in place.