How to Conduct a Cybersecurity Risk Assessment: Step-by-Step
The email lands on a Wednesday. Clearwater Financial Services is renewing its cyber insurance, and the insurer wants a current risk assessment of the customer portal before quoting. The CISO forwards it to the GRC team with one line: “Can we have this in three weeks?” And the newest analyst on the team, staring at a blank document titled “Customer Portal Risk Assessment v0.1,” realizes nobody ever showed her what goes in it.
This article is the missing walkthrough. By the end, you will know how to conduct a cybersecurity risk assessment from scoping to final report, with every step demonstrated on Clearwater’s customer portal so you can see real (fictionalized) inputs and outputs, not just theory. The method follows NIST SP 800-30 Rev. 1, NIST’s Guide for Conducting Risk Assessments, simplified to what a practitioner actually does. ISO 27005 covers similar ground for ISO-aligned organizations; the logic is the same.
What a risk assessment produces (start with the output)
Beginners start with threats. Practitioners start with the deliverable, because knowing the destination shapes every step. A finished risk assessment contains:
- A scope statement: what system was assessed, what was excluded, and who provided information.
- A risk register: the table of identified risks, each with likelihood, impact, an overall rating, and current controls.
- A prioritized findings summary: the handful of risks that matter most, in plain language.
- Treatment recommendations: for each priority risk, what you propose (fix, accept, transfer, avoid) and roughly what it costs.
That is it. Not a hundred pages. A tight assessment a leader can act on beats an encyclopedic one nobody reads. Keep these four outputs in mind as we build them piece by piece.
Step 1: Scope the system and gather context
You cannot assess “the company.” You assess a defined thing. For Clearwater, the scope is the customer portal: the web application where customers log in, view balances, and move money. In scope: the application, its database, its authentication, the cloud environment it runs in, and the vendor that hosts it. Out of scope (this round): the mobile app and internal admin tools. Write the exclusions down; unstated scope is how assessments sprawl and stall.
Then gather context by interviewing the people who know the system. For the portal, that is the product owner, the lead engineer, and the support manager. You are asking:
- What data does it hold, and how sensitive is it? (Portal: customer identity data, account balances, transaction history. Very sensitive.)
- Who and what connects to it? (Customers, the payments vendor, an analytics service.)
- What does the business lose if it goes down, leaks, or is tampered with? (Revenue, customers, regulator attention.)
- What protections already exist? (Note them now, evaluate them in Step 4.)
One hour of good interviews saves ten hours of guessing. If you read What Does a GRC Analyst Actually Do?, this is Monday’s skill in action.
Step 2: Identify threats and vulnerabilities
Now the structured brainstorm. A threat is who or what could cause harm; a vulnerability is the weakness that lets them. Work through threat categories systematically rather than free-associating:
- External attackers: credential stuffing against customer logins, phishing customers for their passwords, exploiting an unpatched component in the application.
- Insiders: a support agent misusing access to customer accounts, an engineer making an untested change that exposes data.
- Third parties: the hosting vendor suffering an outage or breach, the analytics service collecting more data than intended.
- Process and environment: backups that have never been tested, an expired security certificate, cloud storage misconfigured to public.
For each plausible threat, name the matching weakness at Clearwater. Example pairings from the portal:
| Threat | Vulnerability |
|---|---|
| Credential stuffing attack | No multi-factor authentication for customer logins |
| Support agent misuse | Broad support access with no activity review |
| Vendor outage | No tested failover; recovery time unknown |
| Exploitation of software flaw | Patching happens ad hoc, no defined cycle |
Aim for the 8 to 15 risks that are plausible for this system, not the 60 that are theoretically possible. Completeness in categories, restraint in count.
Step 3: Assess likelihood and impact
Every risk now gets two ratings. Use a simple 1-to-3 scale for your first assessments; bigger matrices add precision you cannot yet defend.
Likelihood: 1 = unlikely this year, 2 = could plausibly happen this year, 3 = expected or already happening. Base it on exposure and history: credential stuffing against a public fintech login page is a 3, because it is constant background noise on the internet, while a targeted insider scheme might be a 1.
Impact: 1 = an inconvenience, 2 = serious but recoverable, 3 = severe harm to customers, finances, or the company’s standing. Rate the credible bad case, not the apocalypse. A portal breach exposing customer financial data is a 3 for Clearwater without needing any imagination.
Two rules that keep ratings honest. First, rate the risk as things stand today, with current controls in place, because you are assessing reality, not a hypothetical unprotected system. Second, write one sentence justifying each rating. “Likelihood 3: automated credential attacks are observed weekly in login logs” survives review. A bare number does not.
Working through your own version of this and want the structure ready-made? The Risk Assessment Template inside the free GRC Starter Kit has the register, the scales, and the justification prompts pre-built. [Get the Starter Kit.]
Step 4: Determine and evaluate controls
A control is anything that reduces likelihood or impact: technology, process, or people. For each risk, record what exists and judge how well it works. Three honest verdicts are enough: effective, partial, or missing.
Clearwater portal examples:
- Credential stuffing risk: rate limiting on the login page exists (partial), MFA for customers does not (missing).
- Support misuse: access is granted by role (partial), but nobody reviews activity logs (missing).
- Vendor outage: contract promises 99.9% uptime (partial), failover has never been tested (missing).
- Patching: a tool inventories software versions (effective), but there is no schedule forcing updates (partial).
Evidence discipline applies even inside your own assessment: “MFA is missing” should trace to something you saw or were told by a named role, not an assumption. This is also where beginners find the pattern that defines real environments: controls half-exist. Almost nothing is cleanly present or absent, which is exactly why the partial verdict earns its place.
Step 5: Calculate and prioritize risk
Now combine. With a 1-to-3 scale for each dimension, multiply likelihood by impact for a score from 1 to 9: 6 to 9 is high, 3 to 4 is medium, 1 to 2 is low. The arithmetic is not science; it is a consistent sorting mechanism so that priorities come from method rather than mood.
Clearwater’s portal register, abridged:
| Risk | L | I | Score | Priority |
|---|---|---|---|---|
| Customer accounts compromised via credential stuffing (no MFA) | 3 | 3 | 9 | High |
| Customer data exposed through unpatched component | 2 | 3 | 6 | High |
| Support agent misuse of account access | 2 | 3 | 6 | High |
| Extended outage at hosting vendor | 2 | 2 | 4 | Medium |
| Analytics service over-collection | 2 | 1 | 2 | Low |
Sort descending and resist the urge to inflate everything to high. An assessment where every risk is critical tells leadership nothing; the ranking IS the information.
Step 6: Report and recommend treatment
The final step turns the register into decisions. For each high risk, recommend one of four treatments: fix it (add or improve a control), accept it (document that the business tolerates it and why), transfer it (typically insurance), or avoid it (stop the risky activity). Attach rough effort or cost, because a recommendation without a price is a wish.
Clearwater’s summary to leadership, compressed to what a CISO would actually send upward:
The customer portal assessment identified three high risks. Highest: customer account takeover via automated credential attacks, driven by the absence of multi-factor authentication. Recommendation: implement customer MFA this quarter (estimated 6 engineering weeks); this also satisfies a control our insurer and two enterprise clients have asked about. Second: establish a monthly patching cycle for portal components (low cost, process change). Third: enable quarterly review of support access activity (moderate cost, tooling exists). Vendor outage risk is medium and acceptable short-term pending a failover test scheduled next quarter.
Notice the shape: risk, cause, recommendation, cost, and a business reason to act. One paragraph per priority. That is the communication skill from the skills article doing its job, and it is what separates an assessment that changes things from one that gets filed.
The full worked example, assembled
Threading the steps together, the complete Clearwater deliverable is four parts and roughly six pages:
- Scope: customer portal, its database, authentication, cloud environment, hosting vendor; mobile app excluded; sources: product owner, lead engineer, support manager.
- Register: the table from Step 5, with a justification sentence per rating and control status per risk from Step 4.
- Findings summary: the three high risks in plain language.
- Treatment recommendations: the leadership paragraph above, expanded to half a page per risk.
Three weeks was the CISO’s deadline. A scoped assessment like this, for one system, with cooperative interviewees, fits comfortably inside it. Assessments blow their deadlines when scope is fuzzy, not when analysis is slow.
Your turn. Practice on a scenario small enough to finish: a five-person accounting firm’s email system. Same six steps. Scope it (email service, the accounts, the devices that read it). Identify threats (phishing, account takeover, a lost laptop, the provider failing). Rate, evaluate controls (do they have MFA? backups? anyone training staff?), score, and write a one-paragraph recommendation to the firm’s owner. Done honestly, that exercise is a portfolio piece, and interviewers respond to it far better than to definitions.
Common beginner mistakes
- Skipping scope. The number one killer. Unbounded assessments never finish.
- Rating the apocalypse. Impact reflects the credible bad case. Not every risk ends the company.
- Ignoring existing controls. Assessing the system as if it were naked inflates everything and insults the people who built the protections.
- Fifty shades of high. If everything is critical, nothing is. The ranking is the deliverable.
- Numbers without sentences. Every rating needs its one-line justification, or the first challenge in review unravels the whole register.
- Reporting the register instead of the decision. Leadership acts on the Step 6 paragraph, not the spreadsheet. Always write the paragraph.
Where to go from here
You now have the full procedure: scope, identify, rate, evaluate controls, prioritize, and report, the same sequence whether the subject is a fintech portal or a five-person firm’s inbox. The fastest way to make it stick is to run it once yourself on the small-business scenario above.
The free GRC Starter Kit includes the Risk Assessment Template used throughout this walkthrough, with the register structure, rating scales, and report skeleton ready to fill in, plus the gap assessment and policy templates from the rest of this series. Get the GRC Starter Kit.
And if you are earlier in the journey and wondering whether this career fits you at all, start with the roadmap: How to Get Into GRC With No Experience.
