Bespoke Software for Regulated Industries: GDPR, ISO 27001 and HIPAA-Grade Builds

If your business handles health records, children's data, financial information, or anything else a regulator cares about, off-the-shelf software often fails for a simple reason: it was built for the average customer, and the average customer isn't regulated the way you are. Bespoke software can fit your obligations exactly. It can also go badly wrong if the team building it treats compliance as paperwork to finish at the end.

This guide covers what a bespoke build for a regulated UK organisation actually needs, which parts a development partner can genuinely deliver, and which parts they can't. It draws on two platforms we built where the data was about as sensitive as data gets: children's special educational needs records in UK schools, and clinical research data in the US.

The honest line: engineering controls vs certification

Start with the distinction most agencies blur.

A development partner can build the technical controls that regulations and standards require: access control, encryption, audit trails, data minimisation, secure development practices, and the evidence that those controls exist.

A development partner cannot certify you. ISO 27001 certification comes from an accredited certification body auditing your organisation's information security management system. UK GDPR compliance is your organisation's responsibility as data controller. HIPAA compliance for a US covered entity involves policies, agreements, and administrative safeguards well beyond the code.

So the useful question for any agency is not "are you compliant?" It is "which controls will you build, how will you evidence them, and what will you hand to our compliance lead or auditor?" If an agency claims to make you compliant or certified, treat that as a warning sign.

For clarity about us: Teamseven builds secure, compliance-ready software. We are not ISO 27001 certified ourselves, we do not issue certifications, and we do not perform certified penetration tests. We work alongside the people who do.

The controls that matter in a regulated build

Whatever the regulation, most requirements come down to the same engineering building blocks.

Access control enforced at the data layer

Users should see only the data their role requires. The important detail is where that rule is enforced. Hiding a button in the interface is not access control; the API and database queries must refuse the data too. On COMPASS, the clinical research platform we built for Ball State University, role-based access is enforced at the query layer: a clinician's session cannot retrieve aggregate study data even with a hand-crafted API call, and a family account can only read records tagged to its own participant.

Encryption in transit and at rest

TLS for everything in transit, and encryption for stored data, with key management that someone has actually thought about. On E2P+SEND, the UK early-years and SEND platform we built, children's medical and care information is protected with automated encryption at rest and deliberate key rotation.

Audit trails by construction

Regulated processes need evidence of who did what, and when. That record should be produced automatically by the system, not assembled by hand before an inspection. E2P+SEND replaced SEND workflows run over email threads and paper with structured, multi-stage review workflows that create the audit history as a side effect of doing the work.

Data minimisation and retention

Collect only what the purpose requires, keep it only as long as necessary, and make deletion real. Under UK GDPR, right-to-erasure and retention rules need workflows in the software, not just a policy document.

Secure development practice

Code reviewed against the OWASP Top 10, dependencies scanned and patched, secrets kept out of the codebase, and separate environments so development never touches real personal data. Development and staging should use synthetic or anonymised data.

How this maps to the frameworks UK organisations ask about

The pattern is the same each time: the software carries the technical load, your organisation owns the policies, the certification, and the accountability.

Two regulated builds we delivered

E2P+SEND: UK schools and children's SEND data

E2P+SEND is an early-years-to-primary assessment and SEND management platform built for UK schools. It holds some of the most sensitive data a UK organisation can hold: children's development records, medical and care information, and EHCP review evidence. The users range from classroom teachers to SENCOs with statutory obligations to external professionals who need access to specific children only.

What that required in practice: a role-based permission system that reshapes the product for each role, encryption at rest with key rotation, a compliance posture built to UK GDPR and the Data Protection Act from the schema up, and structured SEND workflows with the audit history Ofsted readiness depends on. It was built on .NET with MSSQL.

COMPASS: clinical research data under HIPAA principles

COMPASS is a clinical research platform we built for autism researchers at Ball State University. Before any participant was enrolled, the study's ethics review (IRB) required evidence that data collection met specific security and consent standards, so the first design conversation was with the IRB coordinator, not a developer. The platform was built with HIPAA access-control principles from day one: query-layer role enforcement, de-identified data by default for researchers, encryption at rest, TLS in transit, and daily backups with point-in-time recovery. We wrote up the engineering in detail in HIPAA access controls, explained for engineering teams.

What to ask any agency before a regulated build

1. Where is access control enforced? "In the UI" is the wrong answer.
2. Will you sign a Data Processing Agreement? For UK personal data, this should be automatic.
3. What data will your developers see? The right answer is synthetic or anonymised data in development.
4. How is encryption and key management handled?
5. What evidence will you hand over for our auditor or compliance lead?
6. What will you not do? An honest agency will tell you it doesn't certify, and doesn't replace your penetration tester or compliance adviser.

Why retrofitting costs more

The strongest financial argument for building compliance in from the start: retrofitting it is dramatically more expensive. A permissions model bolted onto a system designed on the assumption that "everyone with a login sees everything" usually means rewriting the data access layer, not adding a check. If you are commissioning a regulated build, the access and data model should be designed before the first screen.

That is how we approach bespoke software development UK projects with sensitive data, and it is the core of our secure software development practice.

FAQ

Can bespoke software be ISO 27001 compliant? Software itself isn't certified; organisations are. A bespoke system can be built with the technical controls and evidence that support your ISO 27001 certification, such as access control, cryptography, logging, and secure development. Certification comes from an accredited body auditing your organisation.

Is offshore development allowed for UK GDPR data? Yes, with the right safeguards: a Data Processing Agreement, an appropriate international transfer mechanism, and development environments that use synthetic or anonymised data instead of real personal data.

Do you perform penetration testing? No. Certified penetration testing is a specialist discipline. We build securely, review code against the OWASP Top 10, and can help you prepare for a penetration test by a specialist firm.

Can you work with NHS or public-sector data? We have built platforms holding sensitive health and children's data, but NHS and public-sector work often carries specific assurance requirements, such as the Data Security and Protection Toolkit. We'd scope those honestly on a call rather than assume.

Is a regulated build much more expensive? It costs more than an unregulated one because access control, encryption, and audit work are real engineering. It costs far less than retrofitting those controls later, or the consequences of a breach.

---

Muhammad Nabeel is the co-founder of Teamseven. We built E2P+SEND for UK schools and COMPASS for Ball State University. If you're scoping software that will hold sensitive data, book a free 30-minute call and we'll start with the access and data model.

Related reading

• Bespoke software development UK: what it means →
• HIPAA access controls, explained for engineering teams →
• Client-side vs server-side encryption for patient data →
• Bespoke software development UK services →