Cloud Storage Misconfiguration — What Canadian Organizations Must Do

Which laws apply

Jurisdiction	Applies when	Regulator
PIPEDA	The misconfigured storage held personal information used in commercial activity; or the affected individuals are in provinces without substantially similar legislation (Ontario, Manitoba, New Brunswick, and others)	Office of the Privacy Commissioner of Canada (OPC) — priv.gc.ca
Alberta PIPA	Personal information about Alberta residents or employees was exposed	OIPC Alberta — oipc.ab.ca / breachnotice@oipc.ab.ca
BC PIPA	Personal information about BC residents or employees was exposed	OIPC BC — oipc.bc.ca

For most organizations, PIPEDA and one or both provincial statutes apply simultaneously. A separate notification is required for each applicable regulator if RROSH is determined.

---

What makes this scenario different

In every other breach scenario covered in these playbooks, an external party initiates the incident — a phishing email, a ransomware deployment, an employee acting outside their authorization. In a cloud storage misconfiguration, your organization caused the exposure. No attacker was required.

This creates four features that distinguish this scenario from all others.

You may not know how long the data was exposed. A misconfigured S3 bucket or Azure blob storage container can remain publicly accessible for days, months, or years before anyone notices. Cloud storage configuration errors often go undetected because they generate no alerts by default — the data is simply accessible to anyone who knows the URL or runs a cloud scanning tool. When discovery happens, the first question — how long was this public? — is often the hardest to answer.

Discovery is frequently by a third party, not by you. The most common ways organizations learn about cloud storage misconfigurations are: a security researcher running a scanning tool, a threat intelligence service reporting a public bucket, a journalist investigating data exposures, a competitor or customer who stumbled on the URL, or a dark web alert. If you are reading this because a security researcher just emailed you, that email is evidence that your data was accessible and was found. The question of whether it was also accessed by someone with malicious intent is now the relevant question for your RROSH assessment — not whether it was accessible.

Access logs are often not enabled. Cloud providers do not enable access logging on storage buckets by default in most configurations. This means that even after you discover the misconfiguration, you may have no record of which IP addresses accessed which files during the exposure window. The absence of logs does not mean no access occurred — it means you have no evidence either way. Your RROSH assessment must account for this honestly: unknown access to sensitive data is not the same as confirmed no-access.

The data may already be indexed or archived. Search engine crawlers, web archive services, and automated scanning tools index publicly accessible URLs continuously. If the bucket was public for more than a few days, copies of the exposed files may exist in places you cannot reach. Restricting the bucket does not un-expose data that was already cached, downloaded, or indexed.

---

Immediate steps — this scenario specifically

1. Restrict the bucket immediately — but preserve evidence first. Before changing any configuration, take two steps: note the exact current configuration settings (who has access, what permissions exist, when those permissions were last changed), and confirm that any available access logs are preserved. Then restrict the bucket to private access. Do not delete the bucket or its contents — they are evidence.

2. Determine the exposure window. Check your infrastructure configuration history (CloudTrail in AWS, Activity Log in Azure, Audit Logs in Google Cloud) to identify when the bucket was made public. If you use infrastructure-as-code, check your version control history for the configuration change. The exposure window runs from the date the bucket was misconfigured to the date you restricted it. Document this date range precisely — it defines the scope of your RROSH assessment.

3. Inventory what data the bucket held. List every file, folder, or object that was stored in the bucket during the exposure window. Identify: what categories of personal information were present (financial records, health data, SINs, passwords, government IDs, contact information), whose information it was (customers, employees, patients, other), how many individuals are affected, and whether any files contained combinations of data types that together enable identity theft.

4. Check whether access logs exist. If access logging was enabled on the bucket, pull the logs for the entire exposure window. If logs were not enabled, document that explicitly — it is relevant to your assessment and to regulators. If the bucket was managed by a cloud provider, contact them to determine whether any logging exists at the platform level even if application-level logging was off.

5. Do not issue any public statement yet. Premature or inaccurate public disclosure before you have completed your assessment creates confusion, may be legally problematic, and may undermine individual notification. Complete your RROSH assessment first.

---

What drives RROSH in this scenario

RROSH — real risk of significant harm — in a cloud misconfiguration is assessed on two axes: what data was exposed, and what the realistic probability of unauthorized access was during the exposure window.

Factors that push toward RROSH:

• The bucket contained sensitive categories: health data, financial records, SINs, passwords, government-issued ID numbers, or information about minors
• The bucket contained enabling combinations: name + date of birth + address + SIN is more dangerous than any field alone
• The bucket was public for more than a few days — public cloud storage is scanned by automated tools continuously
• A third party (researcher, journalist, competitor) found and reported the bucket — confirming active discovery
• The bucket was indexed by a search engine or web archive during the exposure window
• Access logs show downloads of specific files
• The bucket contained employee records including banking information for payroll

Factors that push against RROSH:

• The bucket contained only generic non-identifying information: product documentation, marketing materials, aggregated statistics with no individual identifiers
• The exposure window was confirmed to be very short (hours) and access logs show no external access
• All files in the bucket were encrypted and encryption keys were not included in or accessible from the bucket
• The bucket held only publicly available information that conveyed no additional risk through aggregation

The no-access-log default: When access logs are absent, the RROSH assessment must account for the realistic probability of access given the exposure window and data sensitivity. For a bucket containing sensitive personal information that was public for more than 48 hours, the probability of access by an automated scanner is very high — not speculative. That probability, combined with the consequence if the data is misused, typically results in RROSH being present even without confirmed access.

---

Likely verdict range

Scenario	Typical verdict
Bucket contained SINs, financial records, or health data; exposure window more than 48 hours	RROSH — sensitive data + high probability of access
Bucket contained employee records including banking or compensation details	RROSH — financial data combination
Security researcher or third party confirmed they accessed and viewed the files	RROSH — access confirmed
Bucket contained customer name, email, and phone number; short exposure window; logs show no external access	Case-by-case — depends on volume and whether data enables harm without additional context
Bucket contained internal documents with no personal information	BELOW_RROSH — but document the assessment and investigate the root cause
Bucket contained only publicly available content (e.g., a public website's static assets)	BELOW_RROSH — no personal information at risk
Bucket was public but all files were encrypted and keys were stored separately and were not compromised	Likely BELOW_RROSH — but confirm encryption scope before concluding

---

Scenario-specific obligations and complications

If RROSH is determined:

• OPC notification (PIPEDA): Report to the Office of the Privacy Commissioner of Canada as soon as feasible after determining RROSH. Use the OPC breach report form at priv.gc.ca. The OPC does not require you to know the full scope before filing — file when RROSH is determined and supplement with additional information as your investigation continues.
• OIPC Alberta notification (AB PIPA): Notify the OIPC Alberta without unreasonable delay. Email breachnotice@oipc.ab.ca. Use the official OIPC Alberta notification form.
• OIPC BC notification (BC PIPA): Notify the OIPC BC through their official breach notification process at oipc.bc.ca.
• Individual notification: Notify each affected individual directly. The notification must describe what happened, what information was involved, what steps the organization is taking, and what the individual can do to protect themselves. For a cloud misconfiguration, this includes advising individuals to monitor their financial accounts and credit reports if financial or identity-enabling data was exposed.

If RROSH is not determined:

• No regulator notification required under PIPEDA or Alberta PIPA.
• No individual notification required.
• Internal breach record required — document the exposure window, data inventory, access log findings, and your RROSH assessment with reasoning.
• Fix the misconfiguration root cause: was this a manual error? A deployment pipeline failure? A missing infrastructure policy? The internal record should capture what failed and what was changed to prevent recurrence.

BC PIPA — voluntary reporting option. Under BC PIPA, organizations may voluntarily report to the OIPC BC even where RROSH is not present. For cloud misconfigurations involving BC residents where the exposure window was significant but access is unconfirmed, voluntary reporting demonstrates good faith and reduces complaint risk. See BC PIPA Breach Reporting.

For Ontario organizations. Ontario has no provincial private-sector privacy legislation — PIPEDA is the applicable framework. Report to the OPC at priv.gc.ca. No separate provincial regulator report is required. See Ontario Data Breach Reporting Requirements.

Complications specific to this scenario:

The exposure window cannot be precisely determined. If your cloud environment does not log configuration changes with timestamps, you may not be able to confirm exactly when the bucket became public. In this case, use the earliest plausible date — the last known-private configuration or the creation date of the bucket — as your conservative exposure window start. Document the basis for your estimate. Regulators understand that configuration history is not always available; they expect you to use the most conservative reasonable estimate, not the most optimistic one.

The data was indexed by a search engine or web archive. If you discover the bucket URL appears in search engine results or a web archive like the Wayback Machine, the data was accessed by an automated crawler. This is confirmed access. It does not mean the data was accessed by a human with malicious intent — but it means the data exists in a form you cannot fully control. Note this in your individual notifications and advise individuals accordingly.

A security researcher disclosed the finding publicly before notifying you. Some security researchers disclose findings publicly before contacting the affected organization, or disclose simultaneously. If your misconfiguration is already public knowledge, individual notification becomes more urgent — affected individuals may be hearing about it from news sources before hearing from you. Accelerate your assessment and notification timeline accordingly.

The bucket contained files from multiple clients or customers. If you are a service provider and the bucket held data belonging to multiple client organizations, each client organization is the accountable party under PIPEDA and PIPA for their own individuals. You may have a contractual obligation to notify each client promptly. Each client then conducts their own RROSH assessment and determines their own notification obligations. Your obligation and theirs are separate.

---

Documents you will need

Regardless of RROSH determination:

• Internal breach record: date discovered, exposure window, bucket contents inventory, access log findings (or confirmation logs were not available), RROSH assessment and outcome, root cause, remediation steps taken
• Cloud configuration history showing when the bucket was made public (if available)

If RROSH is determined, also:

• OPC breach report (PIPEDA)
• OIPC Alberta breach notification (AB PIPA) — if Alberta individuals affected; email breachnotice@oipc.ab.ca
• OIPC BC breach notification (BC PIPA) — if BC individuals affected; submit through OIPC BC's process at oipc.bc.ca
• Individual notification letters — one per affected individual or one per household

ClearBreach generates the regulator reports and individual notification letters automatically from your assessment answers.

---

Common mistakes in this scenario

Treating remediation as the end of the response. The most common mistake in cloud misconfiguration breaches is making the bucket private and considering the matter closed. Remediation is step one of your response. Your PIPEDA and PIPA obligations begin when the misconfiguration is discovered, not when it is fixed.

Assuming no access because no access was detected. "We have no evidence anyone accessed the data" is not the same as "no one accessed the data." If access logs were not enabled, you have no evidence either way. Presenting the absence of logs as evidence of no access is not a defensible position with regulators.

Deleting the bucket or its contents before completing the assessment. Deleting files or the bucket itself destroys evidence and may prevent you from accurately determining the scope of what was exposed. Preserve the bucket contents until your breach record is complete.

Not knowing what was in the bucket. Cloud storage is frequently used as a general-purpose dumping ground for files. Organizations often cannot immediately answer what personal information was stored in a misconfigured bucket because no one maintained a data inventory for it. The RROSH assessment cannot proceed without a data inventory. After this incident, implement a data classification policy for all cloud storage.

Underestimating the exposure window. Organizations often anchor on when they discovered the misconfiguration as the exposure start date. The actual exposure start date is when the misconfiguration occurred — which may be weeks, months, or years earlier. Using the discovery date rather than the misconfiguration date understates the exposure window and is not a credible position with regulators.

Sending a templated notification that does not describe what actually happened. Individual notifications for cloud misconfiguration breaches must explain in plain language that your organization accidentally made files publicly accessible, what files were accessible, for what period, and what individuals can do now. A generic "we experienced a security incident" notice does not meet the regulatory standard.

---

MSP note

If you manage cloud infrastructure for clients and this misconfiguration occurred in a client's cloud environment that you administer:

The client organization is the accountable party under PIPEDA, AB PIPA, and BC PIPA for their individuals' personal information. Your role is to determine the exposure window, inventory the exposed data, preserve logs, and assist the client with their RROSH assessment — not to make notification decisions on their behalf.

If the misconfiguration resulted from your own configuration work or a deployment you managed, you may have contractual liability to the client. That contractual matter is separate from the client's regulatory obligations to their individuals.

Document your findings clearly and provide them to the client as soon as possible. The client's response timeline starts when they are informed of the breach — your disclosure to them is the trigger.

---

Ready to assess this breach? ClearBreach walks you through your cloud storage misconfiguration scenario, applies PIPEDA, Alberta PIPA, and BC PIPA simultaneously, and generates your assessment verdict, regulator reports, and individual notification letters automatically — in under 15 minutes. Start your assessment →

---

This playbook covers PIPEDA, Alberta PIPA, and BC PIPA obligations for private-sector organizations. If your organization handles personal health information under provincial health legislation — such as Alberta's Health Information Act or BC's E-Health (Personal Health Information Access and Protection of Privacy) Act — additional obligations may apply when health information is exposed through a cloud misconfiguration. Those obligations are not covered here.

---

Related guides

• PIPEDA Breach Reporting Requirements — when and how to notify the OPC under PIPEDA
• Alberta PIPA Breach Notification — AB PIPA notification obligations and OIPC process
• BC PIPA Breach Reporting — BC PIPA notification obligations and OIPC BC process
• What Is RROSH? — the real risk of significant harm standard explained
• Cloud Storage Misconfiguration — Quick Reference — checklist for use during the incident