A large retailer’s online store found a suspicious file in an external cloud service, took the site offline, and about a week later said personal data on roughly 7.7 million people may have been viewed or taken. Names, addresses, phone numbers, email addresses, and in many cases birth dates and passwords were in scope. Credit cards, the company said, were not stored in the affected service. The cloud vendor was not named. The attacker was not named. The store stayed down while investigators kept counting.
That pattern should feel familiar to anyone who has read a bank notice about a service-provider hop, or a clinic notice about a billing vendor, or a law firm notice about a document platform. The name customers recognize is on the letterhead. The records often sat one hop away.
If you run a medical practice, dental office, law firm, or small financial shop, you almost certainly have the same architecture in miniature: a customer-facing system that is really a thin shell over somebody else’s storage, exports, and “temporary” migration copies.
What the notice got right
Read the careful verbs. The company said data “may have leaked” and that it had confirmed the “possibility” the data was viewed or acquired. That is honest. It is also what you write when the logs that would answer the question are incomplete, not retained, or never captured reads in the first place.
The notice split members and non-members, admitted that not every field applied to every person, said some items including passwords were encrypted without explaining how, and warned customers about phishing copycats. It also took related sister services offline as a precaution even where unauthorized access was not confirmed. That last move is painful and usually correct. Shared plumbing rarely respects the org chart.
What the notice did not do is invent a confident attacker name, a tidy root cause, or a password-hashing story it could not defend. Borrow that discipline if you ever have to write one of these yourself.
“Encrypted” is not a plan
Breach notices love the word encrypted. Sometimes it means a salted, slow hash. Sometimes it means a fast hash. Sometimes it means reversible encryption with a key that lived next to the data. Customers cannot tell which from the adjective alone.
If you are the organization writing the notice, document how passwords and identifiers are stored in plain internal language before you need the letter. If you are a customer reading someone else’s notice, act as though reuse is dangerous until you know otherwise. Change the password anywhere you reused it. Expect phishing that pretends to be the company or a regulator. Address and date of birth do not rotate; watch account-recovery attempts that lean on them.
The small-firm version of the same failure
You do not need seven million records for this to hurt. A three-provider stack is enough:
- The practice management or case system.
- A cloud file share or document portal.
- A billing, marketing, or analytics export that still holds yesterday’s patient or client list.
Add a “temporary” CSV on a vendor SFTP site, a sandbox that was never wiped, and a former employee’s laptop sync, and you have more copies than your risk analysis admits. Regulators and insurers increasingly ask where ePHI, client files, and financial PII actually live. “In our EHR” is not a complete answer when the EHR backs up to a bucket you have never opened in the admin console.
What to do before you are the one writing the notice
Inventory where records actually sit. Not the app name. The buckets, SaaS tenants, analytics exports, mail archives, and migration copies. The place you find a suspicious file is rarely the place you were watching.
Log reads, not just writes. “We cannot rule out that data was viewed” is what you say when object-level read logging was off. Turn it on before you need it. Retain it long enough to answer the question.
Delete what you do not need. Former customers’ birth dates with no revenue attached are a liability. Closed accounts should not keep every field forever by default.
Vendor access is an identity problem. Unique accounts, MFA, least privilege, and an offboarding date. Shared “support” logins into a cloud tenant that holds your client list are an incident waiting for a schedule.
Say how you will contact people. Publish the channels you will use after an incident, and the channels you will never use to ask for passwords or codes. Copycats will fill any silence.
How Dark Edge helps without overclaiming
Dark Edge Consulting helps small professional firms map where sensitive records live, tighten vendor and cloud access, and put continuous monitoring and alerting around the stores that matter. Our programs are aligned with HIPAA, and similar frameworks where they apply, with management attestation available on request. We do not claim any architecture makes a breach impossible. We do not audit systems we manage. We do help you stop discovering your real data map for the first time while drafting a customer letter.
The entry point keeps moving one hop away from the brand on the homepage. Pull the hop back onto a diagram you own, then watch it.
Adapted from a post by Andrew Trainum on Cybersecsloth.
—
Need help mapping where your customer and patient data actually lives? Book a strategy call.