A Risk Assessment a Canadian Startup Can Actually Run

Direct answer: You need a documented, repeatable method that identifies risks, scores them on likelihood and impact, records a treatment decision with an owner and a date, and gets reviewed at least annually. The method matters less than applying it consistently and being able to show you did.

The method

Identify what you are protecting, using your asset inventory. For each, ask what could realistically go wrong. Score likelihood and impact on a simple scale, and be honest rather than conservative. Decide treatment: mitigate, accept, transfer or avoid. Assign an owner and a date. Review on a schedule.

A five-by-five matrix is plenty. Elaborate quantitative models look impressive and are almost never maintained, and an unmaintained risk register is worse than a simple current one.

Risks worth listing for a Canadian SaaS

Credential compromise leading to production access. A subprocessor breach exposing customer data. Ransomware on corporate endpoints. A departing employee retaining access. Data residency obligations conflicting with where you actually host. Personal information handled beyond what your privacy notice says. Single points of failure in deployment knowledge. Where you ship AI features, model and prompt handling of customer data.

The Canadian layer

PIPEDA applies federally to commercial personal information. Quebec's Law 25 adds its own obligations if you have customers there, including a named privacy officer and breach reporting. Ontario health data brings PHIPA into scope. These belong in the register as compliance risks with owners, because a buyer's reviewer will ask and "we are not sure" is a finding.

Scoring that survives an audit

Auditors do not grade your numbers. They check that the method is documented, applied consistently, and that treatment decisions were actually acted on. A high risk accepted with a written rationale and a sign-off is perfectly acceptable. A high risk with a treatment date eighteen months in the past is not.

Keep it alive

Review quarterly at the same sitting as the access review, and refresh properly once a year. Add a risk whenever you add a subprocessor, a region or a product line. A register that only changes at audit time is visibly a compliance artefact rather than a management tool.

Our risk register builder is free and starts you with the entries above, and the Workspace keeps treatment dates in front of you instead of in a spreadsheet nobody opens.

The fields your register actually needs

Most templates you will find online have thirty columns and get abandoned in week three. Eleven fields is enough for a startup, and every one of them earns its place because a reviewer will ask about it.

ID. A stable identifier such as R-014. Never renumber. Auditors and buyers quote these back at you months later, and a register where the numbers shift is impossible to reference.

Risk statement. One sentence, written as cause, event, consequence. More on this below, because it is where most registers go wrong.

Asset or process affected. Use the same name as your asset inventory. If the inventory says "prod-postgres-01" then the register says "prod-postgres-01", not "the main database".

Category. Something coarse: technical, privacy, supplier, people, availability, legal. This exists so you can sort, not so you can be precise.

Inherent likelihood and inherent impact. The rating before your existing controls. Many startups skip inherent scoring, and it is defensible to do so, but recording it makes it possible to show what your controls are actually buying you.

Existing controls. Name them specifically. "SSO enforced via Okta, MFA required, break-glass account monitored" is a control statement. "Access is restricted" is not.

Residual likelihood and residual impact. The rating with controls in place. This is the number that drives the treatment decision.

Treatment. Mitigate, accept, transfer or avoid, plus one line saying what that means concretely.

Owner. A named person, not a team. Teams do not attend review meetings, people do.

Target date. A real date, moved deliberately with a note, never silently.

Last reviewed. A date and an initial. This single column answers the most common auditor question about the register without anyone having to reconstruct history.

How to write a risk statement that survives review

The most common failure in a startup register is that the entries are nouns rather than risks. "Phishing" is not a risk. "AWS" is not a risk. Neither can be scored, because neither says what happens or how badly.

Write every entry as cause, event, consequence. "Because engineers hold long-lived AWS access keys in local config files, a compromised laptop could allow an attacker to read the production database, exposing personal information for all customers and triggering PIPEDA breach reporting obligations." That sentence can be scored, because impact is stated. It can be treated, because the cause is named. And it can be closed, because you know what would have to change.

Two habits make this faster. First, write the consequence in business terms rather than technical ones: data exposure, service outage, regulatory notification, contract breach, lost deal. Second, if a single statement contains the word "and" twice, it is probably two risks and should be split, because it will need two owners and two treatment dates.

Two worked entries, scored end to end

Here is what a filled-in entry looks like for a twenty-person Canadian SaaS company on a five-by-five scale.

R-007. Because the customer support tool allows agents to view full customer records including addresses and payment metadata, a compromised support account could allow bulk export of personal information, resulting in a reportable breach and loss of an enterprise account. Asset: support platform. Inherent likelihood 4, inherent impact 4, inherent score 16. Existing controls: SSO with MFA, role-based permissions, and audit logging retained ninety days. Residual likelihood 2, residual impact 4, residual score 8. Treatment: mitigate. Implement export rate limiting and an alert on any export over fifty records. Owner: Head of Support. Target date: 30 September. Last reviewed: 12 August, JM.

R-011. Because deployment knowledge sits almost entirely with one engineer, their sudden departure or unavailability could delay incident recovery beyond our contractual four-hour response commitment, resulting in service credits and a customer escalation. Asset: deployment pipeline. Inherent likelihood 3, inherent impact 4, inherent score 12. Existing controls: infrastructure defined in Terraform in a shared repository. Residual likelihood 3, residual impact 3, residual score 9. Treatment: mitigate. Run a documented recovery drill with a second engineer performing the steps unaided, and record the gaps found. Owner: CTO. Target date: 15 October. Last reviewed: 12 August, JM.

Notice that the residual likelihood on R-011 barely moved. That is honest. Having Terraform does not remove key-person risk if only one person has ever run it under pressure, and a register that pretends otherwise is exactly the kind of self-flattery a reviewer spots.

Set a risk appetite before you start scoring

Scoring without a stated appetite produces a register where everything above a certain number is quietly ignored. Write one short paragraph, signed by whoever runs the company, that says what you will and will not tolerate. For example: residual scores of 15 and above require an executive decision and a dated plan; scores of 8 to 12 are treated within two quarters; scores below 8 may be accepted with a written rationale; no risk affecting personal information of Canadian residents may be accepted without the privacy owner's sign-off.

That paragraph does three useful things. It converts the register from a list into a decision rule. It gives the risk owner cover to push back on a product deadline. And it answers a question every serious buyer's reviewer eventually asks, which is not "what is your highest risk" but "who decides what is acceptable here".

Wiring the register into a framework

If you are heading toward ISO 27001, the register is not an optional artefact. Clause 6.1.2 requires a defined risk assessment process with criteria you can restate, clause 6.1.3 requires a risk treatment plan and a Statement of Applicability covering the 93 Annex A controls, and clause 8.2 requires the assessment to be performed at planned intervals and when significant changes occur. Auditors trace all of this. The practical implication is that each register entry with a "mitigate" treatment should name the Annex A control it maps to, so the risk treatment plan writes itself instead of becoming a separate document that contradicts the register. Our ISO 27001 implementation work starts here for the same reason.

For SOC 2 the requirement is looser but the auditor's questions are similar. The common criteria expect that you specify objectives, identify risks to them, consider fraud, and assess changes that could affect the system. A register that only lists technical threats and never mentions a change in the business, a new region, or a new subprocessor reads as incomplete against those criteria. Add entries when the company changes, not only when the threat landscape does.

The failure modes we see most often

The register written once by a consultant and never touched. It is recognisable instantly: every entry uses the same phrasing, no owner is named, and the last reviewed column is either empty or a single identical date. Reviewers treat this as evidence of nothing.

Scores tuned to the answer. Somebody notices that a score of 16 would require an executive decision and quietly rates likelihood at 2 instead of 3. Once the numbers are negotiated to fit the plan, the register stops being useful for making decisions and becomes theatre.

Treatment dates that slide silently. A risk with a date eighteen months in the past is worse than no register at all, because it proves you knew and did nothing. If a date needs to move, move it in the review meeting with a one-line reason and a new date.

Everything rated medium. If eighty per cent of your entries land in the middle of the scale, the scale is doing no work. Force a spread by ranking the entries against each other rather than scoring each in isolation.

Confusing risks with findings. A pentest finding is not a risk entry. Findings go into a remediation tracker with a fix date. The register holds the standing exposure that produced the finding, for example a lack of secure development review, which persists after that specific bug is patched.

When you should not pay anyone for this

A first risk register is genuinely a do-it-yourself task, and we would rather say so than sell an engagement around it. If you are under about thirty people with one product, the work is a focused afternoon with your CTO plus a follow-up session with whoever owns finance and customer contracts. You do not need a consultant to tell you that credential compromise matters. Use the fields above, our free Workspace to keep the treatment dates visible, and spend the money you saved on fixing the top three entries instead of documenting all twenty.

Bringing someone in makes sense in narrower cases. When an auditor has already challenged your methodology and you need it rebuilt to survive a second look. When the register has to cover several products or an acquired environment nobody fully understands. When a regulated buyer, typically in financial services or health, will read the entries line by line. Or when the honest problem is that nobody internally has the authority to force treatment decisions through, which is a leadership gap rather than a documentation one. If that last one is your situation, say so when you talk to us, because the fix is an owner with a mandate rather than a better template.