Fieldwork starts next week. The auditor's sample has 25 vulnerabilities on it, and two went past the remediation SLA your own policy sets. For each one they will ask for the approved exception: justification, compensating control, approver, approval date, review-by date, proof of review and final disposition. Then they read the approval date against the one your policy set. For every finding still inside its SLA, a decision record answers that question with a date our server sets, before your policy date. For the two already past it, here is what still holds.
Approved a deferral in Slack during an incident? Here is what holds.
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.
The Trust Services Criteria belong to the AICPA. The deadline your auditor holds you to is not in them. It is in your own vulnerability management policy, carried into the audit through your system description. Most teams miss this about a SOC 2 finding: you wrote the rule you are tested against.
| Reference | What it says | What it means for a finding you did not patch |
|---|---|---|
| CC7.1 criterion | "To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities." | Detection. The criterion says nothing about how fast you remediate. |
| CC7.1 point of focus, as revised in 2022: Conducts Vulnerability Scans | "Action is taken to remediate identified deficiencies in a timely manner to support the achievement of the entity's objectives." | "Timely" appears here, in a point of focus. No number of days appears anywhere in the criteria. Older copies carry the 2017 wording of this point. |
| TSP 100 .07 status of points of focus | "Use of the trust services criteria does not require an assessment of whether each point of focus is addressed." | Points of focus guide the auditor. They are not a checklist you are graded on. |
| CC5.3 point of focus: Performs in a Timely Manner | "Responsible personnel perform control activities in a timely manner as defined by the policies and procedures." | This is where your remediation SLA lives. "Timely" is measured against your policy, and the exception process in that policy is part of the control. A type 2 opinion also covers whether controls were suitably designed, so an SLA too slow for the commitments you make is a design question, not a free pass. |
| DC 200 .04 and DC2 description criteria | Management "is ultimately responsible for developing, implementing, and operating the service organization's system", and discloses "the service commitments it makes to user entities and the requirements it establishes for the functioning of the system used to deliver those services" (DC2 guidance). | The criteria are fixed. The controls, the SLA and the exception process under test are yours. |
| CC3.2 point of focus: Determines How to Respond to Risks | "Risk assessment includes considering how the risk should be managed and whether to accept, avoid, reduce, or share the risk." | Accepting a risk is a recognised response. A documented decision is what makes it one. |
| CC4.2 point of focus: Monitors Corrective Action | "Management tracks whether deficiencies are remedied on a timely basis." | Deficiencies here are internal control deficiencies. A late finding with no approved exception becomes one, and management tracks its correction. |
| CC8.1 point of focus: Manages Patch Changes | "A process is in place to identify, evaluate, test, approve, and implement patches in a timely manner on infrastructure and software." | Patch management sits under change management. The patches you did apply are evidenced by change tickets. |
Your promises count too. If you commit to customers that you meet the requirements of a framework, TSP 100 .06 says management and the auditor "are likely to consider the requirements of the process or control framework as additional points of focus." What you promised becomes what you are measured against.
An auditor testing a type 2 period does not ask why a CVE is still unpatched. They ask you to show that you did what your policy says you do with the things you did not patch. The request usually arrives in this order.
| What they ask for | What it tests |
|---|---|
| 1. The policy. Remediation timeframes by severity, and the exception procedure: who may approve, what an exception must contain, how long it lasts, how often it is reviewed. | The rule you wrote. Everything after this is measured against it. |
| 2. Scan output for every cycle in the period. | That detection ran as stated. |
| 3. The population. Every finding in the period, reconciled from scanner export to ticket tracker. | Completeness. The auditor has to be satisfied the list is whole before sampling from it. |
| 4. The sample, weighted to critical and high. For each: detected, remediated, inside the SLA or not. | Whether your timeframes held. |
| 5. The approved exception for every sampled finding past its SLA: justification and the risk assessment behind it, compensating control, approver, approval date, review-by date, proof the review happened, final disposition. | The one that decides it. Was the approval in place before the SLA lapsed, or written for the audit? |
| 6. Monitoring. Reports of overdue findings reaching the people responsible. | The CC4.2 point of focus: an overdue finding is a deficiency in your remediation control, and management tracks whether it is remedied on a timely basis. |
A finding remediated late, under an exception approved by the role your policy names, in place before the SLA lapsed, and reviewed since. That is your process working as written, and that is what lets the auditor write "no exceptions noted".
The auditor writes it into the tests of controls. Management may answer it in writing, in its own response section of the report. Your own customers read both during procurement.
"An exception or deviation is when the auditor performs a test and identifies a control activity that was not operating effectively."
SANS, from its guidance on reading SOC 2 reports.
Same word, two meanings. Your exception is a risk you accepted under your policy. Theirs is a control that failed its test. The first, done on time, is what keeps the second out of the report.
Nothing honest moves an approval date, ours included, so the deviation stays in this report. What you control is the response beside it. Management's written answer can cite a decision record made the day you found the gap: the risk accepted, the compensating control, the approver, and a date our server set. The corrective action is the change behind it, and the CC4.2 point of focus asks management to track that remedy. From that day every exception you carry is dated, and the next sample is tested against records rather than tickets.
Before sampling anything, the auditor has to be satisfied the population is whole. When they rely on information you produce, they have to judge whether it is reliable, including whether it is accurate and complete. So the scanner export is reconciled against the ticket tracker, finding by finding. That test usually passes. The one after it is where a deferral fails.
| What gets handed over | Approved before the SLA lapsed? |
|---|---|
| The reconciled population, scanner export against the tracker | Not shown. It proves every finding is on the list. It says nothing about when any exception on the list was approved, or whether one was. |
| An approval in a Slack thread, given during an incident | The timestamp, yes. The approval, only if you hold a role your policy lets approve and the message carries what an exception must: the compensating control and a review-by date. Messages can be edited, and the auditor samples from your tracker, not your chat. What holds is a record made before the SLA lapses, with the thread linked in its rationale and its proof link in the ticket. Tonight: record that CVE as Deferred, paste the thread link and the compensating control into the rationale, and set a review-by date. It is dated tonight under your signed-in name.If your policy names a different approver, at Custody they sign in and add their approval as a new version of the same record before the SLA lapses, because you and the approver work on one shared record. On any tier, send the record's proof link to the approver your policy names first thing tomorrow, and have their approval land in the exception ticket before the SLA lapses. |
| A ticket moved to "Risk Accepted" | Only as far as its history goes. The created date dates the ticket, not the approval. The status change is the timestamp that counts, and when the approval was chased for the audit, that change is dated the week fieldwork began. Read against the policy date, that is an approval written for the audit. |
| An accept rule in your scanner, with an expiry date | Yes, if it was made in time. It dates the rule and can expire it. It holds a comment, not the evidence of the day, and it stays accepted when CISA lists the CVE. A decision record keeps the evidence of the day beside the call, and a watch alerts you when KEV or EPSS moves, so a CISA listing reaches the approver before the review-by date and not at fieldwork. Accepted findings can drop out of a default export, so check the population still counts them. |
| A risk acceptance form in a GRC suite, with an e-signature | Yes, if it was signed in time. It dates the signature over what the approver typed. Signed after the SLA lapsed, it is the deviation with a signature on it. A decision record adds what the form does not hold: the day's KEV, EPSS and version ranges frozen and hashed beside the call, a date our server sets that no admin on your side can set earlier, and a watch that alerts the approver when KEV or EPSS moves before the review-by date. |
When neither answer holds, this is the line the auditor writes into the tests of controls.
"For 2 of 25 sampled vulnerabilities, remediation exceeded the policy timeframe and no approved exception was documented."
Illustrative, in the shape auditors write deviations. Yours will carry your auditor's wording.
If a deferred vulnerability is later exploited, the deferral becomes part of that incident's history. For an identified system incident in a type 2 period that came from a control not suitably designed or not operating effectively, or that otherwise caused a significant failure to meet your service commitments and system requirements, management's description discloses the "nature of each incident", the "timing surrounding the incident", and its "extent (or effect)" and disposition. When you accepted the risk, and on what evidence, is part of that timing. The on-call engineer who approved the deferral at 3am is the person that record protects. Made the same night, it shows the call, the signed-in name and the KEV and EPSS values of that day, before anyone knew how it would end.
A worked example on a real CVE. A service comes into scope this period, and its first scan flags CVE-2023-44487, the HTTP/2 rapid reset denial of service, in an internal Go service. Your policy gives a High 30 days. Detected 2026-08-12, so the policy date is 2026-09-11. On 2026-08-26 your VP of Engineering records the call.
Outside traffic reaches this service only through the edge load balancer, which carries its vendor's rapid reset mitigation and caps stream resets on each client connection before anything is forwarded. The service's own HTTP/2 listener is still vulnerable: it is pinned to a vendor SDK that does not yet build on a fixed Go toolchain (Go 1.21.3 or 1.20.10, with golang.org/x/net 0.17.0). Rebuild when the vendor ships, and before the review date.
CISA KEV listed, added 2023-10-10, CISA due date 2023-10-31
EPSS 0.99999, unchanged since FIRST's model update of 2026-06-15
Weakness CWE-400, uncontrolled resource consumption
CVSS 3.1 7.5 High (NVD), network, no privileges
Ranges nghttp2 before 1.57.0, netty before 4.1.100; first unaffected jetty 9.4.53, 10.0.17, 11.0.17, 12.0.2
Read the snapshot again. The approver knew this CVE was on CISA's list of known exploited vulnerabilities, and that EPSS put the probability of exploitation activity in the next 30 days at 0.99999. They judged the compensating control sufficient anyway. The record does not make that call look safe. It makes it look considered, on the day, with what was knowable then. That is the risk response the CC3.2 point of focus describes, informed by the "use of intelligence sources to identify newly discovered threats and vulnerabilities" that a CC7.2 point of focus names, and written down when it was made.
The vendor ships an SDK build on Go 1.21.3. The service is rebuilt on it and deployed under change ticket CHG-2291. Your VP of Engineering records the new verdict, Not affected, with the ticket in the rationale. Our server dates it. It carries version 1's SHA-256, and version 1 stays readable beside it. The finding closes three days inside your policy date. Had the vendor shipped after 2026-09-11, version 1 would be what the auditor tests at item 5.
| What the auditor tests | Where the record answers it |
|---|---|
| Justification, and the risk assessment behind it | The verdict and rationale in the approver's words, with the evidence snapshot beside them: each value with its source and its date. |
| Who approved | The actor: the signed-in identity that made the record. |
| Approval before the SLA lapsed | The record's date, set by our server when the record was made. Nobody on your side can set it earlier, and here it sits 16 days before the date your policy set. |
| Expiry and review | Review-by. The record comes due on that date, and a watch alerts you if KEV or EPSS moves before it. The review is a new version in the same chain, dated by our server, and the version before it stays readable. That new version is the proof the review happened. |
| Proof the review happened | Version 2, dated 2026-09-08 by our server. It names the change ticket and carries version 1's SHA-256. |
| Final disposition | Version 2's verdict: Not affected, after the rebuild. It joins the chain beside version 1, which stays readable. |
| That nothing in it has changed since | The chain. Each version carries the SHA-256 of the one before. Your auditor recomputes every hash with a standalone verifier and sees the order of every version and that nothing was altered or removed. The values in the snapshot check against their public sources wherever those sources keep history: FIRST publishes EPSS by date. |
Scan output, the population and the reconciliation between them are your scanner's and your tracker's evidence. So are the findings patched on time: change tickets and rescans prove those. Paste a record's proof link into the exception ticket, and your auditor opens the evidence from a ticket they already sample.
Your timeframes, your exception process and the roles in it are yours, stated in your system description. The record names the signed-in identity that approved. Matching it to the role your policy assigns stays with you.
Only the service auditor, a CPA, gives an opinion on whether your controls "operated effectively". We make no claim of compliance for you or anyone. Your auditor validates the record. We produce it, and custody starts on a date that every record shows.
Accept, defer or mitigate: one record per exception, dated by our server, bound to the evidence of the day, watched until review. Access reviews, change management and incident response sit outside it.
The date cuts both ways. A record made after your policy date carries that later date, and the auditor tests it as late. One made before it, by the role your policy names, answers item 5, because nobody could have made it later and dated it earlier. A type 2 tests a period, so start before the period ends.
A SOC 2 report is read by the people who buy from you. A deviation in its tests of controls, with management's response beside it, goes into every security review that asks for the report, for as long as that report is the current one. That is what an exception written for fieldwork puts at risk, and it is paid for in procurement, not in audit fees.
A decision record is made at the moment you decide, from the CVE page or from the tool you decided in, and it is already there when the auditor asks. The tiers follow what a type 2 tests.
On every tier, records cannot be altered or removed, by anyone, including you. A change is a new version in the same chain, and the one before it stays readable.
| Tier | What it gives you in a SOC 2 type 2 |
|---|---|
| Free $0, named Community on the pricing page | The sampled item. A dated record for each exception past its SLA, ready for request item 5. Start free |
| Practitioner $124.50/mo or $1,245/yr at the founding price, locked for life. Standard $249/mo, $2,490/yr. | The period. Each review and each new version lands inside the period with its own date, and review-by dates come due across it. A type 2 tests whether the control operated across the period. This trail is what that looks like, against the CC5.3 and CC4.2 points of focus. Room for 500 exceptions from your scanner, brought in through the API, one call per exception, each dated the day it lands; Custody has no limit. Start Practitioner |
| Custody $1,000/mo or $10,000/yr at the founding price, locked for life. Standard $2,000/mo, $20,000/yr. | The auditor's own access. A grant names your auditor, who signs in, sees the sampled records and nothing else, and leaves you a dated receipt of each record they opened. A deterministic filter returns every deferral past its review date and shows it is the complete set you recorded. Set up auditor access |
If you assemble the auditor's request list, the compliance and audit brief covers what was knowable on a past date. The record format itself is open: what a decision record is. ISO 27001, PCI DSS, NIST 800-53 and FedRAMP test the same exception their own way, and each has its own page.
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.