PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom
Home / Matrix / Requirement 6 / c6.5
Optimized Vulnerability ManagementSecurity domain from the AWS Cloud Adoption Framework (CAF) Security Perspective, used to organize the controls. 🤝 SharedAWS Shared Responsibility Model: who implements and operates this control. Customer = you own it; AWS = AWS operates it and you inherit it; Shared = both have obligations.

c6.5 Automated vulnerability detection and remediation at scale

Optimize the vulnerability management program with automated remediation, SLA metrics by severity, and full change traceability for continuous compliance.

Quick Wins
Foundational
Efficient
Optimized
Effort: High Impact: Medium Applies to CDE: Yes

Requirement 6

Develop and Maintain Secure Systems and Software

PCI sub-requirements coveredCoverage shown per PCI DSS v4.0.1 sub-control. “Covered” = addressed by this AWS recommendation. “Roadmap” = technical, planned. “Your responsibility” = organizational/process control. “Out of scope” = physical or third-party control not implemented in AWS.

6.3 Security vulnerabilities are identified and addressed
  • 6.3.1 Security vulnerabilities identified and risk-ranked Covered
  • 6.3.2 Inventory of bespoke/custom software and components maintained Covered
  • 6.3.3 All system components protected via patches (critical within 1 month) Covered
6.5 Changes to all system components are managed securely
  • 6.5.1 Changes to all system components managed through a formal process Your responsibility
  • 6.5.2 Applicable PCI DSS requirements confirmed after significant change Your responsibility
  • 6.5.3 Pre-production environments separated from production Covered
  • 6.5.4 Roles/functions separated between production and pre-production Your responsibility
  • 6.5.5 Live PANs not used in pre-production environments Your responsibility
  • 6.5.6 Test data and test accounts removed before production Your responsibility

How to implement on AWS

Orchestrate automatic remediation (SSM Automation) on Inspector/Security Hub findings by severity. Measure patching SLAs and generate reports. Rebuild immutable instances from patched AMIs (immutable infrastructure pattern). Correlate changes with CloudTrail for traceability.

Practical implementation

How this control is implemented in each reference architecture:

Reach the optimized state: auto-remediate findings by severity, track patching SLAs, and rebuild immutable instances from patched AMIs.

  1. Wire SSM Automation runbooks to remediate Inspector/Security Hub findings automatically, prioritized by severity.
    Account automation Systems Manager Security Hub
  2. Rebuild instances from freshly patched golden AMIs (immutable infrastructure) instead of patching in place.
    App tier (CDE) / Data tier (CDE) EC2 Image Builder Amazon EC2
  3. Track patching SLA metrics by severity and correlate changes with CloudTrail for traceability.
    Account-wide detection CloudWatch CloudTrail

How to validate: SSM Automation shows remediation history by severity, SLA metrics meet the target, and instances are replaced (not patched in place) from current AMIs.

Avoid: Long-lived instances patched in place forever. Config drift accumulates; adopt immutable rebuilds from patched AMIs.

Single-account, 3-tier →

Operate remediation orchestration and SLA reporting centrally so every CDE account self-heals with aggregated change traceability.

  1. Correlate findings in the delegated-admin Security Hub and drive automated fixes per account with central SSM Automation.
    Security tooling account → CDE accounts Security Hub Systems Manager
  2. Distribute the patched golden-AMI baseline org-wide so every account rebuilds immutably from current images.
    Shared services → PCI OU EC2 Image Builder AWS RAM
  3. Aggregate SLA metrics and change traceability (CloudTrail) in the log-archive account.
    Log archive account CloudTrail Amazon S3

How to validate: Central Security Hub shows remediation across accounts meeting SLA, and change traceability is consolidated in the log-archive account.

Avoid: Per-account remediation logic that diverges. Centralize orchestration and reporting so SLAs are comparable and enforced.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examineobserve

Testing procedures

  • Examine system components and installed patch information to verify vulnerabilities are addressed by risk ranking and critical/high patches applied within one month (6.3.3.b).
  • Examine change control documentation to verify managed-change requirements are met for all system component changes (6.5.1.b).

Evidence in AWS

  • SSM Automation runbooks for remediation by severity and their history.
  • Vulnerability-remediation SLA metrics/reports.
  • Change traceability in CloudTrail correlated with findings.

Customized approach

Requires a targeted risk analysis (Req 12.3.2).

Customized Approach Objective

  • 6.3 — New system and software vulnerabilities that may impact the security of account data are monitored, cataloged, and risk-assessed, and applicable patches are installed within an appropriate time frame.
  • 6.5 — All changes are tracked, authorized, and evaluated for impact and security, and are managed to avoid unintended effects to the security of system components.

AWS services

AWS Security Hub Amazon Inspector AWS Systems Manager Automation AWS CloudTrail

Learning resources

References

  • AWS Security Maturity Model: Continuous improvement program