Detailed privacy and retention policy
Retention, deletion, lawful basis, disclosure, and anonymization policy.
Retention periods by data type
Retention periods are set by sensitivity and operational purpose.
Account and profile data
Retain while the account remains active and for a limited post-closure period where needed for recovery, audit, fraud prevention, or lawful obligations. Remove or anonymize when no longer needed.
Incidents, cases, assignments, and event timelines
Retain according to the formal safeguarding and legal retention schedule agreed for pilot or production use. These records should not be deleted casually while a case remains active, disputed, or reviewable.
Operational telemetry and diagnostics
Retain only for the shortest period needed for service reliability, abuse prevention, debugging, and security review, then rotate or purge.
Deletion rules by data type
Deletion rules vary by data type and case state.
- Account profile fields that are not required for open-case handling, lawful retention, or fraud prevention should be correctable or removable on request.
- Case-linked records cannot always be deleted immediately where they form part of active safeguarding, legal review, partner accountability, or audit history.
- Public datasets should be rebuilt from anonymized aggregates rather than storing public releases with raw personal identifiers in the first place.
- Where full deletion is not possible, the platform should favor de-identification, restriction, and documented retention reasoning.
Lawful basis by data category
Use is tied to service operation, safeguarding, and governed analytics.
Core platform operation
Account access, security, case coordination, and role-based workflow data are handled because they are necessary to operate the service safely and as requested by the user or partner.
Sensitive response and safeguarding
Highly sensitive case data is handled because it is necessary for emergency response, safeguarding, lawful partner coordination, and the protection of life, health, or public safety where appropriate.
Analytics and product improvement
Demographic and product-usage fields should be used only in anonymized or aggregate form for trend understanding, service design, and public-interest reporting where re-identification risk is controlled.
Public transparency layers
Public data publication should rely on governed anonymized aggregates, documented methodology, suppression thresholds, and a stated public-interest basis rather than exposure of operational case detail.
Child and minor handling
Child and minor cases follow stricter access and disclosure controls.
- Child or minor cases should be flagged for restricted handling and should not be treated as ordinary adult self-report workflows.
- Access should be limited to roles with a defined safeguarding or lawful operational reason to view the case.
- Disclosure, referral, and public publication thresholds must be stricter for minor-related information.
- Any future pilot deployment should document age-sensitive consent, guardian issues, mandated reporting obligations, and emergency exception rules explicitly.
Law-enforcement disclosure policy
Law-enforcement access is governed, not automatic.
- Police visibility should follow role-based workflow assignment or a documented legal and safeguarding basis, not unrestricted browsing.
- External law-enforcement disclosures should be reviewed against lawful obligation, emergency risk, survivor safety, and partner governance rules.
- Any compelled disclosure or exceptional safety disclosure should be documented in the audit trail where legally permissible.
- The platform should preserve a distinction between operational coordination and blanket disclosure of all stored information.
Breach response policy
Incident containment, assessment, notification, and remediation.
- Identify and contain the incident quickly, preserve logs, and suspend affected access where needed.
- Assess which systems, users, and data categories are affected, with special attention to survivor safety risk.
- Notify internal owners, affected partners, and users where required by law, contract, or safeguarding risk.
- Record remediation actions, rotate credentials or sessions where needed, and review whether the incident exposes structural access-control weakness.
Public-data anonymization policy
Public release rules for anonymized and aggregated data.
- Public analytics should be aggregated, thresholded, and stripped of direct personal identifiers before publication.
- Low-volume combinations of facts that could identify a person, location, or incident should be suppressed, grouped, or withheld.
- Public exports should come from governed release datasets rather than direct operational tables.
- Metric definitions, update cadence, and methodology notes should accompany public releases so interpretation does not outrun the data.