An email lands in an inbox that may not even be monitored any more. A card appears on the My Apps page marked Required Action. Nothing breaks. The app keeps serving traffic, tokens keep refreshing, and for about eight weeks there is no visible consequence at all.
Then the app is deactivated. Not rejected, not rate-limited — deactivated, because a questionnaire went unanswered. That is the Data Protection Assessment, and the reason it catches teams is precisely that nothing goes wrong until everything does.
What the Data Protection Assessment actually is
The DPA is not part of App Review. App Review is forward-looking — you ask for a permission, Meta decides whether to grant it. The DPA looks backwards at data you already hold.
The scope of “Platform Data” is wider than most teams assume. Meta’s own FAQ states that “all data you receive from Meta through the app is considered Platform Data,” and lists app tokens, page tokens, access tokens, app secrets and user tokens alongside the obvious user fields. A team that thinks of itself as “only storing user IDs” is still squarely inside the assessment.
The current version is v3.1. Meta states that if your assessment number starts with 3.1 you received it on or after 15 February 2024; unnumbered assessments predate that. Older v2.5 question numbering that still circulates in forum posts and consultant checklists does not map to what you will be answering.
Who gets one — and why nobody can tell you in advance
This is where most third-party writing on the DPA quietly invents an answer. Meta does not publish a trigger list. The official wording is deliberately non-committal:
So any article naming the specific permissions or scopes that summon a DPA is inferring, not quoting. The practical consequence: you cannot plan around avoiding it, and you cannot confirm in the App Dashboard that you are exempt. You can only be operationally ready for the notification when it arrives.
Meta does state where the notification lands — the developer or business contact email, the App Dashboard Alert Inbox, a dashboard notification, and a Required Action card on the My Apps page. Every one of those channels assumes somebody is still watching an account that was often set up years ago by a person who has since left.
Two deadlines, not one
The 60 days is the number everyone knows. The second deadline is shorter, harder, and is where prepared teams separate from unprepared ones.
| Initial submission | “More information needed” | |
|---|---|---|
| Window | 60 calendar days from first notification. | 5 business days to respond. |
| Extensions | Not documented for this window. | Two auto-extensions, 15 business days total. |
| Who it depends on | You — and whoever holds your security evidence. | You, at short notice, mid-quarter, with no warning. |
That five-day clock is the real risk. It starts when a Meta reviewer decides your answer was not clear enough, which is not a date you can put in a calendar. If the evidence a reviewer asks for — a penetration test report, an access-control policy, a data-flow diagram — has to be requested from a vendor or a parent company, five business days is not obviously enough time.
One further trap worth naming: the “Request extension” button that appears in the dashboard applies to violation response deadlines, not to the initial 60-day submission window. Teams read about extensions and assume the 60 days is soft. Nothing in Meta’s documentation says it is.
What happens if it is ignored
Two things are worth reading precisely there. First, the app is deactivated, not deleted — and Meta states it is restorable by completing the assessment. Articles claiming a permanent ban are overstating it. Second, and less comfortably, submitting on time is not the end of the exposure. Meta describes a status of “Submitted, violations found,” and notes that while some violations come with a warning period, “the most severe violations do not include a warning period.”
Meta also states plainly that “providing incomplete or vague answers may result in loss of platform access.” The assessment is not a formality you clear by filling boxes. A weak answer is a worse outcome than a slow one.
What the questionnaire actually asks
v3.1 runs in four sections. Three of them are answerable by whoever knows the product. The fourth is not.
1. Data Use
What Platform Data the app takes and what it is used for. Straightforward on the surface — but the answer has to match what your privacy policy, your App Review submission and your actual codebase all say. Three documents written at different times by different people rarely agree.
2. Data Sharing
The deepest branch in the questionnaire, with a full sub-tree behind the first question. Every processor, sub-processor, analytics vendor and offshore development partner that can see Platform Data belongs here, and most organisations have never assembled that list.
3. Data Deletion
Whether deletion actually happens, and whether it reaches backups, logs, caches and downstream vendors. A working data-deletion callback is the visible part; what the questionnaire probes is what happens after it fires.
4. Data Security
Roughly seventeen questions plus two formal acknowledgements — and the section that stops projects. This is CISO territory, not developer territory, and for many of the questions Meta asks for uploaded evidence rather than a yes.
The security section covers, in Meta’s own ordering: security certification; backend storage, data types and hosting; encryption at rest; data on organisational and personal endpoints including a data-flow diagram; TLS 1.2 or above in transit; vulnerability and cloud-misconfiguration testing; access token and app secret protection; multi-factor authentication across collaboration tools, code repository, CI/CD, backend admin and SSH; account maintenance and access revocation; patching across backend, mobile and endpoints; a public vulnerability-reporting channel; admin and application audit logs; and personnel security.
Read those as dates, not policies. If your last penetration test was fourteen months ago, the evidence is already out of scope on the day the notification arrives — and commissioning a new one inside a 60-day window, with a vendor who has their own lead times, is a procurement exercise rather than an engineering task.
How the work is sequenced
Confirm the notification channel is actually alive
Before anything else: who receives the developer contact email, and is that mailbox monitored. This single check is the difference between a 60-day window and a 20-day one.
Map Platform Data end to end
Every field received from Meta, every store it lands in, every vendor that can read it, every backup that retains it. Sections 1 to 3 are unanswerable without this map, and it is almost never documented already.
Audit the security evidence against the stated thresholds
Not “do we have a penetration test” but “is it inside 12 months, does it cover the right surface, and is the report in a form that can be uploaded unencrypted and in English.”
Close the gaps that are closable inside the window
Some findings are configuration and can be fixed in days — MFA coverage, log retention, a vulnerability-disclosure page. Others are procurement. Knowing which is which on day three rather than day forty is the whole game.
Answer for the reviewer, then hold the five-day line
Answers written to be unambiguous on first read are what avoid the “more information needed” branch entirely. If it comes anyway, the evidence pack assembled in step 3 is what makes five business days survivable.
Where these go wrong
- Nobody saw the notification. The developer contact email belongs to someone who left. Weeks of the 60-day window are spent before anyone knows a clock is running.
- It was treated as an engineering ticket. Section 4 asks questions no developer can answer alone, and the escalation to security and legal happens far too late.
- The security evidence is stale. A penetration test outside the 12-month window is not evidence. Commissioning a fresh one inside 60 days is a vendor lead-time problem.
- The data-sharing list is incomplete. Analytics SDKs, crash reporters, offshore contractors and support tooling all touch Platform Data and all get forgotten.
- Answers contradict the privacy policy or the App Review submission. Meta has all three. Inconsistency is what triggers the follow-up questions.
- Uploads are rejected on mechanics. Meta states only English submissions are accepted, and repeats on every evidence question that files must not be password-protected.
- The five-day follow-up window is missed. The initial deadline was met and the team moved on. Nobody was watching when the reviewer came back.
- It was assumed to be a one-off. It is annual. So is the Data Use Checkup, separately.
DPA, Data Use Checkup and App Review are three different things
They are routinely confused, including in places that should know better. Meta separates them explicitly: App Review is “a forward-looking process that allows you to request approval for individual permissions and features”; the Data Use Checkup is “an annual process for developers to self-certify that their continued use of and access to specific data via Meta APIs is in compliance”; the DPA is “an annual questionnaire that asks developers about their data use, sharing and data security.”
The DPA did not replace the Data Use Checkup. Both still exist, both are annual, and an app can be inside both cycles. Meta has signalled that consolidation is coming under a separate initiative called data access renewal, which it describes as bringing “most of these existing assessments into one streamlined process,” released “in phases.” Until that lands, plan for two.
Where this sits in the wider compliance picture
An app carrying advanced access is not in a steady state. It is in a rolling series of checkpoints — App Review when permissions change, Business Verification behind the portfolio, the Data Use Checkup annually, and the DPA annually on its own schedule. Any one of them going unanswered takes the same thing away: production data access.
If a submission has already gone wrong, that is a different problem with a different route — covered by the Meta App Review rejection fix service. If the portfolio layer underneath is the weak point, that is Meta Business Verification. And if what you want is the whole permission chain prepared and submitted properly rather than assembled under deadline, that scope and its pricing are set out separately.
An honest note. Meta reviews and decides these assessments independently. The app administrator must complete and submit the assessment, and Meta strongly recommends developers consult their own legal, policy and security experts. No consultant controls Meta’s decision and no specific outcome or timeline can be promised. What can be controlled is that the evidence is current, the answers are consistent with what Meta already holds, and nothing is left ambiguous enough to trigger a five-day follow-up. This is review preparation and submission support, and it is not affiliated with or endorsed by Meta Platforms, Inc.
Sources: Meta — Data Protection Assessment overview (developers.facebook.com/documentation/resp-plat-initiatives/individual-processes/data-protection-assessment, updated 31 May 2024), Data Protection Assessment FAQ and Contents v3.1 (developers.facebook.com/docs/resp-plat-initiatives/individual-processes/data-protection-assessment/faq and /content), Data Access Renewal (developers.facebook.com/documentation/resp-plat-initiatives/data-access-renewal, updated 23 October 2024) and the Meta Platform Terms. Meta’s Best Practices, Tutorial and Data Security Requirements pages are login-gated and are not quoted here. Reviewed August 2026 — Meta’s documentation changes; verify against the current pages before acting.