MASVS-PRIVACY expects your app to minimize the data it touches, and expects third-party SDKs to act on user consent, not by default. In practice that means listing every SDK, learning what each collects and when, and making sure none starts collecting before consent is confirmed.
What the four privacy controls say
The OWASP MASVS added a PRIVACY group with four controls:
- PRIVACY-1: the app minimizes access to sensitive data and resources.
- PRIVACY-2: the app prevents identification of the user.
- PRIVACY-3: the app is transparent about data collection and usage.
- PRIVACY-4: the app offers user control over their data.
PRIVACY-1 is the one that speaks directly to SDKs. Its description says apps should share data with third parties only when necessary, enforce that third-party SDKs operate on user consent "not by default or without it", and prevent SDKs from ignoring consent signals or collecting data before consent is confirmed.
It also tells apps to be aware of the supply chain of SDKs they include, so data is not unnecessarily passed down a chain of dependencies, and links that to SBOM regulatory requirements.
Step 1: build the SDK list
For each release, list every SDK in the build, including transitive ones that arrive through another library. Record the name, version, purpose, who owns the integration, and what data types it can reach. Without the list you cannot answer anything else.
Step 2: check when each one starts
Many SDKs initialize at app launch. If your consent prompt comes later, data can flow in between. Test it: install a fresh build, decline consent, and watch network traffic through a proxy. Anything that talks to a third party before consent is a finding.
Fixes include delaying SDK initialization until consent, using the SDK's own consent mode where it exists, and removing SDKs you cannot configure.
Step 3: check what each one collects
PRIVACY-2 covers fingerprint-like signals such as device IDs, IP addresses and behavioral patterns. Its example is useful: a fingerprint used for fraud detection should be isolated and not repurposed for audience measurement in an analytics SDK. Review whether any SDK receives identifiers it does not need.
Step 4: match disclosures to reality
PRIVACY-3 asks for clarity about collection, storage and sharing, including behavior a user would not reasonably expect, such as background collection, and for adherence to platform guidelines on data declarations. Compare your store data declarations and privacy notice against the traffic you saw.
Step 5: give users control
PRIVACY-4 asks for ways to manage, delete and modify data and to revoke consent, and for re-prompting when the app needs more data than originally specified. Check that withdrawing consent actually stops the SDKs, not just hides a banner.
Make it routine
- Add a rule to your release checklist: no new SDK without an owner and a data review.
- Re-run the proxy test whenever an SDK version changes.
- Keep the SDK list in the same place as your SBOM.
A caution: this post covers the technical controls in the MASVS. Whether your consent flow meets a particular privacy law is a question for your legal advisers.
Where Safeguard fits
An SBOM and dependency scan gives you the component list that step 1 needs, and flags known vulnerabilities in those components. Try a free scan. It does not tell you what each SDK sends over the network.
Quick check
Is a consent banner enough?
No. The control is about behavior: SDKs must not collect before consent is confirmed. Test the traffic.
Does PRIVACY apply to apps without ads?
Yes. Analytics, crash reporting and any other SDK can touch user data.
Sources
Last reviewed: 19 October 2026.
