The data protection decisions in an internal system are made in the schema
An internal system holding personal data has its position decided in the schema rather than in a policy, which fields exist, what is logged, what is deleted and when, and whether a subject access request can be answered without an engineer writing a query are all build decisions, and they are expensive to add afterwards.
Most internal tools collect everything available, because collecting is easy and deciding is work. Then a request arrives, somebody wants to know what is held about them, or wants it removed, and answering needs a developer to go looking. That is where a great many British organisations sit, and it began when the tables were designed.
Picture a system that has been running for some years. It holds every record ever created, because there was no deletion routine and nobody wanted to be the person removing things. It logs that rows changed, but not who changed them or what the value was before. Contact details for people who left the process long ago sit beside live ones with nothing to distinguish them. When a subject access request arrives, somebody writes queries across half a dozen tables and hopes they found everything. Each decision was reasonable at the time, and together they produced a system that cannot answer a simple question about itself.
When this work makes sense
Questions worth asking any supplier
Ask what the schema deliberately does not collect, because a design capturing every available field has not had the conversation and somebody will have to have it later.
Ask whether audit trails record who acted and what the value was before, because knowing that a record was updated answers nothing when it matters.
Ask where retention actually lives, because a policy in a document and a deletion routine in the system are different things and only one of them runs.
Ask how a subject access request will be answered, because if the answer involves an engineer, the process depends on one person being available and thorough.
Ask what happens when a record must be deleted but is referenced elsewhere, because that case is common and the design needs an answer other than leaving it.
Deliverables
A data model where every personal field has a stated reason to exist, and fields without one are not built
Retention rules implemented as routines that run, with a record of what they removed
Audit trails capturing who acted, when, and what the value was beforehand
An export that assembles everything held about one person across the system, runnable by a non-developer
A deletion path handling referenced records without breaking the system or leaving fragments behind
Role-based access set at field level wherever a role has no business seeing a whole record
Documentation of what the system processes, in a form your data protection adviser can work from
Built with
Process
Before any modelling, we go through the fields the current process collects and ask what each one is for. This is a design exercise rather than a compliance one, and it is uncomfortable, because the honest answer for several fields is that somebody added them once. Every field removed is a field that never needs securing, retaining, exporting or deleting. What remains has a reason attached, which makes the retention rules obvious and the access levels easy to argue for.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Three ways to answer a subject access request
A developer writes queries when one arrives
Fits: Nobody, although it is where most organisations actually are
Limits: Depends on one person's availability and memory of the schema, with no way to show the answer was complete
A built export any authorised person can run
Fits: Systems holding personal data on any meaningful number of people
Limits: Has to be maintained as the schema changes, or it silently stops covering newly added tables
Hold so little that the answer is short
Fits: Systems that can genuinely operate on minimal data, which is more of them than assumed
Limits: Requires refusing fields people want, and some of those requests will be perfectly reasonable
Case studies
Nothing has been published. There is no client work we can show for this service, because internal systems are rarely something a client wishes to discuss publicly and none has agreed to be named. Our London office is at 37th Floor, 1 Canada Square, Canary Wharf, London E14 5AA, and enquiries reach us at uk@mbgdesk.com. Client work will be published only with permission.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
What does data minimisation mean in practice?
Deciding field by field why something is collected, and not building the ones with no answer. In practice it is a conversation with the people who use the system, in which several fields turn out to exist because a paper form once had them. Each removed field never has to be secured, retained, exported or deleted.
Can you tell us how long to keep data?
No. Retention periods depend on what the data is, what it was collected for, and what applies to your sector, and that judgement belongs to your own data protection or legal adviser. What we do is make their decision enforceable: rules per record type, routines that genuinely run, and a log of what was removed.
Why do audit trails need before-and-after values?
Because knowing a record was updated tells you nothing at the moment you need it. When a figure is disputed, a decision questioned or an access concern raised, the useful question is what it was, what it became, and who did it. Recording only that a change occurred is the default, and it is the useless version.
What if a record must be deleted but others point to it?
This is the case that catches systems built without it in mind, and it needs a designed answer. Sometimes the dependent record is kept with the personal data stripped out. Sometimes deletion cascades. Sometimes an obligation to retain the transaction overrides the request, which is a judgement for your adviser rather than for us.
Should this be built or bought?
Buy where a product genuinely fits, and we will say so rather than build something that already exists. Bespoke earns its cost where the process is unusual, where an off-the-shelf tool would hold far more data than you need, or where the integrations are the actual work.
Where will our data be hosted?
Wherever your requirements need, decided deliberately rather than inherited from a default region. Systems can be hosted in the United Kingdom or the European Union as your position requires. Most of our engineering is done from our head office in Hyderabad, and access arrangements are agreed before work starts.
We already have a policy. Is that not enough?
A policy describes intent; the system determines what happens. If the policy says records are removed after a period and nothing removes them, the records are still there, and that gap is what an examination finds. The useful work is turning each statement into something that runs.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.