Data Protection Policy

1 Purpose & scope

This Data Protection Policy describes how Slatify safeguards personal data it collects, stores and processes as part of operating the Service described in our Privacy Policy. It applies to Slatify's own systems and staff, and to any subprocessor engaged to handle personal data on our behalf. It is intended to give schools, guardians, partners and regulators a clear, auditable picture of our data protection program.

2 Data protection principles

We design and operate Slatify around the following principles:

• Lawfulness, fairness & transparency — we process personal data on a valid legal basis (consent, contract, legal obligation, or legitimate interest) and explain that basis in plain language.
• Purpose limitation — data collected for one purpose (e.g. verifying a teacher) is not repurposed for an unrelated one (e.g. advertising) without a new lawful basis.
• Data minimization — we collect the least data needed to run a feature. We do not ask for a mobile‑money PIN, a full card number, or precise location, because we don't need them.
• Accuracy — users and guardians can correct inaccurate profile, learning and account data.
• Storage limitation — data is retained only as long as necessary; see the retention schedule.
• Integrity & confidentiality — technical and organizational safeguards protect data against unauthorized access, alteration, disclosure or loss.
• Accountability — we document these practices, review them regularly, and can demonstrate compliance to a school, partner or regulator on request.

3 Roles & responsibilities

4 Data classification

We classify data so that handling requirements scale with sensitivity:

5 Technical safeguards

• Encryption in transit: all traffic between the app and our servers is encrypted (TLS).
• Encryption at rest: databases and backups holding personal data are encrypted at rest.
• Credential security: passwords are stored using salted, one‑way hashing — never in plain text — and session tokens are short‑lived and revocable (including a "log out other devices" control).
• No raw payment data: Slatify's systems are architected to never receive or store mobile‑money PINs or full card numbers; payment partners handle those directly.
• Role‑based access control: internal systems grant access on a least‑privilege, role‑based basis (e.g. a support agent cannot see wallet PIN‑equivalent data because it doesn't exist in our systems at all).
• Audit logging: sensitive actions — guardian linking, wallet funding, roster changes, admin actions — are written to an audit trail, including the guardian‑facing Guardian Audit Log.
• Secure mobile storage: on‑device secrets (such as session tokens) are stored using the platform's secure storage (Keychain on iOS, Keystore‑backed storage on Android), not plain app storage.
• Network‑level monitoring: automated detection for anomalous sign‑in patterns and abuse (e.g. credential stuffing, rapid wallet activity).

6 Organizational safeguards

• Least‑privilege access: staff access to personal data is granted on a need‑to‑know basis tied to their role, reviewed periodically, and revoked immediately on role change or departure.
• Confidentiality commitments: everyone with access to personal data is bound by confidentiality obligations, including staff and contracted subprocessors.
• Training: staff who can access children's, financial or communications data receive specific training on this Policy and on child‑safety escalation before being granted access.
• Vendor due diligence: subprocessors are assessed for their own security practices before onboarding, and bound by a data processing agreement — see §12.
• Incident response plan: a documented process for detecting, containing, assessing and notifying stakeholders about a security incident — see §11.
• Change management: features touching sensitive data (payments, messaging, child accounts) go through a safety and privacy review before release.

7 Financial & wallet data protections

Slatify Coins and Campus Fund are closed‑loop, in‑app balances funded through licensed mobile‑money and payment partners. Specific protections include:

• Wallet funding for a student account requires an approved guardian link — a student cannot self‑fund an unlinked wallet from an external payment method.
• Every top‑up and purchase produces an immutable, timestamped transaction record; a canteen item's or content's description is frozen at the moment of sale, so later edits or deletions never rewrite past receipts.
• Slatify does not store mobile‑money PINs, passwords, or full card numbers — see §5.
• Automated fraud monitoring flags unusual funding or spend patterns for manual review.
• Disputed or failed transactions follow a documented refund process coordinated with the relevant payment partner.
• Vendor settlement data is scoped to the transactions a vendor is actually party to — a vendor never receives a student's full wallet history.

8 Special protections for minors

• Guardian linkage is required before a student account can hold or spend wallet funds, consistent with our Privacy Policy.
• No behavioral advertising is served to student accounts, and student activity is not used to build advertising profiles.
• Stricter default visibility: a student's posts, profile and content default to school‑community visibility, not the open internet, and private messaging defaults to contacts within shared classes or approved contacts.
• Shorter internal access windows: support staff access to a student account for troubleshooting is time‑boxed and logged.
• Retention limits: we do not keep a departed student's personal data indefinitely — see the retention schedule.
• Mandatory escalation: any staff member who becomes aware of a genuine child‑safety risk (for example, a grooming attempt or a threat of harm) follows a mandatory escalation process to Trust & Safety leadership and, where appropriate, external authorities — regardless of standard data‑minimization practice.

9 Retention schedule

Where we're required to keep certain records longer than the account itself (most commonly financial records), we restrict access to that residual data to what's needed to meet the legal obligation.

10 Data subject requests

To request access to, correction of, export of, or deletion of personal data, contact privacy@slatify.app. We will:

1. Verify your identity (or, for a guardian, your linkage to the relevant student account);
2. Confirm what we can act on immediately versus what's subject to a legal retention obligation (for example, financial records);
3. Respond within the timeframe required by applicable law (commonly 30 days, extendable once with notice for complex requests); and
4. Provide a way to escalate or appeal if you're unsatisfied with the outcome.

11 Breach notification

If we confirm a security incident that puts personal data at risk, we follow a documented process:

1. Detect & contain — isolate the affected system and stop ongoing exposure.
2. Assess — determine what data and how many users are affected, and the likely risk to those users.
3. Notify — notify affected users and, where legally required, the relevant data protection authority, without undue delay (and within any shorter timeframe set by applicable law, such as 72 hours under GDPR, once the breach is confirmed).
4. Remediate — close the underlying gap and, where relevant, offer affected users clear steps to protect themselves (for example, a forced password reset).
5. Review — conduct a post‑incident review and update this Policy or our controls where the review identifies a gap.

12 Subprocessors & international transfers

We rely on a limited set of subprocessors to run the Service — for example, cloud hosting, push‑notification delivery, and payment processing. Each is bound by a data processing agreement requiring safeguards consistent with this Policy, and is used only for the purpose we've engaged it for. Where personal data is transferred internationally, we use legally recognized safeguards (such as standard contractual clauses) appropriate to the transfer.

13 Audits & reviews

We review this Policy and the safeguards behind it at least annually, and whenever we launch a feature that materially changes how we handle personal data (particularly children's or financial data). Reviews may include internal audits, and, as the platform matures, independent third‑party security assessments.

14 Contact the data protection team