Every security program starts with the same question: what are we actually protecting, and what could realistically go wrong? A security risk assessment is how you answer it. It replaces a generic checklist with a ranked view of your own exposure, so you spend time and money on the risks that matter most.
This guide explains what a security risk assessment is, the seven steps to run one, how to score and rank risks, and what HIPAA, NIST 800-171, CMMC and SOC 2 expect from you. It is written for security leads, compliance owners and executives at regulated organizations who need an assessment they can act on and show to an auditor.
What is a security risk assessment?
A security risk assessment is a structured process for identifying your assets, the threats and vulnerabilities that could affect them, the controls you already have, and the resulting risk to your organization. The output is a ranked list of risks with a plan for what to do about each one.
The widely used reference is NIST SP 800-30, Guide for Conducting Risk Assessments, which frames the work as preparing for the assessment, conducting it, and maintaining it over time. The exact method matters less than the discipline: define what is in scope, rate risks the same way every time, and write the results down.
It is different from a one-off scan or a compliance checklist. A checklist tells you what everyone should do. A risk assessment tells you what you should do first, given your systems, your data and your threats. If you want a ready-made professional version, see our security risk assessment services.
Why do organizations run security risk assessments?
Two reasons: to make better decisions and to meet requirements. On the decision side, an assessment tells you where limited budget reduces the most risk. On the requirements side, most major frameworks expect one.
- HIPAA: the Security Rule requires covered entities and business associates to conduct an accurate and thorough assessment of risks to electronic protected health information.
- NIST SP 800-171 and CMMC: requirement 3.11.1, carried into CMMC as RA.L2-3.11.1, calls for periodically assessing the risk to organizational operations, assets and individuals from operating systems that handle controlled unclassified information.
- SOC 2: auditors look for a defined process to identify and assess risks to your objectives.
- NIST Cybersecurity Framework: risk assessment sits in the Identify function, and the other functions depend on it.
Customers and insurers increasingly ask about it too. A dated, documented assessment is one of the easiest ways to show you take security seriously.

What are the steps of a security risk assessment?
Seven steps cover the process from scoping to review. Each one builds on the one before it.
- Define scope and boundaries. Decide which systems, business units, locations and data types are in. Clearly defined boundaries are a prerequisite for a useful assessment, so write them down before you start.
- Inventory assets and data. List the systems, applications, devices, data stores, and third parties that touch your data. Note where sensitive data lives and who can reach it. You cannot assess what you have not found.
- Identify threats and vulnerabilities. Threats are what could cause harm, such as ransomware, credential theft, insider misuse or a vendor compromise. Vulnerabilities are the weaknesses they could use, such as missing multi-factor authentication or unpatched systems.
- Evaluate existing controls. Record what already reduces each risk, and whether it works in practice, not just on paper. Weak or missing controls are the gaps.
- Rate likelihood and impact. For each risk, estimate how likely it is and how severe the consequences would be for operations, customers, compliance and finances.
- Prioritize and choose a treatment. Rank risks by combined rating, then decide to reduce, transfer, accept or avoid each one. Document who owns the decision.
- Document, report and review. Capture findings in a risk register, brief leadership, and schedule the next review. An assessment that nobody can find in six months does not help an audit.

How do you score and rank security risks?
The simplest method that works is a five-by-five matrix. Rate likelihood from 1 (rare) to 5 (almost certain) and impact from 1 (minor) to 5 (severe), then multiply. A score of 15 or more usually earns immediate attention, 8 to 14 goes on the planned roadmap, and anything lower is monitored.
Keep the scale definitions written down so two people rating the same risk reach similar numbers. For impact, tie each level to something concrete, such as hours of downtime, number of records exposed, or a regulatory consequence. Vague scales produce arguments instead of priorities.
If you need more precision, move to a quantitative approach that estimates financial loss. Most organizations get most of the value from the qualitative matrix first. Our AI risk assessment framework uses the same scoring logic for AI systems.

What does a risk register look like?
A risk register is the working document an assessment produces. Each row is one risk, and the columns keep the reasoning visible. A practical register includes:
- Risk description: for example, an attacker uses stolen credentials to reach the patient records system.
- Asset and data affected: the system, and the type of data on it.
- Existing controls: what reduces the risk today, such as multi-factor authentication on some accounts.
- Likelihood and impact ratings: each from 1 to 5, with the combined score.
- Treatment and owner: the decision, the person responsible, and a due date.
- Framework mapping: the HIPAA, NIST, CMMC or SOC 2 requirement the risk relates to.
The framework mapping column is what turns one assessment into evidence for several audits. It is also where most teams cut corners, and where an experienced adviser saves the most time.

What does HIPAA require for a security risk assessment?
The HIPAA Security Rule requires covered entities and business associates to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of electronic protected health information (45 CFR 164.308(a)(1)(ii)(A)).
HHS publishes guidance on risk analysis that walks through the elements it expects, including defining scope, collecting data about where ePHI is stored, identifying threats and vulnerabilities, assessing current security measures, rating likelihood and impact, determining the level of risk, and documenting the results with periodic review. The ONC also offers a free Security Risk Assessment Tool aimed at smaller practices.
The practical lesson is that HIPAA treats risk analysis as ongoing, not a one-time project. Regulators looking at a breach commonly ask whether you had a current, documented assessment.
How does a risk assessment support NIST 800-171, CMMC and SOC 2?
For contractors handling controlled unclassified information, the assessment is a baseline requirement. NIST SP 800-171 requirement 3.11.1 and CMMC practice RA.L2-3.11.1 both call for periodically assessing risk to operations, assets and individuals from the systems that process CUI, and the assessment feeds other requirements such as vulnerability remediation and your plan of action. Read more in our CMMC compliance guide or see our CMMC consulting and readiness services.
For SOC 2, auditors expect to see how you identify and assess risks to your service commitments, and evidence that you act on the results. A dated register with owners and treatments is exactly that evidence.
The efficient approach is one assessment, mapped to every framework you answer to, rather than separate exercises for each auditor.
How is a risk assessment different from a vulnerability scan or penetration test?
They answer different questions. A vulnerability scan finds known technical weaknesses in systems. A penetration test tries to exploit weaknesses to show what an attacker could achieve. A compliance audit checks whether you meet a specific standard.
A risk assessment sits above all three. It considers assets, threats, processes, people and third parties, then ranks what matters most to your business. Scan and test results are useful inputs to the assessment, but they do not replace it.
How often should you run a security risk assessment?
The frameworks say periodically or on an ongoing basis rather than naming a date, so you set the cadence. A common approach is a full assessment at least once a year, with a targeted update whenever something significant changes: a new system or cloud service, an acquisition, a major vendor change, a new regulatory requirement, or a security incident.
Between full assessments, keep the register alive. Review open items on a regular schedule, close out treatments, and add new risks as they appear. Third-party exposure deserves special attention, which is why many organizations pair the assessment with third-party risk management.
What are the most common mistakes?
- Starting without a scope. Assessments that try to cover everything finish nothing.
- Skipping the asset inventory. Unknown systems are usually the ones that cause the incident.
- Rating risks inconsistently. Without written scales, every risk looks high or every risk looks medium.
- Treating it as a one-time report. A PDF that sits on a shelf does not reduce risk.
- Forgetting third parties. Vendors with access to your data are part of your attack surface.
- No owners or dates. A finding without an owner does not get fixed.
When should you bring in outside help?
Outside help makes sense when you lack the time or in-house expertise, when you need an independent view for an auditor or customer, or when you answer to several frameworks at once. A good provider should leave you with a prioritized roadmap, not just a list of findings.
VisioneerIT runs assessments as the first phase of a broader program. If you want leadership on the results, our virtual CISO services can own the roadmap, and our managed security services can operate the controls afterward. For a wider view of the work, see cybersecurity consulting and our guide to building a proactive cybersecurity strategy.
Key things to remember
- A security risk assessment ranks your real exposure so you fix the most dangerous risks first.
- Follow seven steps: scope, inventory, threats and vulnerabilities, controls, likelihood and impact, prioritization, and documentation with review.
- Use written scales and a simple likelihood-by-impact matrix so ratings are consistent.
- HIPAA, NIST 800-171, CMMC and SOC 2 all expect a documented assessment, and one assessment can serve all of them if you map the findings.
- A risk assessment is broader than a vulnerability scan or penetration test, which feed into it.
- Run a full assessment at least yearly, and update it whenever something significant changes.
- Assign an owner and a due date to every treatment, or the findings will not get fixed.
Frequently asked questions
What is a security risk assessment?
A security risk assessment is a structured process that identifies your assets, the threats and vulnerabilities that could affect them, and the controls you already have. It ranks the resulting risks by likelihood and impact so you know what to fix first, and it documents the results for leadership and auditors.
How often should you do a security risk assessment?
Frameworks such as NIST SP 800-171 say to assess periodically, and HIPAA treats risk analysis as ongoing. A common approach is a full assessment at least once a year, plus a targeted update after major changes such as a new system, an acquisition, a significant vendor change, or a security incident.
Is a security risk assessment required by HIPAA?
Yes. The HIPAA Security Rule requires covered entities and business associates to conduct an accurate and thorough assessment of risks and vulnerabilities to electronic protected health information. Regulators looking at a breach commonly ask for a current, documented risk analysis.
What is the difference between a risk assessment and a penetration test?
A penetration test tries to exploit technical weaknesses to show what an attacker could achieve. A risk assessment is broader: it covers assets, threats, processes, people and third parties, and ranks what matters most to your business. Penetration test results are a useful input to a risk assessment.

