How do you run a HIPAA breach risk assessment?
When an impermissible use or disclosure of ePHI surfaces, the default under 45 CFR 164.402 is that it is a breach unless a documented risk assessment shows a low probability that the PHI has been compromised. That assessment must weigh at least four factors: the nature and extent of the PHI, including identifiers and the likelihood of re-identification; the unauthorized person who used or received it; whether the information was actually acquired or viewed; and the extent to which the risk has been mitigated. The organization owns this determination and the record that supports it. A covered entity or business associate cannot hand the call to a vendor, and no outside party issues a certificate that settles it.
An implementation partner can help prepare the inputs: pulling access and audit logs for the affected system, confirming which data fields were in the file or message, documenting whether encryption or destruction applied, and laying out the timeline of discovery and containment. Those are evidence tasks, and they should be scoped in writing before work starts. The partner does not decide whether the event is a breach. Ask any provider to state that boundary in the statement of work.
The answer depends on three things the team must establish, not assume: the data involved (which identifiers appeared, how sensitive the clinical content was), the recipient (whether they are a workforce member, another covered entity, or an unknown party who could retain the information), and the controls already in place (whether the data was unusable, unreadable or indecipherable to the recipient). Record each finding with its source. If the team cannot show that the probability of compromise is low, the presumption stands and notification duties follow. Confirm the current text of the regulation with counsel before finalizing the file.
What the four factors ask you to examine
45 CFR 164.402 requires the risk assessment to weigh four factors together, not one at a time. Each card below names the question the assessor answers and the evidence that supports the answer, so the documented conclusion can stand up if OCR later asks for it.
Nature and extent of the PHI
The assessor asks what the data was: which direct identifiers appeared (names, Social Security numbers, dates of birth), which clinical details were included, and how easily an individual could be identified from what remains. Check whether the record set is a full chart or a single field, and whether the data could be linked to other public information. Record the data elements in a data inventory and the re-identification reasoning in the assessment file, because the sensitivity of the data often drives the outcome more than the volume.
The unauthorized recipient
The assessor asks who used or received the PHI and whether that person is bound to protect it. A recipient who is another covered entity or a workforce member under HIPAA obligations presents a lower risk than an unknown party, a competitor or a criminal group. Obtain written attestations of destruction or non-retention where possible, and document the recipient's identity and relationship to the entity. Record what the recipient's obligations are, not only who they claim to be.
Whether the PHI was acquired or viewed
The assessor asks whether the PHI was actually acquired or viewed, not merely exposed to the possibility. Access logs, file transfer records, email delivery receipts and forensic images show whether a file was opened, copied or exfiltrated. If logs cover only part of the window, state the gap and what the entity did to close it. A record that shows no evidence of access is a stronger position than an assumption of access, but it must rest on logs that were actually retained.
Extent of mitigation
The assessor asks how far the entity has reduced the risk after the event. Typical steps include retrieving or destroying the PHI, obtaining recipient assurances, revoking credentials, and rotating keys or passwords. Check the timing of each step against the discovery date, and record who approved each action and when it was completed. Mitigation reduces risk, but it does not erase a breach that already occurred, so the record should show what was done after the PHI was compromised.
When encryption or destruction removes the notification duty
The Breach Notification Rule applies only to unsecured protected health information. HHS guidance names encryption and destruction as the methods that render PHI unusable, unreadable or indecipherable to unauthorized persons. If PHI was secured by one of these methods before an impermissible use or disclosure, the entity is relieved of notification even if the data was taken. The safe harbor does not replace the risk assessment for unsecured PHI. It removes the question entirely when the data was secured. The entity still has to be able to show that the safe harbor applies, so the analysis should start by identifying which copies of the PHI were secured and by what method.
- Scope of the safe harbor: It applies to the specific PHI that was secured, so a copy stored unencrypted elsewhere remains unsecured.
- Method must be recognized: Only encryption and destruction consistent with HHS guidance qualify, not general obfuscation or access restrictions.
- Timing: The PHI must have been secured at the time of the impermissible use or disclosure.
- Partial incidents: A record set can be partly secured, so each data store needs its own determination.
- Business associates: A vendor's secured status must be confirmed in the contract and in practice, not assumed.
Before relying on the safe harbor, confirm with counsel which data stores and copies were in scope at the time of the event.
Encryption secures PHI when it is rendered unreadable to anyone without the decryption key, and HHS guidance treats properly implemented encryption as a method that makes data indecipherable. The safe harbor depends on how the encryption was implemented, not just whether a setting was turned on. An organization must be able to show which data was encrypted, which algorithm and key management process were used, and whether the key itself was exposed during the incident. If the key was on the same compromised system or stolen with the data, the PHI is generally not treated as secured.
- Data at rest: Confirm that databases, file shares, backups and endpoints holding ePHI are encrypted, and record the encryption method for each.
- Data in transit: Show that transmission channels carrying ePHI were protected at the time of the event.
- Key custody: Document where keys are stored, who can access them, and whether they are separated from the data.
- Key compromise: Establish whether credentials, key material or key management systems were accessed during the incident.
- Configuration evidence: Keep exported configuration baselines and key inventory records captured before the event.
Check whether the encryption configuration was verified before the incident and whether a partner can review the configuration as evidence.
Destruction also secures PHI when it is destroyed or sanitized so that it cannot be read or reconstructed. This matters most for paper records, retired media and discarded devices. A discarded hard drive that was not sanitized does not qualify, and HHS treats the method used as the controlling question. The organization should be able to show the destruction method, the date it was performed, and the chain of custody for the media before it left the organization's control. Destruction of backup copies must be considered too, because a copy kept for recovery may still contain readable PHI.
- Media sanitization: Record the method used for each device or medium, and confirm it leaves the data unrecoverable.
- Paper destruction: Retain vendor certificates of destruction that identify the records and the date.
- Chain of custody: Document each handoff of media to a disposal or recycling vendor.
- Backup copies: Confirm whether retired or offsite backups were destroyed or remained readable.
- Vendor records: Obtain written confirmation from any disposal vendor and check how it describes its method.
Ask whether the destruction records would stand up to review if the media later surfaced outside the organization.
The covered entity or business associate bears the burden of showing that a use or disclosure was not a breach or that notice was not required. For a safe harbor, that means keeping evidence that the PHI was secured by an HHS-recognized method and that the means of unlocking it were not compromised. An unsupported claim that data was encrypted will not carry the burden. Assessors and regulators will ask for the configuration state at the time of the event, the key handling records, and the disposal records. Organizations should treat this evidence as part of the breach file from the start.
- Point-in-time proof: Show the state of encryption or destruction on the date of the incident, not only today.
- Key separation evidence: Show that decryption keys were held apart from the protected data.
- Exception and safe harbor memo: Record the analysis, the facts relied on, and the conclusion in writing.
- Retention: Keep the evidence with the breach documentation so it can be produced later.
- Independent review: A qualified third party can check configurations and records, but it cannot certify the outcome.
Identify which evidence is missing today and confirm with your own counsel what standard of proof applies to your facts.
Organizations often discover after an incident that encryption was enabled on some systems but not others, or that keys were stored beside the data. An outside implementation or assessment partner can help verify configurations before an incident, so the evidence exists when it is needed. Such a partner can review encryption and key management settings, check sanitization procedures, and document what it observed. It prepares systems and evidence for review. It does not decide whether a breach occurred, and it does not issue an attestation of the safe harbor. The covered entity keeps that decision and the reporting obligations.
- Configuration review: Compare encryption settings across storage, backups and endpoints against the organization's inventory.
- Key architecture review: Examine where keys live and who can reach them.
- Disposal process review: Check sanitization steps and vendor documentation.
- Evidence capture: Set up recurring exports of configuration state that can be retained with the breach file.
- Scope of role: Clarify in writing that the partner verifies facts and the organization makes the legal determination.
Ask any partner to state in writing what it will verify, what it will not decide, and how its records will be delivered to your counsel.
How to run the assessment step by step
The sequence turns a suspected impermissible use or disclosure into a documented decision, so the entity can show whether notification was required and why. Each step produces a record that feeds the next, and the final file is the evidence the entity must be able to produce later.
Confirm the impermissible use or disclosure
The privacy or security officer, with input from the workforce member or system owner who raised the concern, establishes what happened: who accessed or received the information, what they did with it, and whether the use or disclosure was permitted under the Privacy Rule. Record the date the event was discovered, because that date anchors later timing. If the event is clearly within a statutory exception, such as good-faith unintentional access by a workforce member within the scope of authority, record that finding now and stop the breach analysis for that event. The output is a written event summary with a discovery date and a preliminary determination that the use or disclosure was impermissible.
Inventory the PHI involved
Identify every record, file, field and system affected, and list the identifiers present, such as names, dates, account numbers or clinical details. Note whether the data could be linked back to a person and how easily, since the first factor asks about the likelihood of re-identification. Check the encryption or destruction status of the affected media, because PHI that was secured by an HHS-recognized method falls outside breach notification. The output is a data inventory that states the sensitivity of each data set and whether it was unsecured at the time of the event.
Identify the recipient
Determine who used or received the PHI and their relationship to the entity. Ask whether the recipient is a workforce member, another covered entity, a business associate, a member of an organized health care arrangement, or an outside party with no obligation to protect the data. Consider whether the recipient is obligated under HIPAA or other law to protect the information, and whether the entity has a good-faith basis to believe the recipient could not reasonably have retained it. The output is a recipient profile that supports or weakens the reduced-risk conclusion in the second factor.
Establish whether the PHI was acquired or viewed
Use audit logs, access records, email and system telemetry, and where needed forensic analysis to determine whether the PHI was actually acquired or viewed, not merely exposed. Preserve logs before they roll over, and document the source, time range and method of each conclusion. Where logs are incomplete, record the gap and the reasons it could not be closed, because the entity carries the burden of proof. The output is a finding, supported by named evidence, that states whether the PHI was acquired, viewed, or neither, along with the confidence level and open questions.
Document mitigation actions
Record every step taken to reduce the risk, including retrieval of the information, written assurances from the recipient that it was not further used or disclosed, and attestations of destruction. Note the date of each action and whether the recipient's assurance came from a named person with authority to give it. Mitigation is weighed under the fourth factor, and its value depends on how quickly it was done and how verifiable it is. The output is a dated mitigation log with copies of signed attestations or retrieval confirmations.
Weigh the four factors together
Assess the nature and extent of the PHI, the unauthorized recipient, whether the PHI was acquired or viewed, and the extent of mitigation as a combined judgment rather than as separate checkboxes. A factor that points toward risk can be outweighed by others, but the assessor must explain why. Test the conclusion against the question the rule asks: is there a low probability that the PHI has been compromised? The output is a written analysis that addresses each factor in turn and states how the factors were balanced.
Decide and record the conclusion
The privacy officer or designated decision maker records whether the event is a breach, is not a breach because a low probability of compromise was demonstrated, or falls under an exception. Sign and date the record, and attach the event summary, data inventory, recipient profile, evidence, mitigation log and analysis. Confirm that the file is complete enough for an outside reviewer to follow the reasoning without interviewing the team. The output is a signed determination file that can be retained as the entity's proof of its decision.
Route the result to notification
If the conclusion is that a breach occurred, or if the entity decides to notify without completing a risk assessment, hand the file to the team responsible for individual, media and HHS notices and to the business associate contract owner where relevant. If the conclusion is that notice is not required, store the determination file with the incident records and confirm it is retrievable for the required retention period. The output is a documented hand-off to notification or a closed file, with the reason for either path stated in writing.
What documentation carries the burden of proof
Covered entities and business associates carry the burden of showing that required notifications were made or that a use or disclosure was not a breach. The practical test is simple: if an assessor, OCR investigator or plaintiff asked why no notice went out, could your file answer with facts? Keep a written risk assessment for every impermissible use or disclosure you did not report, and make it specific enough that a reader unfamiliar with the incident can follow each conclusion.
The file should record the factual basis for each of the four factors: the nature and extent of the PHI, including identifiers and the likelihood of re-identification; the unauthorized person who used or received it; whether the information was actually acquired or viewed; and the mitigation obtained. For each exception you relied on, record the facts that met it, such as the workforce member's role and good-faith scope of access, or the basis for believing the recipient could not reasonably have retained the information. If you relied on encryption or destruction, retain the evidence itself: the encryption method and key status at the time, or the destruction records. Confirm with your security team which logs and system reports can prove those states as of the event date, not as they look today. Record mitigation actions with dates and owners, including attestations or certifications of destruction obtained from recipients.
Name the person who made the decision, the date it was made, and who approved it. Under 45 CFR 164.316, documentation of Security Rule policies, procedures and actions must be retained for six years from the date of creation or last effective date, and must be available to the people who maintain it. Applying that retention practice to breach files keeps the record usable for the period in which OCR or a state regulator may review it. Store the file where it can be retrieved with the incident record, and review your retention schedule with counsel, since state laws can impose longer periods.
Should you run the breach risk assessment in-house or with outside help?
This table compares three ways to support a four-factor breach risk assessment: an in-house team, outside counsel or a HIPAA consultant reviewing the determination, and an incident response retainer supplying forensic facts. Read each row against your own volume, system count and how disputed the recipient or exposure is. The main takeaway is that outside parties can inform the analysis, but the covered entity or business associate still makes and documents the determination.
| Option | When it fits | What the organization still owns |
|---|---|---|
| In-house privacy and security team | Small volume, few systems, and facts that are clear, such as a misdirected fax to one known recipient who confirmed destruction | The determination itself, the documented four-factor analysis, the burden of proof, and any notification decision |
| Outside counsel or HIPAA consultant reviewing the determination | Multi-system events, unclear whether PHI was viewed, or a decision that could be challenged by OCR or affected individuals | Final sign-off, the facts supplied to the reviewer, and the record showing why the determination was made |
| Incident response retainer for forensic facts | Ransomware, suspected data exfiltration, or logs that do not show whether PHI was acquired or viewed | Preserving logs and systems, deciding what to ask forensic examiners to establish, and interpreting findings against the four factors |
| Hybrid model with documented templates | Mid-sized organizations with recurring low-risk events that still need consistent records | Maintaining templates, training staff on the exceptions, and tracking every assessment to retention |
| Any outside party | Whenever a third party helps with the analysis | No outside party issues a breach determination certificate; the organization's own documented record is what it must produce |
Where breach risk assessments usually go wrong
Most weak breach determinations fail in a small set of predictable places: timing, unverified assurances, unclear exposure and undocumented reasoning. Each card below names one failure, why it matters under the four-factor test, and the check that closes the gap.
Starting the assessment late
The presumption of breach applies from the point of an impermissible use or disclosure, so a delayed assessment leaves the organization without a documented answer when the clock is running. Record the date the incident was discovered, the date the assessment began and who opened it. The fix is a written intake step that starts the assessment on day one, even if facts are still incomplete. Notification without a finished assessment is also permitted, so waiting for certainty is rarely the right move.
Trusting an unverified recipient assurance
A recipient who says the data was deleted or will not be misused is one input to the unauthorized person factor, not a conclusion. Ask what was received, how it was stored, who could access it and whether the recipient can attest in writing with a defined scope. Where the recipient is untrusted or unidentified, the assurance carries little weight. Document why you accepted or rejected each assurance.
Ignoring whether data was viewed
The third factor asks whether PHI was actually acquired or viewed, and a file that was sent but never opened presents a different risk from one that was read. Pull access logs, mail or portal open records, and forensic evidence where available, rather than assuming the worst or the best. If the logs are incomplete, say so in the analysis and explain how that gap affects the probability of compromise. Silence on this factor is a common reason assessments fail review.
Treating encryption as an automatic safe harbor
Encryption removes notification duties only when the PHI is unsecured under HHS guidance and the decryption key stayed protected. An encrypted laptop whose key was stored on the same device, or a file exposed alongside its password, does not qualify. Confirm the algorithm, key location, whether the key was compromised and whether the data was in a state the attacker could read. Record the evidence for each point, not only the conclusion.
Failing to keep the written analysis
Covered entities and business associates carry the burden of proof, so an assessment that exists only in someone's memory will not support a decision that notice was unnecessary. Keep the four-factor analysis, the exception relied on, the evidence reviewed and the approver's name together with the incident file. Retain it under the same documentation discipline used for other Security Rule records, and make sure the reasoning is clear to a reader who was not involved.
Questions buyers ask about breach risk assessments
Do we need a written risk assessment before notifying individuals of a breach?
No. HHS states that covered entities and business associates may provide breach notifications without first performing a risk assessment of the probability of compromise. The assessment matters when you want to show that notice was not required, because an impermissible use or disclosure is presumed to be a breach unless the assessment shows a low probability that the PHI has been compromised. If you notify without an assessment, you accept that presumption and skip the analysis, but you still need records showing what was disclosed, to whom, and when. The HHS breach notification guidance sets out the framework your counsel will apply.
Must all four risk assessment factors be scored, or can we skip some?
The assessment must consider at least four factors, so none can be silently omitted. They are the nature and extent of the PHI, including identifiers and the likelihood of re-identification; the unauthorized person who used or received it; whether the PHI was actually acquired or viewed; and the extent to which the risk has been mitigated. Each factor should appear in the written record with the facts you found for it, even if one points toward low risk. A factor that cannot be determined should be recorded as unknown, with the reason and the steps you took to find out. Auditors and OCR reviewers look for this reasoning, not a checkbox.
How long does a HIPAA breach risk assessment take to complete?
No fixed duration applies, because the length depends on facts from the event rather than on the rule. The main drivers are the number of systems, backups and copies involved, whether access logs show the data was viewed, exported or only opened, how many records and which identifiers are involved, whether the recipient is known and can be asked to return or destroy the data, and how much forensic work is needed before the facts are clear. A misdirected email to one known recipient is a different job from an intrusion with unclear access paths. Ask any provider to base its estimate on a written scope and the evidence it expects to review, and to state which findings would require more work.
Can an implementation partner run the breach risk assessment for us?
A partner can gather, organize and test the evidence, but the covered entity or business associate owns the determination and carries the burden of proof. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and it runs security testing and prepares systems and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. For a breach review, useful partner work includes confirming log retention, building a system inventory of where the PHI sat, checking access records, and documenting mitigation steps. The legal conclusion about whether notice is required should be made by the organization, usually with counsel.
Does encrypting PHI always mean we avoid breach notification?
Encryption avoids notification only when the PHI was secured by a method HHS recognizes and the protection held during the event. Breach notification applies to unsecured PHI, and HHS names encryption and destruction as methods that make PHI unusable, unreadable or indecipherable. Entities that secure PHI this way are relieved of notification if it is later breached. Before relying on this, confirm three things: the encryption meets the HHS guidance for the data at rest or in transit, the decryption keys were not exposed in the same incident, and the data was actually protected at the time of the event rather than only on paper in a policy. Document the evidence for each point.
How long should we keep breach risk assessment documentation?
The supplied rules do not set a breach-specific retention period, so confirm the period with counsel. The Security Rule's documentation standard requires written records to be retained for six years, and many organizations apply the same period to breach records because they must be able to prove later what they decided. Whatever period you choose, keep the discovery date, the facts gathered, the analysis for each of the four factors, the exceptions considered, the decision and who made it, any notices sent and their dates, and the evidence of mitigation. Covered entities and business associates bear the burden of showing that required notices were made or that a use or disclosure was not a breach, so the record must stand on its own years later.
When does a good-faith workforce access fall outside the breach definition?
It falls outside the definition when the access was unintentional, made in good faith by a workforce member acting within the scope of their authority, and the PHI was not further used or disclosed. The definition also excludes inadvertent disclosures between people authorized to access PHI at the same entity or organized health care arrangement, and disclosures where the entity in good faith believes the recipient could not reasonably have retained the information. Each exclusion depends on specific facts, so record who accessed the data, why, what they could see, what they did with it, and what steps were taken with them. A general statement that the access was accidental will not satisfy a reviewer.
What a risk assessment cannot settle on its own
A breach risk assessment is only as good as the facts known when it was written, and those facts often change. Forensic work after an incident can show that data was viewed or exfiltrated when the first review assumed it was not, or that an attacker never reached the file store at all. The assessment should carry a date, a list of the facts it relied on, and a clear trigger for revision. Each new forensic finding should be added as a dated update that explains whether the four-factor conclusion still holds. A file that shows only the original analysis will look stale to any reviewer who reads the investigation timeline alongside it.
The rule text controls the analysis, not the summaries that circulate in vendor material or internal wikis. Before relying on an interpretation of the presumption of breach, the three exceptions or a safe harbor, the compliance lead should read the language in 45 CFR 164.402 and the HHS OCR Breach Notification Rule guidance and record which version was used. The pending HIPAA Security Rule revision does not change the breach definition discussed here, so a proposed change to safeguards should not be treated as a change to how a breach is decided. Any interpretation that turns on unusual facts, such as data that was encrypted by an attacker or a recipient who may have retained records, should be confirmed with counsel before notices are sent or withheld.
No independent party can certify that an incident was or was not a breach. An auditor, assessor or consultant who reviews the record can test whether the documentation is complete, consistent and follows the four factors, but the covered entity or business associate keeps the decision and the burden of proof under 45 CFR 164.414. Ask any outside reviewer to state in writing what they examined and what they did not, and do not present that review as a HIPAA determination or certificate. Keep the final assessment, the review notes and the notices together so the file can show why notice was or was not required.
How DeployOpen prepares the evidence behind a breach assessment
DeployOpen helps organizations set up the systems, logs and records that a HIPAA breach risk assessment depends on, so the four factors can be documented from real data. The organization makes the breach determination and owns the decision; DeployOpen prepares the platforms and evidence that support it, and only the organization's own counsel and compliance leads can decide whether notification is required.
How we scope
- Written scope lists which systems holding ePHI, logs and workflows the breach assessment will draw on.
- Scope names the four factors and the evidence each one needs from your environment.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Self-hosted open-source platforms are configured to record access and disclosure events tied to specific ePHI records.
- Encryption and key management status is documented so the unsecured PHI question can be answered with evidence.
- Test scenarios are run against the configured logging to confirm that the records needed for a risk assessment exist.
How we hand over
- Handover includes a documented assessment workflow with templates for the four-factor analysis and exception review.
- Records show how each assessment was reached, retained so the organization can carry its burden of proof.
- Runbooks identify which records to retrieve first and who in the organization approves the final determination.
How we support
- Ongoing support and upgrades are available as a retainer, including updates to logging and assessment templates.
- Retainers can cover periodic review of assessment records so gaps are found before an incident occurs.
- Questions about whether a specific event is a breach are referred back to the organization's privacy counsel and compliance lead.
