Okay, But Actually… “You’ll Get Sued” Is Not Useful Security Advice
The comment that started this series promised a lawsuit and a “world of pain” over a custom app nobody had described yet. I have spent several posts on the security terms in that comment. I still want to know about the lawsuit. Who is suing, and what happened to them?
If the answer is “something might go wrong,” I have unfortunate news about every other piece of software a business uses.
Give the warning a reason
Say an app emails project updates to clients. One client receives another client's report, complete with an unpublished design and a budget. That is a problem I can understand. I can also see why the client whose plans were exposed might be angry.
Now I need to know how it happened. Did the app attach the wrong report? Was the wrong email address saved in the client's account? Did a member of staff select the wrong person before pressing send? I am not asking those questions to dodge responsibility. The answers tell the business what to stop, whom to contact, and what to fix before the next report goes out.
The UK's National Cyber Security Centre advises businesses dealing with an incident to find out what happened, limit the harm, resolve the problem and decide who needs to be told. “You'll get sued” has contributed precisely nothing to any of those jobs.
The report might also contain a person's name, email address or other private details. If the GDPR applies, the European Data Protection Board says the business must record and assess a personal data breach. Whether it must tell the authorities or the people affected depends on the risk. An embarrassing email does not come with an automatic instruction to notify everyone, and ignoring it because “it was only one email” would be a poor idea too.
An unpublished design and budget can be confidential without being personal information. If the studio promised its client to keep them private, I need to know that before I build the feature that emails them out.
Could the customer sue the business?
Possibly. They may believe the business broke a contract or caused them a loss. Someone whose personal information was exposed might make a complaint or seek compensation. The customer may also decide never to work with the business again, which can hurt without a court getting involved.
But a lawsuit is not a scheduled event that appears on the calendar when you commission an app. In a claim for compensation under the GDPR, the Court of Justice of the European Union says breaking the rules alone is not enough. There must also be damage and a link between that damage and the breach. That is about one kind of claim under EU law; contracts and rules elsewhere can work differently.
So I cannot promise a client that nobody will ever sue them. I also cannot predict a lawsuit from the words “custom software” when I do not know what the software does. If someone else can, I would like to borrow their powers for project estimates.
Who would have to deal with the mistake?
The business has a customer to answer to. If I built the part that sent the wrong report, I need to know about it and investigate my work. If the business chose the wrong recipient, it needs to correct the way staff send reports. A supplier that delivers the email may need to help trace what happened. A subscription to that supplier does not make the customer's complaint its problem to handle alone.
The agreement between the business and its developer should cover what was built, who supports it, how the client reports a problem and how quickly the developer needs to respond. If I need access to live records to investigate, that access should be planned too. Nobody wants to discover during an incident that the only person who can check the sending logs has gone on holiday and never agreed to provide support.
For personal information, the European Data Protection Board explains that a business does not lose its responsibilities just because it hires a supplier, and a supplier handling information on its behalf can have duties of its own. The contract and the way the service actually works matter more than pointing at a logo and saying “they handle security.”
Before the first report goes out
Set up two test client accounts. Send each a report and check that neither receives the other's. The app should record which report went to which address, and the business needs to know who can change recipients. It also needs a way to reach the developer if something goes wrong. If its customer contracts promise confidentiality or a response time, I need to know that while building the feature.
An established platform needs checking too. Staff can choose the wrong contact there. A well-run supplier may give the business useful controls and logs, but somebody still has to configure them and use them.
If you can see a way this particular app might hurt somebody, tell me. I want the awkward question about the report that could go to the wrong client, the access setting that lets every employee see everything, or the promise the business made in a contract and forgot to mention to its developer. Those questions might lead to a change in the design, better testing or specialist legal advice.
“You'll get sued” tells a business owner to be afraid. They probably already know that something going wrong would be bad. Give them enough detail to do something about it.