App Privacy Labels Are Broken — Here's What That Means for Your Business

The Promise of App Privacy Labels

When Apple introduced its App Store privacy nutrition labels in December 2020, and Google followed with a similar Data Safety section on the Play Store in 2022, the intent was straightforward: give users a plain-English summary of what data an app collects, why it collects it, and who it shares it with. No legal jargon, no buried terms of service — just a label, much like the nutritional information on a food packet. The concept has genuine merit. Mobile applications now sit at the centre of personal and professional life. A single smartphone may hold banking credentials, health records, location history, and work communications. Knowing what any given app does with that information should be a basic expectation, not a privilege reserved for those willing to wade through a 40-page privacy policy. Here's the problem: the label system is not working as designed, and the consequences extend well beyond individual consumers.

What the Research Actually Shows About App Privacy Labels

Multiple independent studies have documented the same pattern. A 2023 study published in the journal Internet Policy Review examined hundreds of iOS applications and found that a significant proportion of apps misrepresented their data collection practices — either omitting categories of data collected or describing third-party sharing in terms that obscured what was actually happening. Separate research from the International Computer Science Institute found that many apps continued collecting sensitive data categories even when their labels explicitly stated they did not. The inconsistency is not confined to rogue developers. Well-known applications from established companies have been found with labels that do not match their observed network behaviour. Researchers at AppCensus, who analyse app traffic as a routine part of their work, have documented repeated discrepancies between stated and actual data practices. What this means: the labels are self-reported. Neither Apple nor Google independently verifies every claim before an app appears on their stores. Enforcement is reactive rather than proactive — labels only get corrected after a complaint is raised or a researcher publishes findings. For the average user, and for the average IT manager deploying apps across a fleet of business devices, that creates a material blind spot.

• App privacy labels are self-reported by developers — neither Apple nor Google verifies claims before publication.
• Multiple peer-reviewed studies have identified systematic discrepancies between stated and observed data collection behaviour.
• Third-party data sharing is consistently the most underreported category in privacy labels.
• Corrections to inaccurate labels typically only occur after external researchers or regulators intervene.

Why This Creates Real Regulatory Exposure for UK Organisations

UK organisations cannot treat this as a consumer issue that sits outside their remit. Under the UK GDPR, Article 5(1)(a) requires that personal data be processed in a manner that is transparent to the data subject. Article 13 places a positive obligation on controllers to provide clear information about data sharing with third parties at the point of collection. If an organisation deploys a mobile application to staff or customers, they may be acting as a data controller — which means the inaccuracy of that app's privacy label does not simply absolve them of responsibility. Consider a practical example. An organisation deploys a project management or communications app to its workforce. That app's privacy label states it does not share user data with third parties. In practice, the app routes behavioural telemetry to an advertising SDK. Under UK GDPR, the organisation — as controller — may have failed to provide accurate transparency information to its employees, despite having relied in good faith on the developer's label. The Information Commissioner's Office (ICO) has been progressively more assertive about supply chain accountability. Its guidance on accountability and governance, updated in 2023, makes clear that relying on vendor-provided documentation without independent verification is not, on its own, sufficient due diligence. Fines under UK GDPR can reach £17.5 million or 4% of global annual turnover, whichever is higher.

How Do Mobile Apps Exfiltrate Data Without Detection?

The technical mechanism behind the discrepancy is worth understanding, because it has direct implications for how organisations monitor their environments. Modern mobile applications frequently embed third-party software development kits (SDKs) for advertising, analytics, crash reporting, and social media integration. The developer who writes the privacy label may not have full visibility into what each embedded SDK does, particularly if those SDKs update their behaviour independently after the app is published. A label accurate at the time of submission can become inaccurate within weeks, without any visible change to the application itself. Data exfiltration through these channels tends to be low-volume and high-frequency — small packets of behavioural, location, or contact data sent to remote endpoints at regular intervals. This pattern is deliberately difficult to distinguish from normal application traffic. It does not look like ransomware. It does not trigger conventional endpoint alerts. It simply leaves, quietly and continuously. For organisations managing sensitive data — whether client records, intellectual property, or regulated personal data — this represents an exfiltration channel that standard perimeter defences are not designed to catch. Network monitoring at the DNS and traffic analysis layer is where these transfers become visible, but most organisations do not have that level of inspection applied to mobile device traffic.

What Good Privacy Label Regulation Should Look Like

The fundamental flaw in the current system is that it places the burden of accuracy on the party with the strongest incentive to underreport: the developer seeking App Store approval. A more reliable framework would include three elements that are currently absent. First, independent technical verification. Rather than relying solely on developer attestation, regulators or platform operators should conduct — or require third-party audits of — actual network traffic from applications before labels are published. Organisations such as AppCensus already demonstrate this is technically feasible at scale. Second, dynamic label updates. Because app behaviour can change after publication through SDK updates, labels should carry a verified date and trigger re-verification requirements when underlying components change. A label that was accurate in January 2024 should not be presented as current in January 2025 without confirmation. Third, regulatory alignment with existing data protection law. In the UK, the ICO should explicitly require that privacy labels constitute part of the Article 13 information provided to data subjects, making inaccurate labels a reportable compliance failure rather than simply a reputational issue. The EU's Digital Markets Act has begun to move in this direction for gatekeeper platforms, and UK regulators should consider equivalent measures. Until those mechanisms exist, the label on any given app should be treated as a starting point for due diligence, not a conclusion.

What UK Businesses Should Be Doing Right Now

Waiting for regulation to improve is not a viable strategy. The data leaving your organisation through mobile applications does not pause while policy frameworks catch up. There are concrete steps that security and compliance teams can take immediately. Start with a mobile application inventory. Many organisations cannot name every application installed across their managed and BYOD devices, let alone describe what each one does with data. A current, audited inventory is the baseline from which all other decisions follow. Next, treat privacy labels as unverified claims. When assessing any application for deployment, request the developer's full privacy policy, sub-processor list, and data processing agreement. Cross-reference these against the app's stated label. Discrepancies are a material red flag, not a minor inconsistency. Apply network-level monitoring to mobile traffic. If you cannot see what data your mobile applications are sending and to where, you cannot verify that your data protection obligations are being met. This is not a theoretical risk — it is a documented, measurable gap in most mobile security programmes. Finally, include mobile applications within your third-party risk management programme. Apps are vendors. They process your data. They should be subject to the same due diligence as any other third-party processor under UK GDPR Article 28.

• Build and maintain a current inventory of all mobile applications deployed across managed and BYOD devices.
• Treat privacy labels as unverified claims requiring independent cross-referencing against full privacy documentation.
• Implement network-level traffic inspection to detect undisclosed data transmission from mobile applications.
• Include mobile app developers within your formal third-party risk management and vendor assessment process.
• Review Data Processing Agreements with app vendors to confirm alignment with UK GDPR Article 28 requirements.

How Kyanite Blue Can Help You Close the Gap

The risk that mobile app privacy labels fail to disclose falls into two distinct but related categories: undisclosed data exfiltration, and unmanaged third-party supply chain exposure. Both are addressable with the right technology. For data exfiltration, BlackFog operates at the device and network level to detect and block unauthorised data leaving your environment. Rather than relying on developers to self-report what their apps transmit, BlackFog monitors actual outbound traffic patterns and stops data transfers that fall outside defined policy — including the low-volume, high-frequency exfiltration characteristic of embedded advertising SDKs. If an app is sending data it hasn't disclosed, BlackFog catches it. You can assess your current exposure at /data-exfiltration-risk in under two minutes. For third-party risk, Panorays allows you to assess the security and compliance posture of every vendor you depend on — including mobile application developers. Rather than accepting a developer's privacy label at face value, Panorays gives you an evidence-based risk score drawn from external signals: their security controls, their breach history, their compliance certifications. This turns vendor assessment from a manual, periodic exercise into a continuous, automated process. Learn more at /products/panorays. If you are uncertain where your current mobile and third-party data risk sits, our team can walk you through a structured assessment of your environment. There is no obligation, and you will leave with a clearer picture of where your gaps are. Get in touch at /contact.

Frequently Asked Questions