Few phrases in a security questionnaire cause more procrastination than "risk assessment". It sounds like something that requires a framework, a methodology and someone qualified to run a workshop.
It is a table. What could go wrong, how likely is it, how bad would it be, and what have you decided to do. An afternoon produces a genuinely useful one, and a short honest table beats a long generic one comfortably.
Why it is worth doing for yourself
The questionnaire is the reason most teams start, and it is the least interesting reason to do it.
The real value is that it forces the difference between a risk you have accepted and a risk you have not noticed. Both look the same day to day. They are completely different when something happens: the first is a decision you can explain, the second is a gap you have to account for.
Writing the list also tends to surface one or two things nobody had said out loud. Most teams doing this for the first time find at least one risk everyone privately knew about and nobody owned.
The five columns
Everything you need fits in five columns. Resist adding more.
- Risk. One sentence, describing a concrete event rather than a general worry.
- Likelihood. Low, medium, high. Do not use numbers; they imply a precision you do not have.
- Impact. Low, medium, high, judged by consequence to the business rather than by technical severity.
- Decision. Mitigate, transfer, accept or avoid.
- Owner and date. A person, and when it was last looked at.
The decision column is the one that makes the document worth anything, and those four options are the whole vocabulary:
Mitigate: do something that reduces the likelihood or the impact. Most rows end up here.
Transfer: move the consequence to someone else, usually through insurance or a contractual term with a vendor.
Accept: decide it is tolerable and move on. Legitimate and underused, because teams feel every row must have an action. A row reading "accepted, reviewed annually, owner Jane" is a stronger position than an invented mitigation nobody will do.
Avoid: stop doing the thing that creates the risk. Rare, and occasionally the right answer, particularly for data you collect and do not use.
Writing risks that are actually useful
The difference between a useful row and a filler row is specificity.
"Cyber attack" is not a risk. Nobody can assess its likelihood, nobody can mitigate it, and it tells a reader nothing. Compare:
- An API key committed to our repository is found and used to read customer records.
- Our single database has an unrecoverable failure and the most recent restorable backup is a day old.
- A departing contractor retains access to production because nothing triggered offboarding.
- A vendor holding customer email addresses is breached and we learn about it from the news.
- The one person who knows how the deployment works is unavailable for two weeks.
Each of those you can reason about. Each maps to a decision. Several map to other items in this guide, which is not a coincidence: the guide is approximately a list of the risks small teams share.
Where to get your rows
Four prompts produce most of a first list.
What would hurt most? Losing customer data, losing the ability to serve, losing the ability to bill. Start at the consequence and work backwards to the events that cause it.
What depends on one person? Every genuine bus-factor of one is a risk, and these are chronically absent from formal assessments because they are uncomfortable rather than technical.
What depends on one vendor? Your vendor list is a risk list in another format. Anything critical with no alternative belongs here.
What has nearly gone wrong? Near misses are the best available evidence about your actual exposure, and they are free. The deploy that almost went to the wrong environment, the backup that turned out to be a week stale, the alert nobody saw for six hours.
Scoring without pretending
Likelihood and impact are judgements. The scale exists to sort the list, not to produce a number you can defend to three decimal places.
A usable calibration: high likelihood means you would not be surprised if it happened this year; medium means plausible within a few years; low means it would be genuinely surprising. For impact: high threatens the business or customers' data, medium means significant disruption or cost, low means annoying.
Anything high-high gets attention this quarter. Anything low-low can be accepted and left alone. The middle is where judgement lives, and that is fine: the point of the exercise is to have had the conversation, not to eliminate the judgement from it.
Keeping it alive
A risk assessment written once and never revisited is worse than none, because it creates a false impression that the question has been handled.
Three triggers are enough. Review annually, put it in a calendar. Review after an incident, because an incident is evidence that a likelihood estimate was wrong. And review when something material changes: a new product area, a new critical vendor, a significant change in what data you hold.
Each review should be quick. Read the rows, change the estimates that have moved, close what is done, add what is new. Twenty minutes, and the date on the document is itself part of what makes it credible.
Two mistakes that make the document useless
Scoring to reach a conclusion. It is tempting to mark things low-likelihood because the alternative implies work. The document is for you before it is for anyone else, and a register calibrated to avoid uncomfortable rows tells you nothing you did not already believe. If a risk feels high and the mitigation is expensive, write it down as high and accept it explicitly. That is a legitimate position; a downgraded score is not.
Treating it as a security document. The most likely things to damage a small company are frequently not attacks. A key person leaving, a critical vendor failing, a backup that turns out not to work, a single misconfiguration deployed on a Friday. A register listing only adversarial scenarios has skipped the probable in favour of the dramatic.
The test for both is whether anything in the document surprised you. If the finished list contains nothing you had not already comfortably assumed, the exercise was performed rather than done.
What good looks like to somebody reading it
A customer's security reviewer is not looking for a perfect risk profile. They are looking for evidence that you have thought about this deliberately.
Twelve specific rows, honest scores, a mix of mitigations and explicit acceptances, named owners, and a review date within the last year reads as a team that knows its own exposure. Forty generic rows all marked "mitigated" reads as a document produced to answer a question, and experienced reviewers can tell the difference immediately.
The afternoon
Open a spreadsheet. Five columns. Work through the four prompts above and write down what comes out, aiming for ten to fifteen rows. Score them quickly and do not agonise. Put a name and a date against each one.
You will finish with something imperfect, which is the correct outcome. It is a document that can be improved, and every version of it after the first takes twenty minutes.