Cyber security risk analysis has an enterprise costume, heat maps, registers, quantitative models, and a working core that fits a small organisation's afternoon: list what you have that matters, name what could plausibly happen to each, judge how likely and how bad from your own facts, and decide, in writing, what you will do about the ones that matter. The costume is not wrong at scale; at ten or thirty people it obstructs, and the obstruction has a cost, because the analysis's real product is the signed decision list, the owner's own record of what is accepted, what is insured, and what is being fixed by when. Regulated organisations, healthcare among them, are required to conduct and document exactly this. This guide gives the afternoon method in four steps, the honesty rules that keep it from becoming theatre, and what to do with the page it produces.
Steps one and two: assets and events
Assets, listed in an hour: the systems whose death stops work (the books, the job files, the booking system), the data whose leak is an incident (client records, payroll, anything regulated), the money paths (who can move it, on whose instruction), and the accounts that control everything else (mail admin, domain registrar, banking). Events, named plainly against each: taken over, destroyed, leaked, defrauded. The discipline is plain language, the mailbox gets taken over and payment instructions get sent from it, because plain sentences can be judged and priced, while threat taxonomies get admired and filed.
Steps three and four: judgement and decisions
Likelihood is judged from your own facts, not industry dramatics: money moves on emailed instructions here, or does not; factors are enforced, or are not; backups restored last quarter, or did not. High, medium, low against each event, with one sentence of why. Impact the same: what a week without the system costs, roughly, in your own numbers. Then the decision pass, and this is the analysis's entire point: for each high-and-high, one of four verbs, fix (with a date and an owner), transfer (insurance, with the policy checked against the event), accept (in writing, with a review date), or avoid (stop doing the risky thing). Signed, dated, one page.
The honesty rules, and the page's afterlife
Three rules keep it real. Facts over fears: every likelihood judgement cites a checkable fact about your organisation. Joins over systems: the events that hurt cross seams, the leaver, the payment, the restore, so judge the seams, not just the boxes. And decisions over documentation: an analysis that ends without signed verbs is a mood board. The page's afterlife is the programme: each fix lands in a procedure or a control, each acceptance joins the exceptions list, and the annual re-run reads last year's page first. The policy set that holds all of it, the procedures, the exceptions, the review dates, is what the free sheet on this site counts from your facts and Hardenvo Pro generates, so next year's afternoon starts from this year's truth.
Questions people ask about cyber security risk analysis
How do I do a cyber security risk analysis for a small business?
Four steps in an afternoon: list assets (systems, data, money paths, controlling accounts), name plain-language events against each (taken over, destroyed, leaked, defrauded), judge likelihood and impact from your own facts, and sign decisions: fix, transfer, accept or avoid.
What makes a risk analysis honest?
Every likelihood cites a checkable fact (factors enforced or not, restores tested or not), seams are judged as well as systems, and the output is signed decision verbs with dates, not a heat map. One page, dated, is the deliverable.
Is a documented risk analysis required?
In regulated settings, yes, HIPAA's Security Rule requires a documented risk analysis for organisations handling protected health information, and insurers and client questionnaires increasingly ask for one everywhere else. The afternoon version satisfies the honest core.