Most healthcare IT risk registers are a spreadsheet, maintained by one person, reviewed annually because an auditor asks, and referenced by nobody making decisions.
That is a shame, because the register is the only artefact that converts technical problems into the language budget decisions are made in. When it works, it is how an unpatchable modality fleet becomes a funded segmentation project instead of a recurring audit finding.
Three things separate a register that works from one that does not: the risks are written so a non-technical reader can evaluate them, the scoring reflects patient impact, and acceptance is a decision made by a named person rather than a silent absence of action.
Write the Risk, Not the Vulnerability
The most common defect is a register full of technical findings dressed as risks.
"PACS server running unsupported operating system."
That is a fact, not a risk. It states no cause, no event, and no consequence, so a reader outside IT cannot evaluate it or decide anything about it.
The structure that works is cause → event → consequence:
"Because the PACS server runs an operating system no longer receiving security updates, there is a risk that a known vulnerability is exploited to gain access to the imaging archive, resulting in disclosure of patient imaging data, loss of diagnostic service during recovery, and regulatory notification obligations."
Now a reader can assess how likely it is, how bad it would be, and what a mitigation would need to address. The extra sentence is the difference between a finding and a decision.
Two rules that keep registers honest:
One risk per entry. "Legacy systems and inadequate backups" is two risks with different owners, different treatments, and different costs.
Consequences in clinical and business terms. "Service degradation" means little. "Radiology unable to report for an estimated 8–24 hours, with elective imaging cancelled and emergency imaging on downtime procedures" means something to the person deciding.
Score for Patient Impact
Generic corporate scoring matrices score financial loss and reputational damage. In a hospital, the axis that matters most is patient impact, and it does not map neatly onto money.
An impact scale that works for clinical IT:
| Score | Patient impact | Operational impact |
|---|---|---|
| 5 — Catastrophic | Potential for patient death or serious harm | Multi-day loss of a core clinical service |
| 4 — Major | Delayed diagnosis or treatment for many patients | Loss of a core service for hours to a day |
| 3 — Moderate | Delays absorbed by workarounds; individual patients affected | Significant workflow disruption |
| 2 — Minor | No direct clinical impact; staff burden | Localised disruption |
| 1 — Negligible | None | Minimal |
For likelihood, prefer a defined frequency over adjectives. "Possible" means different things to different readers; "expected to occur once every 1–3 years" does not. Where a threat class has published sector data — ransomware against healthcare being the obvious one — use it rather than instinct, and say where the figure came from.
Score inherent and residual separately. Inherent risk is the exposure with no controls; residual is what remains after the controls that genuinely exist and are verified working. The gap between the two is a plain-language demonstration of what the security budget already buys — a rare and useful thing to be able to show.
The Fields That Make It Usable
Beyond the risk statement and scores:
| Field | Why |
|---|---|
| Risk owner | A named person with authority to act. Not "IT". |
| Affected systems | Enables impact analysis when something changes |
| Existing controls | What is already reducing this, and is it verified? |
| Treatment decision | Treat / tolerate / transfer / terminate |
| Treatment plan and target date | What will be done, by when |
| Residual score after treatment | Where this lands if the plan succeeds |
| Review date | When it must be looked at again |
| Acceptance record | Who accepted it, when, and until when |
Existing controls should record verification, not intent. "Backups are performed nightly" is a claim; "Backups performed nightly; last verified restore 12 June, RTO measured at 6 hours against a 4-hour target" is a control with evidence — and it also reveals a gap the claim would have hidden.
Risk Acceptance, Done Properly
Some risks will not be fixed. An unpatchable modality with eight years of clinical life left, a system whose replacement is three budget cycles away, a vendor who will not support MFA. That is normal, and it is the state most healthcare IT risks are in.
The problem is not acceptance. It is implicit acceptance — the risk sits at high, nobody funds treatment, and no one ever decides. When it materialises, nobody owns the decision because none was made.
Formal acceptance requires:
- A named accepting individual with authority appropriate to the score. Low risks can be accepted by a system owner. Critical risks require executive sign-off — and requiring an executive signature is often what unlocks the funding to avoid needing one.
- An expiry date. Acceptance is temporary. Twelve months maximum for anything scored high or above.
- The compensating controls relied upon, and confirmation they are verified.
- The trigger conditions that force re-evaluation before expiry — a published exploit, a change in exposure, a related incident.
A register where every high risk carries a dated executive acceptance is a register being used to make decisions. A register where high risks simply persist is a filing cabinet.
Keeping It Alive
Registers die from review cadences that are either too heavy to sustain or too light to matter.
A workable rhythm:
- Monthly — the operational team reviews new and changed risks only, not the whole register. Fifteen minutes.
- Quarterly — full review of everything scored high and above, plus anything with a review date falling due, plus every acceptance approaching expiry.
- Annually — complete review including low-scored entries and closed risks.
- Event-driven — after any incident, any major change, any new system, and whenever a relevant sector advisory is published.
Close risks explicitly. Registers that only grow become unusable, and people stop opening them. When a risk is genuinely treated, record what was done and close it with a date. Closed entries are evidence that the process works, which is exactly what you want when asking for the next thing to be funded.
Connect it to the systems that create risk. The register should be updated by change management, procurement, incident review, and audit — not solely by one person remembering. If a new system can go live without appearing on the register, the register will always trail reality.
Starting From Nothing
If there is no register today, do not begin with a framework and a taxonomy. Begin with the ten risks you already know about — the ones the team discusses in corridors. Write them properly, score them, assign owners, and take them to a governance meeting.
Ten well-written risks that get discussed will do more than two hundred imported from a template that nobody reads.
Related Reading
- The Healthcare IT Security Audit Checklist — where many register entries originate
- Medical Device Network Security — the classic accepted-risk category
- HIPAA Technical Safeguards for PACS and Interface Teams — the regulatory driver behind risk analysis
- PACS and DICOM Security: The Practitioner's Guide — technical controls that reduce residual scores
Need risk and control evidence pulled together from your own systems? Send us the details.