When a CVE outlives the timeline in your own procedure, the auditor follows the register row to the treatment decision and asks three things: did the person your register names as risk owner accept the residual risk, against which of your criteria, and until when? A decision record holds the answer: the owner, signed in as themselves, the criterion they applied, and a review-by date that keeps the acceptance temporary. ISO 27001 sets no patch deadline in days. Annex A 8.8 says shall, and your own procedure sets the timeline.
Compliance / ISO 27001
On call tonight and not the risk owner? Your signature is the proposal, not the acceptance, unless your procedure names on-call as an accepting role. Record the proposal. Pick Accepted under Your call and sign in as yourself. In the Why box on the next screen, name the risk owner your register lists and write that this is your proposal. That is version 1 in the worked example. On its own, version 1 is your proposal, not the acceptance. The auditor’s finding is an engineer’s acceptance with no version from the risk owner after it before the due date. The owner accepts it as the next version under their own name, and yours stays readable beneath it.
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 chain where the engineer proposes and the risk owner accepts, on one shared record, runs on Custody.
ISO/IEC 27001:2022 (incorporating Amd 1:2024) requires your risk treatment process to “obtain risk owners’ approval of the information security risk treatment plan and acceptance of the residual information security risks.” That is clause 6.1.3 f). The duty to keep documented information about it comes from the closing sentence of 6.1.3 and from 8.3. The owner has to be identified first, under 6.1.2 c) 2), and the residual risk is judged against your own acceptance criteria from 6.1.2 a) 1).
So the acceptance belongs to a named person, and the finding it produces is about the person: an acceptance given by someone with no authority over the asset. The clause never asks for a date, and 7.5.2 a) names a date only as an example of how documented information is identified. The date still matters to the sample, for a different reason. An acceptance on record before your own deadline is the 6.1.3 f) case. One written after it is the 10.2 case.
You identify the risk owners yourself. ISO/IEC 27005 defines one as a “person or entity with the accountability and authority to manage a risk”.
Authority is the test. The engineer who found the CVE can propose the acceptance. Only the person who answers for those hosts can give it. On call at 2am, and the register names someone else? Then you proposed it. Record it tonight as the proposal. Already clicked accept in the scanner or the ticket? Record it here now as the proposal, before the due date, and name the owner in Why. Tonight your record is dated by our server with the day’s KEV and EPSS frozen beside your name. In the morning, share it with the risk owner by name. They sign in and read exactly what you read at 2am. The owner accepts it as the next version, under their own name and our server's date, and yours stays readable beneath it. If your procedure lets on-call accept overnight, it names that role and the day the owner confirms.
“Information about technical vulnerabilities of information systems in use shall be obtained, the organization’s exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken.”
In 27001 the verb is shall. The should on most checklists is the ISO/IEC 27002 guidance wording. 8.8 replaces A.12.6.1 and A.18.2.3 from the 2013 edition. No clause names a number of days, and the timeline tables published online are advice, not ISO text. Your procedure sets the timeline. A defensible one states the severity bands and what moves an item between them, such as a KEV listing, when the clock starts, and who may accept an item that misses it. Clause 8.1 then asks for documented information showing the procedure was carried out as planned. For an item you are not fixing yet, that is the acceptance, on record before the date passes. On the form, Deferred is right while the fix date is still inside your timeline: that is the treatment plan. Accepted is right when the risk owner carries the residual risk past it. 6.1.3 f) asks the owner to approve both.
Risk acceptance is an “informed decision to take a particular risk”, and “Accepted risks are subject to monitoring and review.” Retention is defined as a “temporary acceptance”, and a note adds that retention “can be restricted to a certain period of time.”
An acceptance is meant to be revisited, and informed means you can show what you knew.
Reassess “at planned intervals or when significant changes are proposed or occur”, against your 6.1.2 a) criteria.
A review-by date sets a planned interval for this acceptance. A CVE added to CISA KEV after you accepted it is exactly that kind of significant change.
Your external auditor starts from your own documents: the vulnerability procedure and its timeline, the Statement of Applicability showing 8.8 applies, and your risk acceptance criteria. Then they pull a sample from the scan export, the pentest report or the risk register, pick items that ran past the timeline you set yourself, and trace each one back to a person. At stage 2, and again at each surveillance audit, it runs like this, on the item worked through below.
This was due on 14 May and it ran past that date. Show me the risk assessment, the treatment decision, and who accepted the residual risk.
Who owns the risk on these hosts? Is that the person who accepted it, and against which of your criteria?
When was it accepted? Before the due date, or after?
It went onto CISA KEV in June, before the review date. Was the acceptance reassessed?
Who can change this entry, and where is the version before it?
Four of these questions are clauses. The acceptance is 6.1.3 f). The owner and the criteria are 6.1.2 c) 2) and a) 1). The reassessment is 8.2. The last question is 7.5.3 b) and e): integrity, and control of changes. The date question is not in the standard. The auditor asks it anyway, because it separates the 6.1.3 f) case from the 10.2 case.
The finding the auditor is looking for is the wrong signatory. High Table’s lead-auditor guide to 6.1.3 uses this exact case: a system administrator accepting the risk on an unpatched legacy server, where the head of operations should have signed. Auditors may also interview the risk owner to confirm they know what they accepted. A missed timeline with no acceptance at all is a nonconformity against your own procedure, and 10.2 then asks for evidence of the corrective action.
If you run the ISMS internal audit, the decision record page shows how a record is made, exported and checked.
| What the auditor is handed | Where the trace breaks | The clause it misses |
|---|---|---|
| A risk acceptance form signed by the system administrator who holds the patch ticket | It is signed by someone with no authority over the hosts. That is the textbook finding. | 6.1.2 c) 2) and 6.1.3 f) |
| Your scanner’s accept-risk rule an accept-risk, ignore or exception rule with an approver and an expiry | It hides the finding until the rule expires, so a KEV listing, the kind of significant change 8.2 makes you reassess on, never reaches the owner. It kept none of the evidence it was accepted on, and no hash fixes the terms the owner approved, so an edit leaves nothing to check it against. | 8.2 and 7.5.3 e) |
| An approval in the GRC workflow | The log dates the click. It cannot show the acceptance was informed: the KEV status and EPSS it rested on were never kept, and nothing alerts the owner when KEV lists it later. | 27005 3.2.8 (“informed”) and 8.2 |
| An acceptance with no end date “accepted until further notice” | Nothing makes anyone look at it again. | 8.2 planned intervals, 27005 3.2.10 |
| A Statement of Applicability marking 8.8 applicable | Nothing links the sampled CVE to a treatment decision, so the auditor cannot get from the control to the item. | Annex A 8.8, read with 6.1.3 |
| A reconstruction written the week before the surveillance audit | Written after the deadline, however accurate it is. | The 10.2 case presented as the 6.1.3 f) case |
Each of these can name a person and carry a date. None of them joins up what the trace needs: the person the register names, the evidence they accepted on, and a version history nobody rewrote.
What an ISO 27001 risk acceptance has to hold, and where each item sits in a decision record. ISO prescribes no form. This is what an auditor looks for in one, with the evidence filled in for you.
| The acceptance has to hold | Where the auditor gets it from | In the record |
|---|---|---|
| The assets it covers | the register row the trace starts at | scope |
| The risk level, against your acceptance criteria | 6.1.2 a) 1) | criterion applied |
| The compensating measures | ISO/IEC 27002 8.8 guidance | rationale |
| The risk owner, by name | 6.1.2 c) 2) and 6.1.3 f) | accepted by, signed in |
| When it was accepted | not in the standard; 10.2 turns on it | set by our server when the owner signs |
| When it is looked at again | 8.2, and 27005 3.2.10 | review by |
| The evidence it rested on | 27005 3.2.8, Annex A 5.7 | evidence, frozen at signing |
| Every earlier version | 7.5.3 b) and e), Annex A 5.33 | previous version, by SHA-256 |
A worked example on CVE-2022-0492, the Linux kernel cgroups v1 release_agent flaw. Every public fact below is real and dated, and you can check each one yourself. The team, its hosts, its criteria and its decisions are an example.
A platform team finds the CVE on a fleet of legacy build hosts running a 4.19 kernel. Their procedure allows a month for a High, so the item is due on 14 May. Their acceptance criteria let an asset’s risk owner accept a residual High for one quarter when compensating controls are in place. The kernel goes in the Q3 host rebuild. The engineer on the item proposes an acceptance until then, and the register names the Head of Platform Engineering as risk owner for these hosts.
| Date | Event | Who says so |
|---|---|---|
| 2026-04-14 | The scanner flags CVE-2022-0492 on the build hosts. The procedure’s clock starts. | your scanner, your procedure |
| 2026-04-21 | The platform engineer, signed in, proposes accepting the risk until the Q3 rebuild. That is version 1. | the record |
| 2026-04-21 | The Head of Platform Engineering, signed in as themselves, accepts it. Version 2 freezes the evidence: not on KEV, EPSS 0.05238. | the record, server clock |
| 2026-05-14 | The team’s own 8.8 deadline passes, with the owner’s acceptance already on record. | your procedure |
| 2026-06-02 | CISA adds CVE-2022-0492 to KEV, with a CISA due date of 2026-06-05. The watch alerts the owner with a dated notice by email or Slack. Version 2 stays exactly as it was signed. | CISA KEV, the watch |
| 2026-06-03 | EPSS reads 0.26341. The owner reassesses and amends: patch by 2026-06-05. Version 3 carries the hash of version 2. | FIRST EPSS, the record |
| 2026-06-04 | Version 4. Fixed: 4.19.229, the first unaffected release, is on every build host. | your scanner, the record |
| 2026-10 | Scheduled: the surveillance audit samples the item. | your auditor |
CISA’s due date binds US federal civilian agencies under BOD 22-01, not you. Your procedure sets your date. This owner chose to meet CISA’s anyway, and version 4 shows the hosts fixed a day inside it.
The auditor starts at the register row, follows it to the record, and finds the acceptance given by the person the register names as risk owner for these hosts, on 21 April, 23 days before the team’s own due date. The same acceptance clicked by the engineer, with no version from the risk owner after it, is the finding.
The listing is dated, the notice is dated, and so is the amendment. Each version freezes the threat intelligence it stood on, so the auditor, and the owner at interview, read what the owner read on the day.
A change is a new version carrying the SHA-256 of the one before, and the old one stays readable. Alter a past version and the chain breaks at that point. The verifier your auditor runs on the export names that version.
The engineer on the item copies a paragraph from the record into the ticket. Paste the record’s link into the register row, so the auditor’s trace goes from row to record in one click. Share the record with your auditor by name. They sign in to open it, and the record keeps a log of who opened it and when.
An ISMS is clauses 4 to 10, a Statement of Applicability, internal audit and management review. A decision record is the answer to one sampled item inside one control. That scope is deliberate, and it is why the record is quick to make and hard to argue with.
Risk method, acceptance criteria, treatment plan and Statement of Applicability stay where they live. Records past their review-by date are a ready input to the 9.3.2 f) management review.
Every record exports as a file, with a standalone verifier that shares no code with our service. What you hand the auditor at the next surveillance audit does not depend on us still being there.
Only your external audit body rules on the ISMS. We produce the evidence artifact the sample asks for: who accepted, on what evidence, and when.
Price it against the finding, not against a tool. A sampled item past your own deadline with no acceptance on record is a nonconformity. 10.2 then asks for evidence of what went wrong, what you did about it and the result, and the auditor comes back to that evidence at the next surveillance audit. A reconstruction does not stop any of this. It is written after the deadline, so it is the 10.2 case however well it reads, and next year’s sample brings the same week round again.
The narrative can be accurate and still not answer the 7.5.3 question: whether it was changed, or written, after the fact. It cannot show what the owner knew on the day either, because the sources have moved since.
The date, the frozen evidence and the chain are complete the moment the owner accepts. When KEV or EPSS moves, the watch alerts the owner without anyone remembering to look. When the auditor samples the item, you share the record with them by name.
On every plan a record changes only by a new version, and the old one stays readable. Free: 100 records. Practitioner: 500, at $1,245 a year at the founding price, locked for life. The standard price is $2,490. Custody: no limit. Free covers your own acceptances, against real CVEs. Practitioner is the room for a scanner’s exception list, 500 records, each dated the day it lands. Send each exception from your scanner through the API, which is in every tier, and each lands as its own dated record. Custody is $10,000 a year at the founding price, locked for life. It is where the ISO trace runs on one shared record: the engineer who proposes and the risk owner who accepts, a shared register for the 9.3.2 f) management review, records nobody can delete, and attestation. Prices for every plan are on the pricing page.
Running the surveillance audit? Share a record with your auditor by name. They sign in, and the record logs who opened it and when.
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 chain where the engineer proposes and the risk owner accepts, on one shared record, runs on Custody.
On call tonight and not the risk owner? Your signature is the proposal, not the acceptance, unless your procedure names on-call as an accepting role. Record the proposal. Pick Accepted under Your call and sign in as yourself. In the Why box on the next screen, name the risk owner your register lists and write that this is your proposal. That is version 1 in the worked example. On its own, version 1 is your proposal, not the acceptance. The auditor’s finding is an engineer’s acceptance with no version from the risk owner after it before the due date. The owner accepts it as the next version under their own name, and yours stays readable beneath it.