Security Risk Analysis Method

How to use this method

Know your role. Know every system that holds electronic patient information. Assess the risk, write it down, and act on it. Keep the record.

This document is a repeatable method for the risk analysis and the risk management that follow from it. The risk analysis finds where electronic patient information lives, what could go wrong with it, and how serious each risk is. Risk management is the plan that reduces those risks. Both are required by the Security Rule, and the Rule leaves the method to the organisation.

Legal note. This document helps a security team see what the HIPAA Security Rule and the breach notification rules ask of an organisation like yours, and what it could show. It is not legal advice. It does not say that you are compliant with HIPAA or that you are certified, and the Rules provide no certificate of compliance. Whether HIPAA applies to your organisation, in which role, and what a breach or a contract requires are for counsel to confirm. The notification deadlines are in P09 (RD-17 to RD-20) and P18, and are not repeated here.

Who this is for

The reader is the person who inherited the duty: usually the head of information security, who is also the security official, or an IT manager who was told to produce a risk analysis for a customer or an auditor. You do not need to know HIPAA. You need to know your systems or to be able to ask the people who do. The method works in a table and a document. It does not need a tool.

Use it in four moves. First read the sections on roles and on the ten steps. Then take the ePHI inventory template to the owners of your systems. Then rate and record the risks on the P05 scale. Last, write the report, sign it, and put the review date in the calendar.

What the Rule asks and what it does not

The Security Rule's security management process standard is to implement policies and procedures to prevent, detect, contain and correct security violations (164.308(a)(1)). It has two required specifications that this document serves:

• Risk analysis (164.308(a)(1)(ii)(A)). An accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of electronic protected health information held by the covered entity or business associate.
• Risk management (164.308(a)(1)(ii)(B)). Security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.

Both are required. Neither is weighed against cost or size, although the choice of measures is (164.306(b), (d)). What the Rule does not do is say how.

• No method. HHS says that “the Security Rule does not prescribe a specific risk analysis methodology” and that “there is no single method or ‘best practice’ that guarantees compliance with the Security Rule”. The method in this document is a choice, and it is yours to adapt. Following it does not by itself show that your analysis is accurate and thorough.
• No interval. HHS says that “The Security Rule does not specify how frequently to perform risk analysis” and that the process “should be ongoing”. The Rule does ask that security measures be reviewed and modified as needed (164.306(e)), that the documentation be reviewed periodically and updated when the environment or operations change (164.316(b)(2)(iii)), and that a periodic evaluation be made (164.308(a)(8)), but it names no period for any of them. The [[12]] months in this document is the pack's default, not the Rule's.
• No format. The Rule asks for the analysis to be documented in writing, which may be electronic, and for the documentation to be kept (164.316). It sets no layout.

The Rule also does not say that a risk analysis is the end. The result is what the organisation uses to decide which addressable specifications are reasonable and appropriate, and to choose the measures that reduce its risks.

The proposed changes to the Security Rule published at 90 FR 898 are a proposal and not part of the text this method applies; counsel confirms their status before any document is relied on.

The nine elements and the ten steps

HHS names the elements that any method has to achieve. This method has ten steps, because HHS's third element, identifying and documenting potential threats and vulnerabilities, is two pieces of work: threats, and then vulnerabilities. The steps follow the elements in order.

Do the steps in order the first time. After that, each review revisits the steps that changed. Steps RA-03 to RA-08 are done for each place in the inventory, which is why the inventory comes first.

HR-07 The risk analysis covers all the ePHI the organisation creates, receives, maintains or transmits, wherever it is, including where suppliers hold or reach it. It has the elements the HHS guidance names: scope, data collection, threats and vulnerabilities, current measures, likelihood, impact, level of risk, documentation and periodic review.

Roles and decisions

The Rule names one role, the security official (164.308(a)(2)). Everything else here is the pack's suggestion, and the titles are yours.

Two decisions of the pack belong to this method. They add to the decision rights of P09 and P05 and change none of them.

The security official is named in writing by the executive sponsor (HD-01). If the security official wrote the analysis, someone else, the executive sponsor, approves it. Nobody approves their own work.

The ten steps in full

Each step has the same layout: what the step is, what goes in, what to do, the common mistakes, and an example from Acme Corp (EXAMPLE), a business associate that runs a hosted patient-messaging and appointment service for clinics.

RA-01 Set the scope

All ePHI the organisation creates, receives, maintains or transmits, in every electronic medium and location, including with suppliers and on staff devices. Record what is in and what is out, and why.

Source: 45 CFR 164.306(a). HHS element: Scope of the analysis. Output: A written scope. Who: Security official and Executive sponsor.

What goes in. The answer of the HIPAA Applicability Assessment (A02): which role you hold, and so which parts of the organisation the Rules reach. The list of business units, sites, products and teams. The list of suppliers and subcontractors that can reach patient information.

What to do. Write the scope in one page: the legal entity or entities, the products and sites, the kinds of electronic media, and the suppliers. Write down what is out of scope and why, and have the executive sponsor agree the scope in writing before the work starts (HD-02 covers scope, method and result).

Common mistakes. Scoping to the main application, and leaving out email, exports, backups, laptops, test data and suppliers. Scoping to the systems the security team runs, when the patient information is in systems that other teams run.

RA-02 Collect the data

Find where ePHI is created, received, stored and sent: systems, databases, devices, backups, cloud services, email, messaging, exports and suppliers. Use inventories, interviews, data-flow walks and project history. Record each location in the ePHI inventory.

Source: 45 CFR 164.308(a)(1)(ii)(A); 164.316(b)(1). HHS element: Data collection. Output: The ePHI inventory. Who: Security official, ePHI system owner, IT lead and Vendor owner.

What goes in. Asset and system lists, cloud account lists and the supplier register. Project history: what was built or bought, and what data it was given. Data-flow diagrams, if they exist, and the people who can say how a system is really used.

What to do. Interview each ePHI system owner and the IT lead with the inventory fields IV-01 to IV-08 in front of you. Walk each data flow from where the information is created or received to where it ends. Look in the places people forget: exports and reports, email and chat, spreadsheets, test copies, backups, logs, laptops, phones and removable media, and what suppliers hold. Enter one row in the ePHI inventory for each place, and name the ePHI system owner.

Common mistakes. Building the inventory from the asset register alone. A register lists what was bought, not where the information went. Treating the inventory as finished. It is the part of the analysis that goes out of date first.

EXAMPLE. 5 places ended up in the inventory (EI-01 to EI-05). The support ticketing tool (EI-04) was added only because an interview with support asked what staff paste into tickets.

RA-03 Identify threats

List the reasonably anticipated threats to ePHI: natural, human (intentional and unintentional) and environmental, from the threat list TH-01 to TH-16 and from your own incidents.

Source: 45 CFR 164.306(a)(2). HHS element: Identify and document potential threats and vulnerabilities. Output: The threat list. Who: Security official and IT lead.

What goes in. The threat list TH-01 to TH-16 (below). Your own incident and near-miss records, and your customers' security questionnaires. Threat reports from your industry and your suppliers.

What to do. Go through the threat list for each inventory row and mark each threat that is reasonably anticipated for that row. Add the threats that are particular to you, and write down in a sentence why a threat was left off. A threat left off without a reason looks like a threat that was not thought of.

Common mistakes. Copying a generic list and attaching it to the report without choosing from it. Listing only attackers. Mistakes and failures cause as many incidents.

EXAMPLE. 8 threat types from the list carry a risk in the register (TH-05, TH-07, TH-01, TH-06, TH-15, TH-03, TH-10, TH-11).

RA-04 Identify vulnerabilities

For each inventory entry, find the weaknesses a threat could use: technical (configuration, patching, access) and non-technical (missing or unclear policy, training, process).

Source: 45 CFR 164.308(a)(1)(ii)(A). HHS element: Identify and document potential threats and vulnerabilities. Output: The vulnerability list per system. Who: Security official, ePHI system owner and IT lead.

What goes in. The inventory rows and the threats marked against them. Vulnerability scan and configuration review results, penetration test reports and audit findings. Policies and procedures, access reviews, training records and supplier agreements.

What to do. For each inventory row and each threat marked against it, ask what weakness the threat could use. Use both groups: technical (VT-01, VT-02) and non-technical (VT-03, VT-04). Take the weaknesses from evidence: a scan, a configuration check, a review of who has access, a read of the procedure. Write each in one plain sentence that names the system, so that the owner can act on it.

Common mistakes. Stopping at technical weaknesses. Missing procedures and unclear ownership are weaknesses too. Writing a vulnerability as a control failure in general terms, such as weak security, that nobody can fix.

RA-05 Assess current security measures

Record the measures already in place for each system, whether the Security Rule's specifications are implemented, and whether they are configured and used properly. Use the safeguard register (A03) as the checklist.

Source: 45 CFR 164.306(b)(1); 164.308(a)(1)(ii)(A). HHS element: Assess current security measures. Output: Measures in place, per system. Who: Security official, IT lead and ePHI system owner.

What goes in. The Security Rule Safeguard Register (A03): the 22 standards and their specifications are the checklist. Policies, configuration records, access reviews, test results and logs.

What to do. For each inventory row, record which measures are already in place and whether each is configured and used properly. A tool that is bought and not switched on is not a measure in place. Run down the standards of the register in turn, so that no family of safeguards is forgotten. Where a specification is addressable, note what is in place; the decision is made later (HR-05, HR-06).

Common mistakes. Counting a policy as a measure when nobody follows it. Recording the measures that the supplier says it has, with nothing to show.

RA-06 Rate the likelihood

For each threat and vulnerability pair, rate the likelihood over the next 12 months on the P05 scale, taking account of the measures in place.

Source: 45 CFR 164.306(b)(2)(iv). HHS element: Determine the likelihood of threat occurrence. Output: A likelihood for each pair. Who: Security official, ePHI system owner and IT lead.

What goes in. The threat and vulnerability pairs, and the measures in place for each. The P05 likelihood scale, and your incident history.

What to do. Rate each pair on the P05 likelihood scale for the next 12 months (P05 RM-03), taking the measures in place into account. Write one line of reasoning beside each rating, and have a second person read the pairs that matter most. A rating with no reasoning cannot be reviewed.

Common mistakes. Rating everything Possible. A scale used in one place cannot sort. Rating by what has happened to you before. A threat that has not hit you yet may still be reasonably anticipated.

EXAMPLE. Likelihood of ER-03 is 2 Possible: the backups can be reached only with administrator accounts. Likelihood of ER-06 is 3 Likely: the console is reachable from the internet with a password only.

RA-07 Rate the impact

For each pair, rate the impact on the confidentiality, integrity and availability of the ePHI on the P05 scale, using the ePHI impact prompts: how many individuals, what kind of information, harm to patients, effect on care, and effect on customers' compliance.

Source: 45 CFR 164.306(b)(2)(iv). HHS element: Determine the potential impact of threat occurrence. Output: An impact for each pair. Who: Security official and ePHI system owner.

What goes in. The inventory row for the pair, which says what ePHI is involved and how many individuals. The ePHI impact prompts (below), and the P05 impact scale.

What to do. Rate each pair on the P05 impact scale, using the impact prompts for ePHI. Rate the worst realistic consequence. Think about all three properties: confidentiality, integrity and availability. Ask the clinical or customer-facing owner whether care could be affected. The security team cannot answer that alone.

Common mistakes. Rating only confidentiality. A scheduling error that sends a patient to the wrong appointment is an integrity and availability harm. Rating impact on the organisation only, and leaving out the harm to patients and the effect on customers.

EXAMPLE. Impact of ER-07 is 4 Severe: tickets quote patient details of many individuals, the clinics would have to be told, and the company could not show what the supplier does with the information.

RA-08 Determine the level of risk

Multiply likelihood and impact to the P05 score and take the band (P05 RM-03). List the corrective actions for each risk, in order of band.

Source: 45 CFR 164.306(a)(2). HHS element: Determine the level of risk. Output: A risk register entry per pair, with its band and corrective action. Who: Security official.

What goes in. The likelihood and the impact of each pair.

What to do. Multiply likelihood by impact to get the P05 score, and read the band from the P05 matrix (P05 RM-03, RM-04). Do not use another formula. Write the register entry for each pair (the risk register below), with a corrective action, sorted by band. Critical and High risks go first to the executive sponsor.

Common mistakes. Averaging the likelihood and the impact. HHS gives averaging as one example of a method; the P05 scale multiplies, and the band is what decides who may accept the risk. A corrective action that reads investigate or consider. Write what will be done.

EXAMPLE. The register has 8 risks: 1 Critical, 4 High, 2 Medium and 1 Low. The Critical risk, ER-07, goes to the executive sponsor first.

RA-09 Finalise and approve the documentation

Write the scope, inventory, threats, vulnerabilities, measures, ratings and actions into the risk analysis report. The security official signs it and the executive sponsor approves it (HD-02). It feeds the risk management plan and the addressable decisions.

Source: 45 CFR 164.316(b)(1). HHS element: Finalize documentation. Output: The signed risk analysis report. Who: Security official and Executive sponsor.

What goes in. Everything from the steps before: scope, inventory, threats, vulnerabilities, measures, ratings, register and actions.

What to do. Write the report to the outline below, short enough that the executive sponsor reads it. The security official signs it and the executive sponsor approves it (HD-02). Date both. Send the register to the people who manage the risks, and the actions to the risk management plan.

Common mistakes. Approving a report that nobody has read in full. Leaving the report unsigned until the work is finished. An unsigned analysis is not a record you can show.

EXAMPLE. The report was signed by Max Okafor (EXAMPLE), the security official, and approved by the executive sponsor on 12 Mar 2026.

RA-10 Review and update

Review at least every [[12]] months and on any trigger (HR-09), update the inventory and ratings, and keep every version for six years.

Source: 45 CFR 164.306(e); 164.316(b)(2)(iii). HHS element: Periodic review and updates. Output: A dated review record. Who: Security official and Executive sponsor.

What goes in. The last signed report and register. The list of triggers that have happened since (below).

What to do. Put the review date in the calendar when the report is signed. The pack's default is [[12]] months and the Rule sets none. On a trigger, update the inventory, the pairs it touches and their ratings, and re-sign. Keep each version, with the date it stopped being in effect.

Common mistakes. Reviewing on the date and ignoring the triggers in between. Overwriting last year's file, so the older version, which you must keep, no longer exists.

EXAMPLE. The next review falls due by 12 Mar 2027, at the pack's default of 12 months. ER-07 was found after the signature, which is a trigger, so the register is revised and signed again before that date.

The inventory of electronic patient information

The inventory is the output of RA-02, and everything after it depends on it. It has one row for every place where ePHI is created, received, maintained or transmitted. A place is a system, a service, a device type, a mailbox, a backup or a supplier. It has eight fields.

How to fill it in

• One row for each place, not each product. A product that stores ePHI in three places has three rows.
• Copies are places: exports, test copies, backups, laptop caches and mailboxes each get a row. Never write the information itself into the inventory. Write what kind it is and how many individuals.
• Name one owner for each row. An owner is a person who can say how the place is used, not a team.
• Mark what you have seen and what you were told, and record the date of the last review of each row. A row built from an interview is Described only until a record or a view of the system confirms it.

Blank inventory (copy and complete)

The EXAMPLE's inventory

Acme Corp (EXAMPLE) had 5 rows at 30 Sep 2026. The figures are invented. Each row shows the risks that sit on it, so that the inventory and the register can be read together.

Row EI-04 was added on 30 Sep 2026, after the report was signed on 12 Mar 2026. That is a trigger (see Review and triggers).

Threats and vulnerabilities

A threat is the potential for a person or thing to exercise, by accident or on purpose, a specific vulnerability. A vulnerability is a flaw or weakness in the security of a system, its procedures or its controls that a threat could use. HHS groups threats as natural, human and environmental, and the human ones as intentional or unintentional. It groups vulnerabilities as technical and non-technical.

Threats

The list below has 16 types, in the groups HHS uses. It is a starting point for RA-03, not a complete list. For each inventory row, mark the threats that are reasonably anticipated for it, add your own, and say why you left the others off.

Vulnerabilities

Vulnerabilities are found per row, from evidence (RA-04). The four types below prompt the questions to ask. A weakness is written as a sentence that names the system, such as the support console signs in with a password only.

The unit that is rated is a pair: one threat, on one inventory row, against one vulnerability, such as TH-05 (theft or loss of a laptop) on EI-05 (laptops) against 12 contractor laptops without full-disk encryption. A threat with no vulnerability on a row is not a risk on that row. Write the pairs that matter. A register of every possible pair is too long to be read.

Rating the risks on the P05 scale

Likelihood and impact are rated on the 4 × 4 scale of P05-A02 Risk Assessment Methodology & Scoring Model, and the band is read from the score (P05 RM-03, RM-04). This document does not change the scale or the bands. If this document and P05 ever differ, P05 is right.

HR-08 The risk analysis rates likelihood and impact on the P05 scale and takes the band from it (P05 RM-03, RM-04). A risk outside appetite goes to treatment under P05 RM-06 and RM-07, and an accepted residual risk is recorded under P05 RM-08.

The levels

Likelihood is rated over the next 12 months on four levels: 1 Unlikely, 2 Possible, 3 Likely, 4 Almost certain. Impact is rated on four levels: 1 Minor, 2 Moderate, 3 Major, 4 Severe. The meaning of each level, with the anchors for choosing it, is in P05-A02 and is not copied here. The worked ratings below show how the levels read for ePHI.

The matrix

Impact runs down the side and likelihood across the top. The score is impact multiplied by likelihood, and only these scores are possible: 1, 2, 3, 4, 6, 8, 9, 12, 16. HHS gives averaging as one example of how to set a level of risk; the P05 scale multiplies, so that the band can decide who may accept the risk.

Bands: Low 1–3; Medium 4–6; High 8–9; Critical 12–16.

Impact on electronic patient information

The P05 impact scale is general. For ePHI, ask these questions before you choose the level. They rate nothing by themselves. They make sure the harm to patients and to customers is in the room.

• How many individuals' ePHI is involved?
• How sensitive is it: diagnoses, treatment, payment, identifiers that could cause harm if misused?
• Could patient care or safety be affected by loss of access or altered data?
• Would a customer (a covered entity) have to notify individuals or regulators?
• Would the organisation be unable to show what happened?

Think about all three properties of the information. Confidentiality: who could see it who should not. Integrity: what could be changed without anyone noticing. Availability: what could not be reached when it is needed, including for care.

Worked ratings (EXAMPLE)

The risk register

The register has one entry per pair that is carried as a risk. It is the output of RA-08. Rate with the measures that are in place now (RA-05), so that the score is the residual risk today. If your P05 register also holds a score before existing controls, as P05 RM-03 asks, keep that score in the P05 register and cite the entry here by its ID.

Blank register (copy and complete)

The EXAMPLE's register

Acme Corp (EXAMPLE): 8 risks at 30 Sep 2026, 1 Critical, 4 High, 2 Medium and 1 Low. The scores and bands are computed from the ratings.

Corrective actions and plan (EXAMPLE)

Every risk has a corrective action written so that it can be checked, with the treatment, the owner, the date and the score expected when it is done (P05 RM-07). Dates, owners and expected scores are EXAMPLE values. The risks are in order of band, highest first. None of the eight is accepted, because each can be reduced at a cost the company can bear. The last column names the standards and specifications of the Security Rule that the action bears on, from the Security Rule Safeguard Register (A03). A specification marked addressable is decided on its own record (see below).

Risk management: from the register to the plan

Risk management is the work of reducing the risks to a reasonable and appropriate level (164.308(a)(1)(ii)(B)). The register says what is wrong. The plan says what will be done, by whom and by when.

HR-10 Risk management is the plan that follows the risk analysis: each risk has a treatment, an owner and a date, and the security measures chosen are enough to reduce the risks to a reasonable and appropriate level.

Treatment, owner, date and acceptance

• Treatment. Each risk is reduced, avoided, transferred or accepted, as P05 defines them (P05-A02 Risk Assessment Methodology & Scoring Model). A treatment decision for a risk first assessed outside appetite is due within the window P05 RM-06 sets. This document sets no window of its own.
• Owner and date. Each treatment action has an owner, a due date and the score expected when it is done (P05 RM-07). The owner is a person with the authority to do the work or to ask for it.
• Acceptance. A residual risk that is accepted is recorded on the P05-A08 Risk Acceptance Form & Approval Record, approved at the level the band requires, and reviewed by its date (P05 RM-08). For ePHI, write down why the remaining risk is reasonable and appropriate, because that is the standard the Rule sets for risk management. Ask counsel before a High or Critical risk to ePHI is accepted.
• Completion. An action is complete when its result has been checked, and the risk is re-rated. The expected score was a forecast. The new score is a fact.

Blank plan (copy and complete)

How the result feeds the addressable decisions

HHS says that the outcome of the risk analysis is a critical factor in judging whether an addressable specification, or an equivalent measure, is reasonable and appropriate. The Rule's four factors are size, complexity and capabilities; technical infrastructure and security capabilities; the cost of the measures; and the probability and criticality of the potential risks (164.306(b)(2)). The last is what this method produces.

HR-05 An addressable implementation specification is assessed. If it is reasonable and appropriate it is implemented. If it is not, the reasons are documented and an equivalent alternative measure is implemented if that is reasonable and appropriate. It is never optional, and never skipped without a record.

HR-06 The assessment of an addressable specification uses the four factors of 164.306(b)(2) and the result of the risk analysis, is decided by the person HD-03 names, and is recorded on the addressable decision record.

The decision is recorded on the addressable decision record, one for each addressable specification. The record has eight fields. The person who decides is the one HD-03 names. The security official proposes. The decision is taken by the person whom the P05 band of the risk names, so that the person who would accept the risk is the person who decides.

Required specifications are not decided on a record. They are implemented, and the risk analysis rates how well they are working (HR-04). In the example, ER-01, ER-02, ER-04 and ER-05 point at addressable specifications and so call for a record.

How the result feeds the tracker and the self-assessment

Each corrective action that is not yet done is entered on the HIPAA Gap & Remediation Tracker (P31-A08), with the risk ID as its source, so that its progress is tracked in one place. The tracker's own priorities and dates are in A08 and are not repeated here.

The HIPAA Security Rule Readiness Self-Assessment (P31-A09) asks, among its items, whether the work of this document is in place and can be shown. Five of its items read this method's records: the item numbered SC-03 (the inventory), RA-01 (the analysis covers all ePHI), RA-02 (it is current) and RA-03 (the plan reduces the risks), and GV-03 (leaders approve and oversee). The numbers RA-01 to RA-03 in the self-assessment are its own item numbers and are not the step numbers of this document. The self-assessment reads dated records. A signed report and a plan with owners and dates are the records it looks for.

In the example, the item for a current analysis (RA-02) reads In place and not Operating, because the register holds ER-07, which was found after the signature, and the revised report has not yet been signed.

Review and triggers

HR-09 The risk analysis is reviewed and updated at least every [[12]] months and on any trigger: a new system or supplier that handles ePHI, a merger, a change in key staff, a security incident, or a change in the law. The interval is the pack's default. The Rule sets none, and the HHS guidance says the process should be ongoing.

HHS says that a truly integrated analysis is done as new technologies and business operations are planned, which reduces the effort of addressing risks after the event. In practice, put a line in your change process: before a system that will hold ePHI goes live, its inventory row and its pairs are written.

At each review, go through the steps in order and note what changed. Re-rate the pairs the change touches, and the corrective actions that were completed. Write the date, who took part, and what changed. If nothing changed, say so with the date. A review record that says nothing changed is still a record.

If an incident has to be decided as a breach, that is a separate decision (Breach Assessment & Notification Decision Procedure (P31-A06)), with its roles and clocks in P09 and P18. The analysis only asks whether the incident shows that a rating or a measure was wrong.

The report that is signed

The report is the output of RA-09. It is short enough to be read by the executive sponsor and complete enough to be shown to someone who was not there. The security official signs it and the executive sponsor approves it (HD-02).

Signature block (copy and complete)

The signatures are a record of who did and who approved what, and when. They are not a statement about the law, and the Rules provide no certificate of compliance.

Evidence to keep, and for how long

The analysis is a document, and so the rules on documentation apply to it. The Rule asks for the documentation to be kept for six years from the date it was created or the date it was last in effect, whichever is later (164.316(b)(2)(i)). Each signed version is a document, and so is each version of the inventory.

HR-13 Documentation is kept in writing (electronic is allowed) for six years from the date it was created or the date it was last in effect, whichever is later. A policy that was replaced keeps its six years from the day it stopped being in effect.

Keep the working papers with the report: interview notes, scan outputs, screenshots and the list of people who took part. They show how a rating was reached.

EXAMPLE. The report signed on 12 Mar 2026 is kept until 12 Mar 2032 if it stays in effect only that day. If a new report takes effect on 10 Mar 2027 (an assumption of the example), the old one was in effect until then, and its six years run to 10 Mar 2033. Set the date on the file when the version is replaced, and do not delete it before.

Evidence that recognised security practices have been in place is kept as EV-30. Which practices to follow is for the organisation to determine (42 U.S.C. 17941).

When the analysis covers suppliers and subcontractors

The risk analysis covers all the ePHI the organisation creates, receives, maintains or transmits, wherever it is, including where suppliers hold or reach it (HR-07). A supplier's own risk analysis is the supplier's duty, and you cannot do it for them. What you can do is to list what it holds for you, rate the risk of using it, and ask what it can show.

EXAMPLE. Acme Corp (EXAMPLE) has two subcontractors, a cloud hosting provider and a customer-support ticketing tool. The hosting provider's agreement was signed on 14 Jun 2024, and when it was checked against the security terms in Business Associate Agreement Security Terms (P31-A05), terms BT-04 and BT-06 were missing (The incident clause names breaches but not other security incidents, and sets no time.). The ticketing tool has no agreement at all, and this is ER-07, the one Critical risk in the register. The terms are checked in A05 and the agreement clauses are in P06-A07, by clause ID. The supplier steps are in P06-A03 Supplier Security Assessment Procedure.

Pitfalls

• Doing a risk analysis of the main application only, and leaving out email, exports, backups, laptops and suppliers.
• A risk analysis that was done once and not repeated when the environment changed.
• Having a long register and no plan. A risk with no action, owner or date is a list, not risk management (HR-10).

The role of NIST SP 800-66 Rev. 2

NIST SP 800-66 Rev. 2 is a resource guide that relates the Security Rule to NIST publications. It is informative. It does not change the Rule, and it does not change this method. HHS names NIST publications among the resources that organisations use, and says that they are examples of frameworks and methodologies and that following them does not by itself show that the risk analysis requirements are met.

If you already use a NIST method, or one from another source, you do not need to replace it. Test it against the nine elements. If every element has a step and an output, record which of your steps is which, and add what this document offers: the inventory fields, the ePHI impact prompts and the report outline. If an element is missing, add the step.

Limits of this method

• This is a method. It is not a risk analysis, and following it does not by itself show that your analysis is accurate and thorough. HHS says the Security Rule does not prescribe a method, and that no single method guarantees compliance with the Rule.
• The ratings are judgments. Two people can rate the same pair differently. The method asks for reasons so that a rating can be reviewed, and it does not remove the judgment.
• The EXAMPLE is invented. Acme Corp (EXAMPLE) is not a real organisation, and its ratings say nothing about any real one. The threat list of sixteen types is a starting point, and your environment will have others.
• The method rates risk on the P05 scale. If your organisation uses another scale across the enterprise, decide with the risk owner how the two relate before the first rating, and write the decision in the report. Do not change the P05 scale inside this method.

Not covered here

Adapting this method

Framework references

These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: 45 CFR Parts 160 and 164 as the eCFR prints them (current to 6 October 2026); HITECH Act provisions at 42 U.S.C. 17931, 17934 and 17941; HHS Office for Civil Rights guidance on risk analysis, business associates and unsecured protected health information; NIST SP 800-66 Rev. 2 (informative); NIST CSF 2.0; ISO/IEC 27001:2022 incl. Amd 1:2024 (by number and title only); as published and read on 18 October 2026.

The HIPAA Rules in 45 CFR Parts 160 and 164 apply to covered entities (health plans, health care clearinghouses, and health care providers that transmit health information electronically in connection with standard transactions) and, where the Rules provide, to business associates and their subcontractors. Whether your organisation is one of them is decided by what it does with protected health information, and counsel confirms it. The Security Rule (Subpart C) protects electronic protected health information. The Breach Notification Rule (Subpart D) applies to breaches of unsecured protected health information. This pack does not decide which applies to you.

The HHS guidance and the NIST publication cited here are not law. HHS says its risk analysis guidance is not a blueprint and that no method guarantees compliance. NIST SP 800-66 Rev. 2 is an informative resource. Using either is not a statement that your organisation is compliant or certified.

The proposed rule published at 90 FR 898 is a proposal. It is not part of the text this pack applies. Counsel confirms its status before any document is relied on.

ISO/IEC 27001 references name the clause or control this document relates to, by number and title only. No text of the standard is reproduced. A reference does not say that meeting a clause or control meets any requirement of the HIPAA Rules, or that your organisation holds a certificate.

A reference says what its source asks, and which CISO Times document helps with that work. It does not say that a document from this pack meets a requirement, and it does not say that an organisation is compliant or certified. The Rules provide no certificate of compliance for an organisation to hold.

This pack does not say which document, record or practice meets a requirement of the HIPAA Rules. Each reference says what its source asks and which CISO Times document helps with that work. Using a document does not by itself show that a requirement is met.

Definitions