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

• Notify the OIPC Alberta and affected individuals simultaneously — simultaneous filing triggers the streamlined review process
• Complete the official OIPC Alberta Notification Form — do not substitute an informal letter
• Attach the AB PIPA Individual Notice (s.19.1) to your OIPC Alberta submission (Section D)
• Submit by email to breachnotice@oipc.ab.ca

---

BC PIPA — specific steps

• BC PIPA applies if any affected individuals are BC residents — applies regardless of where your organization is based
• OIPC BC voluntary reporting is available even if RROSH is not present — for cases with significant exposure windows where access is unconfirmed, voluntary reporting demonstrates good faith
• If RROSH is present: notify the OIPC BC through their official breach notification process at oipc.bc.ca and notify affected BC residents directly
• Do not substitute a general public notice for direct individual notification

---

MSPs — if managing this for a client

• If you administered the misconfigured cloud environment on behalf of a client, notify the client immediately with full technical details: bucket name, exposure window, data inventory, access log status
• The client organization is the accountable party — your role is to provide the facts that enable their RROSH assessment, not to make their notification decisions
• Run a ClearBreach assessment under your MSP account for the affected client organization
• If the misconfiguration resulted from your own configuration work, document that clearly — contractual liability to the client is separate from the client's regulatory obligations to their individuals