"We have a privacy policy, we're covered" comes up often enough as a kind of security reassurance that it's worth being precise about what a privacy policy actually is, and isn't. It's a genuinely important document. It's also not the thing most people seem to think it is when they cite it as evidence their app is secure.
What a privacy policy actually does
A privacy policy is a statement of what you claim to do with someone's data: what you collect, how you use it, who you share it with, how someone can request deletion. It's a legal and ethical commitment, often required by law depending on where your users are. What it fundamentally is, though, is a description of intent. It says what's supposed to happen.
What it has nothing to do with
A privacy policy doesn't check whether your database's access rules are actually correct. It doesn't verify that an admin route requires real authentication. It doesn't confirm that one user can't see another user's records. None of the actual technical security work this whole blog covers is touched by the document existing, however well-written it is. A privacy policy describes the promise. The code either keeps it or it doesn't, and that's a completely separate question from whether the promise was written down clearly.
Where this actually becomes a real problem
A privacy policy that says "we only use your data for X" while your actual database configuration allows any logged-in user to read data far beyond X isn't just a security gap. It's a security gap that directly contradicts a written promise, which turns a technical mistake into something closer to a broken commitment, and one that's often quoted directly back at a company after an incident, precisely because it's sitting right there in writing.
How this happens so easily
Plenty of privacy policies get generated quickly from a template, posted, and never revisited as the app actually grows and changes. Meanwhile the actual data collected and how it's actually protected keeps evolving with every new feature. The gap between what the policy says and what the app actually does isn't usually intentional. It's just two documents, one written in legal language and one written in code, that stopped being checked against each other the moment the policy got posted.
What's actually worth doing
- Read your own privacy policy occasionally and check whether it still accurately describes what your app actually collects and does.
- Treat the policy and your actual access-control implementation as two things that need to match, not two unrelated documents.
- Remember that a privacy policy is the promise, and everything on this blog is about whether the promise is technically true. Posting the promise is necessary. It's not the same as keeping it.
A good privacy policy and good security practices are both worth having. They're just not substitutes for each other, and confusing "we wrote down what we're supposed to do" with "we verified that our app actually does it" is exactly the gap worth closing.