Risk assessments get a bad rap. For many teams, it feels like something you have to do to check a box—some mind-numbing compliance artifact for the auditors to rifle through once a year. And hey, I’ve been there.
But here’s the deal: when done right, a risk assessment becomes one of the most powerful tools in your cybersecurity toolkit.
Think of it like this: telling a kid not to run with scissors isn’t just a rule—it’s risk management. You’re not just saying “no” to be annoying. You’re identifying a risk (injury), a threat actor (a wild 6-year-old), and possible mitigations: walk carefully, use child-safe scissors, store them in a high drawer, maybe even add some blunt tip training wheels. That’s a risk assessment in action. It’s about understanding what could go wrong, what’s most likely to go wrong, and what you can do to reduce the odds—or the damage.
That’s how I think about cybersecurity risk assessments. I’ve spent the last few years in this field, and if there’s one thing I’ve learned, it’s this: we’re not just compliance folks—we’re risk managers. We help organizations figure out how much risk they can afford to take on and where to spend their limited resources to get the best return on security investment.
So let’s talk about how to build a real risk assessment process—without drowning in red tape.
What Is a Risk Assessment, Really?
At its core, a risk assessment is a way to systematically identify, evaluate, and prioritize risks across your business. It’s not about perfect alignment to every line item in NIST, ISO, or PCI. It’s about understanding your environment and deciding what’s worth protecting, from what, and how badly you’d be hurt if something went wrong.
Compliance isn’t the goal—it’s just one of the risks. A good risk assessment can turn compliance from a chaotic scramble into a manageable, strategic decision. If you treat compliance as one domain of risk (among many), you start to shift the focus from busywork to actual impact.
How to Identify Threats, Vulnerabilities, and Impacts
There are a bunch of frameworks for this, but don’t overcomplicate it. You want something that’s useful, not something that takes 14 weeks to produce one PowerPoint slide.
Here’s a lightweight step-by-step process using a web application as the asset:
Example Process: Identifying Risk for a Public-Facing Web Application
- Asset: Public-facing e-commerce web application
- Identify Threats – Use a resource like MITRE ATT&CK or brainstorming with your team.
- Threat: Credential stuffing
- Threat Actor: Criminals targeting reused passwords
- Identify Vulnerabilities
- Weak or no rate limiting
- No MFA
- Lack of logging for failed login attempts
- Use tools like vulnerability scanners (e.g., Nessus, OpenVAS) or OWASP Top 10.
- Determine Impact
- Customer account takeovers
- Reputation damage
- Financial fraud
- Regulatory consequences
- Capture it all in a table for reuse and communication.
Helpful Methodologies:
The “Likelihood × Impact” Formula Simplified
This is the peanut butter and jelly of risk assessments. If you remember just one formula, it’s:
Risk = Likelihood × Impact
Now, calculating those numbers is where it gets messy—but also where it gets useful.
- Annual Rate of Occurrence (ARO) – How many times a year might this happen?
- Single Loss Expectancy (SLE) – What does one incident cost you?
- Annual Loss Expectancy (ALE) – ARO × SLE
Example:
- Risk: Phishing email leads to credential theft
- ARO: 5 phishing incidents a year
- SLE: $10,000 per credential compromise
- ALE: 5 × $10,000 = $50,000/year
Resources:
Documenting Risks: DIY Risk Register in Google Sheets
Let’s kill a myth real quick: you don’t need a six-figure GRC platform to track risks.
In fact, some of the cleanest and most usable risk registers I’ve seen live in Google Sheets. It’s collaborative, auditable, and most importantly—accessible.
Example Table:
| Risk ID | Risk Description | Asset | Threat | Vulnerability | Impact | Likelihood | Risk Score | Mitigation | Residual Risk | Owner | Status |
|---|---|---|---|---|---|---|---|---|---|---|---|
| R-001 | Phishing attack leads to credential theft | Email system | Social engineering | No MFA | High | Medium | High | Implement MFA, user training | Medium | IT Sec | In Progress |
What About Residual Risk?
Residual risk is what’s left over after you’ve applied your planned controls and mitigations. It’s a reality check—it tells you, “Even after we implement these safeguards, what risk still exists?”
Why it matters:
- Helps leaders make informed decisions
- Sets realistic expectations for risk reduction
- Drives conversation around risk tolerance
How to capture it:
- Re-score the risk after mitigation plans are in place
- Use qualitative values (Low, Medium, High) or updated ALE estimates
Prioritizing Risks Based on Business Value
Security exists to support the business—not the other way around.
When prioritizing risk responses, tie them to business objectives. Is this risk slowing down sales? Threatening customer trust? Blocking a product launch?
Example Process: Prioritizing Risk for Payment Downtime in a SaaS Company
- Identify Business Objective: Ensure 99.99% uptime for payment processing
- Map Dependencies: Third-party processor and internal APIs
- Identify Risks:
- API latency
- No SLA enforcement
- Quantify the Impact:
- $15,000/hour lost transactions
- $50,000/year in penalties
- Calculate Risk Score: High likelihood × high impact = Urgent
- Tie Mitigation to Business Enablement:
- Add monitoring, switch to provider with SLAs
This approach allows you to speak in terms that resonate with executives—not just “critical vulnerabilities” but actual business disruption.
Building a Cadence: Annual, Quarterly, or Ad-Hoc Reviews
Risk assessments have a shelf life. Depending on your rate of change, that shelf life could be months, not years.
Frameworks like:
- NYDFS – Annual assessments + material change trigger
- PCI-DSS – Continuous assessments for compliance
Good times to reassess:
- Major IT changes
- Business expansion
- Vendor onboarding/offboarding
- System architecture shifts
Do both a before and after assessment where possible:
- Before = plan control needs
- After = validate assumptions and effectiveness
Final Thoughts
If you’re just getting started, don’t wait for perfect. A simple spreadsheet and a few conversations can go a long way toward building a real security posture.
Start with what you’ve got. Talk to people. Use the data. Build trust. That’s how you turn a risk assessment into something useful—not just something you file away until next audit season.
