Most founders think their privacy policy is where compliance lives. Under Philippine rules, that document is barely the one that matters to a user at all. The one that does is the screen they see thirty seconds after opening the app for the first time, and most founders get it wrong without knowing it.
A company usually has these on hand: a finished privacy document, a signed Data Processing Agreement template, and a designated DPO. On paper, the compliance program looked complete. Then we opened the app together and looked at the first screen a real user actually sees.
That screen told a different story than the paperwork did.
Part of why this happens is a mix-up that’s worth clearing up first, because it isn’t just semantics. Under NPC Circular No. 2023-04, a Privacy Policy (sometimes called a Privacy Manual) is an internal document: it governs how your own officers and staff are supposed to handle personal data – this is often confused with what is supposed to be called as a Privacy Notice. A Privacy Notice is the external one: a specific, unilateral disclosure telling a data subject, your user, what happens to their data for a given processing activity, in language they can actually follow. Neither one is consent. But only one of them is meant to be read by the person tapping “Agree” on your onboarding screen, and it’s the Notice, not the Policy.
Founders (and plenty of engineers) use “privacy policy” as a catch-all for whatever privacy document is public-facing, which is exactly how the two get conflated. From here on, when this article says “notice,” it means the document your users are actually shown. That’s also the document most likely to drift out of sync with what your product screens actually do, because it’s written once, reviewed by a lawyer, and then filed away, while onboarding screens are iterated on constantly by product and design teams chasing conversion rates. Nobody re-checks whether the wording on a permission popup still matches the legal basis the lawyer signed off on six months earlier. By the time a founder asks a lawyer to look at the actual screens, gaps have usually opened up that the notice alone would never reveal.
Here’s what to look for on your own first-run flow, and why each piece matters more than it looks.
The notice is not where consent happens
A privacy notice is a document. Consent, where consent is actually your legal basis, is an event that happens at a specific moment, on a specific screen, triggered by a specific action. The National Privacy Commission’s guidelines on consent are built around this distinction: consent must be a freely given, specific, and informed indication of will, evidenced at the point it’s given, not inferred from the existence of a notice nobody read.
Practically, this means the screen where a user taps “Agree” or toggles a permission on is doing legal work that your privacy notice, sitting three menu levels away, is not. If that screen is vague, bundled, or mislabeled, the fact that your notice is accurate elsewhere does very little to save you.
Layered notices: the short version, and the long version underneath it
A well-built compliance gate doesn’t try to explain your entire data practice in one popup. It gives the user a short, plain-language summary of what matters right now, then links out to the full governing document for anyone who wants the detail.
A pattern I look for: three or four short lines, each naming one category of data in plain terms (location, activity you’re tracking, how it will and won’t be used), followed by a single sentence making clear that this summary is for convenience and the full privacy notice is what actually governs. That last sentence is doing real work. It tells a regulator, and a court if it ever comes to that, that the short summary was never meant to be the complete disclosure, and that the company pointed the user toward the real one.
Without that sentence, a company can end up in the position of having its own onboarding summary treated as the operative disclosure, which is a much harder document to defend than a properly drafted privacy notice, because it was written by a designer optimizing for a five-second read, not a lawyer.
The verb on the button is doing legal work you didn’t ask it to do
This is the detail founders miss most often, and it’s the cheapest one to fix.
“I agree” and “I consent” are legally loaded phrases. Using them on a button tells a regulator, later, that consent was your chosen legal basis for whatever processing that button unlocks. That’s fine, and correct, when the underlying activity really is consent-based, a user opting into a marketing newsletter, for instance, where declining costs them nothing.
It becomes a problem when the same wording sits on top of processing that was never meant to rest on consent at all. A lot of operational data processing, fraud prevention, service delivery, safety monitoring, is properly grounded in legitimate interest or contractual necessity, not consent. If a company builds its lawful-basis analysis around legitimate interest internally, but its actual UI says “I consent” to the user, it now has two contradictory legal positions on record: what the lawyers argued, and what the product told the user. A regulator gets to pick whichever one is worse for the company.
The fix is almost embarrassingly simple once you see it: match the verb to the basis.
- Acknowledging a notice (legitimate interest, contractual necessity): “I understand,” “Got it,” “I’ve read this.” You are informing the user, not asking their permission.
- Actually asking for optional, revocable consent: “I agree,” “I consent,” “Allow.” You are asking a real question with a real “no” available.
A well-built app uses this split: one checkbox for the terms of service used “I agree” (correct, that’s a genuine contractual acceptance), and a separate checkbox for the privacy notice used “I have read” (also correct, because acknowledging a notice under a non-consent basis is a different act than agreeing to a contract). Two documents, two different verbs, both legally accurate. That’s not an accident. That’s someone thinking about the words, not just the layout.
When “optional” framing helps you, and when it quietly works against you
There’s a genuine design skill in making a permission request feel low-pressure: warm language, a clear “not now” option, reassurance about what won’t happen with the data. Done well, this respects the user and improves the experience.
But there’s a version of this that creates a subtle legal problem. If a company frames a permission as “yours to turn on or off, no pressure” while treating that same data internally as necessary for the service to function properly, the UI is implying an optional choice that isn’t fully optional in practice. That gap, between how casual the ask feels and how essential the data actually is, is exactly the kind of inconsistency a regulator investigating a complaint will zero in on.
The test I use: if declining the permission meaningfully breaks or degrades the core service, the UI shouldn’t frame it as a free, no-consequence choice. Say plainly what happens if the user declines. Users generally respond better to an honest tradeoff (“without this, we can’t do X”) than to cheerful language that turns out to have a catch.
A five-question test for your own onboarding flow
Before you ship your next onboarding update, or if you’re reviewing what’s already live, run it through these:
- Does every “agree” or “consent” button sit on top of processing that’s actually meant to be consent-based? If the lawful basis is legitimate interest or contract, the wording should inform, not ask.
- Does your short-form summary screen point back to the full privacy notice as the governing document? If the summary could be read as the complete disclosure, it’s doing more legal work than it should.
- Is the consequence of declining a permission stated honestly, right there on the screen? Not buried in the notice, not omitted.
- Do your onboarding screens match what your privacy notice tells users, and what your internal privacy manual tells your own staff to do? Product teams change flows faster than legal documents get updated. Check the drift periodically, not just once at launch, and check it in both directions, the external notice against the screen, and the screen against your internal manual.
- If a regulator took a screenshot of this exact screen tomorrow, would it match the legal basis you’d cite for the underlying processing? If you’re not sure, that’s the gap to close first.
None of this requires redesigning your app. Most of the fixes are wording changes, a verb swapped here, a sentence added there, an honest consequence stated instead of implied. But they’re the kind of changes that are cheap to make before launch and expensive to unwind after a complaint has already been filed.
If you’re getting ready to launch something that collects personal data and haven’t had the actual screens reviewed, not just the notice, that’s usually where the real gap is hiding.
Villarosa Law Office advises founders and product teams on data privacy compliance under the Data Privacy Act, including onboarding and consent-flow review, DPO registration, and Privacy Impact Assessments. Schedule a conversation to have your own first-run flow looked at before it ships.
