Customer data in your app: 15 questions to ask a contractor before you sign

Your customers' data ends up in someone else's code, on someone else's server and behind someone else's accounts. You are accountable for it, even when a contractor builds the app. You do not need to know IT to check this: 15 questions asked before you sign are enough.

Where the data is and who can reach it

Before the questions, look at the route data takes. A user types it into the app, it goes to the API, then to the database, and from there to a backup. At every step someone may have access that you should know about.

A good contractor can draw this diagram for your app and name the owner of each block. If they cannot, treat it as a first warning sign.

The route of data through an app and the people who can reach it.

We split the questions into three groups. Each one has three parts: why you ask, what a good answer looks like and what a bad one looks like.

Questions 1 to 5: hosting, encryption and access

1. In which country is our data physically stored?

Why you ask: the location decides which law protects the data and whether extra legal safeguards are needed when it leaves the European Economic Area.

Good answer: the provider's name and an EU region, written into the documentation and the contract.

Bad answer: "In the cloud, it makes no difference."

2. Is data encrypted in transit and in the database?

Why you ask: encryption makes an intercepted or stolen copy of the data useless without the key.

Good answer: HTTPS connections, an encrypted database and backups, with keys stored separately.

Bad answer: "We have a certificate on the website" (that covers one link in the chain).

3. Who has access to the production environment?

Why you ask: every person with production access is a possible leak path, including by mistake.

Good answer: a named list, least privilege and a regular review.

Bad answer: "The whole team shares one admin account."

4. Is multi-factor authentication (MFA) turned on?

Why you ask: one stolen password to the cloud, the code repository or the domain is enough to take over the whole app.

Good answer: MFA on the cloud, the code repository, DNS and the app store accounts, with no exceptions.

Bad answer: "Our passwords are strong."

5. Where do you keep passwords and API keys, and how often do you change them?

Why you ask: a key pasted into code or a chat tool is a very common cause of system takeovers.

Good answer: a secrets manager, rotation on a schedule and an immediate change when someone leaves the team.

Bad answer: "In a config file in the repository."

Questions 6 to 10: backups, logs and test data

6. How often do you take backups and where are they stored?

Why you ask: a backup on the same server as the database disappears together with it.

Good answer: automatic backups at a stated frequency, encrypted and stored in a separate place.

Bad answer: "We do it when someone remembers."

7. When did you last restore a backup as a test?

Why you ask: a backup nobody has restored is only an assumption. Only a trial shows whether the data comes back and how long it takes.

Good answer: the date of the last test, the measured restore time and the result, written in a report.

Bad answer: "We have backups, they surely work."

Each of the 15 questions works like this: the reason, a good answer and a warning sign.

8. What do you write to logs and who reads them?

Why you ask: logs help detect an attack and work out what happened, but they can become a leak themselves if they contain personal data.

Good answer: logs without personal data, an alert on an unusual number of failed logins and a defined retention time.

Bad answer: "We log everything, just in case."

9. Do you use real customer data in the test environment?

Why you ask: a test environment usually has weaker protection and a wider circle of people with access.

Good answer: synthetic or anonymised data, and security tests never run on production with customer data.

Bad answer: "We copy the production database, it is more convenient."

10. How long do you keep data and how do you delete it?

Why you ask: GDPR requires that data is not kept longer than needed. Deletion must also cover backups.

Good answer: written retention periods, automatic deletion and a description of when data leaves backups.

Bad answer: "Data stays until someone deletes it by hand."

Questions 11 to 15: contract, GDPR and the end of the relationship

11. Will we sign a data processing agreement?

Why you ask: if the contractor can reach your customers' personal data, GDPR requires such an agreement. Without it, you carry the risk.

Good answer: a ready template that you go through with a lawyer before work starts.

Bad answer: "We will add it later."

12. Which subcontractors and vendors can see our data?

Why you ask: hosting, email, analytics and AI tools are more companies processing data. Each should be on the list and have its own processing agreement.

Good answer: a current list of vendors with the purpose and location of each, and notice of changes.

Bad answer: "We use various tools."

13. What do you do when you suspect an incident and how fast do you tell us?

Why you ask: a data controller has a short statutory deadline to report a breach, so the contractor's response time is part of your responsibility.

Good answer: a described procedure, a contact person and a notification deadline written into the contract.

Bad answer: "Nothing has happened so far."

14. Who owns the code, the accounts and the data?

Why you ask: it decides whether you can change contractors without the previous one's consent.

Good answer: the code, designs, accounts and data are yours from day one, and the contract says so plainly.

Bad answer: "The code stays with us, you get a licence to use it."

15. What do I get when we end the cooperation?

Why you ask: after a split nobody is in a hurry to help, so the rules must be written before the start.

Good answer: a full data export, the repository, a run guide, handed-over access and confirmed deletion of data at the contractor.

Bad answer: "We will agree on that then."

What these answers look like at Hindbrain

At Hindbrain the answers to these questions come from the process, not from promises. Before launch we run a security audit and you get the report together with the product. It checks access and MFA, secrets and permissions, and whether backups exist, are encrypted and have a tested, measured restore.

The scope also covers GDPR housekeeping: a processing register, processing agreements with hosting, email and analytics vendors, and retention. The rule is simple: we fix critical and high findings before launch, and a product does not ship with an open critical. We describe the audit in detail in Application security audit [NEED: potwierdzić slug EN artykułu C1].

After launch we do not drop the subject. As part of maintenance we scan dependencies weekly, review permissions every quarter and retest after every major feature. We repeat the full audit once a year. Code, designs and accounts are yours from day one, so questions 14 and 15 have a simple answer with us.

EU hosting: by default we run applications on Hostinger servers in Vilnius (Lithuania, European Union), with a weekly backup of the whole server and separate database backups. If your industry requires servers in Poland, we discuss it on the first call.

This is a set of questions, not legal advice. Discuss the content of a processing agreement and your GDPR duties with a lawyer. If you are comparing offers, also read How to choose a software house [NEED: potwierdzić slug EN artykułu C3].

What to do today

Print these 15 questions and email them to your current or future contractor, asking for written answers. A good contractor will reply within days and without offence. A missing answer to any question is information too.

[NEED: the question list as a printable PDF lead magnet. Decision: download for email or without a gate]

Let us talk about your data

If you want to go through these questions with us, book a conversation. The first call lasts about an hour and is free. We will tell you what the answers would look like in your project. Book a conversation