What Constitutes a Privacy Violation Across Jurisdictions?

A practical guide to privacy incidents, data breaches, and notification thresholds

A privacy violation occurs when personal information is collected, used, accessed, disclosed, retained, altered, or destroyed in a way that conflicts with an applicable law, regulation, contract, or privacy commitment. A privacy violation can involve a security incident, but it can also result from unlawful processing, excessive retention, inappropriate access, or failure to honor an individual’s privacy rights.

There is no universal legal test. The same event may be a reportable data breach in one jurisdiction, a recordable but non-notifiable incident in another, and outside the scope of a third. The outcome depends on which rules apply, what information was involved, where affected individuals reside, what safeguards were in place, who received or accessed the data, and what harm could reasonably result.

For organizations operating across borders, the practical question is not only whether personal data was exposed. It is which rules apply, what each rule requires, and how the organization can document a timely, defensible decision.

What is a privacy violation?

A privacy violation is any handling of personal information that fails to meet an applicable privacy obligation. The obligation may come from a statute, regulation, contract, internal policy, or public privacy notice. A violation can occur even when no outside attacker is involved, and no data is publicly exposed.

Common examples include:

• Collecting personal information without a valid legal basis or required notice
• Using information for an undisclosed or incompatible purpose
• Giving an employee or third party inappropriate access
• Accidentally disclosing information to the wrong recipient
• Keeping personal information longer than permitted
• Failing to apply required security safeguards
• Failing to honor access, deletion, correction, or objection rights
• Failing to notify a regulator or affected individual when the law requires notice

Whether one of these events is also a data breach, and whether it must be reported, requires a separate analysis under each applicable law.

Privacy violation vs. privacy incident vs. data breach

Privacy violation. The broadest concept. It includes conduct that conflicts with a privacy obligation, whether or not a security failure occurred.

Privacy incident. An event that may compromise personal information or violate a privacy requirement. Examples include a misdirected email, a lost device, a misconfigured database, improper access to records, or a temporary loss of data availability.

Data breach. A category of privacy or security incident defined by the applicable law. Depending on the jurisdiction, the definition may cover confidentiality, integrity, availability, acquisition, access, use, disclosure, loss, or destruction.

Notifiable breach. A breach that meets a legal threshold for regulator notice, individual notice, or both. A breach may still require investigation and documentation even when notification is not required.

These distinctions help teams avoid two costly errors: treating every event as reportable without applying the legal threshold, and classifying an incident too narrowly and missing a notification obligation.

How do breach-notification thresholds differ by jurisdiction?

Breach laws differ in the organizations and information they cover, the events that trigger analysis, the risk or harm threshold for notice, the people or authorities that must be notified, and the deadline. The following comparison is an issue-spotting guide, not a substitute for applying the complete law to a specific incident.

European Union and European Economic Area

Under the GDPR, a personal data breach is a security breach that leads to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. The definition reaches beyond confidentiality: an incident can affect the integrity or availability of data.

Examples include sending customer information to the wrong person, losing an unencrypted device, allowing unauthorized access to an employee database, corrupting records, deleting data without a usable backup, or making personal data unavailable due to ransomware.

A controller generally must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware of the breach, unless the breach is unlikely to create a risk to individuals’ rights and freedoms. The controller must also inform affected individuals without undue delay when the breach is likely to create a high risk.

Source: GDPR text and European Data Protection Board breach-notification examples

United Kingdom

The UK GDPR uses a similar risk-based model. An organization must report a notifiable personal data breach to the Information Commissioner’s Office without undue delay and, where feasible, within 72 hours of awareness. If the breach is likely to create a high risk to individuals’ rights and freedoms, the organization must also inform those individuals without undue delay.

If notification is not required, the organization should still document the breach, its risk assessment, and the reason for the decision. The ICO notes that its guidance is being reviewed in light of the Data Use and Access Act 2025, which makes a current-source check especially important before relying on a summary.

Source: Information Commissioner’s Office personal data breach guidance

United States

The United States does not have a single breach-notification standard that covers all organizations and data types. A single incident may trigger state breach laws, federal sector-specific rules, contractual duties, or several of these at once.

State Data Breach Notification Laws

State rules differ in their definitions of personal information, treatment of encrypted data, risk-of-harm exceptions, deadlines, regulator notice requirements, and permitted methods of notice. The residence of each affected individual can matter more than the location of the organization or compromised system.

California, for example, generally requires notice when specified unencrypted personal information about a California resident was acquired, or is reasonably believed to have been acquired, by an unauthorized person. When one breach requires notice to more than 500 California residents, the organization must also submit a sample notice to the state attorney general.

Source: California Department of Justice data breach reporting guidance

HIPAA

For covered entities and business associates subject to HIPAA, an impermissible use or disclosure of protected health information is generally presumed to be a breach unless the regulated organization demonstrates a low probability that the information was compromised or an exception applies.

The required risk assessment considers at least the nature and extent of the protected health information, the unauthorized person who used or received it, whether it was actually acquired or viewed, and the extent to which risk was mitigated. The organization must document either that required notifications were made or why notification was not required.

Source: U.S. Department of Health and Human Services HIPAA Breach Notification Rule

Canada

Under the federal Personal Information Protection and Electronic Documents Act, or PIPEDA, a breach of security safeguards includes loss, unauthorized access, or unauthorized disclosure of personal information resulting from a breach of an organization’s security safeguards or a failure to establish those safeguards.

Organizations subject to PIPEDA must report a breach to the Office of the Privacy Commissioner of Canada and notify affected individuals when it is reasonable to believe the breach creates a real risk of significant harm. The assessment considers the sensitivity of the information and the probability that it has been, is being, or will be misused. Organizations must keep a record of every breach, including those that do not meet the reporting threshold.

PIPEDA is not a complete summary of Canadian privacy law. Provincial and sector-specific requirements may also apply.

Source: Office of the Privacy Commissioner of Canada breach-reporting guidance

Australia

Australia’s Notifiable Data Breaches scheme applies to organizations and agencies covered by the Privacy Act. An eligible data breach generally occurs when personal information is subject to unauthorized access or disclosure, or is lost in circumstances likely to lead to unauthorized access or disclosure, and a reasonable person would conclude that serious harm to one or more individuals is likely.

Remedial action can change the outcome. If the organization acts before serious harm becomes likely, the incident may not qualify as a data breach. For example, effective remote deletion of information from a lost device may prevent notification if the facts show the data can no longer be accessed.

Source: Office of the Australian Information Commissioner NDB scheme guidance

Brazil

Brazil’s data protection authority defines a personal data security incident as a confirmed adverse event that compromises the confidentiality, integrity, availability, or authenticity of personal data. The definition can include accidental disclosure, unauthorized access, alteration, loss, ransomware, or prolonged unavailability.

A controller must notify the ANPD and affected individuals when an incident may pose a relevant risk or cause damage. The assessment considers the processing context; the categories and number of people affected; the nature and volume of data; potential material, moral, or reputational harm; whether sensitive data or data about vulnerable people is involved; whether safeguards prevent identification; and the effectiveness of mitigation.

Under the current incident-reporting regulation, the controller generally must communicate a qualifying incident within three business days, subject to any more specific legal deadline.

Source: Brazilian National Data Protection Authority security-incident guidance

Singapore

Singapore’s Personal Data Protection Act distinguishes between a data breach and a notifiable data breach. A breach can include unauthorized access, collection, use, disclosure, copying, modification, or disposal of personal data. It can also include the loss of a storage medium when unauthorized activity involving the data is likely.

An organization must notify the Personal Data Protection Commission when a breach is likely to cause significant harm to affected individuals or is of significant scale. Current PDPC guidance treats a breach involving 500 or more individuals as significant in scale, even if the information does not fall within a prescribed category associated with significant harm.

Source: Singapore PDPC guide to managing and notifying data breaches

Why can the same incident produce different notification decisions?

Suppose an employee emails a spreadsheet containing names, addresses, and health information to the wrong external recipient. The recipient says the attachment was not opened and confirms that it was deleted.

That event may require several parallel assessments:

• Under the GDPR or UK GDPR, it may be a personal data breach, with notification determined by the resulting risk to individuals.
• Under HIPAA, an impermissible disclosure of protected health information is generally presumed to be a breach unless a documented assessment shows a low probability of compromise or an exception applies.
• Under a U.S. state law, the result may depend on whether the exposed fields match that state’s definition of personal information and whether an exception applies.
• Under Canada’s federal PIPEDA framework, the organization must assess whether the breach creates a real risk of significant harm.
• Under Australia’s NDB scheme, effective remedial action may prevent the incident from becoming an eligible data breach.

The recipient’s confirmation matters, but it does not decide the outcome by itself. The organization must connect the facts about access, data sensitivity, affected individuals, safeguards, mitigation, and potential harm to every applicable legal test.

How do organizations make a defensible decision about a breach?

A defensible decision comes from a repeatable, documented process that connects verified incident facts to each applicable legal test. Regulators often scrutinize whether an organization applies the same consistent assessment process to every incident, rather than an ad hoc approach that varies depending on who reviews it. That discipline is essential whether the final decision is to notify or not.

1. Establish the facts. Record what happened, when the organization became aware, which systems and records were affected, where affected individuals reside, who could access the information, and whether it was acquired, viewed, altered, lost, or misused.
2. Identify the applicable rules. Map affected individuals, entities, data types, sectors, and contractual commitments to the relevant laws, regulators, notice recipients, deadlines, formats, and content requirements.
3. Assess risk and mitigation. Evaluate data sensitivity, likely consequences for individuals, probability of misuse, existing safeguards, recipient trustworthiness, containment, and remedial action.
4. Document and govern the decision. Preserve the evidence, legal tests, assumptions, rationale, approvals, notices, deadlines, and follow-up actions. A decision not to notify can require as much support as a decision to notify.

Turn jurisdictional complexity into a consistent decision process

Cross-border incident assessment becomes difficult when teams must research changing laws, reconcile incomplete facts, calculate deadlines, and rebuild the decision record for every event. Inconsistent tools and handoffs make it harder to show what the organization knew, which rules it applied, and why it acted.

Radar Privacy brings structured incident intake, automated risk scoring tied to legal definitions, notification guidance, and audit-ready reporting into a consistent workflow. It helps privacy, legal, security, and compliance teams use the same incident facts to evaluate jurisdiction-specific requirements, record their rationale, coordinate next steps, and preserve a traceable decision history.

Radar Privacy supports rather than replaces human judgment. RadarFirst’s current platform model combines structured regulatory decisioning with human review so teams remain accountable for the outcome.

See how the RadarFirst platform connects intake, assessment, regulatory interpretation, and documentation.

The definition changes, but the operational requirement remains

What constitutes a privacy violation depends on the governing law, the regulated data, and the facts of the event. Notification rules add another layer: some focus on unauthorized acquisition, while others consider access, disclosure, loss, alteration, destruction, or unavailability and apply different risk thresholds.

Across those differences, the operational requirement is consistent. Teams need to investigate quickly, apply the correct rules, make a reasoned decision, meet applicable deadlines, and preserve the evidence supporting the outcome.

A consistent process creates continuity from intake through notification and provides proof of diligence when regulators, customers, business partners, or executives ask how the organization reached its decision.

See how Radar Privacy helps your team assess multi-jurisdiction incidents and preserve the rationale behind every decision. Request a demo.

This article provides general information and does not constitute legal advice. Privacy and breach-notification requirements change, and organizations should consult qualified counsel regarding specific incidents.