App Privacy Requirements for Developers

1) Scope and Principles

Applies to all apps/plugins/modules that connect to Tanqory or are published on App Store/Google Play under the Tanqory or partner brand.
Enforced on developers, PMs, QAs, Security, Legal/Privacy, and outsourced teams involved with code or user data.
Principles: privacy by design/default, data minimization, clear lawful basis, transparency, comprehensive user rights, and security in accordance with international standards.
Read in conjunction with: API License and Terms, AI Developer Guidelines, DPA, Data Classification/Retention, Incident Response, Acceptable Use Policy.
Any deviation or additional data collection must obtain written approval from DPO/Security.
Notification of policy/requirement changes shall be delivered via durable medium (email/developer dashboard).
All code must comply with sandbox/production separation and not use real data in testing environments.
If there is conflict with local laws, the stricter requirements shall prevail.
Developers must undergo privacy & security training at least annually and before releasing high-risk features.
Assessments shall reference this document as baseline and may include additional appendices per project/region.

2) Apple App Store Requirements

Must complete App Privacy Labels accurately reflecting the app's actual behavior, including data collected/sent by Third-Party SDKs.
Support App Tracking Transparency (ATT): Request permission before using IDFA/cross-app/web tracking; provide clear rationale and respect refusals.
Prohibit device fingerprinting/methods to circumvent ATT; Advertising or attribution must be disclosed and comply with Apple's policies.
Location/microphone/camera/Contacts/Photos must use permissions for limited purposes and display clear purpose strings.
Must update Privacy Labels/ATT prompts every time features or SDKs that collect data are added/changed, and ensure alignment with actual behavior.
Account deletion/closure must provide a button or menu as prominent as registration (Guideline 5.1.1(v)), advise users to download/export data before deletion, and send confirmation of deletion results.
Prohibit sideloading code or loading unspecified modules in App Review submission; avoid restricted APIs (private APIs).
Support account deletion per App Store Guideline 5.1.1: Allow account/data deletion from within the app (or specified channels) with completion confirmation.
Must have an accessible Privacy Policy URL, use understandable language, and align with app behavior.
Refusal/withdrawal of data collection must not deprive users of rights beyond necessity (no dark patterns).
Retain evidence of data/feature declarations submitted for App Review for reference in case of audits.

3) Google Play Store Requirements

Complete Data Safety Form in alignment with actual behavior (collection, sharing, security practices) and Third-Party SDKs used.
If using ads/analytics/SDKs that collect Advertising ID, must support "Delete Advertising ID" and not link to other persistent IDs without permission; clearly state reasons for ID usage.
Use runtime permissions appropriately (fine location, background location, camera, microphone, contacts, SMS, storage) and minimize scope.
Do not use "Sensitive permissions" without legally/policy-supported rationale; comply with User Data Policy and Android Permission Policy.
Upon user request for data deletion, must delete from primary systems, Logs/Cache/Backup (per Retention Policy), and notify/order third-party/SDK to delete data; record complete deletion results.
Confirm data/account deletion in Play Console per specified procedures and retain confirmation evidence for verification.
Publish accessible Privacy Policy URL and update when data collection/usage changes.
If features target parents/children, comply with Families Policy/Design and do not use unapproved SDKs for children.
No unspecified code downloading in Play listing; avoid self-updating mechanisms outside Play Store.
Set requestLegacyExternalStorage = false (if possible) and use scoped storage for Android 11+.
Transparently disclose use of specific files/media/directories and do not scan user files unnecessarily.
If sharing data with third parties, state purposes and obtain consent as per Google's policies.

4) Data Protection and User Rights

Use clear legal bases (contract/consent/legal obligation/legitimate interest + LIA) and retain evidence/records of balancing.
Provide transparent notices: purposes, data types, recipients/sharing, retention periods, rights and contact channels; support multiple languages for diverse user groups.
Support data rights: access, rectification, deletion, restriction, objection/opt-out, portability; SLA per shortest legal timeframe (e.g., ≤30 days GDPR/UK, ≤15 days some US states).
In-app account deletion/closure channels must delete production/log/cache/backup data per Retention Policy and record results.
Prohibit collection/transmission of sensitive data (health, biometric, ideology, union, PAN/CVV, RRN/NRIC) without permitted legal basis and additional measures.
Cross-border transfers use SCC/IDTA/BCR/ADGM/DIFC or legally supported exemptions, with TIA and additional measures (EDPB Rec 01/2020).
Children's/youth data must use parental consent mechanisms per local thresholds (COPPA <13, SG/TH practices <13/<10, KR <14, etc.).
Create/update Privacy Policy and in-app notices to match actual behavior and sync with store listings upon any changes.
Update Data Safety/Privacy Labels within the release cycle (or within 7 business days after data behavior changes if not yet released) and review descriptions for clarity.
Set default to opt-out for tracking/targeted advertising in strict jurisdictions (EU/UK/some US states) unless consented.
In the US, provide "Do Not Sell/Share My Personal Information" button/link in-app or via easily accessible link for CPRA and clearly separate "Share" opt-out.
Retain logs of DSAR responses/deletions/corrections/opt-outs as audit evidence.

5) Permission Management, Data Access, and Third-Party SDKs

Principle of least privilege: Request only necessary permissions and at runtime with brief, clear explanations.
Third-Party SDKs/services must undergo due diligence: purposes, data collected/sent, destination domains, retention, legal basis for sharing, and usage for training/marketing.
Must have DPA/data agreements with providers and prohibit SDKs from reusing data for training/marketing without authorization.
Record SDK inventory/versions/permissions/outbound domains; review at least quarterly and upon major updates.
Disable/remove SDKs that collect excessive data or do not support children/youth/ATT/Play Families requirements.
Data transmission endpoints must be HTTPS/TLS1.2+ and not attach secrets in query strings.
Prohibit dynamic code loading from unauthorized sources or unallowlisted CDNs.
Verify license/open-source obligations for used components and maintain required notices.
Logs/telemetry must not collect sensitive data or identifiable personal data beyond necessity.
Upon SDK/permission changes, update store listing + Privacy Policy + in-app notices before release.

6) Security and Technical Standards

Enforce TLS ≥1.2 (recommend 1.3), HSTS, certificate pinning (if possible), and prevent downgrades.
Store keys/tokens in secure storage (Keychain/Keystore); prohibit hardcoded secrets; use key rotation and least privilege.
Protect against reverse engineering with code obfuscation/anti-tamper for mobile; verify signature/installer integrity.
Prohibit logging PAN/CVV/track/PIN or sensitive data in logs/debug; disable debug/verbose in production.
API calls use OAuth2/JWT/mTLS as specified and respect rate limits; for GraphQL, use cost models and avoid overly complex queries.
Prevent MITM/code injection: Check SSL errors, disallow cleartext traffic, use network security config/ATS.
For payment processing, use PCI DSS-compliant providers; if SAQ involved, follow appropriate type.
Locally stored data (at rest) should be encrypted and tied to user/session; use biometric/OS auth when appropriate.
Set Content Security Policy/anti-XSS/anti-clickjacking for webviews or dynamically loaded content pages.
Regularly update libraries/SDKs/frameworks and use dependency scanning/SBOM to reduce supply chain vulnerabilities.

7) Privacy for Children and Youth

If targeting children/youth, comply with COPPA/Families Policy/local laws: Use minimal data, no targeted advertising without proper consent, and prohibit identifiers for cross-service tracking.
Enforce age verification/parental consent mechanisms per local guidelines (<13 US/SG/TH, <14 KR, etc.) and record consent evidence.
Prohibit SDKs/analytics/ads that do not support child mode or do not specify child tracking-free.
Do not collect precise location/microphone/camera if unnecessary and strictly explain purposes.
Provide rapid channels for child data deletion and respond to parental requests within shortest legal SLA.
Prohibit adult content/inappropriate ads/unfiltered external links in child apps.
UI/notifications must be child-friendly, avoid dark patterns or inappropriate incentives for children.
Prepare child/parent-appropriate Privacy Policy/Notice versions when suitable.
Record child/youth risk assessments and review upon new impacting features.
Report and remediate incidents involving child data immediately per Incident Response.

8) Testing and Auditing

Conduct security testing: SAST/DAST/MASVS, dependency scanning, runtime testing, jailbreak/root detection, anti-tamper checks before release.
Conduct privacy testing: Check permissions, data flows, logging, SDK behavior, ATT/consent flows, DSAR flows, account deletion, data minimization.
Pen testing/bug bounty must be approved and follow Tanqory's testing requirements; report vulnerabilities to security@tanqory.com.
Perform privacy review/DPIA/FRIA for new features or material changes and before production deployment.
Retain evidence of test results/remediation reports and track until vulnerabilities are closed; high/critical must be closed before release.
Limit access to build/signing devices and use CI/CD with secret management/least privilege configuration.
Review analytics/telemetry settings to avoid unnecessary PII collection and use sampling/aggregation when possible.
Verify outbound domain allowlist and certificate pinning (if used) in every release.
Implement phased/canary rollout when possible to minimize impact if issues arise later.
Record audit/review results as compliance evidence when agencies or app stores inquire.

9) Documentation, History, and Notifications

Prepare and update: Privacy Policy, in-app notices, Data Map, SDK inventory, DPIA/FRIA, TIA, Logs of DSAR/account deletion.
Retain evidence of consent/opt-in/opt-out, ATT prompt logs, published store listings, and compliant code versions.
Maintain changelog/Release notes specifying data/rights/permission changes and notify users via durable medium upon material changes.
Notify data/security incidents within 24 hours to security@tanqory.com and comply with local laws (e.g., 72 hours GDPR/UK, 3 days PDPA SG, 24 hours PIPA KR if applicable).
Record SLA for complaint/dispute responses and escalation channels (DPO/legal/support).
Maintain version history within document control system; this file shows only the latest version.
Notify deprecation of features/SDKs/endpoints impacting data in advance and provide data migration/code adjustment paths.
For Enterprise/regulatory sectors, attach specific appendices (e.g., banking/health/government requirements) when necessary.
Manage retention: Retain evidence/records per Retention Policy and highest applicable laws.
Contact Channels: dev@tanqory.com (technical), dpo@tanqory.com (rights/data), security@tanqory.com (incidents/vulnerabilities).

10) Pre-Release App Checklist Summary

• Privacy Policy/Store listing/Labels (Apple/Google) align with actual behavior and used SDKs.
• ATT/Consent/Opt-in/Opt-out/DSAR/Account deletion flows fully functional and tested.
• Permissions limited to necessity, with clear purpose strings/notices, and no dark patterns.
• SDK inventory/allowlist domains/telemetry/logging reviewed and do not collect excessive data.
• Security: TLS≥1.2, secret storage, no sensitive data in logs, obfuscation/anti-tamper, dependencies up to date.
• Payments/PCI: Do not store CVV/track/PIN, use PCI DSS-compliant providers, SAQ if required.
• Children: If applicable, comply with COPPA/Families/local, disable targeted ads, parental consent mechanisms.
• Testing: SAST/DAST/MASVS/consent & privacy tests passed, remediation recorded, rollout plan ready.
• Cross-border: SCC/IDTA/BCR/TIA + measures ready, destinations/recipients disclosed in policy.
• Incident/Contacts: Channels to security@tanqory.com/dpo@tanqory.com ready with runbook, durable medium notifications configured.

Version History