Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →Most risk registers are written once and never opened again. This is how to build one that produces treatment decisions, controls and evidence, and survives an auditor asking where a number came from.
A risk assessment is useful when three things are true: the method is written down before the scoring starts, every risk has a named individual owner rather than a team, and every risk resolves into a treatment decision that produces either a control with evidence behind it or a recorded acceptance with a name and a date on it. A register with scores and no owners is an inventory of worries. The chain an auditor follows is risk to treatment to control to evidence, and it has to hold in both directions: every significant risk should lead to a control, and every control you claim should be traceable back to a reason.
The typical first risk register is a spreadsheet of forty generic threats copied from a template, each scored out of twenty-five by one person in an afternoon, owned by "Engineering", and never opened again until the week before the next audit. It satisfies the letter of a requirement to have a risk assessment and it changes nothing about what the company does.
The diagnosis is usually the same. The scores were assigned before anyone defined what the numbers meant, so they are not comparable between risks or between years. The owners are functions rather than people, so nobody is accountable. And the register terminates in a score rather than in a decision, so there is no output. A risk that has been scored has not been treated.
The test of whether your register is doing work is simple. Pick the third highest risk on it and ask what changed as a result. If the answer is nothing, or if the answer is a control that would have existed anyway, the register is documentation rather than management.
This matters commercially as well as for the audit. The risk assessment is where a small security budget gets allocated, and it is the only defensible basis for telling an executive that the money should go to one thing and not another. Done properly it is the most leveraged document in the program. Done as a template exercise it is the most ignored.
The methodology is a short approved document that says how risk will be identified, how likelihood and impact are defined, how the two combine into a rating, what the acceptance threshold is, and who has the authority to accept a risk above it. It carries a version and an approval date.
The requirement in ISO 27001 terms is a risk assessment process that produces consistent and comparable results, and that phrase is doing real work. Consistent means two people assessing the same risk arrive at broadly the same answer. Comparable means this year's scores can be set against last year's and the difference means something. Neither is achievable if the scales were invented while the scoring was happening.
Keep it to two or three pages. A long methodology is a signal that the process is heavier than the organization will actually run, and an assessment method nobody follows is worse than a simple one everybody does. What the document must contain is the definitions, the threshold, and the authority, because those three are what an auditor checks against the register.
The acceptance threshold is the part teams skip and it is the part that makes the register operational. It states the rating above which a risk cannot simply be lived with, and who can approve living with it anyway. Without it, every risk is implicitly accepted by default and the register has no forcing function.
Approve it before the first assessment, and keep the version history. A methodology that changes between years without explanation makes the year-on-year comparison meaningless, and a reviewer will ask why the scores moved.
There are two workable ways to identify risks and they suit different organizations. Choosing one deliberately and saying so in the methodology is more important than which one you pick.
An asset-based assessment starts from the inventory. For each significant asset or group of assets, you ask what could compromise its confidentiality, integrity or availability. It has the advantage of completeness, because the inventory bounds the exercise, and it connects naturally to the asset register you already have to keep. Its weakness is volume: done literally it produces hundreds of near-identical rows, and it tends to miss risks that are not attached to a single asset, like a failure of the change process or the loss of a key person.
A scenario-based assessment starts from plausible events. Ransomware encrypts the corporate estate. A production credential leaks publicly. A subprocessor is breached. An engineer leaves with a repository. It produces a much shorter and more readable register, each row of which is something a non-technical executive can understand and make a decision about. Its weakness is that completeness is a judgment call, so it needs a deliberate check against the asset inventory to catch what the scenarios missed.
For most companies under a hundred people, scenario-based with an asset-based completeness check is the combination that produces a usable register. Twenty to forty scenario risks is a realistic target. A small company with a hundred and twenty risks has a register nobody reads, and a small company with eight has not looked hard enough.
Whichever you choose, ground the identification in something other than imagination. Your incident history, near misses, findings from assessments and penetration tests, vendor register, and the threat picture for your sector all supply real candidates. The 2022 revision of the ISO Annex A control set added an explicit expectation around threat intelligence precisely because too many risk assessments were built on generic threat lists with no link to reality, and feeding the conclusions of that work into the register is how you avoid the same criticism.
Most unusable registers are unusable because the rows are nouns. "Phishing" is not a risk, it is a topic. Nobody can score a topic, own it, or close it.
Use a three part form: a cause, an event, and a consequence. "A member of staff enters credentials into a phishing page, leading to unauthorised access to the email account, resulting in exposure of customer correspondence and a payment fraud attempt." That row can be scored, because likelihood and impact both have a referent. It can be owned, because there is a specific outcome someone is accountable for. And it can be treated, because the causes and consequences suggest different controls.
Keep each risk at a single level of abstraction. A register that mixes "cyber attack" with "the S3 bucket holding invoices is public" cannot be prioritized, because the scores are not measuring the same kind of thing. If you find yourself with one enormous risk, split it. If you find twelve rows that would all be treated by the same control, merge them.
Record the affected asset or process and the information involved. This is what makes the later trace from risk to control possible, and it is what lets you answer the auditor question about whether the assessment covered confidentiality, integrity and availability rather than just breaches.
Write the row so that a person joining the company in two years can understand it without you. Registers are inherited, and an inherited register full of shorthand gets rewritten from scratch, which destroys the year-on-year comparison you were building.
The single change that most improves a risk register is defining the scale points in concrete terms before scoring. An undefined five point scale collects the assessor's mood. A defined one collects an assessment.
For likelihood, anchor each level to a frequency or a probability over a stated period. "Likely" means nothing. "Expected more than once a year" means something and two people will apply it the same way. Use a period that matches your planning horizon, usually one year.
For impact, anchor each level to consequences in categories that matter to your business, and state the worst applicable category as the score. Financial cost, customer impact, regulatory or contractual consequence, and recovery effort are the usual four. The point of multiple categories is that a risk with no financial cost and a serious regulatory consequence still scores properly.
Resist adding precision the inputs do not support. A three or four point scale that people apply consistently beats a ten point scale applied by feel. Similarly, avoid multiplying scores into a single number and then treating small differences as meaningful. A 12 and a 15 on a five by five matrix are not distinguishable given the quality of the inputs, and treating them as if they are produces false confidence and pointless argument.
Score inherent risk and residual risk, and be clear which one the register column holds. Inherent is the risk before your existing controls. Residual is what remains with them in place. Most decisions are made on residual, but recording inherent is what lets you demonstrate that a control is doing something, which is the argument you need when someone proposes removing it to save money.
Every risk needs a named individual owner. Not a team, not a department, not the CTO by default for everything technical. The requirement to identify risk owners exists because a risk with no owner is a risk nobody is accountable for, and functions do not attend meetings or make decisions.
The owner is not the person who does the work. They are the person accountable for the risk being at an acceptable level, who has the authority to commit the resources or to escalate when they cannot. That distinction matters: the engineer who will implement the fix is usually not the right owner, because they cannot decide it is not worth doing.
Ownership carries three concrete duties. Confirming the assessment is still accurate at each review. Deciding or recommending the treatment. And either closing the treatment or explaining, on the record, why it has not closed. If your owners are not doing those three things, the field is decorative.
Watch the concentration problem. In a small company one person frequently owns eighteen of the twenty-two risks, which is honest but also a finding in its own right: it means risk decisions are concentrated in a single individual whose absence would stall the program. Record that observation rather than distributing ownership artificially to people who cannot actually decide anything.
Get owners to confirm ownership in writing at least once a year. A register listing owners who have never been told they own anything is one of the more common and more embarrassing things an auditor uncovers, usually by asking one of them.
Every risk above the threshold resolves into one of four decisions, and each decision has a different evidence requirement. This is the step that converts a register into work.
Modify. Apply or strengthen controls to reduce likelihood, impact, or both. This is the default and it produces the treatment plan: what will be implemented, by whom, by when, and what the expected residual rating is afterwards. The evidence is the control operating, which is the subject of the next section.
Avoid. Stop doing the thing that creates the risk. Decommission the legacy system, drop the data field you were storing without a reason, exit the market with the regulatory exposure. Avoidance is underused because it feels like a retreat, and it is frequently the cheapest treatment available. The evidence is that the activity actually stopped, which means a decommissioning record rather than a decision.
Share. Transfer some of the consequence to another party, usually through insurance or a contractual allocation. Note what this does and does not do: insurance transfers financial consequence and transfers nothing else. Your customers still had their data exposed and your regulator is still interested. Sharing is almost always a partial treatment applied alongside modification, and a register that lists insurance as the sole treatment for a serious risk will be challenged. Our guide to cyber insurance evidence covers what underwriters expect in return.
Accept. Live with it. This is a legitimate decision and the register needs it, because a register where every risk is treated is a register that is lying about the organization's capacity. What acceptance requires is a record, covered below.
Write the treatment plan as work, not intent. "Improve access controls" is intent. "Enforce hardware second factor on the identity provider for all administrative accounts, owner named, by 30 November" is work, and it can be checked. A treatment plan with dates that have all passed is one of the most common findings in a second-year audit, and it is a finding about the management system rather than about security.
An accepted risk is fine. An accepted risk with no record of who accepted it is a gap, and it is one auditors probe because it goes to whether the organization actually has risk governance or just has a spreadsheet.
The acceptance record needs five elements: the risk as stated at the time of acceptance, the residual rating being accepted, the reason, the named individual who accepted it, and the date. Add a review date, because most acceptances are conditional on circumstances that change. An acceptance with no expiry quietly becomes permanent.
The person accepting has to have the authority to accept it, and the methodology has to say who that is. An engineer accepting a risk that carries regulatory consequence for the company is not an acceptance, it is an omission with a name attached. Above the threshold you defined, acceptance should sit with an executive or the board.
Where the risk is accepted because treatment is not affordable right now, say that explicitly and set the review date to when the constraint might change. This is a much stronger record than a vague justification, and it turns the acceptance into a scheduled decision rather than a permanent shrug.
Acceptances are also the natural agenda for management review. A short standing item listing every risk accepted since the last review, with who accepted it, is the cheapest way to give the governance process something real to govern.
This is the part that makes the register load-bearing, and it is where the assessment stops being a document and starts being the spine of the program.
Every treated risk points at one or more controls. Every control produces evidence that it operated. An auditor walks that chain in either direction. Forwards, they take a risk and ask what you did about it and how you know it worked. Backwards, they take a control you claim and ask why it exists, which your register should answer.
In ISO 27001 the chain is explicit and it runs through the Statement of Applicability. The risk assessment feeds the treatment plan, the treatment plan feeds the Statement of Applicability, and incidents and audit findings feed corrective actions. Every Annex A decision you make has to trace back to a risk, so a weak risk assessment undermines the whole certification rather than just one clause. If your Statement of Applicability includes a control with no risk behind it, or excludes one that a live risk clearly implies, the reviewer has found a break in the chain.
In SOC 2 the mechanism differs but the expectation does not. The criteria include the organization identifying and assessing risks to its objectives, and the audit firm will look for a live risk assessment that connects to the controls described in the system description. The failure mode is the same: a register that exists alongside the control set rather than explaining it.
Make the link a field in the register rather than a paragraph in a document. A column naming the controls that treat each risk, and the artifact that evidences each of those controls, is the difference between a chain you can demonstrate in a walkthrough and one you have to reconstruct under questioning.
Be honest about evidence type at this point. A policy is not evidence that a control operated, it is evidence that a control was designed. The register should point at the thing that shows it running: the dated review record, the ticket, the export, the timed test. We go into what survives review in the guide to evidence auditors accept.
The requirement is to perform risk assessments at planned intervals or when significant changes are proposed or occur, and to retain documented results. Both halves are operational instructions.
Planned intervals means annually for most small organizations, with a lighter quarterly review of the top items and the open treatment plans. The annual pass revisits identification, so new risks enter and dead ones leave. The quarterly pass does not re-score everything, it checks whether treatments are moving and whether anything has changed materially.
Significant change means the assessment is triggered by events as well as by the calendar. Define the triggers in the methodology so it is not a judgment call: entering a new market or regulatory regime, taking on a materially different category of customer data, a substantial architecture change, an acquisition, adding a critical vendor or subprocessor, and any significant incident.
Retain dated snapshots. The evidence expectation is at least two archived assessments showing the exercise was repeated, with dates and participants recorded, and the participants field is the one most often missing. A register held in a live tool that always shows current state cannot demonstrate it was repeated, because it has no history. Export a dated copy at each cycle and keep it, even if the tool has version history, because the export is what goes in the evidence package.
Record who was in the room. An assessment performed by one person is not wrong, but an assessment performed by one person and presented as the organization's view is fragile. Two or three participants from different functions produces better identification and a more defensible record.
The requests are consistent: the approved methodology with its version and approval date, the current register, at least two dated prior assessments with participants, the treatment plans with owners and dates, the acceptance records, and for ISO the Statement of Applicability with its justifications.
The most common failures are structural rather than technical. Scores with no defined scales, so the ratings cannot be defended. Owners recorded as teams. Treatment plans whose dates have all passed with no status update, which is a finding about the management system. Acceptances with no named accepter. And a register with no history, which cannot demonstrate the assessment was repeated no matter how good the current version is.
A subtler one: a register that has not changed at all between two years. Identical scores, identical risks, identical wording. Nothing in a real business stays exactly the same for a year, so an unchanged register reads as one that was copied rather than reviewed. Even where the conclusion is genuinely the same, the record should show the review happened and the participants who confirmed it.
The opposite failure also occurs: a register rewritten from scratch each year by a new person, so no risk can be traced across cycles and no improvement can be shown. Continuity of risk identifiers is a small piece of discipline that pays off in exactly this conversation.
Finally, watch for the register that contradicts other evidence. If your risk assessment rates a supplier as low criticality and your vendor register has them handling all customer personal data, one of the two is wrong, and finding contradictions between registers is a standard reviewer technique rather than bad luck.
A first assessment for a company under a hundred people is a week of elapsed time and roughly two days of actual effort, spread across a few people. Doing it in one long session produces a worse result than three shorter ones, because identification benefits from people thinking between meetings.
Draft and approve the methodology first, in half a day. Then run a ninety minute identification workshop with three or four people from different functions, working from your incident history, your assessment and penetration test findings, your vendor list and your asset inventory, aiming for a long unfiltered list of candidate risks.
Consolidate that list into twenty to forty properly written risk statements. This is desk work and it is where most of the value is added, because merging and splitting is what makes the register scoreable.
Score in a second session with the same group, using the defined scales, and assign owners as you go. Scoring alone at a desk is faster and materially worse, because the disagreements between two people about a likelihood are where the real information is.
Then take the items above the threshold to whoever holds the budget, with treatment options and costs, and get decisions. That meeting is the actual purpose of the exercise. If you never hold it, you have produced a document. If you do hold it, you have produced a plan, and the register becomes the thing you review against for the rest of the year. Our risk register builder is a free starting structure, and the risk assessment template for Canadian startups covers the lighter-weight version of the same exercise.
| Risk statement | Treatment and owner | The evidence that shows it operated |
|---|---|---|
| A leaver retains access to production because offboarding is manual, leading to unauthorised access after departure. | Modify. Tie revocation to the HR leaver event and review access quarterly. Owner: Head of Engineering. | Completed access review records for each period showing decisions per account, plus dated proof that the accounts marked for revocation were actually revoked. |
| A long-lived production credential is committed to a public repository, allowing access to customer data with unknown duration of exposure. | Modify. Secret scanning in the pipeline, short-lived credentials, documented rotation procedure. Owner: Platform lead. | Scanner configuration and alert history for the period, a rotation record for any finding, and the incident record where one was raised. |
| Ransomware encrypts the corporate estate and the backups sit in the same cloud account, preventing recovery. | Modify. Cross-account immutable backup copies, quarterly restore testing. Owner: CTO. | Dated restore test records naming who ran each test, what was restored, elapsed time against the RTO, and the issues found. |
| A subprocessor holding customer personal data is breached, triggering notification obligations we cannot meet because we do not know what they hold. | Modify. Criticality tiering, executed data processing terms, documented data flows per vendor. Owner: Operations lead. | The vendor register showing tier and data categories, executed agreements on file with signature dates, and current assurance reports reviewed rather than merely collected. |
| Staff credentials are phished, giving access to email and enabling payment redirection fraud. | Modify. Phishing-resistant second factor on the identity provider, out-of-band verification for payment changes. Owner: Finance lead jointly with IT. | A configuration export showing enforcement scope, a coverage report against the roster, and the payment verification records for the period. |
| The one engineer who can perform a production recovery is unavailable during an outage, extending downtime beyond the stated objective. | Modify. Written procedure plus an annual key person drill performed by someone else. Owner: CTO. | The drill record naming the substitute performer, elapsed time, and the procedure corrections it produced. |
| A customer-facing outage exceeds the availability commitment in enterprise agreements, triggering credits and escalation. | Share and modify. Contractual credit cap negotiated, plus monitoring and on-call improvements. Owner: CTO with the commercial lead. | Uptime records for the period, incident timelines showing detection and resolution times, and the contract terms held on file. |
| A legacy internal tool holding historical customer records has no owner, no patching and no logging. | Avoid. Decommission and delete the data after confirming no retention obligation. Owner: Head of Engineering. | The decommissioning record, the deletion confirmation, and the updated asset inventory showing the record retired with a date. |
| A generic-account shared login is used for a third party administrative console because the vendor does not support individual accounts. | Accept, with compensating controls. Credential in the password manager with restricted membership, quarterly usage review, reassess at renewal. Owner: accepted by the CEO, review in 12 months. | The acceptance record naming the accepter and the date, the membership list, and the quarterly review records for the compensating control. |
For a company under a hundred people, twenty to forty well-written risks is the range that stays usable. Fewer than roughly fifteen usually means the identification did not look beyond the obvious. More than about sixty means rows are being written at too fine a grain, and the register becomes something nobody reads, which defeats the purpose. If your list is very long, look for groups of rows that would all be treated by the same control and merge them, because those are the same risk expressed several ways.
A matrix is a reasonable presentation device, but it invites two mistakes. The first is treating small differences in the product as meaningful, when a 12 and a 15 are indistinguishable given the quality of the inputs. The second is adopting five levels without defining them, which makes the scores personal rather than comparable. A three or four point scale with concrete definitions, applied consistently, produces a better register than a five by five applied by feel. What matters to an auditor is that the scale is defined in an approved methodology and applied the same way across the register.
A named individual with the authority to commit resources or escalate, not a team and not the person who will do the implementation work. The distinction matters because the owner has to be able to decide that a treatment is not worth doing, and an engineer cannot make that call. In a small company one person often ends up owning most of the register, which is honest. Record the concentration rather than distributing ownership to people who have no decision rights, because a register listing owners who do not know they own anything is something auditors find by asking them.
Annually as a full pass, with a lighter quarterly check on the top items and the open treatment plans, and additionally whenever something significant changes. Define the change triggers in the methodology so it is not left to judgment: a new market or regulatory regime, a materially different category of customer data, a substantial architecture change, an acquisition, a new critical vendor, or a significant incident. The evidence expectation is at least two dated archived assessments with participants recorded, which demonstrates the exercise was genuinely repeated rather than merely maintained.
Yes, and a register where everything is treated is not credible, because no organization has the capacity to treat everything. What acceptance requires is a record with five elements: the risk as stated, the residual rating being accepted, the reason, the named person accepting, and the date, plus a review date so the acceptance does not silently become permanent. The accepter has to have the authority set out in your methodology, which for anything above your threshold generally means an executive rather than the person closest to the problem.
Inherent risk is the rating before your existing controls are taken into account. Residual is what remains with them operating. Most decisions are made on residual, since that is the risk the business is actually carrying. Recording inherent as well is worth the small extra effort because the difference between the two is the demonstrable value of a control, which is the argument you need when somebody proposes removing it to save money. Be clear in the methodology which one the main rating column holds, since mixing the two across rows makes the register incomparable.
In ISO 27001 it is the source. The risk assessment produces the treatment plan, and the treatment plan determines which Annex A controls are applicable and why, which is what the Statement of Applicability records. That makes the chain checkable in both directions: an included control should trace back to a risk that justifies it, and an excluded one should have a justification consistent with the register. A control included with no risk behind it, or an exclusion that a live risk contradicts, is a break in the chain and one of the more common findings raised during certification.
No. A spreadsheet with the right columns, exported and dated at each cycle, satisfies every requirement discussed here and is what most small companies should start with. The columns that matter are the risk statement, affected asset or process, inherent and residual ratings, named owner, treatment decision, treatment actions with dates, linked controls, and the evidence artifact. Tools help once the register is being reviewed frequently by several people, mainly through history and reminders. What a tool cannot supply is a defined methodology, real owners, or the budget conversation that turns ratings into work.
traztech Workspace has every control of whichever frameworks apply to you, written in plain English, with somewhere to attach the proof. Free to use, with no card and no trial clock.
No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.
| traztech Workspace | Other GRC platforms | |
|---|---|---|
| Licence cost | $0. Free forever, no card, no paid tier | $7,500 to $50,000 a year, on an annual contract |
| Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring | Included | Included |
| What it costs inside an engagement with us | $0. You need a workspace either way | Unchanged. The subscription sits on top of the fee |
| What it does to your audit quote | $11,000 off a five-figure quote on one engagement, for a documented readiness position | Nothing. The audit firm prices your readiness, not your tooling |
Pricing in the right column is what compliance automation platforms are publicly reported to charge; none of them publish a number, so treat it as a range rather than a quote. The $11,000 came off the audit firm's own number once the readiness position was documented (the engagement). Where a paid platform is the better buy, and the fuller comparison, is on the Workspace page.
We run the identification, write the methodology, and take the items above your threshold to the people who hold the budget.
Book a strategy callWant the human version?
Jacob sends a few short, practical notes on getting security and compliance right without the months of pain. No fluff, unsubscribe in one click. Reply anytime; it reaches him directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.
Track record
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.