Must Every Health Data Breach Be Reported Under GDPR Within 72 Hours?

cmsapointoo on August 16, 2026

No. The GDPR does not require every breach involving health data to be reported through the same channel within 72 hours. Article 33 requires a controller to notify the competent supervisory authority without undue delay and, where feasible, within 72 hours after awareness, unless the breach is unlikely to result in a risk to people’s rights and freedoms. Article 34 uses a separate high-risk test for communication to affected people.

Health data is sensitive, so its nature can weigh heavily in the risk assessment. Sensitivity does not remove the need to examine what happened, whose data was affected, whether anyone could identify the people, what safeguards worked, and what consequences are reasonably possible. Every personal data breach still needs an internal record, including breaches that do not cross a notification threshold.

What counts as a personal data breach?

Article 4(12) defines a personal data breach as a security breach leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. The definition covers confidentiality, integrity, and availability. A breach is not limited to an attacker downloading a database.

A mistaken disclosure can be a confidentiality breach. An unauthorized change can be an integrity breach. Loss of access can be an availability breach, including a temporary loss when the circumstances can affect people’s rights and freedoms. Planned maintenance is not automatically a personal data breach merely because a system is unavailable.

Not every security incident involves personal data. An outage affecting only a public marketing page may be a security or reliability event without compromising personal data. The response process should classify the incident before applying Articles 33 and 34, while avoiding delay in investigation.

When does the 72-hour period begin?

The clock starts when the controller becomes aware of the personal data breach, not necessarily when the first alert appears or when a processor finishes a full investigation. The European Data Protection Board says a controller is aware when it has a reasonable degree of certainty that a security incident occurred and personal data was compromised.

Some alerts remain uncertain at first. The controller may need a short investigation to establish whether personal data was involved. The EDPB still stresses prompt action. An organization cannot avoid awareness by leaving alerts unreviewed or waiting for complete forensic certainty before making the threshold decision.

Record the alert time, escalation time, facts that established reasonable certainty, and person who made the awareness decision. Audit evidence matters here. The guide to Google Cloud Data Access audit logs explains why seeing administrative changes does not prove that the needed data-access events were captured.

When must the supervisory authority be notified?

Article 33 requires notification unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. If notification is required, the controller acts without undue delay and, where feasible, within 72 hours after awareness. A notification made later must include reasons for the delay.

The test is not whether harm has already occurred. It considers the likelihood and severity of possible effects. The EDPB identifies consequences such as loss of control, discrimination, identity fraud, financial loss, damage to reputation, and loss of confidentiality for information protected by professional secrecy.

Health data can increase possible severity because it is a special category and can reveal private conditions or care. The broader GDPR treatment of health data also appears in the review of automated appointment eligibility under Article 22. Neither topic supports a shortcut that labels every health-data event identical. Context still controls the notification assessment.

When must affected people be informed?

Article 34 uses a higher threshold. The controller communicates the breach to affected people without undue delay when the breach is likely to result in a high risk to their rights and freedoms. Authority notification under Article 33 and individual communication under Article 34 are therefore related but distinct decisions.

Article 34 also lists conditions where individual communication is not required. One concerns appropriate protection measures that made the affected personal data unintelligible to unauthorized people, such as effective encryption. Another applies when later measures ensure that the high risk is no longer likely to materialize. A third addresses disproportionate effort and requires an equally effective public communication or similar measure.

Do not turn encryption into a universal exemption. Verify whether the affected data was encrypted, whether the relevant key remained protected, whether readable copies or credentials were also exposed, and whether integrity or availability consequences remain. The answer belongs to the incident facts.

How do controller and processor duties differ?

The controller decides whether the Article 33 and Article 34 thresholds are met and makes the required notifications. A processor that becomes aware of a personal data breach must notify the controller without undue delay. Article 33 does not give the processor its own 72-hour waiting period before informing the controller.

The processing contract should support fast escalation, evidence preservation, contact routes, and phased updates. It cannot transfer the controller’s legal decision entirely to a cloud provider or another processor. The controller needs enough information to assess risk and meet its own deadline.

Cloud log location and access can affect that investigation. CloudTrail multi-region audit data shows why event contents, destination, keys, and lifecycle need an approved evidence zone. An incident team should not copy health content into a separate ticket merely to centralize evidence.

What information goes into an Article 33 notification?

The notification describes the nature of the breach and, where possible, the categories and approximate numbers of affected people and personal data records. It provides the data protection officer or other contact point, describes likely consequences, and describes measures taken or proposed to address and mitigate the breach.

The GDPR allows information to be provided in phases when everything cannot be supplied at once. That provision supports timely initial notification followed by facts as the investigation develops. It does not justify an empty notice when known information can already be provided.

Keep estimates labeled as estimates and preserve the method used. If later evidence changes the scope, record the revision. Avoid patient names, appointment details, diagnostic information, or raw access logs in the notification workflow unless they are necessary, authorized, and transmitted through an approved route.

What must be documented when no notification is sent?

Article 33(5) requires the controller to document any personal data breach. The record covers facts, effects, and remedial action. It must allow the supervisory authority to verify compliance with Article 33. A decision not to notify therefore needs a reasoned record, not silence.

Document the breach classification, awareness time, data categories, approximate scope, affected groups, safeguards, likely consequences, risk decision, notifications considered, measures taken, and reviewers. Record what remains unknown and when it will be checked again. Keep the report free of unnecessary health content.

Marketing and operational datasets also need separation. The article on measuring clinic show rate without appointment details demonstrates a minimization pattern: retain the state needed for the purpose without sending consultation content into the reporting path.

How can an incident team run the decision process?

  1. Contain the incident while preserving relevant technical evidence.
  2. Determine whether personal data suffered a confidentiality, integrity, or availability breach.
  3. Identify the controller, processors, systems, jurisdictions, and competent escalation contacts.
  4. Record when the controller reached reasonable certainty that personal data was compromised.
  5. Assess likelihood and severity for affected people’s rights and freedoms.
  6. Decide Article 33 authority notification and Article 34 individual communication separately.
  7. Notify with known facts, use phased updates where needed, and explain any delay.
  8. Document the breach, decisions, remediation, and later scope changes.

Operational inference: run legal assessment and technical investigation in parallel once personal-data compromise is reasonably certain. This reduces the risk that a team treats complete forensics as a prerequisite for the first notification. The exact workflow, authority, and additional deadlines still depend on establishment, cross-border processing, Member State rules, contracts, and sector duties.

Frequently asked questions

Does every breach involving health data require authority notification?

No universal answer applies. Article 33 requires notification unless the breach is unlikely to create a risk. Health data can increase severity, but the controller must assess the incident’s actual likelihood and consequences.

Does the 72-hour period begin when a processor completes its report?

No. The controller’s period is tied to controller awareness. A processor must tell the controller without undue delay after becoming aware of a breach.

Must affected people always be contacted within 72 hours?

No. Article 34 requires communication without undue delay when high risk is likely. It does not use the same 72-hour wording as Article 33.

Can a controller skip the internal record when notification is unnecessary?

No. Article 33(5) requires documentation of every personal data breach, including the facts, effects, and remedial action.

References

GDPR Article 22 and Automated Appointment Eligibility: When Scheduling Becomes a Decision

cmsapointoo on August 16, 2026

An automated scheduling feature does not fall under GDPR Article 22 merely because software is involved. The threshold asks three questions together: does the system make a decision, is that decision based solely on automated processing, and does it produce legal effects or similarly significantly affect the person? Automated appointment eligibility can cross that threshold when it denies, delays, or diverts access to care without meaningful human involvement, but the result depends on the actual workflow and effect.

Slot sorting, reminders, and administrative suggestions are not automatically Article 22 decisions. A product team needs to trace who or what determines the outcome, whether a person can genuinely change it before it takes effect, what data drives it, and how serious the consequence is for the person seeking care.

The three-part Article 22 threshold

Article 22(1) gives a person the right not to be subject to a decision based solely on automated processing, including profiling, when it produces legal effects concerning that person or similarly significantly affects that person. The Court of Justice described these as cumulative conditions in its SCHUFA judgment.

Start with a decision. Displaying open times may supply information without deciding whether a person can receive care. A rule that labels someone ineligible, blocks suitable times, creates a slower route, or assigns a pathway that determines access is closer to a decision. Labels such as “recommendation” or “triage support” do not settle what the system does.

Next ask whether processing is solely automated. A staff member who merely receives the score and confirms the same outcome may not supply meaningful involvement. Finally, assess the effect. Article 22 does not cover every inconvenience. The legal or similarly significant standard needs a fact-specific account of the person’s circumstances, the service, the delay, available alternatives, and the consequence of the outcome.

Scheduling support versus appointment eligibility

A calendar can automate steps without making an eligibility decision. It can sort slots by location, display clinician availability, send reminders, or detect a duplicate booking. Those functions may involve personal data and other GDPR duties, but Article 22 requires the three-part threshold.

Eligibility logic asks a different question. It may use age, location, symptoms, referral status, payment route, prior interactions, or a generated risk score to decide whether a person can book, which service is available, or how soon a request is considered. Some of those inputs can reveal health information. Some outcomes may have little effect; others may materially limit access.

Map the real outcome rather than the interface. A user who can click “request review” only after an automatic refusal has already experienced an automated decision. A clinician who receives a suggestion and freely assesses the underlying information before any effect may be part of a different workflow. The review must examine authority, timing, information, and actual ability to change the result.

What SCHUFA changes about upstream scores

In Case C-634/21, the Court considered a credit information agency that automatically created a probability value. A third party used that score to establish, implement, or terminate a contractual relationship. The Court held that producing the score could itself constitute automated individual decision-making where the third party drew strongly on it.

The case concerned credit scoring, not healthcare appointments. It should not be presented as a judgment that every health risk score is an Article 22 decision. Its relevant principle is functional: separating score generation from the final system does not necessarily avoid Article 22 when the score strongly determines the downstream result.

For an appointment workflow, test how often staff depart from the score, what information they see, whether they have authority and time to reassess it, and whether the person receives a different outcome before the decision takes effect. A nominal reviewer or an unexplained override button is not evidence by itself.

Exceptions do not remove the safeguards

Article 22(2) lists three circumstances in which paragraph 1 does not apply. The decision may be necessary for entering into or performing a contract, authorized by Union or Member State law that also provides suitable safeguards, or based on the person’s explicit consent. These are defined routes, not a general list of convenient legal bases.

For the contract and explicit-consent routes, Article 22(3) requires suitable measures to protect rights, freedoms, and legitimate interests. At minimum, the controller must provide the right to obtain human intervention, express a point of view, and contest the decision. A team should not assume that scheduling automation is necessary for a contract merely because it is cheaper or already deployed.

The law-authorized route depends on the applicable Union or Member State measure and the safeguards it establishes. National healthcare rules may also affect the service and professional duties. The sources mapped to this article do not answer those jurisdiction-specific questions, so a local legal assessment remains necessary.

Health data creates an additional restriction

Article 22(4) limits decisions covered by the Article 22(2) exceptions when they are based on special categories of personal data under Article 9(1). Health data is one of those categories. Such decisions may be based on special-category data only when Article 9(2)(a) or 9(2)(g) applies and suitable measures protect the person’s rights, freedoms, and legitimate interests.

Article 9(2)(a) concerns explicit consent under its stated conditions. Article 9(2)(g) concerns processing necessary for reasons of substantial public interest based on Union or Member State law that meets the regulation’s requirements. This restriction means a general Article 6 analysis or ordinary consent label does not complete the review.

Consent also needs to remain separate from unrelated permissions. The article on authorization, privacy consent, and platform permission addresses a US advertising context, but its operational lesson still helps: record each permission against its own source, purpose, and scope rather than treating one checkbox as universal approval.

Explanation, intervention, and contest must work in practice

In Case C-203/22, Dun & Bradstreet Austria, the Court interpreted the right to meaningful information about the logic involved under Article 15(1)(h). For automated decision-making within Article 22, the person may require an explanation of the procedure and principles actually applied to use personal data and reach the specific result. The explanation must be concise, transparent, intelligible, and easily accessible.

The judgment says the controller does not satisfy that duty by providing a complex formula alone. It also addresses claimed trade secrets and third-party data: the controller cannot simply refuse all information, although a competent supervisory authority or court may need to balance the interests and determine the scope of access.

For appointment eligibility, connect the explanation to the person’s result. State which categories of information mattered, how the procedure applied, what consequence followed, and how to seek intervention or contest the result. Do not disclose another person’s data or pretend that a generic model description explains a specific outcome.

A product review that preserves the legal boundary

  1. Write the outcome in ordinary language: ranking, suggestion, delay, diversion, refusal, or another result.
  2. Identify the controller, processors, data sources, model or rules, and downstream decision maker.
  3. Test whether a person exercises meaningful control before the outcome takes effect.
  4. Describe the legal or practical consequence for the affected person and available alternatives.
  5. If Article 22 applies, document the exact exception relied on and every required safeguard.
  6. Identify special-category inputs and test Article 22(4) with Article 9 separately.
  7. Prepare a result-specific explanation, intervention route, point-of-view channel, and contest process.
  8. Test the workflow with realistic scenarios, including disagreement, missing data, and an incorrect score.

This is an editorial review sequence, not a substitute for a GDPR assessment. It should sit beside the controller’s broader work on lawful processing, transparency, data quality, security, retention, rights, and any required impact assessment. A narrow Article 22 conclusion does not approve the rest of the processing.

Keep health data inside the approved processing boundary during product testing. Where teams also measure marketing outcomes, the review of health conversion tracking outside HIPAA shows why a non-HIPAA environment can still carry privacy risk. For cloud and advertising boundaries, see why a provider agreement does not follow data into another product.

Frequently asked questions

Does automatically sorting appointment slots trigger Article 22?

Not automatically. The workflow must meet all three conditions: a decision, solely automated processing, and a legal or similarly significant effect. Slot ordering may fall short, while an automatic denial or material delay may require closer review.

Does a staff approval step always prevent the decision from being solely automated?

No. Review the staff member’s authority, information, time, and actual ability to change the outcome before it affects the person. A token confirmation step may not amount to meaningful involvement.

Can explicit consent always authorize automated health eligibility?

No universal conclusion follows. Article 22(2)(c), Article 22(3), Article 22(4), and Article 9 must be applied to the facts. Other GDPR duties and applicable healthcare law also remain.

Must the controller reveal its source code?

The cited Dun & Bradstreet Austria judgment focuses on a concise and understandable explanation of the procedure and principles actually applied. It rejects reliance on a complex formula alone and provides a balancing route for protected information; it does not create a universal source-code disclosure rule.

References