Is your app GDPR compliant? This is your responsibility

There’s a misconception that costs app buyers dearly: that GDPR is the developer’s problem. It’s not. Whoever owns the app and decides what it does with users’ data is the data controller, regardless of who wrote the code. The agency is your processor, not your liability insurance. Here’s what that responsibility means in practice, from design to operations.

Data minimization and legal basis – per feature, not per app

GDPR work doesn’t start with a policy, it starts with the feature list. For every feature in the app, two questions need an answer:

• What personal data does the feature need, at minimum? Data minimization means not collecting “nice to have” data. Does registration really need a national ID number, or is an email address enough? Does the map feature need continuous location history, or just position while in use?
• On what legal basis? Core features usually rest on the contract with the user. Marketing and tracking normally require consent. Internal statistics can rest on legitimate interest, if the balancing test has been done and documented.

Do this as a simple table in the requirements specification: feature, data, basis, retention period. The exercise takes an afternoon and forces the decisions while they’re still cheap. That same table then becomes the backbone of your record of processing activities and the information you give users. A vendor handed a table like that will also build it right from the start, the requirements spec is the right place for data protection, not the final inspection.

Third-party SDKs: the most common trap

The biggest GDPR risk in modern apps is rarely your own code, it’s the ready-made building blocks. Analytics tools, crash reporting, push notifications, ad networks, and login services ship as SDKs baked into the app, and several of them start collecting data the same second the app launches: device ID, IP address, behavioral data.

That makes you responsible for data flows you might not even know about. Here’s how to take control:

1. Inventory. Require a list of every third-party SDK in the app, noting what data each one collects and where it’s sent. Update the list at every major release.
2. Question. Every SDK should be justified by a need, not stay just because “that’s usually how it’s done.” Fewer dependencies is also better engineering.
3. Check transfers. If data leaves the EU/EEA, a valid transfer basis is required. EU-hosted alternatives reduce both risk and paperwork.
4. Sync with consent. Tracking SDKs must not activate until the user has said yes. A common mistake is that the consent banner exists but the SDKs have already started sending data, something that’s easy to spot in a network analysis and looks bad under regulatory review.

The app stores now have their own declaration requirements for data collection, so the inventory needs doing anyway, do it properly once instead of sloppily twice.

User rights: build them, don’t just promise them

The right to deletion, data access, and withdrawing consent isn’t policy text, it’s functionality that should be designed and tested like everything else:

• Deletion. What actually happens when a user deletes their account? The data should be removed from the production database, copies, and third-party services, with defined exceptions (e.g., accounting data under bookkeeping law) and documented retention periods. “We deactivate the account” is not deletion.
• Data access requests. A user has the right to receive their data. Manual handling works at low volume but should exist as a documented procedure: who does what, within what time frame (one month is the main rule).
• Consent management. Consent should be as easy to withdraw as to give, and the choice should be changeable inside the app, not require an email to support.

A concrete scenario: a user emails “delete everything you have on me.” Without preparation, that becomes a week of detective work across databases, backups, analytics tools, and push services. With a deletion flow built in from the start, it’s a button press and a confirmation email. The difference is design decisions that cost a few hours in the requirements phase.

GDPR as a quality requirement, not a brake

Handled right, data protection isn’t something that slows the app down, it’s the same discipline as good architecture: knowing what data exists, why, where it flows, and how it gets removed. At Weapp we build apps with that mindset from the first sketch and are happy to help review the requirements from a data protection angle before the build starts, get in touch and we’ll set up a conversation.