By EJN Labs · 28 Aug 2026 · 8 min read
App Privacy Details are the self-declared privacy labels Apple requires for every App Store app. Procurement teams increasingly ask mobile suppliers for app privacy details security assurance: independent evidence that the declarations match how the app actually behaves. Apple does not mandate a penetration test. A CREST-accredited mobile application test, typically £4,400 to £8,400 (4 to 6 days at £1,100 to £1,400 per day), is widely accepted as that evidence.
Why app privacy details security assurance comes up in procurement
App Privacy Details come up in procurement because buyers want proof the labels are true, not just completed. Apple already forces suppliers to fill them in before App Store distribution, so UK organisations use security questionnaires to check the declared data collection and sharing matches the app’s real behaviour.
If you supply mobile apps into UK organisations, you have probably seen the request in security questionnaires: evidence that your App Privacy Details accurately reflect the app’s data collection and sharing behaviour.
The reason is simple. App Privacy Details are entirely self-declared. Apple requires developers to state what data the app collects, whether it is linked to the user’s identity, and whether it is used for tracking, but does not routinely verify those statements against the compiled binary. Independent research has repeatedly found apps whose network traffic contradicts their labels, usually because a third-party SDK collects data the developer never audited. Buyers know this, so a screenshot of your App Store listing carries little weight.
For a UK buyer there is a second driver: UK GDPR. If your app processes personal data, your privacy labels become part of their due diligence record, and a label that turns out to be wrong is evidence the buyer failed to vet a processor. That is why the question lands during procurement, not after go-live.
What Apple actually requires, and what buyers add on top
Apple requires truthful App Privacy Details for any App Store app that collects, uses or shares data, and the declaration is mandatory for distribution. Apple does not require a penetration test, privacy audit or third-party validation. Anything beyond the declaration itself is added by buyers, not by Apple.
Precision matters because suppliers often over-claim or under-claim in questionnaire responses. There is no Apple clause obliging you to commission testing, so any assurance evidence a buyer requests sits on top of the platform requirement rather than inside it.
Say this honestly in your responses. The credible position for a supplier is: “Apple mandates the declaration; independent testing is how we evidence its accuracy.” Where testing enters the picture is as accepted evidence. When a procurement team asks how you know your labels are right, the answers that survive scrutiny are technical: traffic interception results, SDK inventory analysis, and a report from a CREST-accredited firm confirming that observed data flows match the declared categories.
The same evidence usually does double duty. Questionnaires that ask about privacy labels also ask about secure development, OWASP Mobile Top 10 coverage and API security, and one well-scoped engagement can answer all of them. Our penetration testing checklist covers the preparation that makes this efficient.
What buyers expect mobile suppliers to evidence
Across UK enterprise and public sector questionnaires, the asks cluster into four areas, each mapping to a specific type of technical validation.
| What the buyer asks | What they are really checking | Evidence that satisfies it |
|---|---|---|
| Are your App Privacy Details accurate? | Declared data categories match real behaviour | Traffic interception and binary analysis mapped against each declared label |
| What third-party SDKs are embedded? | Undeclared collection by analytics or ad SDKs | SDK inventory with data-flow analysis per SDK |
| How is data protected in transit and at rest? | TLS configuration, certificate pinning, local storage | Mobile application penetration test findings |
| Is the backend as secure as the app? | API authentication, authorisation, data exposure | API penetration test of the endpoints the app calls |
The fourth row is where many suppliers get caught out. Privacy labels describe what the app collects, but a buyer’s security team will follow the data to your backend, and if an API endpoint leaks other users’ records the labels are irrelevant. A mobile application penetration test paired with an API penetration test closes the whole question off.
How a privacy validation engagement runs
When EJN Labs scopes this work for a mobile supplier, the first thing we ask for is the current App Privacy Details declaration and a build of the app. The declaration becomes the test oracle: every claim in it is something we will try to confirm or contradict.
- Static analysis. We decompile the build, inventory every embedded SDK and framework, and identify which ones are capable of collecting or transmitting data, including device identifiers your own code never touches.
- Dynamic analysis. We run the app on instrumented devices with traffic interception in place, exercising every feature while recording exactly what leaves the device, to which hosts, and whether identifiers are linked to the user.
- Label mapping. Observed flows are mapped against each declared category. Anything collected but not declared, or declared as “not linked to you” while carrying a persistent identifier, is written up as a finding.
- Security testing. Alongside the privacy work we test the app and its APIs against the OWASP Mobile and API Top 10, since buyers almost always want both in one report.
The output is a report you can hand to a procurement team: an executive summary stating whether the labels are accurate, findings with evidence, and a remediation plan. The most common surprise for suppliers is an analytics SDK transmitting device identifiers declared as “data not collected”. It is nearly always a configuration fix, but you want to find it before your buyer’s security team does.
What it costs and how scope drives the price
Pricing follows effort, and effort follows scope. UK day rates for CREST-accredited testing typically run £1,100 to £1,400 per day. The main scope drivers are the number of platforms, the size of the app’s feature set, and whether backend APIs are included.
| Scope | Typical effort | Typical UK cost |
|---|---|---|
| Single-platform mobile app with privacy label validation | 4 to 6 days | £4,400 to £8,400 |
| Mobile app plus backend API testing | 6 to 9 days | £6,600 to £12,600 |
| Mobile, API and cloud configuration review | 8 to 12 days | £8,800 to £16,800 |
| Retest after remediation | 1 to 2 days | £1,100 to £2,800 |
These are typical UK ranges rather than quotes; the exact figure depends on your app and comes from scoping. For a wider view of how testing prices are built up, see our guide to penetration testing costs in the UK. One commercial point: a single engagement producing evidence reusable across every procurement exercise for a year is usually far cheaper than the sales time lost to stalled security reviews.
How EJN Labs approaches app privacy validation
EJN Labs is a UK-based, CREST-accredited penetration testing firm, certified to ISO 27001 and Cyber Essentials Plus. All testing is carried out by UK-based testers, which matters to buyers whose compliance obligations restrict where test data can be handled.
We treat privacy label validation as an evidence exercise, not a box-tick. Every engagement starts from your actual declaration, tests against it on real devices, and produces a report written for your buyer’s security and procurement teams. Where findings contradict the labels, we explain both the technical fix and the declaration change. If you are comparing firms, our guide to choosing a UK penetration testing provider sets out the questions worth asking any vendor, including us.
Frequently Asked Questions
Does Apple require a penetration test for App Privacy Details?
No. Apple mandates the App Privacy Details declaration for any App Store app that collects, uses or shares data, but it does not require penetration testing or third-party validation of those labels. Independent testing is a voluntary assurance activity, commissioned by suppliers rather than demanded by Apple.
The usual reason suppliers commission it is procurement: buyers’ teams treat an independent test as accepted evidence that the self-declared labels are accurate.
What evidence do procurement teams accept that privacy labels are accurate?
Procurement teams accept a report from a CREST-accredited firm covering traffic interception on real devices, an inventory of embedded SDKs and their data flows, and a mapping of observed behaviour against each declared label. That is the strongest evidence that privacy labels are accurate.
Expect the same report to carry standard mobile and API penetration test results too. Privacy and security questions arrive together in most questionnaires, so buyers look for one document that answers both.
What does app privacy details security assurance cost?
A single-platform mobile app test with privacy label validation typically takes 4 to 6 days at £1,100 to £1,400 per day, so £4,400 to £8,400. Adding backend API testing takes it to 6 to 9 days, or £6,600 to £12,600. The exact price depends on the app’s size and platforms, and comes from scoping via the quote form.
How long does a mobile app privacy validation take?
One to two weeks is the typical testing window, depending on scope, with the report delivered shortly after. Suppliers working to a procurement deadline should start four to six weeks before the questionnaire is due, leaving time for remediation and a retest.
The extra margin exists because findings that contradict your labels need fixing before the report is buyer-ready, and a retest confirms the fixes.
What happens if testing finds the app behaves differently from its labels?
Fix the app or fix the declaration. Either reconfigure or remove the SDK responsible, or correct the App Privacy Details to match reality. The report will recommend one of the two, and most discrepancies found are configuration-level and quick to fix.
Whichever route you take, resolving it before a buyer’s security team finds the mismatch protects both the deal and your UK GDPR position as a processor.
Turn your privacy labels into procurement-ready evidence
If a security review is holding up a deal, we can scope a mobile and API engagement around your App Privacy Details declaration. Get a CREST pentesting quote and we will come back with a fixed scope and price for your app.
Leave a Reply