The deal closes this quarter. Your customer's risk analyst read your Yes to the policy exception question and wrote back: show us one vulnerability you chose not to patch, who approved it, when it gets reviewed, and that this was not written for us. Grant them one decision record. It names who approved the call and when it is reviewed, it was dated when the call was made rather than when they asked, and it shows them nothing else you carry.
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.
A questionnaire imposes nothing by itself. It asks you to represent your controls, and your customer tests the representation. On the Cloud Security Alliance's CAIQ v4.1, released with the Cloud Controls Matrix v4.1 on 27 January 2026, four questions, under three controls, decide what happens to a vulnerability you chose not to patch yet.
“Is an approved exception process mandated by the governance program established and followed whenever a deviation from an established policy occurs?”
“Are processes, procedures, and technical measures defined, implemented, and evaluated to enable scheduled and emergency responses to vulnerability identifications (based on the identified risk)?”
“Is a procedure implemented to manage exceptions, including emergencies, in the change and configuration process?” Then: “Is the procedure aligned with the requirements of the ‘GRC-04: Policy Exception Process’?”
The CCM v4.0 control behind it, which the v4.1 question restates, says it without the question mark: “Establish and follow an approved exception process as mandated by the governance program whenever a deviation from an established policy occurs.” A deferred patch is a deviation. CCC-08.2 routes the change exception, which is where a deferred patch usually lives, straight back to it. Every one you carry is an exception that process should have caught.
If you publish on the CSA STAR Registry, your Yes is public and dated. A Level 1 self-assessment is made “publicly available, promoting industry transparency” and “STAR Self-Assessments are updated annually.” The records standing behind that Yes should carry dates earlier than it.
The Shared Assessments SIG asks about vulnerability management too. Its 21 risk domains include Threat Management. SIG question text is licensed to members, subscribers and licensees, so we name it here rather than quote it. EDUCAUSE HECVAT 4 asks about vulnerability management for higher education. You may also get the Vendor Security Alliance's questionnaire, or a spreadsheet your customer's third-party risk team wrote themselves. The wording changes. The follow-up does not.
Two numberings are live at once. CSA requires v4.1 for new STAR applicants from July 2027 and to keep a registration from January 2028, so until then the same questionnaire reaches you in both. GRC-04 and TVM-03 keep their IDs. The later TVM controls do not, because v4.1 inserted two new ones.
| What the control asks | CCM v4.0 | CAIQ v4.1 |
|---|---|---|
| Policy exception process | GRC-04 | GRC-04.1 |
| Scheduled and emergency remediation | TVM-03 | TVM-03.1 |
| Threat analysis and modelling | not present | TVM-04.1, new |
| Risk-based remediation priority | TVM-08 | TVM-09.1 |
| Threat response | not present | TVM-10.1, new |
| Tracking and reporting, with stakeholder notification | TVM-09 | TVM-11.1 |
| Vulnerability metrics | TVM-10 | TVM-12.1 |
No audit period stands behind a questionnaire, and no engagement letter. The person testing your answer is your customer's third-party risk or security analyst, and the deadline is the signature date on your deal. They already have your vulnerability policy. You attached it. What they ask for next is proof that the policy ran.
The published test procedure is CSA's CCM v4.0 auditing guideline for GRC-04. After examining the exception policy, an assessor is told to “identify and confirm that exceptions to policies are tracked, authorised, and evidenced” and to “confirm a review of policy exceptions takes place on a periodic basis by appropriate management.” Tracked, authorised, evidenced, reviewed. Four words, and a spreadsheet row satisfies the first one.
Out in the deal, the follow-up usually reads like this:
Are any critical or high vulnerabilities open past your remediation SLA? Which ones, and why?
Send us one example of an approved exception. Who approved it?
What compensates while it stays open, and when is it reviewed?
Do you run MOVEit Transfer? Were you affected by CVE-2023-34362, and what did you decide?
Every version converges on the same request. Show one real exception. Prove someone accountable approved it. Show its review date. Show it was not written for this questionnaire.
If your CAIQ answers sit inside a STAR Level 2 attestation, which combines “SOC 2 engagements using criteria from the AICPA ... and the CSA Cloud Controls Matrix,” a SOC 2 auditor tests them across a period. That is a different mechanism, and the SOC 2 page covers it.
CVE, owner, “risk accepted”, and a date somebody typed. The analyst asked for one exception and now holds all of them, and still cannot tell whether the date on the row they wanted was typed in June or last night.
The questionnaire tool or trust center that answered GRC-04.1 holds the Yes and the policy PDF. It stores the answer, not the decision: no CVE, no approver, no date the call was made. The analyst already has everything in it.
Your CISO signs the honest story, rebuilt from chat under a signature deadline. It is dated after the question. If your CAIQ is on the STAR Registry, it is also dated after your public Yes, and that is the order an analyst notices.
The register proves too much. The library and the letter prove too little. None of the three hands the analyst one exception, dated when it was decided, and nothing else.
The vendor and its people below are fictional. The CVE is real, and every snapshot value is copied from the CVE-2023-34362 record in our index.
An example SaaS vendor closes an acquisition in May 2026. The company it bought runs a customer file-drop service on MOVEit Transfer 2020.0, and the integration inventory turns up CVE-2023-34362 on it. The record publishes a fixed version for every branch from 2021.0 up and none for 2020.0, so there is nothing to patch to without migrating those customers. The vendor decides to move them onto its own platform and switch the server off. Until then the web interface is closed, because the CNA's record says exploitation “can occur via HTTP or HTTPS”. On 10 June 2026 the CTO records the call.
Evidence frozen at recording. What the public record held on 10 June, sourced and dated value by value.
2020.0 sits inside the record's published range, moveit transfer < 2021.0.7. The version check on the CVE page says where a version sits in the record, not whether a deployment is exploitable. The call on exploitability belongs to the CTO, and the record carries that name.
The customer's analyst asks whether you run MOVEit Transfer, and what you decided about CVE-2023-34362. It has been on CISA's list since June 2023, with ransomware use known.
You grant VDR-0214 to that analyst by name. They sign in with GitHub, Google or an emailed link, which tells us who read it, and they see that one record. The hostname redaction is disclosed with the original digest kept, so they can see what was removed and that nothing else moved.
Recorded 10 June by a named person, with a review date. The KEV listing, the ransomware use and the public exploit were all on the record that day, so the call never rested on a low score. It rested on the closed web interface and the retirement date, and both are written into it. The CVE's page now reads EPSS 0.99934, after FIRST's new model on 15 June. The call did not depend on either number.
What goes in the questionnaire cell. One line. The grant carries the rest.
Progress MOVEit Transfer 2020.0, acquired file-drop service. Mitigated: HTTP and HTTPS denied, SFTP only, server retires 2026-07-31. Recorded 2026-06-10 by the CTO. Review by 2026-07-31. Decision record VDR-0214 granted to you by name.
And you know they read it. The analyst signs in to open the record, and you hold a dated receipt that they did. If they mark it reviewed, that signature joins the chain. The grant is a dated notice to the stakeholder who asked, and the receipt shows it was opened: one entry in the stakeholder notification CAIQ v4.1 TVM-11.1 asks your reporting process to include.
You cannot type the date, and the evidence agrees with it. Our server sets it when you record. The snapshot holds EPSS 0.94254 under model v2025.03.14. FIRST replaced that model on 15 June, so a record made later would carry the new number. FIRST publishes every day's scores, and the analyst can check 10 June at the source. Export the record and they can run the published verifier on it: one file, Node and nothing else, no packages and no network, written from the open format document rather than from our service code. It recomputes each SHA-256 link from the record's first version to its last and names any version that does not match. “Intact since the first version” means that check passes.
No record from June, or a CVE in this week's news and a prospect asking if you are affected? Record the call now, as not affected, mitigated or patch by. It reads recorded today, by our clock, and the analyst sees that. It still names the approver, carries a review date, freezes today's KEV listing and EPSS with their sources, and goes to that one analyst with nothing else from your register. A letter carries today's date too. It carries none of the rest.
Record each deferral the day you make it. When the next analyst writes back after your Yes, the record is waiting, with a date earlier than their question and a review date they can hold you to.
One exception, nothing else disclosed. The record format is open, and yours whether or not you ever pay.
A decision record is the evidence behind your Yes. It answers the follow-up to the CAIQ v4.1 exception and remediation questions (GRC-04.1, CCC-08.1, CCC-08.2 and TVM-03.1) and to their SIG and bespoke equivalents: one exception, approved, dated, reviewed, with the facts it stood on.
Which exception, and why. Who approved it. When it was decided, by our clock. When it is reviewed. What was known about the CVE that day. That none of it has changed since.
Authorised Evidenced Reviewed
“Which ones are open past your SLA?” asks for a set, not a record. Record each finding past SLA as an exception and the Custody shared register holds the set. It answers “every exception past its review date”, and a deterministic filter beside the search shows the set is complete rather than whatever search surfaced.
Tracked
Not the questionnaire answer: a record does not make a Yes true. Not your TVM-01 policy (CAIQ v4.1 TVM-01.1) or your GRC-04 exception policy. Not scan or penetration test evidence, or the metrics CAIQ v4.1 TVM-12.1 asks for. Not a SOC 2 report or an ISO 27001 audit report, which a customer may accept in place of a questionnaire.
The sign-off stays the analyst's. A record supports that sign-off and never stands in for it. It hands the analyst something they can check before they sign.
A record is dated the day it is recorded. An exception carried since March and first recorded today reads as recorded today, and the analyst can see that. An analyst can set each record's date against the date of your Yes.
Who does what. Recording a decision, with its evidence frozen and a proof link, is in the free tier. A proof link opens for anyone it is forwarded to and carries no receipt. A grant names one reader, who signs in, sees that record and nothing else, and leaves you a dated receipt. Granting, redaction that keeps the digest, the receipt and the shared register are Custody, because a questionnaire is answered by an organisation, not one person. See what each tier includes.
The question arrives either way. What changes is what answering it costs you, and what the analyst holds afterwards.
| What you do instead | What it costs you | What the analyst gets |
|---|---|---|
| Send the exception register under NDA | Every other exception you carry, disclosed to prove one, and an NDA to negotiate in the week the deal is meant to close | A list of typed dates they cannot check |
| Have your CISO sign a letter | A senior signature on a story rebuilt this week | A paragraph dated after their question, citing today's numbers |
| Point them at the trust center | Nothing new | The policy and the Yes they are already testing |
| Grant one decision record | The minute you spent deciding, and one grant | One exception: attributed, reviewed, its evidence frozen, dated when the call was made, and nothing else |
And it compounds. The record you grant for this deal answers the next customer's analyst without being written again. Your STAR self-assessment renews annually, and every deferral you record between now and then is dated before next year's Yes.
If you answer questionnaires for the sales team, start from the compliance and audit brief.
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.