A risk assessment is a structured process for identifying what could go wrong, estimating how likely each risk is and how much harm it would cause, and ranking the results so that limited time and money go to the risks that matter most. In IT and security, it looks at the organization’s systems, data, people and vendors, the threats they face and the weaknesses that would let those threats succeed, then weighs them against the controls already in place. The output is a prioritized list of risks with decisions about what to do about each, not a report for its own sake.
At a glance
- A risk assessment combines assets, threats, vulnerabilities, likelihood, impact and existing controls into a ranked view of risk.
- Each significant risk gets a decision: reduce it, transfer it (for example, through insurance or contract), avoid it, or accept it.
- Scoring can be qualitative, semi-quantitative or quantitative; consistency matters more than precision.
- Results belong in a risk register with owners and deadlines, and should be refreshed when things change.
- Many frameworks, regulations, insurers and customers expect one, though what they require varies.
What problem it solves
Security budgets are finite and the list of possible threats is not. Without a structured assessment, organizations tend to spend on whatever was in the news, whatever a vendor pitched most recently, or whatever the loudest stakeholder wanted. Important gaps, such as an unprotected administrator account or a vendor with access to sensitive data, can go unaddressed while money goes to lower-value tools.
A risk assessment gives leadership a defensible way to decide. It shows which risks are unacceptable, which controls would reduce them most, and what can reasonably wait. It also gives insurers, auditors, customers and regulators evidence that risk is being managed deliberately.
How it works
1. Set scope and context. Decide what is being assessed: the whole organization, a business unit, a system, a vendor or a project. Agree on the time frame, the stakeholders and the organization’s risk appetite, meaning how much risk it is willing to accept.
2. Identify assets. Inventory the systems, data, processes, identities and vendors in scope, and mark the critical ones, such as payment processing, patient care or production lines, and the most sensitive data. A business impact analysis helps here by showing which processes matter most and how long they can be down.
3. Identify threats and vulnerabilities. For each asset, ask how it would most plausibly fail. Threats include phishing, ransomware, stolen credentials, insider misuse, vendor compromise, outages and natural events. Vulnerabilities include missing multi-factor authentication, excessive privileges, unpatched systems, exposed services and weak vendor controls. Vulnerability scanning, penetration tests and network assessments provide evidence.
4. Analyze likelihood and impact. Estimate how likely each scenario is and how much damage it would do in money, downtime, legal exposure, safety and reputation, taking existing controls into account. Document the assumptions so future assessments are comparable.
5. Prioritize and decide. Rank risks by their rating and choose a treatment for each significant one: mitigate with controls, transfer through insurance or contracts, avoid by changing the activity, or accept and monitor within the risk appetite. Assign owners, deadlines and expected results.
6. Record and report. Put the results in a risk register and give leadership a short summary of the top risks, decisions and requests.
7. Monitor and repeat. Track progress, test that controls work (for example, restore tests and tabletop exercises) and reassess on a schedule and after significant changes.
Published guidance can help structure the method, including NIST’s guide to conducting risk assessments, ISO/IEC 27005 for information security risk and the NIST Cybersecurity Framework. For AI systems, the NIST AI Risk Management Framework is a common reference.
When it matters for buyers
- When a framework, regulation or contract expects one. ISO/IEC 27001 certification is built around risk assessment, and the HIPAA Security Rule requires covered healthcare organizations and their business associates to analyze risks to electronic health information. Requirements vary, so confirm what applies with your compliance lead or counsel.
- When renewing cyber insurance or answering a security questionnaire. A current assessment makes answers faster and more accurate.
- When setting the security budget. Tie each major spend to the risk it reduces.
- When something changes. Acquisitions, new systems, cloud moves and new vendors deserve a targeted assessment; vendor risk is often handled through third-party risk management.
- When choosing an outside assessor. Independent assessments can add credibility with boards and customers.
Our governance, risk and compliance overview covers tools and services for running assessments and keeping the register current. For a practical starting list, see our cyber security risk assessment checklist.
Questions to ask vendors
- What method and scoring scale do you use, and is it aligned with a recognized framework?
- What will you need from us: interviews, documents, system access, scan results?
- Do you test controls, or rely on interviews and documents?
- What do the deliverables look like: an executive summary, a risk register, a remediation roadmap?
- How do you rate likelihood and impact, and how will you document assumptions?
- Can the results be imported into our GRC tool or risk register?
- Do you also sell the products or services you might recommend, and how do you manage that conflict?
How it differs from a penetration test or vulnerability scan
A vulnerability scan finds known technical weaknesses in systems. A penetration test tries to exploit weaknesses to show what an attacker could actually do. Both look at technology and answer “can this be broken?” A risk assessment asks a wider question, “what matters most and what should we do about it?”, by combining technical findings with business impact, threats, vendors, processes and existing controls. Scan and test results are inputs to an assessment, and the assessment’s decisions are tracked in a risk register. A compliance audit is different again: it checks whether required controls exist, not which risks are most important.
Problems this helps with
- Not sure which security risks matter most or where to spend first
- Insurer, auditor or customer asking for our latest risk assessment
- Leadership wants a clear picture of cyber risk, not a list of tools
- Security projects chosen by whichever vendor called last
