What should a breach management procedure include once a healthcare organisation discovers a potential incident?

A breach management procedure should define the steps from discovery through reporting determination and internal documentation. That means assigning the process for investigating the event, deciding whether it meets reportable threshold criteria, and creating an internal incident report even when external notification is not required. The procedure should also cover breaches involving business associates, not just incidents inside the practice.

What a healthcare breach procedure must do after discovery

Once a potential incident is discovered, the procedure should move the team from uncertainty to a documented decision path. It needs to define who investigates, what facts are collected, how the event is assessed against the reporting threshold, and how the organisation records the decision. For healthcare, that process should work even when the issue involves a business associate.

A strong procedure does more than name a contact person. It should specify when the clock starts, what evidence is preserved, how legal and privacy review is triggered, and where the internal record is stored so the organisation can show its reasoning later. That makes the procedure usable under pressure, not just compliant on paper.

How the procedure should handle investigation and threshold determination

The investigation step should be structured enough to answer three practical questions: what happened, what data or systems were involved, and whether the event is actually reportable. In healthcare, that means separating a suspected security event from a confirmed breach, then documenting the rationale used to decide whether notification duties apply.

Threshold determination should be a defined decision point, not an ad hoc judgment by the first responder. The procedure should name the functional owner, the information needed for the decision, and the escalation path when facts are incomplete. If the organisation cannot reliably determine scope, it should treat the uncertainty as part of the workflow rather than delaying documentation.

Because business associates may be part of the event chain, the procedure should also describe how notifications and evidence flow between the covered entity and the associate. That reduces gaps where each party assumes the other is handling the analysis, a common failure mode in shared-service environments.

Why internal documentation matters even when no external notice is required

An internal incident report is essential even when the final determination is that no external breach notice is needed. The record should show the trigger, the investigation summary, the threshold analysis, the conclusion, and any follow-up actions. That creates an audit trail for leadership, counsel, and regulators, and it helps the organisation spot repeat patterns across smaller events.

The documentation should be complete enough that a later reviewer can understand why the event was not reportable. In practice, that means capturing the facts that drove the decision, not just the decision itself. If the procedure only records confirmed breaches, the organisation loses visibility into close calls, weak controls, and recurring process failures.

What the procedure should say about business associates

Healthcare breach handling often breaks down at the boundary between the covered entity and a business associate. The procedure should explain how to receive, triage, and assess associate-reported events, and how the organisation will decide whether the event affects its own reporting obligations. It should also define whether the associate must provide a minimum fact set before the breach clock can be evaluated.

That boundary matters because the covered entity still needs a defensible internal record even when the event originated outside its own environment. If associate incidents are handled informally, teams may miss notification deadlines, duplicate work, or fail to preserve evidence that is only visible early in the response. Good procedure design makes the associate path explicit, not exceptional.

Risk and Threat Considerations

A weak breach management procedure creates exposure in two directions: first, the organisation may under-report a true breach, and second, it may over-report or misclassify an event because the decision process is unclear. Both outcomes create operational and regulatory risk, especially when multiple parties are involved and facts are changing quickly.

Failure mechanism: The procedure fails when investigation, legal review, and threshold determination are not sequenced clearly, or when business associate incidents fall outside the documented workflow. In that case, evidence can be lost, deadlines can be missed, and the organisation may be unable to justify why it reached a particular reporting decision.

Impact: The result can be inconsistent breach decisions, incomplete records, delayed notification, and unnecessary exposure during audits or enforcement review. Where a shared-service partner is involved, the gap can also delay containment and weaken the organisation’s understanding of scope.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IR-4 — Incident Handling	Defines response handling and incident analysis for discovered events.
	AU-6 — Audit Record Review, Analysis, and Reporting	Supports internal documentation and review of incident decisions.
	IR-6 — Incident Reporting	Matches the need to determine when an event crosses reporting thresholds.
Recommendation — Document triage, investigation, containment, and decision steps for suspected incidents. Retain and review incident records that justify reportability decisions. Define when and how reportable incidents must be escalated and reported.
ISO/IEC 27001:2022	A.5.24 — Information security incident management planning and preparation	Applies to planning the incident workflow and roles before a breach occurs.
	A.5.26 — Response to information security incidents	Applies to investigation, response, and decision handling after discovery.
	A.5.28 — Collection of evidence	Supports preserving facts needed to justify the breach determination.
Recommendation — Prepare incident procedures that assign roles, evidence handling, and escalation. Use a defined response workflow to investigate and resolve suspected breaches. Preserve evidence and maintain a defensible incident record from discovery onward.

Practitioner Guidance

What to verify: Confirm that the procedure names the investigation owner, the escalation path, the threshold decision point, and the minimum facts required for a reportability decision. Also verify that business associate events use the same workflow, not a separate informal channel.

What good looks like: A responder can open the procedure and see exactly how to move from initial discovery to documented conclusion, including when to preserve evidence, when to involve privacy or legal review, and where the internal report is filed.

Common mistake: Treating the procedure as a notification checklist instead of a decision record. The better approach is to make the documentation part of the control, because the internal explanation is what proves the organisation handled the event responsibly.

Practitioner takeaway: The procedure should make reportability a repeatable decision, not a case-by-case improvisation, and it should do so for both internal incidents and business associate events.