If your app handles personal data of people in the UK, you are generally responsible for meeting UK GDPR and the Data Protection Act 2018, even when an outsourced team builds and runs the software. Outsourcing the build does not outsource the responsibility. This checklist covers the main points to settle with your team. It is general information, not legal advice, so take advice from a qualified professional on your own situation.
Decide who is responsible for what
Start by working out roles. In most app projects, the business commissioning the app decides why and how personal data is used, which generally makes it the controller. A development or hosting vendor that processes data on your instructions is generally a processor. The roles can be less obvious in some setups, so confirm them rather than assuming.
Where a processor is involved, the rules generally expect a written contract setting out what they may do with the data and what security they must maintain. Ask any vendor, including us, whether they will agree to appropriate data processing terms and which sub-processors they use.
Map the data before you build
List every piece of personal data the app will collect, why you need it, where it is stored and who can see it. Include the less obvious items: device identifiers, location, push notification tokens, analytics events and crash reports. Collect only what you need, because every extra field is extra risk and extra paperwork.
Then choose and record a lawful basis for each purpose, and write privacy information that is clear and easy to find in the app and in the store listing. Consent that is bundled, hidden or pre-ticked is a common weakness.
Build security and privacy in
Ask the team how they will protect the data. Sensible questions cover encryption in transit and at rest, role-based access so staff see only what they need, separate staging and production environments, code review on every change and logging of access to sensitive records. Ask that real personal data is not used in development and testing where realistic test data will do.
Ask about third-party software development kits inside the app. Analytics, advertising and crash reporting tools can send personal data to other companies, so each one needs a reason to be there and a place in your privacy information.
Plan for rights, breaches and international transfers
People have rights over their data, including access, correction and deletion in many cases. Make sure the product can actually do this: a way to export a user's data, a way to delete an account and its data, and a process for handling requests within the deadlines the rules set.
Agree a breach process in advance. Who tells whom, how quickly, and who decides whether the regulator must be notified? Some breaches must be reported within a short window, so a plan written in advance is far better than one invented during the incident.
If the team, the servers or any sub-processor sit outside the UK, ask where personal data will be stored and accessed. Transfers to other countries generally need a recognised safeguard or mechanism, and your adviser should review this before launch.
Contract and handover
Finally, write it down. Agree who owns the source code, who holds the app store and cloud accounts, what happens to the data when the contract ends, and what support you get after launch. Our fixed-scope plan includes full source and infrastructure handover and a 30-day post-launch fix window, and a focused MVP is typically an 8-14 week build.
Get your lawyer or data protection adviser to review the processing terms before work starts. A short review at the start costs far less than fixing the design later.
Building something in this space? We've probably shipped it before.
Talk to an engineer