Data Privacy & Compliance

Joryio includes built-in GDPR and CCPA compliance tools to help you manage data subject requests, configure privacy settings, and maintain audit trails for regulatory compliance.

Data Subject Requests (DSR)

Data subject requests allow you to process erasure (right to be forgotten) and data export (data portability) requests for individual users.

Creating a DSR

1. Open the Data Subject Requests page (at /compliance/dsr in your dashboard)
2. Click New Request
3. Enter the User ID of the data subject
4. Select the request type:
   • Export: Collects all personal data across all systems into a downloadable JSON archive
   • Erasure: Permanently deletes or anonymizes all personal data across all systems
5. Click Create Request

You can also create DSRs directly from a user's profile page using the Export Data or Erase Data buttons.

DSR Processing

Each DSR is processed asynchronously across all data stores:

Store	Data Affected
Profile store	User profile, devices, aliases, list subscriptions, canvas executions
Engagement store	WhatsApp messages/conversations, SMS messages, in-app impressions, variant assignments
Analytics event store	Analytics events (including message opens/clicks) and rendered messages
S3	Export files and wallet pass files

Processing steps are tracked individually, so you can monitor progress in real-time on the DSR detail page.

Deadline Tracking

Deadlines are automatically calculated based on the applicable regulation:

• GDPR: 30 days from request creation
• CCPA: 45 days from request creation

Overdue requests are flagged daily and logged in the compliance audit trail.

Downloading Exports

For export DSRs, once processing is complete:

1. Go to the DSR detail page
2. Click Download Export
3. The export file stays available for 24 hours after processing; each generated download link is valid for 1 hour

The export file is a gzipped JSON archive containing all personal data organized by data store.

Privacy Settings

Open the Data Privacy & Compliance settings page (at /settings/privacy in your dashboard) to configure organization-level privacy settings.

Default Regulation

Set the default regulation framework (GDPR or CCPA) that applies to new DSR requests. This determines the default deadline period.

Data Retention

Configure how long different types of data are retained:

Setting	Description	Default
Events Retention	Analytics events	730 days (2 years)
Tracking Retention	Message opens and clicks	None - tracking events follow the events retention unless you set a shorter window (7–365 days)
Audit Log Retention	Compliance audit entries	180 days
Export File Retention	DSR export files on S3	24 hours

Erasure Behavior

• Anonymize instead of delete: When enabled, an erasure keeps the user's event/message rows but irreversibly de-identifies them - the user identifier is replaced with a random, non-reversible token and every identifying field is scrubbed (event properties, anonymous/session/device ids). Only non-personal analytics dimensions (event name, timestamp, campaign/channel) remain, so aggregate analytics stay intact while the person can no longer be identified. When disabled, the records are hard-deleted.
• Retain aggregate statistics (Enterprise add-on): For customers who require a true hard delete (not anonymization) but still don't want dashboards to drop, this keeps scrubbed, de-identified event rows so campaign totals and funnels survive - while every PII store (profiles, messages, devices) is fully deleted.

Enterprise add-on

Retain aggregate statistics is an enterprise add-on. It can only be turned on for your organization by the Joryio team through our admin console - it is not self-serve. Until it's enabled the toggle stays disabled on this page. Once we enable it, you control whether to apply it per erasure from here. Contact us to add it to your plan.

tip

Anonymization alone already preserves aggregate analytics and satisfies erasure, so most organizations don't need the hard-delete add-on. Choose the add-on only when a policy or regulator specifically requires actual deletion rather than anonymization.

Privacy Contact (DPO)

Configure your Data Protection Officer's contact information:

• DPO Name and Email: Displayed in compliance records
• Privacy Policy URL: Link to your organization's privacy policy

Marking data as personal (PII)

Personal data is stored normally and hidden at read from users who lack the pii:view permission. Marking a field as PII does not delete it or change what you can do with it - you can still segment and target on it exactly as before. It controls who sees the values.

What is personal by default

Fields the platform defines are covered without any setup - email, phone, firstName, lastName, address fields, date_of_birth, postal_code, ip_address, national_id and similar. These match in any casing, so first_name and firstName are the same field.

We do not guess beyond that list. A field called plan_name, store_name or emailSubject is ordinary data, because guessing from names gets it wrong in both directions - and a field wrongly marked as personal has its values hidden from your own team for no privacy gain.

Marking your own fields

Anything you send is yours to classify:

• Attributes - Settings → Data Dictionary, the PII toggle on the row.
• Event properties - Settings → Data Dictionary, open an event and use the PII toggle on the property.

email and phone cannot be un-marked. They are the addresses the platform delivers to, so their contents are not a matter of configuration.

What changes when a field is marked

Where	Effect
Data Dictionary & Event Explorer	example values hidden without pii:view
Segments & targeting	unchanged - you can still filter on it
Campaign personalization	unchanged
AI assistant context	values withheld from the model
Predictive models	the field is excluded from training

The last row is the one that behaves differently on purpose. Display can be undone by unticking the box; a value learned into a model cannot. So fields that are personal by nature stay out of training even if you untick them, and identifiers such as externalId are never trained on although they are shown normally.

The "ID?" hint

Some properties are flagged with a small ID? marker. That means their values behave like identifiers - a new value on almost every event, or roughly one per person - which a name alone cannot reveal. It is a prompt to review, not an automatic decision: nothing is hidden or excluded because of it.

Compliance Audit Log

All compliance-related actions are logged in an immutable audit trail, accessible from the Data Subject Requests page (audit entries are visible on each DSR's detail page).

Logged actions include:

• DSR creation, processing, completion, failure, and cancellation
• Export file downloads
• Privacy settings changes
• Overdue deadline warnings

Important

The subscription audit log is never deleted during erasure requests (GDPR Article 17(3)(b)). Instead, user identifiers are anonymized to maintain proof of consent while removing PII.

Quick Actions from User Profile

On any user's profile page, you'll find two compliance action buttons:

• Export Data: Creates an export DSR for the user
• Erase Data: Creates an erasure DSR for the user (requires confirmation)

These are shortcuts that create DSR requests with the same processing pipeline.