Record of Processing Activities (GDPR Article 30(2))¶

Purpose. Soon's processor record of processing activities, required by Article 30(2) GDPR. It is the document a supervisory authority asks for first, and the one enterprise buyers request during security review. It also satisfies A.5.34 (privacy and protection of PII) and supports A.5.31 (legal requirements).

Soon is a processor, not a controller, for customer workforce data. The customer decides why and how their employees' data is processed; Soon processes it on their documented instructions. Soon is a controller for its own employee and prospect data, which is recorded separately in §6.

1. The processor and its representative¶


Processor	Soon Technologies B.V., Netherlands
Contact for data protection	security@soon.works
Representative in the EU	Not applicable — Soon is established in the EU
Data Protection Officer	Not appointed. Assessed under Art. 37: Soon does not carry out large-scale systematic monitoring, nor large-scale processing of special categories, as a core activity. The analysis is recorded in the Privacy and Personal Data Protection Policy §2.6 and is revisited annually

2. Controllers on whose behalf Soon processes¶

Article 30(2)(a) asks for each controller. Naming every customer in a document that is shared externally would itself disclose the customer list, so controllers are recorded here by category, with the identified list held in the CRM and the executed DPAs in Drive.

Category of controller	Relationship	Where identified
Enterprise customers	Signed MSA + DPA	Google Drive → Legal → Customers
Self-serve customers	DPA incorporated into the online terms at soon.works/legal/terms	Attio (CRM) + billing records in Stripe
Trial and pilot accounts	Same terms as self-serve for the trial period	Attio

An identified, current controller list is available to a supervisory authority on request.

3. Categories of processing carried out for controllers¶

Article 30(2)(b). Soon carries out these operations on customer personal data:

Processing activity	Purpose (set by the controller)	Categories of data subject	Categories of personal data
Workforce scheduling	Creating, publishing and amending shift schedules	The controller's employees and contractors	Name, work email, role, team, skills, employment identifiers
Availability and leave management	Recording availability, leave requests and approvals	Same	Working hours, availability, leave dates and types — may include absence records (see §7)
Demand forecasting and auto-scheduling	Predicting demand and proposing assignments	Same	Historical schedule and activity data
Time and activity tracking	Recording worked time and intraday activity	Same	Timestamps, activity categories
Authentication and access	Letting users into the controller's tenant	Same	Email address, authentication identifiers, SSO attributes, IP address
Notifications	Sending schedule and account notifications	Same	Name, email address, device push tokens
Support	Responding to user questions	Users who contact support	Name, email, the contents of the conversation
Optional integrations	Only where the controller enables them — calendar sync, contact-centre platforms	Same	Calendar identifiers, agent identifiers, activity data
Optional location features	Where the controller uses location-based scheduling	Same	Work location, address input

Retention. For the duration of the customer contract, then deleted 90 days after contract end; backups age out on their own cycle. Per the Records Retention & Protection Policy.

4. Sub-processors and third-country transfers¶

Article 30(2)(c). The full list, with what each one does, is the Vendor & Sub-processor Register. Recorded here is the transfer position for each.

Sub-processor	Role	Location	Transfer mechanism (checked 2026-09-09)
Amazon Web Services (incl. SES)	Hosting, database, transactional email	eu-west-1, Ireland	No transfer — data remains in the EU
PostHog	Product analytics	EU Cloud	No transfer (verified in code 2026-08-22)
Cloudflare	DNS, CDN, hosting	Global edge	DPF (Cloudflare self-certifies; its DPA states transfers under the DPF are not a Restricted Transfer), with EU SCCs Module 3 as fallback — Module 3 applies expressly where the customer is a processor
Stripe	Payments	EU / US	DPF + EU SCCs Module 2 (controller-to-processor). Module 2, not 3, because Soon is the controller of billing contact data — it is Soon's own commercial data, not customer workforce data
WorkOS	Enterprise SSO	US	EU SCCs Module 3 — WorkOS's DPA names Module Three where the subscriber is itself a processor. No DPF certification is claimed, so the SCCs are the whole basis here, not a fallback
Intercom	Support	US	DPF (EU-US, Swiss-US and UK-US), with SCCs Module 3 as an express fallback if the DPF is invalidated
Sentry	Error tracking	US (confirmed 2026-09-09)	DPF, with SCCs Module 3 as fallback — Sentry's DPA names Module 3 where the customer is a processor
Cloudinary	Media hosting	EU / US	DPF (Cloudinary, Inc. self-certified), with EU SCCs Module 2 or 3 as applicable
OpenAI	AI features	US (contracting entity OpenAI Ireland Limited)	EU SCCs Module 3 (its DPA names Module Three where the customer is a processor), with the DPF where OpenAI holds a valid certification
Google (Workspace, Maps)	Collaboration, address lookup	EU / global	DPF — Google LLC has certified adherence to the DPF Principles — plus SCCs where a transfer is not covered by an adequacy decision

How this was established. Each mechanism was read from the provider's own data processing addendum on 2026-09-09 and the SCC module recorded, because the module matters: Soon is a processor, so transfers to sub-processors are Module 3 (processor-to-processor), not the Module 2 most templates assume. The exception is Stripe, where Soon is the controller of its own billing data.

Re-check annually and on any DPA change. A DPF certification can be withdrawn, and the mechanism then falls back to the SCCs — which is why every row above records a fallback rather than relying on the DPF alone.

Transfer impact assessments. Required where identifiable personal data reaches a non-adequate destination. Two are outstanding: Intercom (identifiable support conversation content) and OpenAI (see §7.1 — the assistant sends unanonymised personal data). WorkOS carries authentication identifiers under SCCs with no DPF, so it is third in line. Tracked as S-411.

On the two US vendors we are migrating. Sentry (S-540) and Intercom (S-303) are both covered today by a valid mechanism, so neither migration is required to make the transfer lawful. They reduce exposure and simplify the story for enterprise buyers; they are not compliance blockers, and should be scheduled as improvements rather than fixes.

4.1 What the AI features actually send (V-4, answered 2026-09-09)¶

Read from soon-server on 2026-09-09. There are two AI paths and they differ, which matters because only one of them is anonymised.

Path	Code	What reaches OpenAI
Auto-scheduling / target-state	`src/models/ai.ts`	Names are replaced with tokens (`u1`, `u2`…) by `src/util/nameAnonymizer.ts` before the prompt is built, and mapped back on return. Shift times, hours, activity types and schedule structure still go, but not names. This is pseudonymisation, not anonymisation — Soon holds the mapping, so it remains personal data in law
Assistant / chat, conversation titles, and the other model calls	`src/lib/assistant/*`, `src/lib/ai.ts`, `src/resolvers/Mutation/activities.js`	No anonymisation at all. The anonymiser is not imported on any of these paths. Planners type free text that routinely names people, and the assistant's tools (`get_schedule`, `find_users_on_board`, `list_team_users`) return real employee records into the model context

Conclusion. OpenAI does receive customer personal data — names, schedules and free-text content — through the assistant. It is correctly listed as a sub-processor in the public DPA, and it needs a transfer impact assessment. The common assumption that "we anonymise before sending to AI" is true of the scheduling feature only.

The decision, taken by the owner on 2026-09-09: do not anonymise the assistant. Tokenising names there would make the feature unusable — a planner asks the assistant to move a named person's shift, and the assistant's tools return real employee records by design. Nor is switching provider realistic: there is no EU-based model provider on par with the frontier labs.

The chosen remedy is residency, not redaction. OpenAI offers European data residency for the API Platform, where requests are handled in-region under zero data retention. That is a better outcome than anonymisation, because no customer personal data leaves the EU at all. It is set per project at creation and enabled for the organisation by OpenAI rather than self-serve, so it needs starting early — tracked as S-542.

Until that lands, the position is stated plainly: the assistant sends customer personal data to OpenAI in the United States under SCCs Module 3, and a transfer impact assessment is outstanding (S-411). Completing S-542 removes the transfer, and with it the need for that assessment.

Sub-processor changes are notified to controllers per the DPA before the new sub-processor begins processing.

5. Technical and organisational measures¶

Article 30(2)(d), by reference to Article 32(1). Described in full in the Security Overview and the policies it cites. In summary: encryption in transit (TLS 1.2+) and at rest (AES-256); role-based least-privilege access with MFA on the AWS console and Google Workspace; segregated environments; centralised logging with continuous threat detection; peer-reviewed change management; automated dependency and vulnerability scanning; Multi-AZ hosting with point-in-time recovery; and a documented incident-response process with a defined breach-notification path.

6. Soon as controller (its own data)¶

Recorded for completeness — this part falls under Article 30(1).

Activity	Data subjects	Data	Retention	Basis
Employment and payroll	Founders, contractors	Contract, payroll, banking	Statutory (NL)	Legal obligation / contract
Sales and marketing	Prospect contacts	Name, work email, company	Until objection or 24 months inactive	Legitimate interest
Website analytics	Site visitors	Usage events, IP	Per provider settings	Consent — gated by the cookie banner
Support and billing	Customer contacts	Name, email, billing details	Contract + statutory	Contract

7. Absence and sickness data — a deliberate position¶

Leave management is a core function, so the product can hold absence records. Dutch law is unusually strict here: the Autoriteit Persoonsgegevens permits an employer to record that someone is absent and the expected duration, but not the nature of the illness.

Soon's position: the product records absence as a category and a period. It does not ask for, and controllers should not enter, a medical reason. Where a controller's own configuration permits free-text entry against an absence, that field is under the controller's control and Soon's guidance is that it must not carry health information.

TODO(owner): confirm with Thomas which absence-related fields the product exposes, including whether any free-text field can reach an absence record, so this position is stated from the schema rather than from intent.

8. Assisting controllers¶

Under Article 28(3)(e) Soon assists controllers with data-subject requests. In practice a controller can export or delete their own tenant's data through the product; where they cannot, security@soon.works handles the request and Soon responds within 5 working days so the controller can meet its own one-month deadline. Deletion actions are recorded in Linear.

Change log¶

Version	Date	Author	Comments
0.1	2026-08-22	ISMS	First version — the Article 30(2) processor record the Privacy Policy referenced but which had never been written. Controllers recorded by category; nine processing activities described; transfer mechanisms listed per sub-processor with the open ones marked; the Dutch absence-data position stated.