Years earlier, a shop's order notification plugin had been configured to send a copy of every order to the developer who built the site. He later left the agency, and his mailbox was kept open as a courtesy.
It was not noticed until he mentioned, in passing, that he was still receiving customers' names, addresses and order details. That was a privacy problem, not a technical one, and it needed a proper response.
The recipient list was fixed, the mailbox was cleared with his cooperation, and the shop started an annual review of who receives what.
How the copy got there
The shop sold handmade furniture and had two staff and a part-time packer. The website was built by a small agency, and during the build the developer added his own address as a second recipient on the new-order email. This is a common practice, and a reasonable one during testing: you want to see exactly what the shop owner will see. Then the site launched, and the testing address stayed in the field.
Nobody removed it for the dull reason that nothing visibly changed. The owner still got her email. The packer still got hers. The developer's copy was invisible to everyone except him, and after he left the agency he had no reason to say anything, since the messages were landing in a mailbox the agency had decided to keep alive for forwarding client mail.
For several years, every order, with name, delivery address, phone number and what was bought, went to a person with no connection to the shop.
How it came to light
It surfaced at a coffee. The former developer, now working elsewhere, was chatting to the shop owner about her new range and remarked that he had seen her sell a lot of the oak benches lately. She asked how he knew. He explained that he still got the order emails, assumed she had set it up on purpose, and had stopped looking at them long ago.
That conversation is a fortunate way to find out. The alternative route is a customer's complaint, a leaked mailbox, or an audit by someone who is paid to be thorough. The owner thanked him, went home and opened the plugin's settings.
Why this counts as a data protection issue
Customers give a shop their personal details to get goods delivered. They do not expect the details to be sent to someone who has nothing to do with the order. In many places that is a personal data breach under data protection law, even though nobody hacked anything and the recipient was friendly.
The details matter for how seriously to take it. Who received the data, for how long, what it contained, whether they kept it, and whether it could cause the customers harm are all questions a regulator would expect an owner to be able to answer. Some jurisdictions also set short deadlines for reporting a breach that meets a threshold. I cannot tell you which rules apply to you, but I can tell you not to treat this as a private embarrassment. If you are in doubt, speak to your data protection regulator's guidance pages or a professional adviser.
Here, the data held no payment card details, since the card was handled by a payment provider, but it did hold names, postal addresses, phone numbers and purchase history. That is enough to matter.
The response, step by step
- Remove the address from the plugin's recipient field and send a test order to confirm the copy stopped.
- Ask the former developer, in writing, to delete every order email and not to use or share the information. He agreed within the hour and sat with the owner's laptop while they searched his mailbox, trash and archive together.
- Ask the agency, which still ran the mailbox, to confirm in writing that no backup or forwarding rule held a copy. They found a rule that forwarded a copy of everything to a shared archive and removed it.
- Write down what happened: dates, what was sent, who saw it, what was done. Dates came from the plugin's change history and the first test order from the site's launch.
- Decide whether affected customers or a regulator need to be told. The owner took advice, and the written record made that conversation short.
The mailbox clean-up was the easy part because the developer was cooperative. If he had been hostile or silent, the same steps would have involved lawyers and weeks.
Where else the same mistake hides
Notification addresses are scattered. The owner went hunting afterwards and found the pattern repeated in smaller ways. A contact form copied a second address that belonged to a former packer. The stock-alert plugin sent to the agency's general inbox. A shipping integration sent labels to an account that was set up with the developer's own email.
| Place | What to look for |
|---|---|
| Order and booking plugins | Recipients, CC and BCC fields, per-status emails |
| Contact and enquiry forms | "Send to" and auto-reply settings |
| Site admin users | Accounts for people who have left; roles and recovery emails |
| Mail server | Forwarding rules, aliases, shared mailboxes |
| Third-party services | Payment, shipping, analytics and monitoring alert addresses |
| Hosting and domain accounts | Technical and billing contacts |
The aftermath
The owner wrote to the customers whose orders fell in the period, after taking advice. The letter was short: what happened, what information was involved, that it had been deleted with the recipient's written confirmation, and who to contact. Several replied. Most said thank you; one asked for a copy of the data held about her, which the owner could now produce quickly because she had written everything down.
The agency changed its own handover routine as a result. Every project now ends with a settings sweep that removes the developer's address from anything it was added to for testing, and the sweep is signed off by someone other than the person who built the site. That second pair of eyes is what usually catches the leftover.
Role mailboxes and leaving the business
The structural fix was to stop addressing operational mail to people. The shop now sends order notifications to orders@ on its own domain, a shared mailbox that the owner and packer both read. When someone joins or leaves, access to that mailbox changes. Not one setting inside a plugin needs touching.
There is a trade-off. Shared mailboxes are easy for everyone to read, and nobody feels responsible for them. The owner added a rule that she looks at the mailbox's member list on the first of every quarter, and removes anyone who no longer needs it.
When staff leave, a short offboarding list now covers more than the front door key: remove their access to the site, change shared passwords, close or redirect their mailbox, and check whether their address appears in any notification setting. The glossary explains terms such as alias and forwarding rule, if those are unfamiliar.
Try it on your own site
Place a test order on a test product and look at every message it creates, in every mailbox that should and should not receive one. Look at the full headers of one, which show the To, Cc and Bcc lines the plugin used. Then open each plugin that sends email and read its recipient settings.
On the mail server or in your hosting panel, list forwarders and aliases and read each destination. If you use a separate mail provider, its admin console lists forwarding rules per user. Search your own mailbox for the names of people who have left and see where their addresses still appear.
What would have caught it
- Audit notification recipients in plugins and forms.
- Remove access and forwarding when people leave.
- Prefer role mailboxes over individuals for operational mail.
- Place a test order after every site change and read the recipient lines of each email it produces.