Annual risk assessment is documented for cardholder data environment

PCI-DSS 4.0 Req 12.3 requires that a targeted risk analysis is performed for each PCI requirement that provides flexibility; Req 12.3.1 requires it to be documented and reviewed at least annually. A risk assessment is the mechanism by which you discover gaps before an auditor or attacker does — it forces enumeration of CDE assets, threat actors, and compensating controls. ISO 27001:2022 A.6.1.2 (Information Security Risk Assessment) and NIST RA-3 both require periodic, documented risk assessments as the foundation of a security program. Without one, your security posture is reactive rather than managed.

Conduct an annual CDE risk assessment and document it in docs/annual-risk-assessment-YYYY.md. The document must name the assessment date, define the CDE scope explicitly, and list at least three risks with likelihood/impact ratings and named mitigations. Review and update it before each anniversary.

# Annual Risk Assessment: CDE
**Date:** 2026-02-15  **Next:** 2027-02-15

## CDE Scope
Payment API, webhook receiver, cardholder_data table (tokens only), admin panel.

## Risk Register
| Risk                      | Likelihood | Impact   | Mitigation                        | Residual |
|---------------------------|-----------|----------|-----------------------------------|----------|
| Unauthorized CDE access   | Medium    | Critical | MFA + RBAC + audit logging        | Medium   |
| SQL injection in payment  | Low       | Critical | Parameterized queries + pentest   | Low      |
| Dependency CVE exploited  | Medium    | High     | Dependabot + weekly Trivy scan    | Low      |

Reference this document from docs/pci-compliance.md and link it to your incident response plan so the risk assessment feeds directly into your operational controls.

• ID: ecommerce-pci.monitoring-compliance.annual-risk-assessment

• Severity: info

• What to look for: Search for risk assessment documentation (look for "risk-assessment", "risk assessment", "security assessment" in docs/ and project root). For each document found, check the assessment date and calculate months since assessment (must be under 12 months). Count the number of identified risks documented with likelihood/impact ratings. Count the number of mitigation measures documented. Check for a CDE scope section.

• Pass criteria: At least 1 risk assessment document exists dated within the last 12 months (no more than 365 days old). The assessment covers at least 3 identified risks with likelihood and impact ratings. At least 3 mitigation measures are documented. A CDE scope section defines which systems are in scope. Report: "Assessment date: [date], X risks identified, Y mitigations documented."

• Fail criteria: No risk assessment document found (0 files), or assessment is older than 12 months, or assessment covers fewer than 3 risks, or no CDE scope section.

• Skip (N/A) when: No CDE in your infrastructure (no cardholder data stored or processed locally, fully third-party payment processing).

• Detail on fail: Specify the gap. Example: "0 risk assessment documents found in docs/ directory." or "docs/risk-assessment-2024.md found but dated 2024-01-15 (14 months old). 2 risks identified (below 3 minimum)."

• Cross-reference: See ecommerce-pci.access-control.pci-documentation (compliance overview), ecommerce-pci.monitoring-compliance.penetration-testing (security testing), ecommerce-pci.monitoring-compliance.incident-response-plan (breach response).

• Remediation: Conduct and document annual risk assessment. Create docs/annual-risk-assessment-2026.md:

  # Annual Risk Assessment: Cardholder Data Environment
  **Fiscal Year:** 2026
  **Assessment Date:** 2026-02-15
  **Assessor:** Security Team
  **Next Assessment Due:** 2027-02-15
  
  ## Executive Summary
  This assessment covers the cardholder data environment for our e-commerce platform. Overall risk rating: **MEDIUM** with acceptable mitigations in place.
  
  ## CDE Scope
  - Payment API (Webhook receiver, payment webhook processing)
  - Database (cardholder data storage, limited to last-4 and expiry only)
  - Admin panel (staff access to transaction data)
  - Monitoring systems (Datadog)
  
  ## Identified Risks
  
  ### 1. Unauthorized CDE Access
  - **Likelihood**: Medium (multiple user accounts)
  - **Impact**: Critical (full cardholder data exposure)
  - **Risk Rating**: High
  - **Mitigations**: MFA enforced, RBAC configured, audit logging enabled
  - **Residual Risk**: Medium
  
  ### 2. SQL Injection in Payment API
  - **Likelihood**: Low (parameterized queries, prepared statements)
  - **Impact**: Critical (data breach)
  - **Risk Rating**: Medium
  - **Mitigations**: Input validation, OWASP Top 10 testing, annual pentesting
  - **Residual Risk**: Low
  
  ### 3. DDoS Attack on Payment Webhooks
  - **Likelihood**: Medium (public endpoint)
  - **Impact**: High (service unavailability)
  - **Risk Rating**: Medium
  - **Mitigations**: WAF, rate limiting, AWS DDoS protection
  - **Residual Risk**: Low
  
  ### 4. Insider Threat / Compromised Credentials
  - **Likelihood**: Low (background checks, MFA)
  - **Impact**: Critical (full system compromise)
  - **Risk Rating**: Medium
  - **Mitigations**: Principle of least privilege, audit logging, 90-day log retention
  - **Residual Risk**: Low
  
  ### 5. Third-Party Vendor Breach (AWS, Datadog)
  - **Likelihood**: Low (Level 1 PCI vendors)
  - **Impact**: High (data exposure)
  - **Risk Rating**: Low-Medium
  - **Mitigations**: Vendor compliance verification, incident response plan
  - **Residual Risk**: Low
  
  ## Control Effectiveness
  
  | Control | Status | Evidence | Effectiveness |
  |---------|--------|----------|----------------|
  | MFA for admin access | Implemented | Supabase config, user verification | High |
  | Encryption at rest | Implemented | RDS encryption enabled | High |
  | HTTPS/TLS enforcement | Implemented | HSTS header, ALB SSL | High |
  | Audit logging | Implemented | 365-day retention, CloudWatch | High |
  | Vulnerability scanning | Implemented | Trivy + Snyk in CI/CD | Medium |
  | Penetration testing | Completed | Last test 2025-12-15 | High |
  | Incident response plan | Documented | docs/incident-response-plan.md | Medium |
  
  ## Recommendations for Next Year
  1. Migrate to fully tokenized payment system (remove card storage)
  2. Implement hardware security module (HSM) for key management
  3. Conduct quarterly, not annual, risk assessments
  4. Establish security metrics dashboard
  5. Increase penetration testing to bi-annual