GDPR and software builds in 2026: the questions your agency clients are starting to ask

TL;DR

• Agency clients are no longer accepting a privacy policy and a verbal assurance that data is handled properly 
• They want technical evidence showing where data sits, who can access it and what happens when someone requests deletion 
• Agencies that cannot answer with specifics are losing trust before the project conversation begins

A client mentions their compliance team has asked for evidence of how user data is handled in a platform the agency built for them.. Not a policy question. A technical one. They want to know where the data physically sits, who can access it and what actually happens in the system when a user asks for their data to be deleted.

Three years ago, this level of specificity was rare in agency-client relationships. In 2026, it is becoming standard. The conversation has shifted from "Do you have a privacy policy?" to "Show me the architecture." And many agencies are finding they cannot answer the second version.

Why the pressure is landing on agencies now

The legal obligations have not changed dramatically since 2018. What has changed is who is asking the questions and how specific those questions have become.

Enterprise clients and regulated industries have tightened their procurement processes. When they commission an agency to build a platform or digital product, they increasingly expect evidence that the build itself meets GDPR software development requirements. Not a checkbox exercise. Documented architectural decisions that show how data protection was considered from the start.

This pressure flows downhill. The client's compliance team asks the client. The client asks the agency. The agency turns to whoever built it and finds the answer is not documented anywhere.

We built a safety compliance platform handling personal data across multiple construction organisations simultaneously. The client needed to demonstrate to their own customers that data was isolated between organisations, that access was role-based and that every interaction left an audit trail. They were not afterthought requirements. They were the reason the platform needed to exist in the first place.

The four questions that surface in every conversation

These are not legal questions. They are architectural decisions that should be made during the build. If they were not made deliberately, they were made by default, and the default is rarely compliant.

Where is the data physically stored? If the platform runs on cloud infrastructure, the data could be sitting in whichever region the provider defaults to. Agency clients in regulated industries increasingly require UK or EEA data residency. On the safety compliance platform referenced above, data residency was specified in the infrastructure configuration before the first deployment. Not assumed. Configured.

Who can see what? A platform where every admin user has access to every piece of customer data is a liability. Role-based access controls that limit visibility to what each user role actually needs are not a feature request. They are a baseline expectation. On multi-tenant platforms, this becomes critical. An administrator in one organisation should never be able to see data belonging to another.

What actually happens when a user requests deletion? If the answer involves a manual process where someone runs a database query and hopes they have found everything, that is not compliant. Erasure needs to be built into the application logic so it is consistent, complete and auditable every time it runs.

Are processing agreements documented across the supply chain? The agency and any development partner involved in the build need clear data processing agreements defining who is responsible for what. If freelancers or a third-party team were involved and no processing agreement exists, the client has a gap in their compliance chain that will surface during an audit.

What "baked in" looks like versus bolted on

The difference between GDPR handled properly and GDPR retrofitted afterwards is visible in how confidently the agency can answer these questions.

Baked in means data residency was specified before the first deployment. Access controls were part of the user role design. The right to erasure was considered during the data model design, so deletion is a function of the application rather than a manual database task. 

Bolted on means someone reviewed the platform after it was built and wrote a policy document describing how data should be handled, without checking whether the platform actually handles it that way.

The first version survives a client audit. The second version creates a conversation no agency wants to have.

What this means for agencies choosing a development partner

The development partner an agency works with directly affects whether these questions can be answered with confidence. A partner who treats GDPR as an architectural discipline from the start produces a platform that can evidence compliance. A partner who treats it as someone else's concern produces one who cannot.

When evaluating a development partner, it is worth asking three things specifically: how data residency is handled in their standard infrastructure setup; how role-based access controls are implemented in a multi-tenant environment; and what happens technically when a right to erasure request comes in.

The answers reveal whether the partner builds with compliance as a design principle or as a problem to deal with later.

How Aecor helps

We build GDPR compliance into the architecture from the first conversation. Data residency, access controls, erasure logic and processing documentation are part of how we set up every project, not features added at the end. 

If your agency clients are starting to ask harder questions about how the platforms you deliver handle their users' data, a free 60-minute technical discovery call is a good place to start.

Book your free Technical Discovery Call → aecordigital.com

See how we built privacy by design into a multi-tenant safety compliance platform → Realsafe case study