A small data path, described plainly.

What the current apps do not send to us.

Polished Play does not receive or store the following from current public Book Builder builds:

• Student, teacher, or family account profiles
• Names, email addresses, or school identifiers
• Device and advertising identifiers
• Analytics events or usage history
• Books, page text, imported photos, or exported PDFs

The standard edition receives an Apple-provided purchase state so the device can recognize Full Unlock. Apple, not Polished Play, handles payment-card information.

Device → Apple service or user-selected destination.

• The current apps do not include Polished Play user accounts, advertising, or third-party analytics and tracking SDKs.
• Student-created content is not processed on Polished Play servers.
• App updates are code-signed and distributed through Apple’s App Store infrastructure.
• A release that introduces a new data path requires review of the privacy policy, security plan, applicable App Store disclosures, and school-facing documentation before publication.
• Support and procurement messages are handled outside the app; schools are asked not to send student information in email.

The organization controls Apple’s side of the path.

Schools can use Apple School Manager and MDM to assign app licenses, configure Managed Apple Accounts, restrict managed-app data movement, and determine whether managed apps may use iCloud storage or backup.

Removing a managed app can remove its data container. Schools should export any book that must be retained before app removal, device reassignment, or reset. Shared iPad deployments should also test account storage quotas and document sync behavior.

Because Polished Play does not hold current Book Builder user content or account records, an incident involving the app is most likely to concern app integrity, distribution, a newly introduced service, or a report from Apple or a school.

Polished Play will assess the affected version and data path, contain or disable the affected functionality where practical, coordinate a corrected build through Apple, and notify affected customers when the facts and applicable requirements warrant it. A response timeline depends on the nature of the event; this plan does not promise a universal notification deadline.

NIST CSF 2.0, used as an organizing lens.

Govern

Define the shipped data posture and require documentation review when that posture changes.

Identify

Maintain an inventory of app data paths, Apple services, release changes, and school dependencies.

Protect

Minimize collection, avoid unnecessary services, and rely on Apple’s signed distribution and school controls.

Detect

Review reports from users, schools, Apple, and release testing for unexpected data behavior or app integrity issues.

Respond

Assess scope, contain affected functionality, communicate based on verified impact, and prepare a corrected release.

Recover

Distribute a corrected app, restore documented operation, and revise controls and guidance based on the incident.

This plan is reviewed when Book Builder’s data flow or service providers change and should also be reviewed before a materially different app release. Questions may be sent through the Polished Play contact page.