GDPR for mobile apps.

Your app handles personal data? Article 32 of the GDPR asks you to regularly test the effectiveness of your security measures. We test your app and its API and give you that evidence.

Talk to our team All services

What the GDPR expects from your app.

For teams whose Android or iOS app processes personal data of users in the EU.

Article 32 of the GDPR requires security of processing appropriate to the risk, and specifically, in Article 32(1)(d):

a process for regularly testing, assessing and evaluating the effectiveness of the technical and organizational measures for ensuring the security of the processing.

Under the accountability principle (Article 5(2)), you have to be able to demonstrate that you do this. A penetration test and vulnerability assessment of your app is a recognized way to evidence it. When the app handles special categories of data, such as health data, the appropriate level of security is higher. There is no certificate you must obtain: GDPR certification (Article 42) is voluntary. We produce the testing evidence you keep as part of your accountability.

What we test.

We focus on the paths that expose personal data. Depending on the agreed scope, testing can cover:

Personal data on the device: what the app stores, how it protects it and what ends up in logs or backups.
Data in transit: whether the communication with the backend protects the data it carries.
API authorization: whether one user can read or change another user's personal data by changing an identifier in a request.
Third-party SDKs: what data the libraries in your app send off the device, and to whom.

How we work.

Call: you tell us about your app, its backend and the personal data it handles.
Proposal: we set out the agreed scope, what we need from you, the schedule and a fixed price.
Testing: you send us the builds and we start. If we find something critical, we let you know right away.
Report and review: we send you the report and go through it with your engineers.
Retest: once you have fixed the vulnerabilities, we confirm they are resolved in the new build.

What you receive.

Technical report

States what we tested and the result, with attention to the data each issue exposes. Every finding includes evidence, reproduction steps, impact, a CVSS score and vector, CWE and OWASP MASWE references, and how to fix it.

Executive summary

Covers the scope and build tested, the results and the priorities, for management, your DPO and non-technical readers.

Retest report

If you include the retest, we send a new version of the report with the status of each finding on the new build, as evidence that the measures were applied.

Why vulnit for the GDPR.

We look for where data leaks

Insecure storage, a chatty third-party SDK or a broken API authorization are the issues that turn into a personal data breach. Those are exactly what we go after. You can see several of them worked through end to end in our sample report.

We contribute to OWASP MAS

We map your tests to OWASP MASVS and MASTG, the standard and testing guide our team helps write. OWASP recognized this work by naming vulnit an OWASP MAS Advocate.

Independent evidence

We are an external, independent team. The report is the kind of evidence you keep for your accountability and can show a supervisory authority if it asks.

Meet the team

GDPR frequently asked questions.

Does this make us GDPR compliant?

No single test makes you compliant. The GDPR covers much more than security. What a pentest does is evidence one specific obligation: Article 32(1)(d), regularly testing the effectiveness of your security measures. Our report is that evidence for the app and its API.

Do we need a GDPR certification?

No. Certification under Article 42 is voluntary and not required to meet Article 32. The obligation is to test and be able to demonstrate it, which is what our report supports.

Our app handles health or other special-category data. Does that change anything?

The appropriate level of security is higher, so we weight the testing towards the data most at risk. If your app is also a medical device, see our healthcare page, where other rules apply as well.

Are backend APIs included?

They can be, and we generally recommend it: much of the personal data risk lies in the API. We decide it with you case by case.

Do you need source code?

No. By default, testing is black-box: we attack your app with the same information an attacker would have, using the same build you release. If you share the source code, we review it too.

Do you test iOS as well as Android?

Yes. We test both, to the same depth. On Android we work with Chameleon; on iOS we test on physical devices. If your app runs on both platforms, we deliver one report per platform.

How long does it take and what does it cost?

It depends on the number of apps and platforms, the complexity of your app and the backend interfaces in scope. We send you a proposal with a fixed price and the schedule. It usually takes one to two weeks per platform, report included.

What language is the report in?

English by default. If you need it in Spanish, just tell us.

How do you handle confidentiality?

We agree confidentiality terms before you share builds or documentation. We have a standard NDA, but if you prefer to use yours, we are happy to review it.

Testing your app for the GDPR?

Tell us about your app and the personal data it handles. We reply within one business day to arrange a scoping call.

Talk to our team