Is an "addressable" HIPAA safeguard optional?

Start

A safeguard in the Security Rule is marked addressable

Addressable is a label on an implementation specification. It tells you what the Rule asks you to do before you decide, and the answer is to assess it. It does not say that you may leave it out. Every standard that applies to you must be met, and none is optional.

• Then: Find the specification on the safeguard register

Step

Find the specification on the safeguard register

The register lists all 22 standards and their implementation specifications, each marked Required or Addressable. All 22 standards are required: a standard is never addressable. Only a specification is required or addressable. Of the specifications, 19 are required and 22 are addressable. Work from the register row so that you know which kind you hold. A standard with no specification under it is simply required.

• Then: Is it a standard, or a specification marked Required?

Decision

Is it a standard, or a specification marked Required?

Read the mark on the row. A standard, or a specification marked Required, has nothing to weigh. If the mark says Addressable, or you cannot tell which it is, take the addressable path and assess it. That path ends in an implemented measure or a written reason, so it costs little to follow.

• Yes: required: Required: implement it; cost and size shape how, never whether
• No: addressable, or not known: Is there a current risk analysis covering the ePHI involved?

Outcome

Required: implement it; cost and size shape how, never whether

A required specification is implemented. Cost, size and the other factors in 164.306(b) may shape how you implement it, never whether, and it does not need an addressable decision record. The risk analysis then rates how well it is working.

Decision

Is there a current risk analysis covering the ePHI involved?

The result of the risk analysis is a critical factor in judging whether an addressable specification is reasonable and appropriate. Without a current one, the fourth factor, the probability and criticality of the risks to ePHI, has nothing behind it. If you are not sure it is current, treat the answer as No.

• Yes: Assess it against the four factors and the risk analysis
• No, or not known: Run or refresh the risk analysis first

Step

Run or refresh the risk analysis first

Do the analysis before you decide, so that the risks the specification would reduce are rated on the same scale as the rest of your register. “How do we run and record a HIPAA security risk analysis?” takes you through it. Then go on to the assessment.

• Then: Assess it against the four factors and the risk analysis

Step

Assess it against the four factors and the risk analysis

The Rule's four factors are the size, complexity and capabilities of the organisation; its technical infrastructure and security capabilities; the cost of the measures; and the probability and criticality of the risks to ePHI. Set them beside the risks the specification would reduce. Write each factor down for your own environment, not for organisations in general.

• Then: Is it reasonable and appropriate in our environment?

Decision

Is it reasonable and appropriate in our environment?

Ask whether the specification is a reasonable and appropriate safeguard here, given the four factors and the risks it would reduce. Answer Yes or No with the reasons. Until the person who decides confirms it, your answer is the security official's proposal. If the facts are not known yet, answer Yes for now: the cautious course is to plan to implement it and revisit once the facts are in.

• Yes, or not known: Plan to implement it as written
• No: Is cost the reason, and not yet weighed against the risk?

Step

Plan to implement it as written

If the specification is reasonable and appropriate, the proposal is to implement it. Set an owner and a date in your own plan, as for any other control, and keep the records of the measure itself. The person who decides confirms it at the end of this flow.

• Then: Is this specification about encryption?

Decision

Is cost the reason, and not yet weighed against the risk?

Cost is one of the four factors in the Rule. It does not end the assessment on its own. A measure that is expensive but reduces a high risk, or that can be done in a cheaper form, may still be reasonable and appropriate. If cost is the main reason and you have not yet weighed it against the risk, or you do not know the other reasons, answer Yes. Once you have weighed it, answer No.

• Yes, or not known: Weigh cost against the risk and cheaper ways to do it
• No: weighed, or other factors also point away: Document why it is not reasonable and appropriate

Step

Weigh cost against the risk and cheaper ways to do it

Put the cost beside the rated risk and your capabilities. Look for a cheaper form of the same specification, for example one the tools you already own can do. Then repeat the assessment with the new facts. If the answer is still No, say in the record that you weighed cost against the risk.

• Then: Assess it against the four factors and the risk analysis (back to an earlier step)

Step

Document why it is not reasonable and appropriate

The Rule asks for the reasons in writing. Write them against the four factors in the specification's decision record, so that a reviewer can follow them without you. A note that says it was too much work gives a reviewer nothing to test.

• Then: Is an equivalent alternative measure reasonable and appropriate?

Decision

Is an equivalent alternative measure reasonable and appropriate?

An equivalent alternative reduces the same risks the specification would have. Name what you would do instead and why it is equivalent. If you are not sure that it is equivalent, answer No and say so in the record rather than relying on it.

• Yes: Plan the alternative and record why it is equivalent
• No, or not known: Is this specification about encryption?

Step

Plan the alternative and record why it is equivalent

The proposal is to implement the alternative. Write down what it is and why it reduces the same risks. The record lets a reviewer see why the substitution is sound. The person who decides confirms it at the end of this flow.

• Then: Is this specification about encryption?

Decision

Is this specification about encryption?

Encryption is the common case. The register has two encryption specifications, encryption and decryption (HS-14.4) and encryption in transmission (HS-18.2). Both are addressable, so both need a decision record. Neither is a free pass.

• Yes, or not known: Note the second effect: encryption decides if PHI is secured
• No: Record the proposal on the addressable decision record

Step

Note the second effect: encryption decides if PHI is secured

PHI counts as secured for breach purposes only if it was encrypted as HHS guidance specifies and the key has not been compromised, or destroyed as the guidance specifies. HHS says the key must not have been breached and should be kept apart from the data, so a key kept on the lost device needs a recorded reason to believe it was not compromised. A decision not to encrypt has consequences beyond this Rule. Encryption at rest does not stop an attacker acting on a running system, and “When does a security incident become a reportable HIPAA breach?” explains the ransomware presumption.

• Then: Record the proposal on the addressable decision record

Step

Record the proposal on the addressable decision record

Fill one record for each addressable specification, in the eight fields: the specification, the risks it addresses, the four factors, the answer to reasonable and appropriate, the decision, the alternative, who decided and when, and the review. The decision field is never left blank.

• Then: Have the right person decide; redo the assessment if they differ

Step

Have the right person decide; redo the assessment if they differ

The security official proposes. The person the P05 acceptance band of the residual risk names decides, so that the person who would accept the risk is the one who decides. If they decide differently, redo the assessment with their reasons and update the record. The Rule asks for the assessment and the record and does not name a person. This is the pack's default, and your governance may set it differently.

• Then: Decided and recorded: review it with each risk analysis

Outcome

Decided and recorded: review it with each risk analysis

Review the decision with the next risk analysis and on any trigger, such as a new system or a change in the risk. A written reason that stood last year may not stand now. Keep the record in your own register.