Cloud Storage Misconfiguration — Quick Reference Guide

First 30 minutes

• Preserve evidence before changing any configuration: screenshot the current access settings, note the bucket name and region, confirm that any existing access logs are saved
• Make the bucket private — after evidence is preserved
• Pull your cloud configuration history (AWS CloudTrail, Azure Activity Log, Google Cloud Audit Logs) to identify when the bucket was made public
• Designate an incident lead — all communications and decisions route through them
• Record the exact date and time you discovered the misconfiguration — this starts your response clock

---

Within 24 hours

• Determine the exposure window: from when the bucket was misconfigured to when you restricted it
• Inventory every file and object stored in the bucket during the exposure window: what categories of personal information, whose information (customers, employees, patients), how many individuals
• Check whether access logging was enabled — if yes, pull all logs for the exposure window; if no, document that access logs are unavailable
• Search engine check: query the bucket URL or file names to determine whether any content was indexed during the exposure window
• Identify which provinces' residents are affected — this determines whether AB PIPA and BC PIPA apply in addition to PIPEDA
• Begin your ClearBreach assessment — do not wait for full log analysis to start

---

Within 72 hours

• Complete your RROSH assessment in ClearBreach and review your verdict
• If PIPEDA RROSH threshold is met: file OPC Breach Report as soon as feasible — do not wait until access is confirmed if logs are unavailable
• If Alberta PIPA applies and RROSH is met: notify OIPC Alberta (breachnotice@oipc.ab.ca) and affected individuals simultaneously
• If BC PIPA applies and RROSH is met: notify the OIPC BC through their official breach notification process and notify affected BC residents directly
• Send individual notifications: explain that cloud storage was accidentally left publicly accessible, what data was accessible, the exposure period, and what individuals can do to protect themselves
• If a security researcher or third party reported the finding, acknowledge their disclosure appropriately — do not make any public statement before individuals are notified

---

Ongoing — until resolution

• Update your Internal Incident Record as log analysis or third-party disclosure adds new information — if material new facts emerge after notifying, send follow-up notifications to regulators and affected individuals
• Confirm the bucket remains private and no other storage containers in your environment are misconfigured
• Monitor for signs of data misuse: credential stuffing, phishing using exposed contact data, identity fraud reports from affected individuals
• Retain all records — configuration history, access logs, internal assessment records, notifications sent — for 24 months minimum from date of discovery
• Conduct a full cloud storage audit: identify all buckets and containers, verify access controls, enable access logging going forward, implement an infrastructure policy to prevent public buckets

---

Alberta PIPA — specific steps

• If Alberta residents' data was in the exposed bucket, file your OIPC Alberta notification and send individual notices on the same day — this qualifies the file for the streamlined review track and a private closing letter instead of a full investigation
• Use OIPC Alberta's official notification form itself, not an email summary of the incident — an informal write-up will be treated as incomplete
• Attach the AB PIPA Individual Notice (s.19.1) as Section D of that form, not as a separate document — a missing Section D is the most common reason a submission gets sent back
• Address the completed package to breachnotice@oipc.ab.ca

---

BC PIPA — specific steps

• BC PIPA is triggered by where the affected individuals live, not where your bucket or your company is hosted — a container in any region can create this obligation the moment a BC resident's data is in it
• If the exposure window was long or you have no access logs to rule anything out, consider reporting to the OIPC BC voluntarily even without a confirmed RROSH finding — it puts a good-faith record on file before a complaint does
• Where RROSH is present, file through the OIPC BC's breach notification process at oipc.bc.ca
• Write to each affected BC resident individually — a notice posted on your website does not satisfy this requirement

---

MSPs — if managing this for a client

• If you administer the client's cloud environment, hand over the full technical picture immediately: which bucket, how long it was public, what was in it, and whether any logging exists — the client cannot start their own assessment without these specifics
• Your client is the accountable party for their own individuals' data — you're supplying the facts their RROSH determination depends on, not making the call yourself
• Set up the assessment under your MSP account so the client's determination is built on your findings rather than a second-hand summary
• Where the misconfiguration traces back to your own deployment or configuration work, note that separately — it's a contractual liability question between you and the client, distinct from what they owe their affected individuals under PIPA