How do we run and record a HIPAA security risk analysis?

Start

We need a security risk analysis we can defend

The Security Rule requires an accurate and thorough assessment of the risks to electronic protected health information (ePHI). It prescribes no method, and HHS says no method guarantees compliance. What you can do is follow the elements HHS names and keep records that show each was done. This flow asks, in order, whether those records exist.

• Then: Is a security official named in writing?

Decision

Is a security official named in writing?

The Rule names one role, the security official, responsible for the policies and procedures (164.308(a)(2)). In this pack they run the analysis, write the report and sign it. The executive sponsor names them in writing, and that sponsor is whoever your governance makes the senior approver. If the security official wrote the report, someone else approves it. Without a named person the analysis has no owner.

• No, or not known: Ask the executive sponsor to name one, then restart
• Yes: Write the scope: all ePHI, what is out, and why

Outcome

Ask the executive sponsor to name one, then restart

Fill the role first, because the analysis needs an owner. Do not let that delay the work: the analysis is required whether or not the role is filled. Take it to whoever governs the organisation: the board, a board committee it has delegated to, the management board in a two-tier structure, or executive management where there is no board. Whether you are a covered entity or business associate at all is “Is our organisation a HIPAA covered entity, a business associate, or neither?”.

Step

Write the scope: all ePHI, what is out, and why

The scope covers all the ePHI the organisation creates, receives, maintains or transmits, in every electronic medium and location, including suppliers and staff devices. Record what is in, what is out and the reason for each exclusion, and have the executive sponsor agree it in writing before the work starts. A scope limited to the main application is a named pitfall.

• Then: Is every place ePHI lives or moves inventoried?

Decision

Is every place ePHI lives or moves inventoried?

This includes systems, databases, devices, backups, cloud services, email, messaging, exports and suppliers. Each row records the system, what ePHI it holds, how it flows, who can reach it, where it is hosted, the agreement reference, backups and the date last reviewed. If you do not know, assume locations are missing.

• Yes: Are threats and vulnerabilities recorded for each location?
• No, or not known: Walk the data flows and complete the inventory

Step

Walk the data flows and complete the inventory

Use existing inventories, interviews, data-flow walks and project history. Ask each ePHI system owner to describe how the system is used and to answer for their row. Check tools meant for other things, such as ticketing, chat and shared drives, for ePHI in practice, not only what policy says.

• Then: Is every place ePHI lives or moves inventoried? (back to an earlier step)

Decision

Are threats and vulnerabilities recorded for each location?

Threats are the reasonably anticipated ones: human intentional and unintentional, natural and environmental. The pack gives sixteen as a starting point, not a complete list, and asks you to add your own incidents. Vulnerabilities are technical and non-technical weaknesses a threat could use, found per inventory row.

• Yes: Are current measures assessed, as configured and used?
• No, or not known: List the threats and find the weaknesses per row

Step

List the threats and find the weaknesses per row

Go through the threat list for each row and add your own incident history. Then look for weaknesses in configuration, patching, access, policy, training and supplier terms. Record how each was found, and which threats you left off and why.

• Then: Are threats and vulnerabilities recorded for each location? (back to an earlier step)

Decision

Are current measures assessed, as configured and used?

Record, for each row, the measures in place and whether the Security Rule's specifications are implemented, configured and used properly. A policy on paper is not the same as a measure that works. The safeguard register is the checklist. If you do not know, treat the measure as unproven.

• Yes: Are likelihood and impact rated on your own scale, with reasons?
• No, or not known: Check each measure against how the system is really used

Step

Check each measure against how the system is really used

Use configuration facts, scan results, account lists and the owner's answer, not only the policy. Record how each measure was checked. Anything that cannot be checked goes in the limits of the analysis.

• Then: Are current measures assessed, as configured and used? (back to an earlier step)

Decision

Are likelihood and impact rated on your own scale, with reasons?

Rate each threat and vulnerability pair for likelihood and for impact on confidentiality, integrity and availability. The Rule prescribes no scale. The pack's choice is the P05 scale, so the band is derived as for any other enterprise risk. If you rate on another scale, decide with the risk owner how the two relate before rating, and write it down.

• Yes: Does every risk have a level and a corrective action?
• No, or not known: Rate each pair and write the reasoning

Step

Rate each pair and write the reasoning

Take account of the measures in place. Use the impact prompts: how many individuals, how sensitive, effect on care, effect on customers who are covered entities. Two people can rate the same pair differently, so the reasons are what let a reviewer test the rating.

• Then: Are likelihood and impact rated on your own scale, with reasons? (back to an earlier step)

Decision

Does every risk have a level and a corrective action?

Multiply likelihood and impact to the score and take the band. List corrective actions in order of band. A risk with no action, owner or date is a list, not risk management.

• Yes: Does each risk have a treatment, owner and date?
• No, or not known: Complete the register and order it by band

Step

Complete the register and order it by band

One entry per pair: score, band and corrective action. After any incident, check whether a rating was too low or a threat or weakness was missing, because an incident is a review trigger.

• Then: Does every risk have a level and a corrective action? (back to an earlier step)

Decision

Does each risk have a treatment, owner and date?

Risk management follows the analysis: security measures chosen to reduce risks to a reasonable and appropriate level. Each treatment has an owner, a due date and the score expected afterwards. A residual risk that is accepted is recorded with why it is reasonable and appropriate. Addressable safeguards are “Is an "addressable" HIPAA safeguard optional?”.

• Yes: Is the report signed by the security official and approved?
• No, or not known: Write the plan: treatment, owner, date, expected score

Step

Write the plan: treatment, owner, date, expected score

Treat each risk as reduced, avoided, transferred or accepted. Ask counsel before a High or Critical risk to ePHI is accepted. An action is complete when its result is checked and the risk is re-rated.

• Then: Does each risk have a treatment, owner and date? (back to an earlier step)

Decision

Is the report signed by the security official and approved?

The report holds the scope, method, inventory, threats, measures, ratings, register and its limits. The security official signs and the executive sponsor approves it, both dated. The sponsor is whoever your governance makes the senior approver: the board or a committee it delegates to, the management board in a two-tier structure, or executive management where there is no board. The signatures are not a statement about the law.

• Yes: Is it reviewed on every change and by the pack's interval?
• No, or not known: Write the report, sign it and have it approved

Step

Write the report, sign it and have it approved

Include the limits: what could not be checked and what rests on interviews only. Someone other than the author approves it. Ask counsel before the report goes outside the organisation.

• Then: Is the report signed by the security official and approved? (back to an earlier step)

Decision

Is it reviewed on every change and by the pack's interval?

The Rule sets no interval and HHS says the process should be ongoing. The pack's default is 12 months and 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. Put a line in the change process so a new system gets its rows before it holds real data.

• Yes: Keep every signed version and the evidence for six years
• No, or not known: Add the triggers to change control and set the review date

Step

Add the triggers to change control and set the review date

Record the interval as the pack's default or your own, and decide who is told when a trigger fires. Each review record says what changed, or that nothing did, with the date and who took part.

• Then: Keep every signed version and the evidence for six years

Outcome

Keep every signed version and the evidence for six years

These records show the elements HHS names were done and kept current. They promise no result from OCR. Keep the inventory, each signed report, the plan and the review records for six years from the date created or last in effect, whichever is later. If OCR asks for your documents, that is “If OCR asks for our HIPAA documents, then what should we have ready?”.