How to Do a Cybersecurity Risk Assessment
A cybersecurity risk assessment is not supposed to be a decorative heat map. It should help a CISO, founder, board, or security owner decide what needs action, who owns the work, and what tradeoff the business is accepting if nothing changes.
The useful version starts with context: what systems matter, what data is held, what vendors can affect delivery, what customers are asking for, what legal or regulatory obligations apply, and what would actually hurt the organization if a control failed.
This guide walks through a practical way to run the assessment. When you are ready to turn the outputs into a register and visual matrix, use GreenHat's Cyber Risk Matrix Builder.
Start with the decision the assessment needs to support
Before scoring anything, decide why the assessment exists. A board risk update, SOC 2 readiness review, vendor review, privacy program, incident follow-up, AI approval, and budget request all need different levels of detail. If the purpose is unclear, the register will collect risks without helping anyone decide what to do next.
A strong starting question is: what decision should be easier after this assessment? That may be whether to fund remediation, accept a vendor, delay a launch, change an architecture decision, assign a new control owner, or brief the board on a material cyber exposure.
Write that decision at the top of the assessment. It keeps the work practical and prevents the team from turning every possible issue into the same level of urgency.
- Name the audience before naming the risk categories.
- Decide whether the output is for executives, operators, customers, auditors, or product owners.
- Make the assessment produce decisions, owners, and next actions.
Define impact before scoring likelihood
Impact is where many risk assessments become vague. If one person thinks impact means financial loss, another thinks customer trust, and another thinks regulatory exposure, the scores will not be comparable. Define impact levels before scoring the register.
A practical impact scale can include financial exposure, customer effect, operational downtime, privacy harm, compliance consequences, legal exposure, reputational visibility, staff impact, and safety considerations. Not every organization needs every dimension, but the team should agree what a 1, 3, and 5 mean.
The Cyber Risk Matrix Builder includes a default 1-to-5 impact scale that you can use as a starting point, then adapt for your organization.
Impact criteria to define
- Financial exposureEstimate loss bands, remediation cost, revenue interruption, fines, or customer credits.
- Operational effectDefine what minor, local, major, or extensive disruption means for the business.
- Customer and reputationSeparate internal awareness from customer-visible, media-visible, or regulator-visible events.
- Privacy and complianceCapture breach obligations, audit impact, non-compliance, penalties, and contractual pressure.
Build the risk register from known work, not guesses
The register should start from real inputs: recent incidents, audit findings, customer diligence, vendor dependencies, architecture reviews, cloud and identity controls, data flows, privacy obligations, AI use cases, business continuity assumptions, and known control gaps.
Do not ask a tool to invent your risks and then treat the output as truth. That may be useful for brainstorming, but it is not a risk assessment. A real assessment needs owners who recognize the issue, evidence that explains current control strength, and enough context to decide treatment.
For vendor-driven risks, start with GreenHat's Vendor Security Assessment Questionnaire Template. For AI-driven risks, use the AI Risk Questionnaire before adding AI risks to the register.
- Write each risk as an event or condition that could affect the organization.
- Include the affected asset, process, vendor, customer flow, system, or data set.
- Add current controls or compensating controls before assigning a treatment plan.
- Assign an owner even if the owner is provisional.
Score likelihood and impact consistently
Likelihood should describe how plausible the event is in the assessment period, not how nervous the team feels about it. A five-year window can work for strategic risks, while a one-year or two-year window may work better for operational reviews. Pick the window and use it consistently.
Then score likelihood and impact separately. A risk can be unlikely but catastrophic, common but low impact, or both likely and severe. Mixing those judgments together too early makes the matrix less useful.
When the score is uncertain, record the uncertainty. That may become a data collection task: review logs, interview owners, inspect evidence, test a control, ask a vendor for proof, or confirm whether a legal obligation applies.
Use the matrix to prioritize, not to pretend precision
A 5x5 cyber risk matrix is a conversation tool. It helps show which risks need immediate attention, which can be tracked, and which need executive acceptance. It does not prove the exact mathematical value of a risk.
The most useful matrix is connected to the register. If the visual shows a critical risk but no owner, treatment decision, target date, or current control note, the organization has not finished the assessment. It has only created a picture.
Open the Cyber Risk Matrix Builder when you are ready to enter the risks, see the matrix, and export the register.
Turn the assessment into an operating cadence
The assessment should not die in a slide deck. Once risks are scored, leadership needs treatment decisions: mitigate, transfer, avoid, or accept. Each risk needs an owner, status, target date, and review cadence.
For startups, this often becomes the security roadmap. For larger teams, it can become a quarterly risk review, a board reporting input, a SOC 2 readiness input, or a way to connect security work to budget and product decisions.
If the assessment identifies Canadian privacy, cybersecurity, sector, or customer-driven obligations, use GreenHat's Cybersecurity and Privacy Requirements for Your Organization tool to map those requirements before finalizing treatment.
Common mistakes to avoid
The most common mistake is treating the matrix as the deliverable. The matrix is useful, but the register, owners, treatment decisions, control notes, and follow-up rhythm are what make the assessment operational.
Another mistake is scoring everything in isolation. A vendor issue may also be a privacy issue. A SOC 2 control gap may also be a customer renewal risk. An AI approval issue may also be an identity and data retention risk. Keep the relationships visible.
- Do not score risks before defining the scale.
- Do not let every risk become High because the team is uncomfortable.
- Do not separate the matrix from owners and treatment decisions.
- Do not use a generated risk list as a substitute for business context.
- Do not leave accepted risk undocumented.
Build the matrix after the guide
Once the scope, impact criteria, likelihood scale, and known risks are clear, use the free GreenHat tool to create the risk register, place each risk in a 5x5 matrix, and export the result.
Related GreenHat Resources
GreenHat Link
Cyber Risk Matrix Builder
Create a risk register, score likelihood and impact, view the 5x5 matrix, and export the register.
GreenHat Link
Vendor Security Assessment Questionnaire
Collect vendor evidence before adding third-party risks to the register.
GreenHat Link
Cybersecurity and Privacy Requirements Tool
Identify Canadian cybersecurity and privacy requirements that can create risk obligations.
GreenHat Link
AI Risk Questionnaire
Review AI vendors, data access, model behavior, and governance before scoring AI risk.
GreenHat Link
Virtual CISO Services
Bring in ongoing security leadership when the register needs owners, reporting, and cadence.
GreenHat Link
SOC 2 Readiness Assessment
Connect risk findings to SOC 2 scope, evidence, controls, and remediation priorities.
Source and further reading
Original GreenHat Security commentary based on current service pages, security leadership workflows, and startup readiness patterns already documented on this site.