A critical CVE lands on the firewall in front of your cardholder data. There is no hotfix to install yet, so the one-month clock has not started. You rank it, put a compensating control in front of it, check you were not already compromised, and record the call. At the annual assessment the QSA asks what you knew that morning. PCI SSC says a missed control cannot be backdated. A record made that morning never needs to be.
Tonight, record six things: your 6.3.1 ranking and its basis, that no vendor patch exists yet, the compensating control in place, the result of your compromise check, a review-by date, and the owner.
The record opens with that CVE's facts already filled in: KEV status, EPSS and its date, weakness class, fixed versions, each from its public source. Our server dates it. Sign in with email, Google or GitHub to keep it. The first 100 records are free. Practitioner, $124.50 a month, keeps 500. Custody, $10,000 a year, is unlimited and adds the organisation register your QSA reads. Both are founding prices.
PCI DSS v4.0.1 asks for two decisions and one deadline. You rank every vulnerability for your environment. A critical one gets patched inside a month. The month starts when the vendor ships the patch, not when you open the ticket.
"Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact. Risk rankings identify, at a minimum, all vulnerabilities considered to be a high-risk or critical to the environment." Requirement 6.3.1
"Patches/updates for critical vulnerabilities (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release." Requirement 6.3.3
Critical vulnerabilities "must be resolved within one month of release." Resolved: "the entity solves or fixes the vulnerability." Addressed: "the entity determines whether to resolve the vulnerability or to mitigate the risk by addressing the vulnerability in another way (e.g., with a compensating control or by disabling a vulnerable service)." PCI SSC FAQ 1597
"...there is no way for them to perform the control retroactively or backdate a later occurrence of the control to an earlier period." PCI SSC FAQ 1572, whose examples include a critical patch not installed within 30 days of release
"Compensating controls may be considered when an entity cannot meet a PCI DSS requirement explicitly as stated, due to legitimate and documented technical or business constraints". Its own example is "a security update is not yet available from a vendor", answered in its text with segmentation, limited access to the interface and IDS/IPS on its traffic. "A compensating control cannot address a requirement that was missed in the past". Appendix B
6.3.3 says "within one month of release". FAQ 1572 says "within 30 days of release". Discovery, triage and your decision all happen inside that month, and until a patch exists the month has not started. If a template tells you critical and high within 30 days, it follows v4.0, retired on 31 December 2024. v4.0.1 says critical only.
FAQ 1597: 6.3.1 "does not require that an entity accepts risk rankings assigned by external sources". You may rank a CVSS 9.8 as high for your environment. The assessor will ask what you based that on, and when you decided it.
All other patches go in "within an appropriate time frame" you set. The 6.3.3 guidance gives "60 days for high-risk vulnerabilities and 90 days for others" as an example. High-risk and critical findings on internal scans must still be resolved and confirmed by rescan under 11.3.1. Lower-ranked findings follow your targeted risk analysis under 11.3.1.1 and 12.3.1. PCI SSC publishes TRA guidance and sample templates.
Your QSA, or ISA, works through the published testing procedures and records each result in your Report on Compliance or Self-Assessment Questionnaire. For a vulnerability you have not patched, these are the procedures that reach it, and the question each one turns into across the table.
| Where it comes from | What the text says | What you get asked |
|---|---|---|
| 6.3.3.b | "compare the list of installed security patches/updates to the most recent security patch/update information" | Why is this one not installed? If you ranked it critical, show the release date and the install date. |
| 11.3.1 guidance | "additional documentation may be required to verify non-remediated vulnerabilities are in the process of being resolved" | This was open across two quarterly scans. Show me it is being worked. |
| 6.3.1.b | "Interview responsible personnel, examine documentation, and observe processes" | You ranked this below its CVSS score. What was that based on, and when? |
| 11.3.1.1.b | "examine internal scan report results or other documentation to verify that all other applicable vulnerabilities ... are addressed based on the risk defined in the entity's targeted risk analysis" | Show me this lower-ranked finding was handled on the timeframe your TRA set. |
| Appendix B | "All compensating controls must be reviewed and validated for sufficiency by the assessor" | Document the legitimate constraint. What did you know about the risk at the time? |
| FAQ 1572 | "The entity demonstrates that the activity was missed due to an exceptional circumstance" | Show me this miss was exceptional, and that your process existed before it. |
Most teams meet the QSA with an Appendix C compensating controls worksheet in a spreadsheet, filled in for the assessment rather than on the day of the call. The rows are the right rows: constraints, definition, objective, identified risk, validation, maintenance. What fails is the date on the evidence behind them.
Row 4 restates today's CVSS, not the ranking you gave it on the day you ranked it, or the KEV listing and EPSS score it stood on. The 6.3.1 guidance expects rankings to move: "a vulnerability initially identified as low risk could become a higher risk later." A row with no date cannot show which way yours moved, or when.
Row 1 says the vendor had no patch. A worksheet typed in March about a decision made last April reads as typed in March, and it cannot show the day the patch did arrive. PCI SSC already says a missed control cannot be backdated. Nothing in a spreadsheet shows the row existed before the question did.
Appendix B has the assessor evaluate every compensating control at every annual assessment. A row that was right in April and never revisited shows the maintenance did not run. Once the patch ships, the no-patch constraint is gone. A control kept after that needs a new constraint, in place and written down before the month runs out. With none, a control still standing a month after the vendor shipped the patch is a missed 6.3.3 deadline, which FAQ 1572 says no compensating control can cover.
A worked example. PAN-OS 11.1.2 runs the GlobalProtect gateway in front of the cardholder data environment. Palo Alto Networks publishes a command injection, CVSS 10.0, exploitable without credentials. There is no hotfix to install yet. The team and its versions are illustrative. Every public value below is dated on the CVE-2024-3400 record or in the vendor's advisory, so your QSA can check each one. A record never changes after it is written.
Tonight, record six things: your 6.3.1 ranking and its basis, that no vendor patch exists yet, the compensating control in place, the result of your compromise check, a review-by date, and the owner.
| Date | What the public record did | What the decision record did |
|---|---|---|
| 12 Apr 2024 | Published. Listed on CISA KEV the same day. EPSS 0.00043. | Version 1: ranked critical, mitigated, not yet resolved, signature in front of the gateway. No release, so no clock yet. |
| 13 Apr 2024 | First public proof of concept. EPSS 0.02734. | Nothing rewritten. Version 1 still shows EPSS 0.00043, which is what you had. It reads exactly as it did the morning before. |
| 14 Apr 2024 | Palo Alto releases hotfixes 10.2.9-h1, 11.0.4-h1 and 11.1.2-h3. The 6.3.3 month opens. | Version 2, five days ahead of its review-by date. The owner records "11.1.2-h3 released 14 Apr" with the vendor advisory as its receipt, beside our server date. Appendix B's constraint has ended. Emergency change booked for 15 Apr, and the control stays until the install. |
| 15 Apr 2024 | EPSS 0.00371. | Version 3: resolved on 11.1.2-h3, one day into the month. Chained to versions 1 and 2, which stay readable. The server date shows when the install was recorded. Set beside the release date in version 2, the one-month window reads at a glance. |
| 19 Apr 2024 | CISA due date. | Nothing comes due. The record closed four days earlier. |
| Annual assessment | Still listed on KEV. The record closed on 15 Apr. Version 3 reads exactly as it was written. | The QSA opens one link: three versions, each dated, each with the evidence it stood on. Your patch tooling shows the install. The record shows the release it answered and the day it was answered. |
The same record, if the 15 Apr change had not gone ahead. The month from the 14 Apr release runs out on 14 May. FAQ 1572 says no compensating control covers that miss, so the signature stays in front of the gateway as risk reduction, never as cover. What FAQ 1572 does allow is an In Place finding once the patch is in, if the assessor has assurance on four conditions. The three versions below cover the install and all four.
| Date | What the decision record did | FAQ 1572 condition it evidences |
|---|---|---|
| 14 May 2024 | Version 3, written the day the month ran out. The owner records the miss and why. The 15 Apr change was cancelled: the standby firewall of the CDE boundary pair was out for a hardware replacement, and the change board refused to upgrade the only live unit. The replacement is due 16 May, so version 3 sets a new review-by of 17 May, the first window after it. | An exceptional circumstance, written down the day it happened. Versions 1 and 2, and every other critical in your register, show a repeatable and documented process that ran before it. |
| 17 May 2024 | Version 4: resolved on 11.1.2-h3, three days past the month. Chained to versions 1 to 3, which stay readable. Your patch tooling shows the install. | Corrective action taken, and the control now performed as 6.3.3 requires. |
| 31 May 2024 | Version 5: the root cause and its fix. No spare unit was held for the boundary pair. A spare now sits on site, and the patch runbook escalates any critical with no install booked by day 20 of its month. | The issue that led to the miss addressed, and steps in the process to prevent recurrence. |
Already past the month, with nothing written that morning? Start the record today. It is dated today and claims nothing earlier, so it cannot show what you knew on the day the patch was released. Record the miss and its cause now, the install when it lands, and the root-cause fix after it. Those versions evidence the FAQ 1572 conditions for corrective action and preventing recurrence from the day you write them. Every critical you record from here on adds to the repeatable, documented process the next assessment asks you to show.
| Appendix C row | Filled from the record |
|---|---|
| 1. Constraints | "No vendor hotfix for PAN-OS 11.1.2 as of 12 Apr 2024." The owner's words in version 1, under our server date. Beside them, CISA's required action as the record holds it: "Apply mitigations per vendor instructions as they become available." |
| 4. Identified risk | Ranked critical under 6.3.1. KEV listed 12 Apr 2024. EPSS 0.00043, FIRST series dated 12 Apr 2024. CVSS 10.0 from the CNA and from NVD. |
| 6. Maintenance | Review by 19 Apr, or the day a hotfix ships. Came due on 14 Apr with the release. Closed on 15 Apr by the install. Three versions, one chain. |
Compliance is your assessor's finding, written in your ROC or SAQ. vciy produces evidence artifacts, never compliance: the dated, per-CVE evidence a specific testing procedure asks for. It is not an ASV and it does not scan. Everything else in the assessment belongs to you and your assessor, and the line between them is clean.
| Item | Who holds it | How |
|---|---|---|
| 6.3.1 ranking, with the external ratings beside yours | In the record | One dated version holds CVSS, KEV, EPSS, your ranking and your reason. |
| The vendor release date that opens the 6.3.3 month | In the record, in your words | Your statement with the vendor advisory as its receipt, beside our server date. Kept as your statement, never mixed with the facts we source. |
| 11.3.1: proof a non-remediated finding is being resolved | In the record | A server date that predates the assessment, and every later change as a chained version. |
| 11.3.1.1: the "other documentation" for a lower-ranked finding | In the record | Ranking, rationale and a review-by date set to your TRA's timeframe. A watch alerts you when KEV or EPSS moves. Your new ranking is a new version in the same chain, and the old version stays readable. That is the re-ranking the 6.3.1 guidance expects. |
| Appendix C rows 1, 4 and 6: constraint, identified risk, maintenance | Evidence for the row | The constraint as you stated it that morning, under our server date. KEV and EPSS on the day with their source dates. The review-by date and every later version. The worksheet itself stays yours. |
| 12.3.1 targeted risk analysis | Yours | The register is an input to its 12-month review: which deferrals held, which came due, which were re-ranked in a new version. |
| The compensating control, and its validation | Yours and your QSA's | The record dates the decision to use it. The control and the sufficiency ruling are not ours. |
| 6.3.3.b: proof a patch is installed | Your patch tooling | A decision is not an install. The record shows which release the install answered. |
| The one-month clock for critical patches | PCI SSC's | Fixed at the vendor's release. A record documents the month. It does not extend it. |
| Internal and external scans, rescans, ASV passing scans | Your scanner and ASV | 11.3.1 and 11.3.2 are scans. A record is not. When an external scan fails on a CVE you mitigated, the record is the dated evidence you attach to the dispute. The ASV decides. |
| CDE scope, the ROC, the SAQ, the AOC | You and your assessor | CVE facts describe the CVE. What it means in your environment is your judgement, dated. |
The real alternatives are the risk-acceptance exception your scanner already keeps, with its expiry date, and the Jira ticket with its history. Both are dated, and both can be edited afterwards. An exception's reason and expiry are rewritten in place, and a ticket shows today's CVSS, not the KEV listing and EPSS score you decided on. A record never changes after it is written. The day's KEV status, EPSS and CVSS are frozen and hashed with it, and your next call is a new version in the same chain while the old one stays readable. Your scanner may show a patch publication date. The record puts that date beside your call and your install, under our server date, on one page. The cards below show where each part counts.
6.3.3.b sets your installed patches against the vendor's latest. The record holds the other half: the day the vendor released the fix, in your words with the advisory as its receipt, and the day you recorded the install, dated by our server. Where the install fell inside the month reads off one page.
A finding with no vendor fix can sit open across two quarterly scans. The 11.3.1 guidance says "additional documentation may be required" to show it is being resolved. The first version predates both scans, and each later version shows the work between them.
At Custody, the organisation's register returns every open compensating-control record as a complete set, not a search result. Your QSA reads the register through a Custody grant, not a copy you forward. When your QSA reviews one, that review joins the chain as a dated receipt. The day's evidence is frozen and hashed with each version. Your QSA can recompute the hash from the export to see it is intact. The record logs each time they open it.
Decisions arrive one at a time from the CVE page, or in bulk from your scanner export or ticketing over an API that can only add. The API is in every tier, Free included. See what each tier keeps. For the whole compliance lead's view, including what the public record said on any past date, start at Compliance and audit. For the record format itself, see the Decision Vault.
The same exception under other standards: SOC 2, ISO 27001, NIST 800-53, FedRAMP and security questionnaires. All six start from the compliance hub.
The record opens with that CVE's facts already filled in: KEV status, EPSS and its date, weakness class, fixed versions, each from its public source. Our server dates it. Sign in with email, Google or GitHub to keep it. The first 100 records are free. Practitioner, $124.50 a month, keeps 500. Custody, $10,000 a year, is unlimited and adds the organisation register your QSA reads. Both are founding prices.