PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom
Home / Matrix / Requirement 6 / c6.2
Foundational 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.2 Patch management and controlled changes

Install critical security patches within one month of release and manage changes to system components through a controlled, documented process.

Quick Wins
Foundational
Efficient
Optimized
Effort: Medium Impact: High 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

Automate patching with SSM Patch Manager and severity-based baselines. Manage infrastructure as code to make changes traceable and reviewable (version control + review). Document the impact, approval, testing, and rollback of each change. Verify patching compliance with Patch Compliance.

Practical implementation

How this control is implemented in each reference architecture:

Patch critical/high vulnerabilities within one month automatically, and make every change traceable, reviewed, and reversible.

  1. Automate OS patching with SSM Patch Manager using severity-based patch baselines and a maintenance-window schedule.
    App tier (CDE) / Data tier (CDE) Systems Manager
  2. Manage the infrastructure as versioned IaC (CloudFormation/CDK) so every change is reviewed via pull request and carries reason, approval, and rollback.
    Account baseline (IaC) CloudFormation
  3. Verify patch compliance with SSM Patch Compliance to prove critical/high patches land within the one-month window.
    Account-wide detection Systems Manager

How to validate: Patch Compliance shows critical/high patches applied within one month, and the IaC repo shows each change with approval and back-out notes.

Avoid: Patching manually and ad hoc. It misses the one-month window and leaves no change record; automate with Patch Manager and drive changes through reviewed IaC.

Single-account, 3-tier →

Drive patch baselines and change control from a central pipeline so every CDE account meets the one-month window with consolidated evidence.

  1. Distribute patch baselines and maintenance windows to all CDE accounts from the central management tooling.
    Security tooling account → PCI OU Systems Manager AWS Organizations
  2. Deploy all infrastructure changes through a central IaC pipeline with review gates and least-privilege cross-account deploy roles.
    Shared services (CI/CD) account CloudFormation CodePipeline
  3. Aggregate Patch Compliance and change history centrally so the one-month window is provable org-wide.
    Security tooling / log archive Security Hub CloudTrail

How to validate: Aggregated Patch Compliance shows all CDE accounts within the window, and the central pipeline's change records carry approvals and rollback plans.

Avoid: Letting each account patch on its own schedule. Compliance windows drift; centralize baselines and reporting.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examineobserve

Testing procedures

  • Examine policies and procedures to verify a process is defined for installing applicable security patches/updates per the requirement (6.3.3.a).
  • Examine system components and compare installed patches to the latest patch information to verify critical/high-security patches are installed within one month of release (6.3.3.b).
  • Examine change control documentation and trace recent changes to verify each includes reason, approval, functionality testing, and back-out procedures (6.5.1.a, 6.5.1.b).

Evidence in AWS

  • SSM Patch Compliance report showing patches applied within the window.
  • Change history in the IaC repository with approvals and reviews.
  • Versioned CloudFormation templates and deployment records.

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 Systems Manager AWS CloudFormation AWS Config

Learning resources

References

  • AWS Security Maturity Model: Patch management
  • PCI DSS v4.0.1 Requirements 6.3.3, 6.5