Skip to content

Data Protection by Design

Data protection built into the software, not bolted on before launch

GDPR names principles, not features. We translate them into the standard controls every compliant system needs, classification, access control, encryption, audit, subject rights, and retention, designed in from the first sprint and enforced by tests. The result is data protection an auditor, an insurer, or a regulator can verify.

Why compliance so often fails in software

Data protection fails less on policy than on engineering. These are the gaps we see most, and the ones designing in from the start prevents.

Compliance bolted on at the end

Data protection added before launch is weaker and full of gaps. Access control hidden in the interface, deletion that was never tested, and a classification spreadsheet that stopped matching the code a year ago.

Sensitive data nobody has mapped

Most systems cannot answer a simple question: which columns hold personal, special-category, or children's data. Without that map, minimisation, masking, retention, and breach response are all guesswork.

Subject rights handled by hand

Access requests and erasure run as ad-hoc database queries when someone is free. Statutory deadlines turn routine requests into fire drills, and manual erasure quietly leaves personal data behind.

Growth across borders

A platform built for one country meets data residency, breach routing, and local consent rules the moment it crosses a border, and forks into per-country variants that drift apart.

The standard controls, designed in

A defined set of features that turn the GDPR principles into working software, grounded in real production experience building systems that hold personal, special-category, and children's data.

Machine-readable data classification

We classify every sensitive column by tier and overlay, expressed in the database and the code from one taxonomy, and held in lockstep by a test that fails the build if they drift. Classification that drives real controls, not a spreadsheet.

Deny-by-default access control

Access granted only on an explicit permission check, scoped to an organisational boundary, and enforced on the server so no client, export, or integration can bypass it. Sensitive fields are masked by role, not just hidden in the UI.

Encryption and secrets management

TLS pinned in transit, encryption at rest, and secrets held in a managed key vault rather than source or the database. Card data is delegated to tokenising providers so it never enters the system at all.

Immutable audit and accountability

Every change to personal data carries a who, a when, and a why, in an audit trail built to be immutable by construction. Accountability you can demonstrate to an auditor from data, not from memory.

Subject rights, retention and erasure

Permission-gated data exports, authorised editing with audit, and a retention engine that enforces storage limits per data class and jurisdiction. Erasure that removes personal data while preserving the audit trail.

Multi-jurisdiction by design

Residency treated as deployment topology so each region stays self-contained, and jurisdiction modelled as data so one codebase serves many privacy regimes without forking. UK GDPR grade, extended internationally.

From data map to demonstrable compliance

A sequence that puts classification first and makes protection a definition-of-done constraint, accelerated by AI-augmented delivery.

1-2 weeks

Assess and classify

We map the personal data the system holds and assign a sensitivity tier and handling overlays to every field. You get a data classification inventory and a prioritised view of where the highest-risk data lives, before any controls are designed. This is the foundation everything else stands on.

1-2 weeks

Design the controls

We design the control set against the GDPR principles as build constraints: access model, masking, encryption and secrets, audit, consent and suppression, subject rights, and retention. Where the platform crosses borders, we design residency topology and jurisdiction handling in from the start.

Build and enforce

We build the controls into the architecture and back them with tests that fail the build when protection is missed: classification coverage, retention coverage, and permission parity. Data protection becomes a definition-of-done constraint, not a review at the end.

Verify and demonstrate

We verify the controls, obfuscate non-production data, and give you the artefacts that prove compliance: the classification register, the audit trail, and the subject-rights and retention tooling. The result is a system that can be asked hard questions and answer them from data.

Seen enough? Let's talk through your requirements.

Book a free consultation

Frequently asked questions

What is data protection by design?

Data protection by design is the UK GDPR Article 25 requirement to build data protection into a system's architecture from the outset, rather than adding it after the fact. In engineering terms it is a defined set of features: data classification, deny-by-default access control, encryption, an immutable audit trail, consent and suppression, subject-rights tooling, and retention and erasure. We build these as constraints enforced in code and tests, not a checklist reviewed before launch.

Can you add data protection to an existing system?

Yes, though it is harder than designing it in. Some controls retrofit well, such as encryption at rest, transport hardening, and audit logging. Others are structurally harder to add late, including field-level classification, deny-by-default scoping, and crypto-shredding erasure. We start by classifying the data, then close the highest-risk gaps in priority order, so you get the biggest compliance improvement first.

How does this relate to your ISO 27001 and Cyber Essentials Plus certifications?

They reinforce each other. Our ISO 27001 information security management system and Cyber Essentials Plus accreditation provide the security foundation that data protection by design stands on. Neither proves GDPR compliance on its own, because they do not require data minimisation, consent, or subject rights. We treat the certifications and the data-specific controls as one programme.

Can one platform comply with multiple countries' privacy laws?

Yes, if it is designed for it. The core controls GDPR requires are near-universal across modern privacy regimes, so a GDPR-grade baseline satisfies most of what other laws ask. What varies is data residency, breach routing, and specific consent rules. We treat residency as deployment topology and jurisdiction as a first-class attribute, so one codebase serves many regimes. See our multi-jurisdiction data protection guide.

What is data classification and why does it come first?

Data classification is labelling every field by how sensitive it is and why, in a form the system can act on. It comes first because you cannot minimise, mask, encrypt, retain, or erase data consistently if the system does not know which columns are sensitive. We make classification machine-readable and enforced by a test, so it drives real controls. Our data classification guide covers the technical detail.

Is data protection by design a legal requirement?

Yes. Article 25 of the UK GDPR makes data protection by design and by default a legal obligation for data controllers, and the Information Commissioner's Office expects it. It is also sound engineering, because retrofitting access control, audit, and erasure into a live system is far more expensive and error-prone than designing them in. The legal requirement and the economics point the same way.

Building something that holds personal data?

Tell us about your system. We will map the data, propose the controls, and design data protection in from the first sprint.

Book a free consultation

or call 01202 006729