Data protection should never be an afterthought tacked on at the end of a project. It needs to be part of the design from day one, especially if your app, web app, or website handles any kind of sensitive data about real people.

Data protection by design, not as a patch

When you bolt security and privacy on at the end, you’re not really protecting data – you’re just trying to paper over cracks. True data protection by design means:

• You know what data you collect and why.
• You minimise data from the start (only collect what you truly need).
• You plan how it is stored, who can see it, and when it is deleted.

In every project I work on – whether it’s an app, a web app, or a website – I design the system with data protection and legal compliance as core requirements, not optional extras. That way, businesses can deal with their customers and their data with confidence, instead of hoping nothing ever goes wrong.

Retention, access, and control

Good data protection isn’t just “we keep it safe”. It also means having clear answers to basic questions:

• How long is data stored? Every system should have an explicit data retention policy. Customer data should not live forever “just in case”. Some records must be kept for legal or tax reasons for a set number of years, others should be deleted as soon as they’re no longer needed.
• Who can see what? Role‑based access is essential. Staff should only see the data they genuinely need for their role – nothing more. Admins, customer service, finance, and external contractors should all have clearly separated permissions.
• Can users see and delete their data? Under GDPR and similar laws, users usually have the right to access their data, correct it, and sometimes request deletion. Your system should be designed so this isn’t a manual nightmare but a predictable, auditable process.

This is not just good practice; it protects the business. If you can show that you know exactly what you store, why, for how long, and who has access to it, you’re in a much stronger position if something goes wrong.

Legal compliance is not optional

If you operate in the UK or EU, GDPR is non‑negotiable. But many businesses now have customers across multiple regions, which means you might also need to consider:

• UK GDPR and Data Protection Act.
• EU GDPR.
• Other regional privacy laws (for example, if you have customers in different countries outside Europe).

From the design stage, I always consider:

• What laws apply based on where the business operates and where its customers are.
• What the lawful basis is for processing each type of data (consent, contract, legal obligation, etc.).
• Who the data controller is and whether a Data Protection Officer (DPO) is required.

If a business needs a DPO, that person must be clearly identified, and their role and responsibilities should be supported by the systems we build – not undermined by them.

Practical tips to bake privacy and security into the design

Here are some practical, design‑stage considerations that make a real difference:

• Data minimisation. Do you really need date of birth, address, phone number, and national insurance number – or are you collecting it out of habit? Less data means less to protect.
• Segmentation and separation. Store the most sensitive data separately, with extra protections, not in the same database table as everything else.
• Access control by design. Build roles and permissions into the architecture from the start rather than adding them later when it’s already messy.
• Logging and audit trails. Keep track of who accessed what and when – this is crucial for both security investigations and compliance.
• Encryption in transit and at rest. Use HTTPS everywhere and appropriate encryption for sensitive fields in the database.
• Backups with brains. Backups need to be encrypted, regularly rotated, and subject to retention rules as well – not forgotten archives that quietly become a massive liability.
• Data deletion workflows. Make sure “delete” really means delete according to policy (or properly anonymise the data) and that it’s consistent across all systems and backups.

Reducing damage even if something goes wrong

No system is perfect. Even the biggest companies in the world get attacked and sometimes breached. The goal is not just to prevent every possible attack (which is unrealistic), but to limit the damage if something does happen.

That’s where good design and hygiene matter:

• Retention limits exposure. If you only keep data for as long as necessary, there is less for an attacker to steal. If you’ve been storing everything for 20 years “just because”, a single breach can expose your entire business history.
• Proper file permissions (chmod) and separation. Sensitive files and directories should have strict permissions and not be readable by processes that don’t need them. Even if the public‑facing site is compromised, well‑designed permission management can prevent an attacker from reaching internal data stores.
• Separate environments. Don’t mix development, staging, and production data casually. Live customer data should not be floating around on test servers or developer laptops.

You absolutely do not want to be the business that gets hacked once and suddenly all customer data from the past 20 years is out there in the wild – including people who haven’t dealt with you in over a decade.

Even the big players get it wrong

It’s easy to think, “We’re too small for anyone to care.” But attackers often target smaller businesses precisely because they expect weaker protections.

Even giants like Apple have had security gaps exposed over time – for example, issues where systems didn’t properly limit repeated attempts (like multiple password or code guesses) because a simple check was overlooked. That wasn’t about bad technology overall, but about a small, missed detail in one part of the design.

If a company with huge security teams can miss something like that, it shows how careful smaller businesses need to be. The difference is that you can’t afford the reputational and financial hit in the same way they can.

Food for thought for your next project

If you’re planning a new website, app, or internal system that touches customer data, ask yourself – at the design stage:

• What exactly are we collecting, and why?
• How long do we need to keep each type of data?
• Who in the organisation needs to see what?
• How can users see, correct, and (where appropriate) delete their data?
• What happens if this system is compromised tomorrow – what would an attacker actually get?

If you can’t answer those questions confidently today, now is the right time to fix that – not after an incident.

Every project I build is designed from the ground up with data protection and compliance in mind, so that businesses can focus on serving their customers instead of worrying about what might happen if something leaks. If you’d like to review how your current systems handle data – or want to build something new the right way from the start – get in touch – I’m happy to help.