The breach at the home-care app “Naaste”
A fictional incident in the running case, written the way a public post-mortem would read. Realistically assembled from recurring patterns: a copy of production data outside production, a report landing on the wrong doormat, and an organisation that is not the first to tell the news.
1The facts
- Who
- Home-care organisation “Naaste”, around 60 staff, 1,412 clients. App built and maintained by an external nine-person agency.
- What
- A full copy of the production database sat for over eleven weeks in the builder’s test environment, reachable from the open internet with a default password.
- Which data
- Care notes (A1) and medication data (A2) of 1,412 clients over six months, plus the chat history with informal carers (A5) and 214 carer accounts (A3).
- How long
- 79 days between the copy being placed and the first report from outside; 116 days before clients heard about it.
- How it surfaced
- An external researcher e-mailed info@ — where it sat for two weeks. Clients eventually read about it in the regional newspaper.
2The timeline
Three moments are marked. What sits between them — 79 days blind, 14 days deaf, 6 days silent — is what this block is about.
- 3 Nov09:12T0 · it starts
A developer copies production data into a test environment
A ticket reports that medication data is not syncing for some clients. The developer cannot reproduce it with test data and pulls a copy of the production database into the agency’s sandbox. Nobody forbids this; there is no agreement permitting it either. The action is not recorded anywhere.
- 3 Nov17:40
The bug is found and fixed — the copy stays
The sandbox runs a dashboard for logs and database inspection, reachable from the internet, with the credentials it shipped with. For test data that was never a problem.
- 79 d79 days with nobody looking
No monitoring on the sandbox, no inventory of environments, no periodic check by “Naaste” at the builder. The contract covers availability and support, not what may happen to data.
- 14 Jan02:40
An automated scanner finds the dashboard
Not aimed at the care organisation: a scanner sweeping the whole internet for known dashboards with default passwords. Over the next two nights the database is downloaded in parts.
- 22 Jan16:20someone notices
A researcher e-mails info@naaste.nl
A security researcher comes across the dataset, recognises Dutch care data and sends a polite report to the only address on the website. There is no security.txt, no reporting point, no procedure.
- 22 Jan16:55
The office manager marks the e-mail as phishing
The message asks for confirmation that the domain belongs to the organisation and contains a link. That is exactly the pattern from last year’s awareness training. It goes to the spam folder — the training worked, the organisation did not.
- 14 d14 days with nobody listening
There is no second channel. The researcher tries the phone number on the site; it reaches care planning, who have no idea where to put such a question.
- 4 Feb11:30
The researcher finds the data protection officer via LinkedIn
He adds that he will go public in two weeks, and tips off a regional journalist so it cannot stay quiet.
- 5 Feb08:50
The director hears about it and calls the builder
There is no incident procedure. The director, the DPO and the team lead spend the morning working out who is responsible for what. At the agency, nobody initially knows which environment is meant.
- 5 Feb11:30
The sandbox goes offline
Within two and a half hours of the first phone call. From here on it moves fast — which is exactly why the slow half before it weighs so heavily.
- 6–7 Feb—
The scope turns out to be impossible to establish
The sandbox kept no access logs. It is visible that the dashboard was exposed, not who visited or what was taken. The sentence “we have no indication that data was downloaded” is literally true and utterly misleading.
- 8 Feb17:00
Notification to the Dutch data protection authority
Three days after the director heard about it — but seventeen days after the organisation received the first report. Whether the 72-hour clock started on 22 January or 5 February is the sharpest discussion question of this block.
- 6 d6 days with nobody telling
Meanwhile the team works internally towards “a complete picture”. Clients, informal carers and care workers know nothing. The journalist already has his deadline set.
- 11 Feb06:30someone tells
The article appears
Clients and informal carers read it in the paper. That morning care workers get questions on the doorstep they cannot answer — they were never informed.
- 11 Feb09:15
The e-mail to clients goes out
Two and a half hours after the newspaper, in a tone written for the regulator. See part 5.
- 12–22 Feb—
The damage shows up somewhere other than expected
41 informal carers withdraw their access, two clients move to another provider. The team lead loses a week and a half almost entirely to phone calls. Two care workers later say they started doubting whether to put notes in the app at all — and that hits the reliability of the client record (A1).
3The design choice underneath
Ask why three times. The first layer is what went wrong; the third layer is what you can actually change in a design.
- What went wrong?
A test environment holding real client data was exposed with a default password.
- Why was that possible?
Because a copy of production data was allowed to exist outside production. The test environment was set up for made-up data and was never reassessed once real data arrived. The security matched what was supposed to be there, not what actually was.
- Why had nobody decided that?
Because the question “may production data leave production, and who decides?” was on nobody’s plate. The care organisation assumed the builder handled it; the builder assumed the client would say so if it were not allowed. That same assumption was already sitting at the bottom of the week 1 Security Context Canvas — as an open question, not as a risk with an owner.
Nobody decided that production data was allowed to leave. There was also nobody who could decide that it was not.
4What went well
Deliberately placed before the communication section, so the discussion afterwards is about design rather than blame.
- After the first phone call the environment was offline within two and a half hours. The technical response was not the problem.
- The researcher reported it properly and allowed ample time. That the organisation did not use that time is not on him.
- The awareness training worked: the office manager correctly recognised the phishing pattern. What was missing was a route for a genuine report from outside.
- The DPO acted within a day of hearing about it, and pushed to notify the authority despite pressure to wait for “a complete picture”.
- A post-mortem was held, with the builder in the room. That is less obvious than it sounds.
5The communication
Four messages, exactly as they went out. Each one is defensible on its own; together they tell the story of an organisation protecting itself rather than its clients.
A limited amount of data was unintentionally accessible at an external supplier. There has been no hack of the “Naaste” app.
How it landed: Both sentences are true and both read as ducking. “Limited” covers 1,412 client records, and “it wasn’t the app” interests nobody whose medication data was in there. On top of that the message came after the newspaper — which made it a reaction rather than an announcement.
— no date when it started, no numbers, no answer to “was my data in there?”
How it landed: The helpdesk took 90 calls asking exactly that, with no answer available. Every call repeated the mistake the e-mail had already made. One line with a date and a number would have prevented most of them.
Please refer client questions to the team lead.
How it landed: Care workers had been in people’s homes since eight that morning. They were the face of the organisation and were informed last — precisely the wrong way round. This is the mistake that cost the most trust, and the cheapest one to avoid.
We take privacy very seriously and took immediate measures.
How it landed: The standard line. It was quoted verbatim in the follow-up article, with the seventeen-day timeline printed underneath. A sentence you cannot back up with a timeline makes the story worse, not better.
6Recovery & post-mortem
The post-mortem was held three weeks after the breach. This is the list of measures with the state of play four months later — the part that is usually missing from real write-ups.
- doneBan on copies of production data outside production, written into the processor agreement
Contract amended at the June renewal. The test environment has used generated data ever since.
- doneA reporting point for vulnerabilities: security.txt and an address that reaches the DPO
Arranged within two weeks. Two reports have come in since, both picked up within a day.
- partialIncident procedure with roles, escalation path and a spokesperson
A four-page draft exists, never rehearsed. At the next outage nobody reached for it.
- partialLogging on all of the builder’s environments, including non-production
Production is covered. No budget was freed for the other environments.
- not doneCommunication playbook: staff first, then those affected, then the press
Noted as an action point, no owner assigned. Four months on, unchanged.
- not doneAnnual supplier review of environments and access
Agreed for the autumn. No date, no checklist, no identifiable owner.
7What we do not know
The honest loose ends. For this block they matter more than the facts: they show what you should have set up in advance in order to know.
- Whether the dataset was actually taken in full, and by whom. Without logging on the sandbox that can no longer be established — and that is a design choice, not bad luck.
- Whether the data is still circulating somewhere. There is no indication of it, but here “no indication” literally means: we have no way to look.
- Exactly when the GDPR 72-hour clock started running. On receipt at info@ (22 January) or when the management learned of it (5 February)? The organisation uses the second reading; the first is defensible and would make the notification seventeen days late.
- How many clients left for this reason. Two said so out loud; how many walked away quietly cannot be traced.
- Whether care workers have been writing less in the app since. Two said they were; if it is wider, the breach shifts into the reliability of the client record (A1) — and you only notice that when something goes wrong in the care itself.