# Security and privacy by design: the six findings you will not be fixing [Home](https://3bird.nl/)/Security and privacy by design: the six findings you will not be fixing # Security and privacy by design: the six findings you will not be fixing Two weeks before launch the penetration test comes back. Eighteen findings. Twelve of them are closed within a day: a missing header, an expired certificate, an endpoint returning more than it should. The other six are the problem. Not because they are hard to understand, but because they are not mistakes. They are decisions. The users table holds the national identity number because that seemed useful once. The application talks to the database as a single account that can reach everything. There is not one log line telling you who opened which customer record. You do not fix that in two weeks, because it sits in the design. Which is exactly what security and privacy by design are about. ## The difference between a finding and a design decision A mistake gets patched. A design decision gets migrated, and migration hurts the moment there is production data involved. Take that identity number. Removing it means working out everywhere it ended up: in backups, in exports, in a log file somebody once found convenient, in the search index. Each of those is a separate conversation. Never having stored it means never having the conversation. That is the core of the idea, and it is less lofty than the phrase suggests. This is not about a security culture or a mindset. It is about making a handful of decisions before they get expensive, at the point where they still cost nothing. ## This year it moved from optional to required The GDPR has said since 2018, in Article 25, that you must arrange data protection by design and by default. In practice that often stayed a paragraph in a processing agreement. That changed inside five weeks. On **15 August 2026** the Dutch Cyberbeveiligingswet came into force, the national implementation of NIS2. Around eight thousand organisations fall under it. They have to register with the national cyber security centre, run a risk analysis and take proportionate measures based on it, and report incidents to the CSIRT within twenty-four hours. One detail matters in the boardroom: the board approves those measures and supervises their implementation. That duty cannot be delegated away. On **11 September 2026** the reporting obligations under the EU Cyber Resilience Act took effect for manufacturers of products with digital elements. Actively exploited vulnerabilities and severe incidents have to be reported: an early warning within twenty-four hours, a full notification within seventy-two, and a final report within fourteen days of a fix being available. It runs through the Single Reporting Platform to the CSIRT and is shared with ENISA. If neither applies to you, you are still not clear of it. Your customers do fall under them, and whatever they have to demonstrate gets pushed down into their contracts. It reaches you either way. ## What twenty-four hours actually means That one deadline deserves a moment, because it reads like an administrative requirement when it is a technical one. To report within a day that you are being actively exploited, you have to be able to see it. That means logging you can search, some sense of what normal traffic looks like, and somebody looking. Most organisations reading this discover a breach because a customer rings up, or because spam suddenly starts leaving their domain. Audit logging has therefore moved from something you add later to something the law effectively requires. Not “we log everything” into a file nobody ever opens, but logging that answers one question: who saw or changed what, and when. ## Privacy by design, concretely Set the law aside for a moment. This is what it means when you are designing a system. - **Data minimisation is the cheapest security control there is.** A field you do not collect cannot leak, does not need encrypting, is not in your backup and does not resurface in a subject access request. Ask of every field: what breaks if we do not have this? - **Retention periods belong in code, not in policy.** A retention period in a Word document is not a retention period. A scheduled job that actually deletes is. - **Pseudonymising is not anonymising.** Replace a name with an id but keep the key, and you still hold personal data with every obligation intact. That distinction gets blurred in exactly the conversations where it matters. - **Purpose limitation visible in your data model.** What you need to deliver is separate from what you keep in order to sell. Put them in the same table and you cannot withdraw one without the other when somebody objects. - **Access to production data is a design decision.** Who on your team can run a query against customer records, and is that recorded anywhere? ## Security by design, concretely - **Threat model before the schema is fixed.** An hour with the team at a whiteboard and four questions: what are we protecting, who wants in, how would they get in, and would we notice. That hour is priceless in hindsight. - **Closed by default.** New endpoints, buckets and ports start shut and get opened deliberately. The other way round, somebody always forgets. - **Least privilege, machines included.** Most applications talk to the database as one all-powerful account. That is comfortable while building and it is precisely what an attacker needs. - **Keys with a lifecycle.** Not in the repository, rotatable, and owned by someone. A token with no expiry is a debt you only see when it goes off. - **Assume one layer fails.** That is the whole point of defence in depth: not that every wall holds, but that there is a second one. - **Know what is inside your software.** A current list of your dependencies is the only way to answer, within a day of the next Log4j-style disclosure, whether you are affected. ## Why doing it up front is so much cheaper Up front, these are conversations. Half an hour about which fields you store, an hour on your threat model, a decision about permissions nobody has run into yet. Afterwards they are data migrations, with everything that comes attached: backups to carry along, customers to inform, a supplier who also has it sitting in their system. And with personal data something else arrives that technology does not solve. Data you should never have collected can be deleted, but you cannot undo the fact that it was there. ## How to set this up without building a programme You do not need a security department for this. You need a few fixed moments where the question gets asked. For every new component: which data does this touch, how long do we keep it, and who can reach it. Before a schema is locked: an hour of threat modelling. In your pipeline: a scan for keys left behind in the code. And once a quarter, the question of whether you would genuinely make that twenty-four hour deadline with the logging you have today. That is it. No certification programme, no thick document nobody reads. ## Want to know where you stand? In forty-five minutes we will walk through how your system sits on these points and tell you honestly what we see. If it is in good shape, you will hear that too. [Book a 45-minute call](https://calendly.com/3-bird/45min) or email [contact@3bird.nl](mailto:contact@3bird.nl). ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) --- Book a free 30-minute consultation: https://calendly.com/3-bird/3bird-oscar-30-minuten-meet Email: contact@3bird.nl | Phone: +31757993038