What to Do If You Discover PII on the Web

First: Do Not Panic

You found personal data exposed on the internet. Maybe it is customer records on a publicly accessible page. Maybe someone posted a spreadsheet with employee details to a public file share. Maybe a vendor's system leaked data that includes your customers' information. Maybe you googled your company name and found a database dump on a paste site.

Whatever happened, the discovery is stressful. But panicking leads to bad decisions — hasty public statements, overlooked steps, and incomplete responses. What you need right now is a clear sequence of actions.

This guide is that sequence. Follow it step by step.

Step 1: Document What You Found

Before you do anything else — before you try to remove the data, before you call anyone, before you start drafting notifications — document the exposure.

What to Record

• What data is exposed? Be specific. Names, email addresses, phone numbers, Social Security numbers, financial information, health records, login credentials, or something else? Note the types and, if possible, the approximate volume (10 records? 1,000? 100,000?).
• Whose data is it? Customers, employees, job applicants, business contacts, or a mix? What geographies are affected (EU residents, California residents, Canadian residents)?
• Where is it exposed? Record the exact URL or location. Take screenshots with timestamps. If it is a website, note the domain and any identifying information about the site.
• How did you find it? Did you discover it yourself, did someone report it to you, did a security researcher notify you, or did you see it in the news?
• When did the exposure likely start? If you can determine when the data first appeared publicly, note it. This affects your notification timelines.
• Is the data still accessible? Check whether the data is currently live and accessible to anyone who visits the URL.

Why Documentation Comes First

Three reasons:

1. Evidence preservation. Web content can be taken down, changed, or moved. If you do not document it now, it might be gone later, and you will be working from memory instead of evidence.
2. Regulatory requirements. Most data protection laws require you to document security incidents, including what happened, what data was affected, and what you did about it. Your documentation from this moment forward is your compliance record.
3. Legal protection. If this leads to regulatory investigation, litigation, or insurance claims, contemporaneous documentation is your strongest asset. Reconstructing events after the fact is unreliable and looks bad.

Take screenshots. Save webpage copies. Record URLs. Note the date and time of everything. Store this documentation securely — not on a system that may itself be compromised.

Step 2: Assess the Exposure

Now that you have documented what you found, assess the situation. The answers to these questions determine your next steps.

Is This Your Data?

Determine whether the exposed data came from your systems or from a third party. Possibilities include:

• Your systems were breached. An attacker accessed your database, file server, or cloud storage and published the data.
• You accidentally exposed it. A misconfigured cloud storage bucket, a publicly accessible database, an unsecured API endpoint, or a file uploaded to the wrong location.
• An employee or contractor exposed it. Someone shared data they should not have — emailed it to the wrong person, uploaded it to a public repository, or posted it on social media.
• A vendor or service provider exposed it. A third party that processes data on your behalf had a breach or misconfiguration.
• It was scraped from public sources. Data that was individually public (like business directory listings) was compiled into a dataset.

Why this matters: if the data came from your systems, you have direct obligations. If it came from a vendor, you still have obligations, but the remediation path is different.

Is It Actually a Data Breach?

Under most privacy laws, a "personal data breach" is a security incident that leads to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. The key word is "unauthorized."

The exposure is likely a breach if:

• The data was not intended to be public
• It includes personal data of identifiable individuals
• It reached (or could have reached) unauthorized recipients

The exposure may not be a breach if:

• The data was already public information (e.g., published business contact details)
• The data is effectively anonymized and individuals cannot be identified
• The data is encrypted and the encryption key was not compromised

If you are unsure, treat it as a breach. It is far better to go through the breach response process unnecessarily than to skip it and find out later that you should not have.

How Sensitive Is the Exposed Data?

This determines the severity of your response. Rate the sensitivity:

High sensitivity (requires urgent action):

• Social Security numbers, national ID numbers
• Financial account numbers, credit card numbers
• Login credentials (passwords, security questions)
• Health or medical records
• Data about children
• Biometric data

Medium sensitivity:

• Names combined with email addresses, phone numbers, or physical addresses
• Employment records
• Purchase history or transaction details
• Location data

Low sensitivity (still requires action, but less urgently):

• Email addresses alone
• Names alone
• Business contact information

Step 3: Contain the Exposure

Act quickly to limit ongoing harm.

If the Data Is on Your Systems

Misconfigured cloud storage (S3 bucket, Google Cloud Storage, Azure Blob): Immediately change the access permissions to private. Verify the change took effect. Check access logs to see who accessed the data while it was exposed.

Publicly accessible database or API: Take it offline or restrict access immediately. If taking it offline would disrupt your business, implement access controls (IP whitelisting, authentication) as a stopgap while you plan a proper fix.

Data on your website: Remove the page or file. If you cannot remove it immediately, add authentication or take the site into maintenance mode. Ask your hosting provider for help if needed.

Compromised credentials: If login credentials were exposed, force password resets for all affected accounts immediately. Check for unauthorized access using those credentials.

If the Data Is on Someone Else's Systems

Contact the site or platform operator. Most platforms have abuse reporting mechanisms or security contact information. Send a clear, specific request to remove the data. Reference the specific URLs and describe the data.

If the platform does not respond: File a takedown request based on applicable laws. Under GDPR Article 17 (the "right to erasure"), you (or the affected data subjects) can request erasure of personal data. Similarly, under CCPA (Cal. Civ. Code § 1798.105), consumers have the right to request deletion of their personal information. Some countries have additional specific mechanisms for data removal requests.

Contact search engines. Even after the original source removes the data, cached copies may remain in search engine results. Google has a process for removing sensitive personal information from search results. Submit a removal request at Google's removal tool page. Bing and other search engines have similar processes.

If the data is on a paste site, dark web forum, or similar: Removal may not be feasible. Focus on mitigation — notifying affected individuals so they can take protective action (change passwords, monitor accounts, freeze credit).

Preserve Evidence Before Removal

Before you or anyone else removes the data, make sure you have your documentation from Step 1. Once the data is removed, you cannot go back and document what was exposed.

Step 4: Determine Your Notification Obligations

This is the legal part. Different regulations have different rules about when and how you must notify regulators and affected individuals.

GDPR (EU and UK)

Notify your supervisory authority: Within 72 hours of becoming aware of the breach (GDPR Article 33), unless the breach is unlikely to result in a risk to individuals' rights and freedoms. If you cannot provide all details within 72 hours, you can provide information in phases.

Notify affected individuals: Required when the breach is likely to result in a high risk to their rights and freedoms. No specific deadline, but "without undue delay" — which in practice means as soon as reasonably possible.

What to include in the authority notification:

• The nature of the breach (what happened)
• Categories and approximate number of individuals affected
• Categories and approximate number of data records affected
• Name and contact details of your DPO or other contact point
• Likely consequences of the breach
• Measures taken or proposed to address the breach and mitigate its effects

What to include in the individual notification:

• Clear, plain language description of what happened
• Name and contact details of your DPO or contact point
• Likely consequences of the breach
• Measures taken or proposed, including what they can do to protect themselves

CCPA/CPRA (California)

CCPA does not have a specific breach notification provision — it relies on California's existing data breach notification law (California Civil Code 1798.82).

Notify affected California residents: Required when unencrypted personal information was (or is reasonably believed to have been) acquired by an unauthorized person. Notification must be made "in the most expedient time possible and without unreasonable delay."

Notify the California Attorney General: Required if the breach affects more than 500 California residents.

What triggers CCPA-specific liability: If the breach involved personal information as defined by CCPA and resulted from a failure to implement and maintain reasonable security measures, affected consumers may have a private right of action under Cal. Civ. Code § 1798.150. Statutory damages range from $100 to $750 per consumer per incident.

US State Breach Notification Laws

All 50 US states have their own breach notification laws, each with different definitions, timelines, and requirements. Key variations:

This is not exhaustive. Check the specific requirements for every state where affected individuals reside.

PIPEDA (Canada)

Notify the Office of the Privacy Commissioner: Required when the breach creates a "real risk of significant harm" to any individual. Report as soon as feasible.

Notify affected individuals: Required when there is a real risk of significant harm. As soon as feasible.

Notify any organization or government institution: If notification to another entity could reduce the risk of harm, notify them as well.

When In Doubt

If you are unsure whether notification is required, err on the side of notifying. Regulators are consistently more understanding of organizations that report breaches proactively than those that try to hide them. A notification that turns out to be unnecessary is far less damaging than a failure to notify that comes to light later.

Step 5: Notify Affected Individuals

If notification is required (and in most cases involving exposed PII, it will be), do it properly.

What to Include

Your notification to affected individuals should be:

Clear and specific. Do not use vague language like "a security incident may have occurred." Tell them what happened in plain English.

Actionable. Tell them exactly what they should do to protect themselves:

• Change passwords (if credentials were exposed)
• Monitor financial accounts and credit reports (if financial data was exposed)
• Consider placing a fraud alert or credit freeze (if SSNs or financial data were exposed)
• Watch for phishing emails or scam calls that may use the exposed data

Honest about what you know and what you do not. If you do not yet know the full scope, say so. Do not speculate or minimize.

Timely. Delayed notification reduces the value of the notification. The sooner people know, the sooner they can protect themselves.

How to Notify

• Email is the most common method for online businesses
• Postal mail may be required or preferred for certain types of data
• Prominent website notice is sometimes required when individual notification is not feasible
• Phone calls for high-severity breaches where immediate action is needed

What Not to Do

• Do not blame the victims ("you should have used a stronger password")
• Do not minimize the severity ("we take your privacy very seriously" without substance)
• Do not wait until you have all the facts if waiting would put people at continued risk
• Do not send the notification from an email address that looks like phishing

Step 6: Report to Regulators

If your assessment determines that regulatory notification is required, file the reports.

How to File

EU supervisory authorities: Each EU member state has its own data protection authority. File through their online portal. The UK's ICO has a straightforward online reporting form at ico.org.uk.

US state attorneys general: Most accept breach reports through their websites. Some require specific forms.

Canadian Office of the Privacy Commissioner: File through the online breach reporting form at priv.gc.ca.

What Regulators Want to See

Regulators are not looking for perfection. They are looking for:

1. Timely detection and response. Did you identify and respond to the breach promptly?
2. Appropriate containment. Did you take reasonable steps to limit the damage?
3. Thorough investigation. Did you determine the scope and impact?
4. Proper notification. Did you notify affected individuals with actionable information?
5. Remediation. What are you doing to prevent this from happening again?

Having documented each step of your response (starting from Step 1 of this guide) puts you in a strong position.

Step 7: Remediate and Prevent Recurrence

After the immediate crisis is handled, address the root cause.

Investigate the Root Cause

How did the data end up exposed? Common causes include:

• Misconfigured access controls — Cloud storage or databases set to public instead of private
• Human error — Someone shared the wrong file or emailed data to the wrong person
• Software vulnerability — An unpatched system was exploited
• Credential compromise — An attacker obtained login credentials and used them to access data
• Inadequate vendor security — A third party had a security failure
• Lack of encryption — Data was stored or transmitted without encryption

Fix the Immediate Issue

Address whatever caused the exposure. If it was a misconfiguration, fix it and verify the fix. If it was a vulnerability, patch it. If it was human error, understand why it happened and what controls would prevent it.

Implement Preventive Measures

Based on the root cause, implement changes:

• Access reviews — Regularly audit who has access to sensitive data and revoke unnecessary access
• Configuration monitoring — Use tools or processes to check that storage and database configurations remain secure
• Encryption — Encrypt personal data at rest and in transit
• Training — Ensure employees understand how to handle personal data securely
• Vendor assessments — Review the security practices of third parties that handle your data
• Data minimization — Delete personal data you no longer need, so there is less to expose

Update Your Incident Response Plan

If you did not have an incident response plan before this, create one now. If you did, update it based on what you learned. What worked? What was confusing? What steps were missing?

Step 8: Keep Records

Maintain a complete record of the incident:

• The initial documentation (Step 1)
• Your assessment findings (Step 2)
• Containment actions taken (Step 3)
• Notification decisions and rationale (Step 4)
• Copies of all notifications sent (Steps 5 and 6)
• Remediation actions taken (Step 7)
• A timeline of events with dates and times
• Names and roles of people involved in the response

Store this record securely. Under GDPR, you must document all breaches — not just those you notified about. This record should be kept for at least the limitation period for regulatory action (typically 3 to 6 years, depending on the jurisdiction).

A Timeline for the First 72 Hours

Here is a condensed timeline of what should happen in the critical first 72 hours after discovering PII on the web.

Hour 0 to 1: Discover and Document

• Document the exposure (screenshots, URLs, data types, scope)
• Alert your internal point of contact (business owner, IT lead, DPO if you have one)

Hour 1 to 4: Assess and Contain

• Assess the severity and scope
• Begin containment (remove data, restrict access, contact platform operators)
• Determine whose data is affected and what jurisdictions are involved

Hour 4 to 24: Investigate and Decide

• Investigate the root cause
• Determine notification obligations for each applicable regulation
• Begin drafting notifications (regulatory and individual)
• Consult legal counsel if available (especially for high-severity breaches)

Hour 24 to 48: Notify and Remediate

• File regulatory notifications where required (GDPR 72-hour deadline is approaching)
• Begin notifying affected individuals
• Implement remediation for the root cause

Hour 48 to 72: Complete Notifications and Document

• Complete all regulatory filings
• Complete individual notifications
• Document the full incident response
• Begin implementing preventive measures

This timeline assumes a significant exposure. For minor incidents (e.g., a single email address found on a public page), the response can be compressed. The key is not the exact timing but the sequence: document, assess, contain, notify, remediate, record.

When to Get Legal Help

You do not need a lawyer for every privacy incident. But there are situations where legal counsel is strongly advisable:

• The exposed data includes highly sensitive categories (health records, SSNs, financial data)
• The breach affects individuals in multiple jurisdictions
• The exposure was caused by a vendor and contractual liability is in question
• You are uncertain about your notification obligations
• The volume of affected individuals is large (hundreds or thousands)
• You have reason to believe regulatory investigation or litigation is likely

If you do not have a regular attorney, look for a lawyer with data protection or cybersecurity experience. Many offer incident response as a service with rapid response times.

What to Do If You Discover Someone Else's PII

If you discover personal data on the web that does not belong to your business — maybe you stumbled upon a data dump that includes your own personal information, or you found another company's customer data exposed — the right thing to do is:

1. Do not download, copy, or further distribute the data. Accessing exposed data beyond what is necessary to understand the exposure could create legal issues for you.
2. Notify the organization whose data it is. Contact their security team, DPO, or general contact. Be specific about what you found and where.
3. Report it to the relevant authority. If the organization does not respond, consider reporting the exposure to the applicable data protection authority or CERT (Computer Emergency Response Team).

For more context on what happens when data protection obligations go unmet, see our guide on what happens if you ignore a DSAR.

References

• General Data Protection Regulation (GDPR): Regulation (EU) 2016/679. Full text
• California Consumer Privacy Act (CCPA): Cal. Civ. Code §§ 1798.100–1798.199.100. Full text
• California Data Breach Notification Law: Cal. Civ. Code § 1798.82. Full text
• PIPEDA (Canada): Personal Information Protection and Electronic Documents Act, S.C. 2000, c. 5. Full text
• NIST Privacy Framework: NIST Privacy Framework

---

Build Your Incident Response Capability

The best time to prepare for a data exposure incident is before it happens. Our DSAR Compliance Guide includes incident response frameworks, notification templates, and documentation checklists that help you respond quickly and correctly when something goes wrong. Because it is not a matter of if — it is a matter of when.

Download the DSAR Compliance Guide