PCI DSS 6.3.3: All system components are protected from known vulnerabilities by installing applicable
PCI DSS v4.0.1 control 6.3.3: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 6.3.
Requirement 6: Develop and Maintain Secure Systems and Software › Section 6.3
All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:
- Patches/updates for critical vulnerabilities (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release.
- All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity’s assessment of the criticality of the risk to the environment as identified according to the risk ranking process at Requirement 6.3.1.
Summary
Patch critical vulnerabilities within a month and everything else within a timeframe you have defined and can defend.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 6.3.3.a | Examine policies and procedures to verify processes are defined for addressing vulnerabilities by installing applicable security patches/updates in accordance with all elements specified in this requirement. |
| 6.3.3.b | Examine system components and related software and compare the list of installed security patches/updates to the most recent security patch/update information to verify vulnerabilities are addressed in accordance with all elements specified in this requirement. |
The action half of 6.3.1: that control ranks vulnerabilities, this one fixes them, and the one-month clock applies to whatever your ranking called critical. That dependency is the thing to get right, because a ranking that never produces a critical produces no one-month obligation either, and an assessor reads those two controls together. For everything else the requirement deliberately does not name a period: you set it, from your own risk assessment, and then you are held to it. 6.3.3.a examines policies, 6.3.3.b examines system components against the patch levels those policies require.
What to prepare
- The defined timeframes: one month for critical, and your own defined period for the rest, with the reasoning.
- Current patch levels for a sample of system components, which is what 6.3.3.b examines.
- Evidence of the patch process running: change records, deployment logs, or pipeline output.
- The exception process for patches you cannot apply, and what you do instead.
How to implement it
1. Set the non-critical timeframe deliberately and write down why. "As soon as practical" is not a timeframe and cannot be tested. A stated ninety days you meet is far stronger evidence than an aspiration to thirty that you miss.
2. Measure against the release date, not the date you noticed. The clock in the requirement starts at release. A discovery process that lags by three weeks spends most of the month before anyone begins.
3. Cover the whole component, including its dependencies. Application libraries, container base images and the runtime are all part of the system component, and they are usually patched by a different mechanism than the operating system.
4. Have a real answer for what you cannot patch. Where a patch breaks a dependency, the defensible position is a documented risk assessment and a compensating control, reviewed. Silence is what turns an exception into a finding.
Where this commonly fails
- A critical patch installed in five weeks, which is inside a "monthly patch cycle" and outside the requirement.
- Ranking and patching maintained by different teams, so what 6.3.1 called critical never reaches the one-month queue.
- Operating systems patched on schedule while application dependencies are updated only when a feature needs them.
- A defined timeframe nobody measures against, so the policy exists and the compliance is unknown.
Related controls
This control refers to 6.3.1.
Others in section 6.3:
| Control | What it requires |
|---|---|
| 6.3.1 | Security vulnerabilities are identified and managed… |
| 6.3.2 | An inventory of bespoke and custom software, and third-party software components incorporated… |
← 6.3.2 · All controls · 6.4.1 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.