apointoo.
Request access
HIPAA

How to Perform a HIPAA Breach Risk Assessment

cmsapointoo··6 min read

A HIPAA breach risk assessment asks whether an impermissible use or disclosure of unsecured protected health information poses a significant risk of financial, reputational, or other harm, using the required facts and documented mitigation. Start with evidence, not a desired outcome. Apply the four-factor structure, record uncertainty, and route the notification decision to the appropriate privacy and legal owners.

The assessment is not a checkbox that a security tool can complete. Encryption, access logs, a BAA, or a backup can provide important facts, but none removes the need to analyze what happened. Keep the current rule, contract notice windows, and any other jurisdictional duties separate.

What the four-factor assessment examines

HHS guidance describes four core factors. First, examine the nature and extent of the information, including the types of identifiers and the likelihood of re-identification. Second, identify who used or received it and whether that person or entity could reasonably use it. Third, determine whether the information was acquired or viewed. Fourth, assess the extent to which the risk was mitigated.

Factor Questions Evidence
Nature and extent What data and identifiers were involved? Schema, logs, scope review
Recipient Who received or could receive it? Identity, vendor, and access records
Acquired or viewed Was it opened, copied, or only exposed? Access, export, and network evidence
Mitigation What reduced or ended the risk? Containment, return, deletion, and attestations

Do not assign a conclusion to a factor without stating the evidence source and confidence. “No evidence of access” is not the same as “proved no access.” Record the difference.

How to establish the incident facts

Open a restricted assessment record with an opaque incident reference. Capture discovery time, systems, tenants, identities, event type, affected period, data classes, and known recipients. Preserve logs before changing retention or rotating systems. If a vendor holds evidence, request it through the contract and record the request date.

  1. Define the suspected event and initial scope.
  2. Identify the source and destination.
  3. Determine whether data was acquired, accessed, used, or disclosed.
  4. List each field class without copying full records.
  5. Validate tenant and recipient roles.
  6. Record containment, return, deletion, or other mitigation.

Keep separate timelines for detection, containment, vendor notice, risk assessment, and decision. A contract can require notice before the statutory outer limit. Record the earliest deadline and the owner without stating that every deadline is the same.

The healthcare incident response runbook covers the first 24 hours. The security monitoring alerts article helps ensure future incidents produce useful evidence without content logging.

Unsecured data, encryption, and exceptions

Determine whether the affected records were secured under the applicable breach rule and guidance. Check the actual encryption algorithm, key custody, configuration, endpoint, backup, and key exposure. Do not infer encryption from a provider label. If the decryption key was exposed or the control did not cover the affected copy, document that fact.

Encryption is one factor in the assessment and may affect breach-notification analysis. It does not remove incident response, access review, contract notice, or other jurisdictional duties. Similarly, a signed BAA establishes obligations between parties but does not prove that the application, service, or tenant configuration is compliant.

Use encryption at rest and in transit to check algorithm and key evidence. If a field is unclear, ask the security owner for a reproducible configuration record instead of marking it protected by assumption.

Mitigation evidence

Mitigation can include stopping access, retrieving or deleting a misdirected message, obtaining a reliable recipient attestation, rotating credentials, isolating a vendor, or reducing future exposure. Evaluate whether the action actually addressed the risk and whether it is supported by evidence. An unverified promise to delete is not the same as a deletion log or vendor attestation.

Mitigation Proof Remaining question
Access revoked Identity event and session closure Was data already viewed?
Recipient returned data Attestation or transfer record Were copies retained?
Credential rotated Rotation and denial tests Was the old credential used?
Vendor isolated Connector state and notice What did vendor logs show?
Data deleted Deletion evidence and scope Do backups or caches remain?

Record mitigations against the four factors. Do not use a broad “resolved” label that hides an unresolved recipient or copy. If a mitigation is incomplete, keep the assessment open or label the limitation.

Decision, notification, and documentation

The risk assessment supports a notification decision; it does not replace the decision owner. Privacy leadership and qualified counsel should determine whether notice to individuals, the Secretary, media, customers, or other regulators is required. Business associates should follow their agreement and applicable rule for notice to the covered entity, including any shorter contractual window.

Document the conclusion, factors, evidence, assumptions, approvers, date, and follow-up. Preserve the record according to the applicable retention policy. If the decision is “no notification,” explain why with the four factors and the evidence. If the conclusion is uncertain, escalate rather than choosing the least disruptive answer.

Separate current duties from proposed Security Rule changes. A proposal can inform future preparedness but cannot be cited as an enforceable obligation until finalized and effective.

Tenant approval checklist

Before an incident occurs, approve roles and the assessment template. Identify the privacy owner, security lead, counsel, customer contact, vendor contact, and record custodian. Test the process with synthetic events involving misdirected messages, unauthorized support access, exports, and backup restores.

  • Restricted assessment location and access roles set.
  • Four factors built into the record.
  • Source and confidence captured for each fact.
  • Contract and statutory clocks kept separate.
  • Vendor evidence request process defined.
  • Notification approvers named.
  • Retention and no-notification rationale documented.
  • Post-incident action owner assigned.

Stop when the event scope, recipient, or data class cannot be established. A documented uncertainty is safer than an unsupported conclusion.

FAQ

What is the first verification step for a HIPAA breach risk assessment?

Preserve evidence and define the event, affected systems, data class, recipient, and discovery time. Then apply the four factors with sources and confidence labels.

Which source or configuration detail could change this answer?

Encryption and key evidence, recipient role, access logs, vendor attestations, contract deadlines, and the current rule can change the result. Reassess when new facts arrive.

What must be approved before a production claim or outbound action?

The privacy owner and qualified counsel should approve the notification conclusion and communications. Security, contracts, customers, and vendors should provide the evidence required for that decision.

References

Related articles