You can’t protect what you don’t know you have, and you can’t prioritize what you haven’t measured. A risk assessment is the process of figuring out what you’ve got, what could go wrong, and how bad it would be if it did. Every mature security program starts here — not with buying tools, not with writing policies, not with hiring a SOC team. Here. Because without a risk assessment, every security decision you make is a guess dressed up as strategy.
DO / DON’T
DO:
- Inventory every asset — hardware, software, data, people, third-party services. If it touches your network or your data, it goes on the list.
- Involve the business side — IT doesn’t own the risk. The business units that depend on the systems own the risk. Get them in the room.
- Quantify where you can — “high risk” is subjective. Dollar amounts and probability ranges are not. Use numbers when the data supports it.
- Document risk treatment decisions — Accept, mitigate, transfer, or avoid. Write it down. Name the person who made the decision.
- Review regularly — Quarterly at minimum for critical assets. Your risk posture changes every time you deploy a new system, onboard a vendor, or see a new threat intelligence report.
- Use established frameworks — NIST CSF self-assessment and CIS RAM are free, structured, and well-documented.
DON’T:
- Don’t skip the BIA (Business Impact Analysis) — If you don’t know what’s critical, you’ll spend equal effort protecting the lunch menu database and the payment processing system.
- Don’t rate everything as “medium” — If every risk is medium, you’ve failed to differentiate. Force the hard conversations about what actually matters.
- Don’t treat it as a one-time project — A risk assessment is a snapshot. The moment you finish it, it starts aging. Build reviews into your operational rhythm.
- Don’t let the perfect be the enemy of the done — A rough risk assessment with 30 well-understood entries is worth more than a delayed, perfect one with 500.
- Don’t confuse compliance with risk management — Compliance tells you what you must do. Risk assessment tells you what you should do. They overlap, but they’re not the same thing.
Step 1: Asset Inventory
You cannot assess risk to things you don’t know about. Start here.
What to Inventory
- Hardware — Servers, workstations, laptops, mobile devices, network equipment, IoT devices. Include anything that stores, processes, or transmits data.
- Software — Operating systems, applications, databases, SaaS platforms, custom-built tools. Include version numbers.
- Data — Customer records, financial data, intellectual property, employee information, credentials. Classify by sensitivity: public, internal, confidential, restricted.
- People — Roles with privileged access. Admin accounts, service accounts, third-party vendor access.
- Third-party services — Cloud providers, SaaS tools, managed services, payment processors. Your risk extends to their risk.
How to Do It
Use a spreadsheet or a dedicated asset management tool. For each asset, record: asset name, owner, location, data classification, criticality (how important it is to business operations), and dependencies (what else breaks if this breaks).
If you’re starting from nothing, the NIST Cybersecurity Framework Identify function walks through this systematically. The CIS Critical Security Controls put asset inventory as Control #1 for a reason — everything else depends on it.
Step 2: Threat Identification
Once you know what you have, ask what could threaten it.
Common Threat Categories
- External attackers — Ransomware operators, phishing campaigns, opportunistic scanning, targeted attacks. Check CISA’s Known Exploited Vulnerabilities Catalog for what’s actively being exploited.
- Insider threats — Malicious insiders, careless employees, compromised accounts. This category is uncomfortable to discuss, which is exactly why it gets underestimated.
- Natural disasters — Flooding, fire, power outages, extreme weather. If your data center is in a flood zone, that’s a risk.
- Supply chain — Vendor compromise, third-party breaches, dependency vulnerabilities. The SolarWinds and Log4Shell incidents demonstrated how supply chain threats cascade.
- Human error — Misconfigured systems, accidental data exposure, failed backups. The most common threat vector and the least glamorous.
Map threats to assets. Not every threat applies to every asset. Ransomware is a threat to your file server; a flood is a threat to your physical data center; a phishing campaign is a threat to your people.
Step 3: Vulnerability Identification
Where are the gaps between your threats and your defenses?
- Run vulnerability scans against your infrastructure. Tools like Nessus, Qualys, or OpenVAS identify known vulnerabilities in your systems.
- Review configurations against benchmarks. The CIS Benchmarks provide hardening guides for operating systems, cloud platforms, and applications.
- Check patch levels — Unpatched systems are the most exploited vulnerability class. CISA KEV tells you which ones attackers are actively exploiting right now.
- Assess process gaps — Do you have an incident response plan? Is access reviewed regularly? Are backups tested? Technical vulnerabilities are only half the picture.
- Review third-party risk — Request SOC 2 reports or security questionnaires from critical vendors. Their vulnerabilities become your vulnerabilities.
Step 4: Risk Scoring
For each threat-vulnerability pair, score the risk.
Likelihood + Impact
Likelihood: How probable is it that this threat will exploit this vulnerability? Consider threat actor motivation, vulnerability exposure, and existing controls.
Impact: If it happens, how bad is it? Consider financial loss, operational disruption, reputational damage, regulatory penalties, and legal liability.
A simple 5x5 matrix works:
| Impact: 1 (Minimal) | 2 (Low) | 3 (Moderate) | 4 (High) | 5 (Critical) | |
|---|---|---|---|---|---|
| Likelihood: 5 (Near Certain) | 5 | 10 | 15 | 20 | 25 |
| 4 (Likely) | 4 | 8 | 12 | 16 | 20 |
| 3 (Possible) | 3 | 6 | 9 | 12 | 15 |
| 2 (Unlikely) | 2 | 4 | 6 | 8 | 10 |
| 1 (Rare) | 1 | 2 | 3 | 4 | 5 |
Scores above 15: address immediately. Scores 8-15: plan remediation. Scores below 8: monitor and review.
For organizations ready to go deeper, quantitative methods like FAIR (Factor Analysis of Information Risk) translate risk scores into dollar values using probability distributions. When you need to justify a security budget, speaking in dollars beats speaking in colors.
Step 5: Risk Register
The risk register is where everything comes together. For each identified risk, document:
| Field | What Goes Here |
|---|---|
| Risk ID | Unique identifier |
| Description | What could happen, in plain language |
| Asset(s) affected | What’s at risk |
| Threat source | Who or what causes it |
| Vulnerability | What weakness is exploited |
| Likelihood | Scored 1-5 |
| Impact | Scored 1-5 |
| Risk score | Likelihood x Impact |
| Risk owner | Name of the person accountable |
| Treatment | Accept, mitigate, transfer, or avoid |
| Treatment details | Specific actions, timelines, and budgets |
| Status | Open, in progress, closed |
| Review date | When this gets re-evaluated |
The risk register is a living document. It gets reviewed at every security meeting, updated when conditions change, and reported to leadership regularly. A risk register that nobody reads is a compliance artifact, not a security tool.
Step 6: Risk Treatment
For each risk, you have four options:
- Mitigate — Implement controls to reduce likelihood or impact. This is the most common treatment. Patching, encryption, access controls, training.
- Transfer — Shift the financial impact to someone else. Cyber insurance, contractual liability transfers, outsourcing to managed service providers. The risk still exists; you’ve moved who pays for it.
- Accept — Acknowledge the risk and do nothing. This is legitimate when the cost of mitigation exceeds the potential loss, but it must be a documented, informed decision by someone with authority. “We didn’t know about it” is not risk acceptance.
- Avoid — Eliminate the risk entirely by eliminating the activity. Don’t want the risk of storing credit card numbers? Don’t store them — use a tokenization service. Risk avoidance is the most effective treatment and the least popular because it often means changing how the business operates.
If It Already Happened
If you’re reading this after a breach or incident, a risk assessment is still the right next step — but scope it to the incident first. Identify what was compromised, what data was affected, and what controls failed. Then expand outward. The incident just gave you real-world data about your threat landscape. Use it.
Report the incident through appropriate channels. CISA accepts voluntary incident reports. If personal data is involved, check your breach notification obligations under applicable regulations. The FTC and FBI IC3 are the primary federal reporting channels.
The risk assessment is step one. Not the last step — the first one. Pick one framework, start with your most critical assets, and work outward. A completed, imperfect risk assessment that gets reviewed quarterly is worth infinitely more than a perfect one that’s still in planning. Open the spreadsheet. Start counting what matters.