Shipping with a known weakness is sometimes the right call. What makes it defensible is a short written record: what the risk is, who accepted it, what limits the exposure, when the decision expires, and what the fix plan is. Without that record, accepted risk becomes forgotten risk.
When a record is worth writing
Use one when the team knowingly releases something that does not meet its own standard, and the gap could matter if exploited. A cosmetic issue does not need a record. A missing rate limit on a login endpoint does.
Writing it is not an admission of failure. It is how an organization makes a trade visibly instead of by accident.
The template
Keep it to one page. Copy these headings.
Title and date. What the decision is about and when it was made.
The risk. One or two sentences in plain words. What could happen, to whom.
Why we are shipping anyway. The business reason, such as a contractual date or a customer commitment. Be specific.
Limits on exposure. What reduces the chance or damage in the meantime: a feature flag, a small initial audience, extra monitoring, a manual review step.
Likelihood and impact. Coarse low, medium, high, with one line of reasoning each.
Owner of the risk. A person with authority over the product, not only the engineer who raised it. See who should own and accept a security risk.
Expiry date. When the decision must be revisited. Pick a date, not "soon."
Fix plan. The ticket, the sizing, and the sprint or quarter it is scheduled for.
Signals that change the decision. Events that trigger early review, such as public disclosure of a related flaw, an unusual spike in traffic to the endpoint, or a customer complaint.
Make the expiry real
An expiry date only works if something enforces it. Put the date in the tracker as a due item, or in the risk register, and assign a person to be reminded. When the date arrives, there are three honest outcomes: fix it, extend with a new record and fresh reasoning, or retire the risk because circumstances changed.
Silent extension is the failure mode. If the same record keeps rolling forward untouched, escalate.
Check whether the risk is as real as it looks
Before you sign, verify the exposure. For dependency issues, ask whether the vulnerable code is reachable and whether an exploit is known. The demo below walks through an exploitability check. Click through it and notice how the answer can change the likelihood line in your record.
Try it yourself
Click through it at your own pace, or open it full screen.
Where to store records
Keep them with design documents or in the repository, linked from the ticket. They should be searchable by service name so the next engineer on that code finds them.
Quick check
Who should sign a known risk decision?
Someone who owns the product or business outcome and can accept the consequences, with the engineer and security reviewer named as advisers.
What if the expiry passes and nothing is fixed?
Treat that as an escalation. Either schedule the fix, or write a new record with fresh reasoning and a new date. Do not let it roll forward silently.
Last reviewed: 19 October 2026.
