Privacy, Security, Anonymity, and Data Retention

Terminology warning

The user requirement uses “retention period” to mean when a question may be asked again. In the product and code, call that exposure cooldown.

Reserve data retention for how long personal data, responses, comments, and reports are stored. Combining these concepts in one field creates serious privacy and deletion risks.

Privacy principles

• Purpose limitation: every program declares why data is collected.
• Data minimization: collect only what is needed for that purpose.
• Storage limitation: define deletion or review periods.
• Transparency: explain who can see individual, group, and narrative data.
• Access control: use least privilege and explicit role scopes.
• Separation: keep respondent identity mapping separate from response content where possible.
• Deletion: support subject and respondent rights while preserving lawful aggregate data only when truly anonymized.

The European Commission’s GDPR guidance states that personal data should be kept for the shortest time possible and that organizations should establish time limits for deletion or review. It also distinguishes truly irreversible anonymization from pseudonymization, which remains personal data.

Data classes

Suggested configurable retention categories

These are product defaults to validate with legal counsel, not universal legal requirements:

• respondent identity linkage: 12–24 months after survey closure
• raw ratings: 24–36 months
• narrative comments: 12–24 months
• individual reports and PDP history: 36–60 months or employment plus a short closure period
• de-identified organization trends: longer only after re-identification assessment
• audit logs: 24–84 months depending on contractual and security requirements
• source import files: delete after confirmed extraction unless the customer opts to retain them

Each tenant must be able to set a policy, review date, and legal hold.

Anonymity architecture

Separate identifiers

Use a response pseudonym generated for a survey context. Store the identity mapping in a separate encrypted service or table with a narrower permission boundary.

Thresholds

• default peer/direct-report/customer group threshold: 3
• configurable higher threshold for sensitive contexts
• no “difference attack” where adding or removing one response reveals a person
• comments should not be displayed in ways that identify a small group through language, time, or context

External raters

• use expiring signed links
• explain purpose, visibility, and retention
• avoid requiring an account unless necessary
• do not place external raters in the paid-seat count
• allow withdrawal before survey closure where legally appropriate

Security controls

Baseline

• encryption in transit and at rest
• tenant-scoped authorization on every query
• row-level or service-level tenant isolation
• secure secrets and key rotation
• MFA for administrators
• audit of access, export, impersonation, and policy changes
• rate limiting and abuse prevention
• backup, recovery, and tested deletion propagation
• secure software-development lifecycle

Enterprise

• SAML SSO and SCIM
• customer-managed keys where commercially viable
• regional data residency
• IP restrictions and conditional access
• dedicated or logically isolated data plane option
• configurable retention and legal hold
• security logs and SIEM export
• custom DPA, SLA, and subprocessor commitments

AI controls

• Do not train shared models on tenant data without explicit contractual permission.
• Make AI summaries traceable to source evidence.
• Use human review for consequential interpretations.
• Allow tenants to disable AI by function: authoring, translation, comment themes, summaries, coaching.
• Redact direct identifiers before external model calls where possible.
• Store model, prompt-template, policy, and output version for audit.
• Do not infer protected characteristics or mental-health status.

Deletion workflow

1. Identify data subject and tenant authority.
2. Resolve legal hold and contractual obligations.
3. Delete or anonymize directory data, raw responses, narrative comments, PDP data, imports, and backups according to policy.
4. Recalculate aggregates if deletion could change anonymity or scores.
5. Record a non-content deletion audit event.
6. Confirm completion to the tenant.

Data export

Exports should be entitlement- and role-controlled. Provide:

• individual report export
• tenant aggregate export
• raw response export only to authorized roles
• comments as a separate sensitive export
• source and mapping fields for imported assessments
• deletion-safe identifiers rather than unnecessary personal information

Reference sources

• European Commission, “For how long can data be kept and is it necessary to update it?”: https://commission.europa.eu/law/law-topic/data-protection/rules-business-and-organisations/principles-gdpr/how-long-can-data-be-kept-and-it-necessary-update-it_en
• European Commission, “Data protection explained”: https://commission.europa.eu/law/law-topic/data-protection/reform/what-does-general-data-protection-regulation-gdpr-govern_en
• European Commission, “What data can we process and under which conditions?”: https://commission.europa.eu/law/law-topic/data-protection/rules-business-and-organisations/principles-gdpr/overview-principles/what-data-can-we-process-and-under-which-conditions_en