App Security and Privacy: A Practical Checklist

Most app security advice is either too abstract to act on or too technical to hand to a client. The version that is neither starts with the two things that are enforced immediately, by a machine, on every release: the store declarations. Both Apple and Google now require you to state what data leaves the device, and both make you answer for code you did not write.

This guide covers that first, because it is the part with a deadline, then the security standard worth working against, and then the honest boundary where legal advice starts.

The declarations are mandatory and they gate releases

Apple's app privacy details requirement is unambiguous: this information is "required to submit new apps and app updates to the App Store."

Google's Data safety requirement goes further on scope: "All developers that have an app published on Google Play must complete the Data safety form, including apps on closed, open, or production testing tracks." A closed beta is not an exemption.

The consequence of getting it wrong is the part worth putting in front of a stakeholder. Google states:

"When Google becomes aware of a discrepancy between your app behavior and your declaration, we may take appropriate action, including enforcement action."

with outcomes described as blocked updates or removal from Google Play. Apple assigns the same ongoing duty: "You're responsible for keeping your responses accurate and up to date. If your practices change, update your responses in App Store Connect."

This is not a fine you can budget for. It is a release you cannot ship, which is worse — it arrives on the day you have a fix to deploy, not on a schedule. The same logic runs through the rejection reasons that stop updates.

The clause that catches everyone: other people's code

Here is the requirement most teams discover late. Apple asks you to "identify all of the data you or your third-party partners collect", and defines those partners as:

"analytics tools, advertising networks, third-party SDKs, or other external vendors whose code you've added to your app."

Google's scope is the same: the declaration "includes data collected and handled through any third-party libraries or SDKs used in their apps", and "you alone are responsible for making complete and accurate declarations."

So the honest version of this task is: for every SDK in the build, state what it sends off the device and why. An analytics library, a crash reporter, an ad network, a chat widget, a payment SDK, a map component. Most teams cannot answer that for their own dependency list, and the answer is not in the code — it is in each vendor's documentation, which is why this is a research task with a schedule rather than a form to fill in on submission day.

Two practical consequences follow. First, every new SDK is a declaration change, so adding one is a product decision rather than a developer preference. Second, the fewer SDKs you carry, the smaller this obligation is — which is a reason to be strict about dependencies that has nothing to do with bundle size.

What "collect" actually means

Apple's definition is narrower than the word suggests, and knowing it prevents both over- and under-declaring:

"'Collect' refers to transmitting data off the device in a way that allows you and/or your third-party partners to access it for a period longer than what is necessary to service the transmitted request in real time."

Two things fall outside that. Data that never leaves the device. And data transmitted only to serve the immediate request and not retained. Both still need care, but they are not the same as retaining a user's information.

Apple also defines tracking specifically: "linking data collected from your app about a particular end-user or device… with Third-Party Data for targeted advertising or advertising measurement purposes, or sharing data collected from your app about a particular end-user or device with a data broker."

Read that before ticking the tracking box, because the box has consequences for what the app must ask the user.

A security standard you can actually verify against

"Make the app secure" is not a specification. OWASP's Mobile Application Security Verification Standard is, and it organises the work into eight groups:

MASVS-STORAGE, MASVS-CRYPTO, MASVS-AUTH, MASVS-NETWORK, MASVS-PLATFORM, MASVS-CODE, MASVS-RESILIENCE and MASVS-PRIVACY.

The value is that each group is something a developer can be asked to demonstrate. Where are credentials stored, and in which platform keystore? What is encrypted, with what, and who holds the key? How are sessions established and revoked? What does the app do on a network it does not trust? Which platform permissions does it request, and can it degrade without them?

Those are answerable questions with evidence attached, which is the difference between a security requirement and a security aspiration — the same distinction that separates the metrics with a published threshold from the ones that only fill a report. For the backend half of the same picture, what your backend meters and stores determines a lot of the answers.

Where the law starts, and where we stop

KVKK, GDPR and their equivalents are legal obligations. What they require of you depends on your jurisdiction, what data you handle, whether you are a controller or a processor, and where the data physically sits. Those questions need your own counsel, and an agency that answers them in a blog post is overreaching.

What we will say is the distinction that actually helps: the store requirements and the legal requirements are different in kind. The store requirements are universal, they apply the moment you submit, and they are enforced by a button that stops working. The legal requirements vary, arrive on a longer timescale, and are enforced by regulators. Meeting one does not satisfy the other, and teams routinely assume the store form is the compliance work.

Where the two meet is the data inventory. The list of what you collect, from whom, why, where it goes and how long you keep it serves the store declaration, your counsel and your own engineering. Build it once, keep it current, and both conversations get shorter.

Where we say no

We do not add analytics or advertising SDKs without the client deciding, in writing, what each one is for. Every one is a permanent declaration obligation and an answer somebody has to keep accurate.

We do not write privacy policies or advise on KVKK or GDPR compliance. We will build what your counsel specifies and produce the data inventory they need, which is the part we can actually do.

And we do not treat security as a phase at the end. Storage, transport and authentication decisions are made in the first week and are expensive to revisit, which is why they belong in scoping — as covered in our mobile app development guide.

The checklist

1. List every SDK in the build and, for each, what it transmits off the device. If you cannot answer, that is the first task.
2. Write the data inventory: what, from whom, why, where it goes, how long it is kept.
3. Complete both store declarations from that inventory, not from memory.
4. Re-check the declaration whenever a dependency changes. A new SDK is a declaration change.
5. Work through the eight MASVS groups and record the evidence for each, rather than asserting the app is secure.
6. Send the inventory to your counsel for the legal half, and keep the two conversations separate.

If you want the declarations and the inventory produced as part of the build rather than discovered at submission, tell us what the app handles — or start from the mobile app development page.