Requirement 6.3.3 in PCI DSS v4.0.1 puts an actual clock on patching, not a general expectation of “timely” remediation. Critical and high severity vulnerabilities must be patched within one month of the patch’s release, and everything else follows a timeframe your organization sets and defends through a documented risk analysis. That distinction sounds simple in a policy document. It gets complicated when a QSA asks for the date a patch was released, the date your ticket was opened, the date it was installed, and the record proving the vulnerability is actually gone. Most patch programs do not fail because patching is slow. They fail because the paper trail does not line up with the requirement’s exact wording.
What Requirement 6.3.3 Actually Requires
The requirement splits into two tracks. For vulnerabilities ranked critical or high under 6.3.1, the deadline is fixed: patches or updates must be installed within one month of release. For everything else, the timeframe is whatever your entity determines through the targeted risk analysis described in Requirement 12.3.1, not an arbitrary internal preference.
| Severity | Deadline | Where it comes from |
|---|---|---|
| Critical | 30 days from patch release | Fixed deadline, stated directly in 6.3.3 |
| High | 30 days from patch release | Fixed deadline, stated directly in 6.3.3 |
| Medium | Entity-defined, risk based | 12.3.1 targeted risk analysis |
| Low | Entity-defined, risk based | 12.3.1 targeted risk analysis |
Why the Clock Starts at Release, Not at Discovery
The most common misread of 6.3.3 is anchoring the 30 days to the date your scanner flagged the issue instead of the date the vendor shipped the fix. If you scan monthly, a patch released on the 2nd of the month might not appear in your results until the next cycle, which already consumes a third of your window before a ticket even exists. Continuous or event-driven scanning closes that gap; a quarterly-only cadence structurally cannot meet 6.3.3 for anything released early in a quarter. Build your SLA measurement from the vendor’s published release or advisory date, not from your own detection date, and you avoid an argument with your QSA before it starts.
Defining “Applicable Security Patches” and the Link to 6.3.1
6.3.3 only applies to patches that are relevant to your environment, and relevance is defined upstream in 6.3.1. That requirement obligates you to identify new vulnerabilities using industry-recognized sources, assign a risk ranking based on industry practice and potential impact, and flag which ones are high or critical at minimum. It also explicitly covers bespoke and custom software as well as third-party components, so an in-house application with an unpatched library dependency is squarely in scope, not just commercial software.
“Applicable” is a filtering test, not a blanket label. A patch is applicable to you when three things line up:
- The affected component actually exists in your inventory, not just in the vendor’s product family.
- Your deployed version falls inside the range the advisory names as vulnerable.
- The vulnerable code path or configuration is reachable in how you actually run it.
Risk ranking is not required to be a raw CVSS score. The standard asks for a ranking based on industry best practices and consideration of potential impact, which gives you room to fold in exploit availability, asset criticality, and network exposure alongside the base score. Document that methodology once, in writing, so a QSA sees a consistent rule applied across findings rather than ad hoc severity calls made at ticket time.
Handling Systems Where the Patch Cannot Be Applied on Time
Deadlines get missed for real reasons: a vendor hasn’t released a compatible build, an OS is end of life pending decommission, a patch breaks a dependent application, or a production freeze during a peak processing period blocks changes. PCI DSS v4.0 gives you two structured ways to handle this instead of simply going noncompliant.
The Customized Approach lets you define your own control that meets the requirement’s stated objective, backed by your own testing procedure and a documented risk analysis, without following the defined approach language literally. The compensating controls path, via the Appendix B worksheet, remains available when a documented business or technical constraint prevents you from meeting the requirement as written but you can show the risk is sufficiently mitigated another way. In practice, the mitigations that hold up under QSA review are specific to the finding, not generic:
- Network segmentation isolating the unpatched host from the rest of the cardholder data environment.
- Virtual patching through an IPS or WAF rule that blocks the specific exploit path the vulnerability enables.
- Tightened access control limiting the host to the minimum users and services required.
- Enhanced logging and monitoring scoped to that host until the real fix ships.
Whatever route you take, write down the target remediation date, the specific control mapped to the specific finding, and a re-evaluation cadence. A risk acceptance with no expiration date reads to a QSA as a permanent exception, which 6.3.3 does not allow for critical and high findings. Some vulnerability management platforms, SITEY among them, let a team attach a compensating control directly to an open finding rather than closing it out, so the mitigation and the underlying vulnerability stay linked in the same record until the real patch lands.
Evidence a QSA Requests
Assessors trace dates. They will pull a sample of patches, usually weighted toward critical and high findings, and ask you to produce the chain from advisory to closure. Missing links in that chain, not slow patching itself, are what generate findings during the assessment.
| Evidence | What it proves | Common gap |
|---|---|---|
| Vendor advisory or CVE record with a publish date | The start of the 30-day clock | Ticket creation date used instead of release date |
| Change or patch ticket with timestamps | Internal handling time | Ticket opened weeks after the advisory, with no explanation |
| Deployment or configuration record | The patch was actually installed | Ticket marked “resolved” with no install evidence attached |
| Authenticated rescan or config check | The vulnerable condition is gone | Closure based on the patch claim alone, never re-verified |
| Risk analysis per 12.3.1 | Justifies the timeframe used for non-critical findings | Document exists but was never reviewed by management |
The rescan step is where teams lose the most ground. Marking a ticket closed because a patch was deployed is an assertion, not proof. Platforms that automate this phase, such as SITEY, re-test the specific finding through an authenticated check instead of trusting the patch command’s exit code, which is the difference between a closure that survives sampling and one that gets flagged as unverified. Structuring your findings and their closure evidence around a defined vulnerability lifecycle makes this traceable by default rather than reconstructed at audit time, and a dedicated retest and closure step gives the QSA the exact artifact they are asking for.
Aligning Internal Remediation SLAs With the Requirement Wording
A frequent mismatch: internal policy states “critical findings remediated within 30 days of ticket creation,” while 6.3.3’s clock runs from patch release. If detection lags release by even two weeks, an SLA that looks fully met on your dashboard can already be in breach of the standard on paper. Fix this by capturing patch release date and internal ticket creation date as two separate fields, never one collapsed timestamp, and by feeding advisory publish dates in automatically rather than relying on whoever opens the ticket to backfill it correctly.
For the medium and low tier, the requirement does not want a number pulled from a vendor’s best-practice guide. It wants your own risk analysis, covering the assets involved, the threats considered, and the factors driving likelihood and impact, reviewed and approved by senior management, with the resulting timeframe applied consistently. Tools that ingest vulnerability data continuously, including SITEY, timestamp the release date and the ticket date as distinct fields precisely so these two clocks in 6.3.3 don’t get silently merged into one during an audit walkthrough. Tie your SLA tiers to the criticality of the system, not just the severity of the finding: an internet-facing component in the cardholder data environment should carry a tighter internal window than an isolated back-office system carrying the same CVSS score, and that distinction should be visible in the risk analysis document itself, not just implied in practice.
Cloud and Third-Party Components Under Shared Responsibility
Cloud deployment does not remove your 6.3.3 obligation, it splits it. Under an IaaS model, the provider patches the hypervisor and underlying hardware while you remain responsible for the guest OS, middleware, and applications running on it. Under PaaS or SaaS, the provider typically covers the runtime layer, but application-level dependencies you introduced, libraries, container base images, custom code, stay yours to track and patch on the 6.3.3 timeline.
Confirm the split in writing rather than assuming it. Provider attestations, contractual language, or a documented shared responsibility matrix should state explicitly which layer each party patches, and your own compliance mapping should reflect that split per system rather than treating “cloud-hosted” as a blanket exemption. For container-based environments, pin base image versions in your build pipeline, refresh them on a defined cadence, and maintain a software bill of materials so a newly disclosed vulnerability in a transitive dependency can be traced to every image that includes it, not discovered piecemeal months later. Centralizing this tracking inside a single patch management view, rather than splitting it across cloud console tickets, container registry alerts, and spreadsheet trackers, is usually the difference between meeting the 30-day window and explaining after the fact why you didn’t.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.