Security & data handling

Phosra handles children's data, so the bar is higher than "we take security seriously." This page is the developer-facing reference: exactly which fields each object stores, how long they live, how to erase them against a real endpoint you can call right now, how data is encrypted, where it lives, who the subprocessors are, and how to report a vulnerability.

Data minimization — collect the least that works

Phosra is a control plane for parental-controls policy, not a data lake. It stores the metadata needed to compile and enforce a policy, and nothing it does not need. The core object model is the whole surface — there is no hidden telemetry object.

What each object stores

What Phosra never does with child data

Retention

Retention windows are parent-configurable, and defaults follow the most conservative applicable statute (COPPA / UK AADC). The exact numeric windows and the backup-rotation period are governed by the DPA rather than the API — request them from [email protected] for a security review. They are tagged policy preview here because they are not readable from the sandbox or OpenAPI spec.

Right to erasure — a real, runnable flow

Erasure is not a support ticket. Deleting a Family cascades to every Child, ChildPolicy, PolicyRule, and enforcement record beneath it, and deleting a single Child erases just that child's subtree. Both are ordinary DELETE calls that return 204 No Content.

Erase a single child

DELETE /children/{childID} removes the child profile and its entire policy subtree.

bash
# childID from when you created the child (or POST /setup/quick)
curl -i -X DELETE "$PHOSRA_BASE_URL/children/e6e094ee-de89-4dc2-98b2-cd3c3a28309e"
# → HTTP/2 204

Verify it's gone — a read of the erased child returns 404, not a soft-deleted tombstone:

curl -s "$PHOSRA_BASE_URL/children/e6e094ee-de89-4dc2-98b2-cd3c3a28309e"
# → 404  {"error":"Not Found","message":"child not found","code":404}

Erase the whole household (cascade)

DELETE /families/{familyID} erases the family and everything beneath it in one call — proven live: a child created under the family reads 404 immediately after the family delete.

bash
curl -i -X DELETE "$PHOSRA_BASE_URL/families/ec5bc0d7-e02c-42f8-b821-c71d926f27d2"
# → HTTP/2 204
 
# The child that lived under it is now gone too:
curl -s -o /dev/null -w "%{http_code}\n" \
  "$PHOSRA_BASE_URL/children/d48d0260-1881-449e-98f8-7aa21dae546c"
# → 404

Data portability / export

Machine-readable JSON exports for portability (GDPR Art. 20 / CCPA) are available on request — email [email protected]. There is no self-serve export endpoint on the API today (a GET …/export returns 404) — we say so plainly rather than imply one exists. A self-serve export API is policy preview.

Encryption

Data residency & subprocessors

US-primary data residency across all subprocessors. Phosra updates this list when the data path changes; the Trust Center is the authoritative copy.

Need the signed subprocessor DPA for your vendor review? Request it at [email protected].

Regulatory alignment

Phosra maps its controls to the statutes that govern children's data. Conformance is evidence a regulator can weigh — not an approval Phosra issues, and not a safe harbor.

See the compliance hub for the per-statute detail pages.

Report a vulnerability

Phosra welcomes good-faith security research.

1. 1
   Email [email protected]

   Send findings to [email protected]. We triage within one business day and keep you updated through remediation.

2. 2
   Stay in scope

   Don't access data that isn't your own, don't test against production parent or child accounts, and don't run scanners that degrade service. Use the open sandbox for testing — it holds only synthetic data.

3. 3
   Coordinated disclosure

   Give us a reasonable window to remediate before public disclosure. With your permission, we credit researchers in our disclosure log.

Where to go next