The annual security risk assessment, done the way it's supposed to be done

A real risk assessment vs. a checkbox

Most organizations have a document somewhere called a risk assessment. Too often it is a vendor questionnaire, a maturity spreadsheet, or a one-page attestation that was filled out once, mapped to nothing in particular, and never changed a single budget decision. It satisfies a line on a form. It does not tell you what to fix first, why, or how much risk you actually carry.

A real risk assessment is a decision-making instrument. It starts from your specific environment, the systems you run, the data they hold, the devices on your network, the vendors who touch your information, and it reasons about what could go wrong, how likely it is, and what it would cost you in dollars, downtime, and patient safety. The output is not a grade. It is a ranked set of risks with the rationale behind each rating, so the people who control the budget can act on it.

The difference shows up the moment anyone with authority asks a hard question. When a board member, an auditor, an OCR investigator, or a cyber-insurer's underwriter asks 'how did you arrive at that conclusion?', a checkbox cannot answer. An evidence-backed risk assessment can, every risk level traces back to identified threats, observed vulnerabilities, and documented likelihood-and-impact reasoning. That traceability is the whole point, and it is exactly what the cheap version skips.

• A checkbox tells you a control exists; a risk assessment tells you whether the residual risk is acceptable.
• A checkbox produces a static PDF; a risk assessment produces a living register you update as the environment changes.
• A checkbox is generic and portable between organizations; a risk assessment is specific to your systems, your devices, and your data flows.
• A checkbox is a cost you absorb; a risk assessment is the input that lets you spend your security budget where it removes the most risk.

Methodology: built on NIST SP 800-30

We run every engagement on a recognized, repeatable methodology rather than a proprietary scoring gimmick. The backbone is NIST Special Publication 800-30, the federal guide for conducting risk assessments. It is a standard auditors recognize and one that produces defensible, explainable results, which is precisely why we use it.

The 800-30 process is disciplined: identify the threat sources and threat events relevant to your environment, identify the vulnerabilities those threats could exploit, determine the likelihood that a given threat exploits a given vulnerability, determine the impact if it does, and then combine likelihood and impact into a risk level for each threat-vulnerability pair. That likelihood-and-impact reasoning is what separates a risk assessment from a vulnerability scan or a list of findings, a scanner tells you a flaw exists; the assessment tells you how much it actually matters here.

Where useful, we draw on the wider NIST risk family, NIST SP 800-115 for technical security testing and assessment to inform the technical evidence, and the NIST CSF 2.0 functions to organize the picture for leadership. But the answer to 'how did you score this?' is always the same and always in the record: stated threats, observed vulnerabilities, reasoned likelihood, reasoned impact. Nothing lives only in someone's head.

Mapped to the frameworks you're measured against

A finding is only useful if it connects to the standards the people around you already speak. We map every risk to the frameworks your compliance team, your board, your auditors, and your cyber-insurer use, so one assessment answers many questions instead of generating yet another isolated report.

Healthcare organizations are rarely measured against a single yardstick. You may owe a HIPAA Security Rule obligation, be pursuing or maintaining HITRUST, reporting posture to leadership through NIST CSF, and being asked by partners and insurers whether you follow the HHS 405(d) practices. Rather than run four overlapping assessments, we run one rigorous risk assessment and cross-walk the results to each.

Note the deliberate boundary: this is the broad, multi-framework risk assessment. If what you specifically need is the HIPAA Security Rule risk analysis required at 45 CFR 164.308(a)(1)(ii)(A), the one OCR cites, that is a focused engagement of its own, and we offer it as a dedicated service. This page is the wider annual SRA that situates HIPAA alongside the other frameworks you answer to.

• HIPAA Security Rule (45 CFR Part 164), risks tied to the safeguards and to the risk-analysis requirement OCR enforces.
• NIST CSF 2.0, findings organized across the Govern, Identify, Protect, Detect, Respond, and Recover functions for a leadership-level view of posture.
• HITRUST CSF, results aligned to support a HITRUST program, whether you are working toward certification or maintaining one.
• HHS 405(d) HICP, risks checked against the Health Industry Cybersecurity Practices, sized for small, medium, and large organizations and recognized under federal law as security practices OCR may consider.
• Supporting NIST guidance, SP 800-30 for the assessment process and SP 800-115 for technical testing, so the evidence base is sound.

Corporate IT and the connected-device estate, both

Generic IT assessors stop at the servers, laptops, cloud tenants, and identity systems they already understand. In a hospital or clinic that leaves the most dangerous part of the network unassessed: the connected medical devices. We cover both halves of the estate because attackers and auditors both look at the whole thing.

On the corporate IT side we assess the familiar surface, Active Directory and identity, email and collaboration, endpoints and servers, cloud and SaaS, network architecture and segmentation, backup and recovery, and the vendors and business associates who handle your data. This is table stakes, and we do it thoroughly.

The connected-device estate is where healthcare risk concentrates and where most assessments fall short. Infusion pumps, patient monitors, imaging modalities and the PACS behind them, lab analyzers, and other clinical equipment frequently run unsupported operating systems, cannot be patched on a normal cycle, and speak protocols like DICOM and HL7 that were never designed with security in mind. In its 2022 State of Healthcare IoT Device Security Report, Cynerio found that roughly 53% of connected medical devices have at least one known critical vulnerability. You cannot scan these the way you scan a laptop; the risk has to be characterized, compensating controls evaluated, and the device kept safely in service. That is the part of healthcare we concentrate on, and it is in scope by default.

• Corporate IT: identity and Active Directory, email, endpoints and servers, cloud and SaaS, network segmentation, backup and recovery, and third-party/vendor risk.
• Clinical and IoMT: infusion pumps, monitors, ultrasound, lab analyzers, and other connected medical devices that handle or transmit ePHI.
• Imaging: PACS, DICOM archives, and modality workstations that store and move studies.
• Interfaces and data flows: HL7, FHIR, and APIs that move ePHI between systems and out to vendors.

What you get: register, roadmap, and evidence

The value of an assessment is not the engagement, it is what it leaves behind. You walk away with three deliverables built to be used by three different audiences: the people who fix things, the people who fund things, and the people who audit or insure you.

The risk register is the analytical core. Every identified threat-vulnerability pair carries its likelihood, its impact, its resulting risk level, and the rationale behind that rating, structured so your team or ours can keep it current as systems, devices, and vendors change, rather than rebuilding from zero every year.

The remediation roadmap turns that register into a plan you can actually fund. We sequence remediation by risk reduced per dollar and per unit of operational disruption, not by vendor convenience, so the roadmap survives contact with a real budget cycle and a real clinical schedule. And the evidence package wraps methodology, scope, and findings into documentation built for an auditor, a regulator, or a cyber-insurer's underwriter to review as proof the work was real, thorough, and current.

• A prioritized risk register scoring every threat-vulnerability pair by likelihood and impact, with the resulting risk level and the reasoning behind it.
• A fundable remediation roadmap sequenced by risk reduced versus cost and disruption, what to fix first, why, and a realistic path.
• An evidence package, methodology, scope, asset inventory, and findings, organized for auditors, regulators, and cyber-insurers.
• Framework cross-walks tying findings to the HIPAA Security Rule, NIST CSF 2.0, HITRUST CSF, and HHS 405(d) HICP.
• An executive summary that translates technical risk into business and patient-safety terms leadership can act on.

How it works

1. 01

   Scope

   We define the boundary deliberately and build the asset inventory and data-flow map the assessment depends on, every system, cloud tenant, vendor, location, and connected device in play. Working with IT, security, and biomedical/clinical engineering, we make sure the connected-device estate and the interfaces that move data are in scope, not quietly omitted. Incomplete scope is one of the most common reasons an assessment fails review, so we settle it up front.

2. 02

   Assess

   For each in-scope asset we identify the realistic threats and the vulnerabilities that expose it, drawing on interviews, configuration and architecture reviews, vulnerability data, and the specific failure modes of healthcare environments, unpatchable devices, flat clinical networks, weak vendor controls, and gaps in identity and segmentation. We also document the security measures already in place, because residual risk is what matters.

3. 03

   Rate

   Using the NIST SP 800-30 method, we score each threat-vulnerability pair by likelihood and impact to produce a defensible risk level, and we map each finding to the HIPAA Security Rule, NIST CSF 2.0, HITRUST CSF, and HHS 405(d) HICP. The result is a risk register where every rating is reasoned and evidence-backed, not a flat list of findings.

4. 04

   Roadmap

   We translate the register into a sequenced, fundable remediation plan, what to fix first, the controls that remove the most risk for the least disruption to care, and the timeline to get there. We then deliver the full evidence package and walk your leadership and compliance team through it so the results are understood, owned, and ready to produce on demand for an auditor or insurer.

Frameworks & standards we align to

Every finding maps back to the standards your auditors, board, and cyber-insurer already speak.

Frequently asked questions