GDPR privacy by design applies to a mobile app whenever the service behind it processes personal data within the regulation’s scope, and it applies whoever wrote the code. Article 25 places the duty on the controller: the organisation that decides why and how the data is processed. Hiring an agency or buying a white-label app does not move that duty. In practice, it means each data flow in the app has a purpose, a protective default and evidence that the release behaves as designed. This article gives an engineering view of that work; your legal reviewer decides scope, roles and lawful basis.
Who is responsible when someone else writes the code
GDPR is about processing, not programming. The question is not who typed the code, but who decides what personal data the app collects and why. That organisation is the controller, and Article 25 applies to it “both at the time of the determination of the means for processing and at the time of the processing itself”.
Recital 78 speaks to app makers directly. It says producers of products, services and applications should be encouraged to take data protection into account when developing and designing them, so that controllers and processors can meet their obligations. The supplier is encouraged; the controller is obliged.
Article 28 adds a second link. Where a supplier processes personal data on the controller’s behalf, for example by running the app’s backend or support tools, the controller may use only processors that give sufficient assurance that they will implement appropriate technical and organisational measures. An agency that only builds the app and never touches live data may not be a processor at all. Ask your legal reviewer to decide each role from the actual relationship.
- 27 April 2016
GDPR adopted
Regulation (EU) 2016/679, including Article 25 on data protection by design and by default.
- 25 May 2018
GDPR applies
The obligations take effect for controllers and processors.
- 20 October 2020
EDPB guidelines finalised
Final version of Guidelines 4/2019 on Article 25, with practical examples.
4 areas
By default: amount collected, extent of processing, storage period, accessibility
€10 million
Fine ceiling for Article 25 infringements, or 2 per cent of worldwide annual turnover for an undertaking if higher
What by design and by default mean in an app
Article 25(1) asks for appropriate technical and organisational measures, such as pseudonymisation, that implement the data-protection principles effectively. The measures must take account of the state of the art, the cost of implementation and the risks of the processing. Article 25(2) is narrower and more testable: by default, only the personal data necessary for each specific purpose is processed.
That default covers four things, and each maps to a decision your mobile team already makes.
| Article 25(2) area | Mobile decision | Evidence to keep |
|---|---|---|
| Amount collected | Which fields, permissions and SDK data a fresh install gathers | Data inventory and a first-launch network capture |
| Extent of processing | What the backend, analytics and SDKs do with each field | Purpose record per field and per recipient |
| Storage period | How long device caches, logs and server copies last | Retention settings and deletion tests |
| Accessibility | Who inside and outside the organisation can see the data | Access rules and processor arrangements |
The principles behind it sit in Article 5: purpose limitation, data minimisation, storage limitation, and integrity and confidentiality. The lawful basis for each purpose is a separate question under Article 6. A permission prompt is an operating-system access decision, not a lawful basis.
A feature statement
- The connection uses encryption.
- The app has runtime protection.
- There is a privacy setting.
A reviewable control statement
- This flow sends only the approved fields to the approved recipient.
- This threat test produced the expected response on this release.
- A fresh install and a later change both apply the documented choice.
Building evidence another reviewer can repeat
An evidence record links a requirement, an implementation and a test. Give each record an owner, the app build, the OS and framework versions, and the date. A screenshot of a setting does not show what the app transmitted.
Define the purpose
Record why the data is needed; legal review confirms the basis.
Set the default
Fix collection, recipients, retention and access before building.
Test the release
Compare observed behaviour with the design on Android and on iOS.
Review on change
Re-run when an SDK, permission or purpose changes.
Take an optional analytics flow as an example. Install the release build on a clean test device. Complete the core journey with the option off and capture the traffic. Turn the option on, repeat, and compare the fields and recipients with the inventory. Turn it off again, restart, and check that queued events are not sent under the old choice. Run the same steps on Android and on iOS, because a shared interface does not mean shared storage, permissions or background behaviour.
For the hands-on side of this work, tracing one data item through the app and testing changed choices, see better mobile privacy.
Where security controls fit
Article 32 requires security appropriate to the risk and a process for regularly testing and evaluating the effectiveness of the measures. App security belongs there. A modified app, a hooked process or intercepted traffic can expose exactly the data your Article 25 defaults were meant to limit.
Otukan Application Security provides code, runtime, data, network and API protection controls. Its signals describe the check that fired, not the content of user messages, contacts, files, keystrokes or form input, so the protection itself stays inside a minimal data design. For the control view, see data loss prevention.
Make the supplier handover testable
Whether the app is built in-house or outside, ask for evidence the receiving team can re-run, not a feature list.
- Legal scope and the controller and processor roles have a named reviewer.
- Each personal-data field has a purpose and necessity record.
- Defaults cover collection, processing, storage and access.
- Android and iOS tests name the release and OS versions they cover.
- Changed choices and interrupted transmissions have been tested.
- Security telemetry is listed in the data inventory.
- Technical findings and legal conclusions are recorded separately.
Further reading
- Regulation (EU) 2016/679 (General Data Protection Regulation) — EUR-Lex
- Guidelines 4/2019 on Article 25 Data Protection by Design and by Default — European Data Protection Board
- Minimize your permission requests — Android Developers
- User privacy and data use — Apple Developer