Read a Media App Privacy Policy With Ten Questions
Ten consistent questions turn privacy-policy reading into an evidence exercise covering scope, categories, purposes, actors, sources, flows, retention, security, controls, and revision.
In short: Read the policy for scope, then answer ten questions: which service is covered, what data categories and examples appear, why they are used, who receives them, how connected sources fit, where data may be processed, how long it remains, which security claims are specific, which user controls exist, and how changes are announced. Mark answers clear, partial, absent, or outdated, cite the section and date, and ask support about gaps.
This scorecard improves comprehension; it is not a legal-compliance test. A short policy can be precise, while a long policy can leave an operational question unanswered.
1. What exact service does the policy cover?
Find the named operator, website, applications, device platforms, and effective or updated date. Check whether help pages, payment, a connected source, or an external store has its own notice.
Use the privacy basics guide to separate the media player, device platform, store, and compatible source before filling the rest of the scorecard.
2. Which data categories have concrete examples?
Look for account, source settings, usage, preferences, devices, pairing, entitlement, technical logs, network addresses, and downloads. A category should be tied to examples so the reader can recognize it.
Mark “personal information” without examples as partial, not automatically bad. The next action is a factual clarification.
3. What purpose is stated for each category?
Connect every category to a stated service purpose. Avoid replacing policy language with guesses such as “probably analytics.” Distinguish account security, synchronization, source connection, access verification, support, and reliability.
4. Which actors receive or process data?
List named providers, generic provider categories, stores, payment services, and the user-selected source. Record the stated function and data relationship.
The third-party processor review helps ask whether names, purposes, links, sub-processors, and change mechanisms are available without assuming every third party has the same role.
5. How does a connected source change the flow?
Find who selects and controls the source, which settings are used to connect, when requests occur, and which source terms apply. A service can be responsible for its own processing without controlling everything the independent source does.
Never put private source credentials into the scorecard.
6. Where may data be stored or processed?
Separate on-device, synchronized cloud, provider infrastructure, store, and source locations. Then read any international-processing section. “May be processed in other countries” is a statement to record, not a complete map.
7. What retention rule applies?
Look for exact durations, account-status events, purpose-based criteria, deletion or anonymisation outcomes, backups, and limited exceptions. Use the retention-language guide for a category-by-category table.
Mark a rule as partial when it gives an event but no explanation for important categories. Do not invent a duration.
8. Which security statements are specific?
Record the data and state protected: traffic in transit, password storage, eligible on-device downloads, account access, or provider controls. Note qualifiers such as “where available.”
A security section is not a guarantee against every incident. Avoid converting “we work to protect” into an unsupported technical claim.
9. Which controls and contact routes exist?
Find account access, update, deletion, preference, download, device, support, and contact paths. Test only safe, reversible controls. Do not submit an account-deletion request merely to verify that the button exists.
Record location-specific rights as policy statements, not individualized legal advice.
10. How are policy changes communicated?
Check the “last updated” date, material-change notice language, archive availability, and in-product communication. Use the policy-change audit to compare meaning rather than only word count.
Original evidence: ten-question privacy policy scorecard
| Question | Section | Evidence note | Clear / Partial / Absent | User impact | Follow-up |
|---|---|---|---|---|---|
| Service scope and date | |||||
| Categories and examples | |||||
| Purposes | |||||
| Actors and sources | |||||
| Location and transfers | |||||
| Retention and outcomes | |||||
| Security and controls | |||||
| Change communication |
Common mistakes and limitations
- Scoring length instead of specificity.
- Treating “absent” as a proven hidden practice.
- Copying passwords or source settings into notes.
- Ignoring a separate store or source notice.
- Turning security wording into an absolute guarantee.
- Assigning legal roles without factual analysis.
- Comparing policies from different dates without noting them.
Frequently asked questions
Should every answer be in one policy?
Not necessarily. A policy may link to settings, processor lists, terms, or support, but the reader should record where each answer lives.
Does an absent detail prove misuse?
No. It identifies a disclosure gap or reading gap that should be clarified through official sources.
Can this scorecard determine compliance?
No. It supports data literacy; legal assessment depends on applicable rules, facts, contracts, and qualified advice.
Your next step
Apply the Questions to Norva's Policy