Data Processing Agreement

Version 2.1 · Effective 2 November 2026 · Article 28 GDPR. Concluded electronically as part of the agreement for access to the contentmaker.space platform.

Parties

1. The Client: the business that has concluded an agreement for access to the contentmaker.space platform, whether online through the Platform's signup and subscription checkout or in a separately signed written agreement (the "Controller"); and
2. contentmaker.space BV, registered with the Belgian Crossroads Bank for Enterprises (KBO) under number 1019179691, with its registered office at Bampslaan 21 3.01, 3500 Hasselt, Belgium (the "Processor"),

each a "Party".

This Data Processing Agreement (the "DPA") governs the processing of personal data by the Processor on behalf of the Controller in the course of providing the contentmaker.space platform under the Processor's General Terms and Conditions and any order form or written agreement that refers to them (together, the "Main Agreement"). It satisfies the requirement of Article 28(3) and (9) of Regulation (EU) 2016/679 (the "GDPR") that processing by a processor be governed by a contract in writing, including in electronic form.

This DPA forms an integral part of the Main Agreement. It is concluded when the Controller accepts the General Terms and Conditions (at workspace creation, at checkout, by signing an order form that refers to them, or by accepting this DPA in the Platform), and no separate signature is required for it to apply. A copy signed by the Processor is available on request (Article 12.5).

Article 1. Definitions and roles

1.1 Terms used in this DPA that are defined in the GDPR have the meaning given to them in the GDPR, in particular personal data, processing, controller, processor, data subject, personal data breach and supervisory authority. "Sub-processor" means a processor engaged by the Processor to carry out processing of Customer Data on behalf of the Controller.

1.2 In this DPA:

• "Platform" means the contentmaker.space platform as described in the Main Agreement, including its web, desktop and mobile applications;
• "Workspace" means the Controller's account on the Platform, to which its users belong;
• "Authorised User" means a person the Controller has invited to, or allowed into, its Workspace, including members with limited seats and external collaborators the Controller has given access to specific projects;
• "Customer Data" means any personal data contained in content and data that is uploaded to, entered into, recorded in, imported into or generated in the Workspace by or on behalf of the Controller or its Authorised Users, including output of the Platform's AI features;
• "Integration" means a third-party service that the Controller or an Authorised User connects to the Workspace using an account with that third party.

1.3 Roles. For Customer Data, the Controller is the controller and the Processor is a processor. Personal data that the Processor processes for its own purposes (registration and account data of users, billing and payment data of the Controller, communications with the Processor, security logs, and usage analytics, subject to consent where required) is processed by the Processor as an independent controller in accordance with its Privacy Policy and is not Customer Data. A person's own published creator profile on the Platform is account data; notes, rates and selections a Workspace stores about that person are Customer Data.

1.4 The Controller determines the purposes and means of the processing of Customer Data. The Processor processes Customer Data solely on behalf of, and in accordance with the documented instructions of, the Controller.

1.5 Documented instructions. The Main Agreement, this DPA, and the actions and configurations of Authorised Users in the ordinary use of the Platform together constitute the Controller's complete documented instructions. These include uploading, importing and recording content; inviting users and external collaborators; creating share links, client portal links and public forms; connecting Integrations; and invoking the Platform's AI features. Any additional or different processing requires a prior instruction in writing, which includes email to privacy@contentmaker.space.

1.6 The Processor shall inform the Controller without undue delay if, in its opinion, an instruction infringes the GDPR or other Union or Member State data protection law. The Processor may suspend execution of that instruction until the Controller confirms or changes it.

1.7 No processing for the Processor's own purposes. The Processor shall not process Customer Data for its own purposes. In particular, it shall not sell Customer Data, use it for advertising, combine it with data from other customers except as necessary to operate shared Platform features at the Controller's instruction, or use it to train machine-learning models. The Processor may generate aggregated, anonymised statistics about the operation and use of the Platform (such as feature usage counts and performance metrics) that contain no Customer Data and do not identify the Controller or any data subject.

Article 2. Subject matter and details of processing

2.1 Subject matter. Processing of Customer Data in order to provide, operate, secure and support the Platform.

2.2 Nature of processing. Collection through the Platform's forms, imports and Integrations at the Controller's instruction; hosting and storage; organisation, structuring and display; transmission and notification (in-app, email and mobile push); transcription of voice input and recordings; AI-assisted analysis and generation at the Controller's instruction; disclosure as configured by the Controller (within the Workspace, to external collaborators, through share links, client portals, public forms and connected Integrations); backup; and erasure.

2.3 Purpose. Performance of the Main Agreement: making the Platform and its features available to the Controller and its Authorised Users.

2.4 Duration. For the term of the Main Agreement and, afterwards, for the periods set out in Article 10.

2.5 The categories of data subjects and personal data, and the other details required by Article 28(3) GDPR, are set out in Schedule 1.

Article 3. Processor obligations

3.1 The Processor shall process Customer Data only on documented instructions of the Controller, including with regard to transfers to a third country, unless required to do so by Union or Member State law to which the Processor is subject. In that case the Processor shall inform the Controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.

3.2 The Processor shall ensure that persons authorised to process Customer Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality, and that they access Customer Data only to the extent necessary for the purposes in Article 2.

3.3 The Processor shall take all measures required pursuant to Article 32 GDPR, as set out in Article 6 and Schedule 3.

3.4 The Processor shall respect the conditions for engaging sub-processors in Article 4.

3.5 The Processor shall assist the Controller with data subject requests as set out in Article 8.

3.6 The Processor shall assist the Controller in ensuring compliance with Articles 32 to 36 GDPR (security of processing, notification of personal data breaches, data protection impact assessments and prior consultation), taking into account the nature of processing and the information available to the Processor. Assistance beyond providing the Platform's documentation and this DPA may be charged at reasonable cost, except where the need for it results from the Processor's breach of this DPA.

3.7 The Processor shall return or delete Customer Data at the end of the provision of services in accordance with Article 10.

3.8 The Processor shall make available to the Controller all information necessary to demonstrate compliance with Article 28 GDPR and allow for and contribute to audits, including inspections, as set out in Article 9.

3.9 The Processor shall notify the Controller without undue delay of any request for disclosure of Customer Data by a public authority, unless prohibited by law, and shall challenge requests it considers unlawful. It shall disclose no more Customer Data than the request legally requires.

Article 4. Sub-processors

4.1 General authorisation. The Controller grants the Processor general written authorisation to engage sub-processors. The sub-processors engaged are listed in Schedule 2, which the Processor publishes at contentmaker.space/subprocessors.

4.2 Prior notice of changes. The Processor shall inform the Controller of any intended addition or replacement of a sub-processor that processes Customer Data at least fourteen (14) days before the new sub-processor starts processing Customer Data. Notice is given by email to the Workspace's administrators and by updating the published list; the notice states the sub-processor's name, the processing it will carry out, the categories of Customer Data concerned and the location of processing.

4.3 Right to object. The Controller may object to the change on reasonable grounds relating to data protection by written notice within the notice period. The Parties shall discuss the objection in good faith; the Processor may propose a reasonable alternative, such as a configuration that keeps the Controller's Customer Data away from the new sub-processor. If the objection is not resolved before the change takes effect, the Controller may terminate the Main Agreement with effect from the date the change takes effect, without a notice period, and the Processor shall refund fees prepaid for the period after termination. Articles 3.7 and 10 apply. If the Controller does not object within the notice period, the change is deemed accepted.

4.4 Urgent replacement. Where a sub-processor must be replaced urgently for reasons outside the Processor's reasonable control, such as the sub-processor's insolvency, a security incident, or the sub-processor ceasing the service, the Processor may engage a replacement with shorter notice, giving notice as soon as reasonably possible. The Controller's rights under Article 4.3 apply from that notice.

4.5 Flow-down. The Processor shall engage each sub-processor by a written contract imposing data protection obligations that offer at least the same level of protection as this DPA, in particular sufficient guarantees to implement appropriate technical and organisational measures. Before engaging a sub-processor, the Processor reviews its data processing terms, transfer mechanism and security documentation.

4.6 Liability. The Processor remains fully liable to the Controller for the performance of each sub-processor's obligations.

4.7 AI providers. Customer Data submitted to the Platform's AI features is processed by the AI providers listed in Schedule 2 solely to return the requested output. The Processor uses these providers under business terms that do not permit them to use Customer Data to train their models, and does not itself use Customer Data to train models.

4.8 Integrations are not sub-processors. Where the Controller or an Authorised User connects an Integration using an account with that third party (for example a Frame.io (Adobe), Dropbox or Google account, a Cal.com or Calendly account, a meeting recorder such as Fathom, Fireflies or Granola, a Meta advertising account, a Tally account, or a Slack or Google Chat incoming webhook), the third party acts under the Controller's own agreement with it and is not a sub-processor of the Processor. The connection is the Controller's documented instruction to exchange the relevant Customer Data with that service. The Processor is responsible for the exchange as far as it takes place on the Platform; the third party's own terms govern its processing. Schedule 2, Part C lists the Integrations available.

4.9 Optional features. Some features are off for every Workspace until a Workspace administrator switches them on. Schedule 2, Part D lists each one, with its provider, the data the provider receives and where it is located. Switching a feature on is the Controller's documented instruction that its Authorised Users' devices may send that data to the provider when they use the feature. Switching it off stops any further data reaching the provider from the Workspace. Schedule 2 states where such a provider has not agreed data processing terms with the Processor, and Articles 4.2, 4.3 and 4.5 do not apply to it.

Article 5. International transfers

5.1 The Processor stores Customer Data in its primary database and file storage in the European Union (Frankfurt, Germany). Some sub-processors listed in Schedule 2 process Customer Data, or can access it, in third countries, in particular the United States.

5.2 The Processor shall transfer Customer Data to a third country, or allow access from one, only in compliance with Chapter V GDPR: on the basis of an adequacy decision (including the EU-U.S. Data Privacy Framework where the recipient is certified), or, failing that, the Standard Contractual Clauses adopted by Commission Implementing Decision (EU) 2021/914, Module Three (processor to processor), or another appropriate safeguard under Article 46 GDPR.

5.3 Where Standard Contractual Clauses are required, the Controller authorises the Processor to conclude them with the sub-processor on the Controller's behalf. Schedule 2 states the transfer mechanism for each sub-processor. The Processor shall provide a copy of the relevant transfer mechanism on request.

5.4 The Processor has assessed the transfers and applies supplementary measures where appropriate, including encryption in transit and at rest, limiting each sub-processor to the Customer Data needed for its function, and sending data to AI and transcription providers only when an Authorised User invokes the relevant feature.

Article 6. Security

6.1 The Processor shall implement and maintain technical and organisational measures that ensure a level of security appropriate to the risk, taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing, in accordance with Article 32 GDPR.

6.2 The measures in place are described in Schedule 3.

6.3 The Processor may update the measures as technology and risks develop, provided the overall level of protection is not reduced.

6.4 The Controller is responsible for the security of its own use of the Platform, including who it invites, which roles it assigns, which share links and public forms it creates, and which Integrations it connects.

Article 7. Personal data breaches

7.1 The Processor shall notify the Controller without undue delay, and in any event within forty-eight (48) hours, after becoming aware of a personal data breach affecting Customer Data. Notice is given by email to the Workspace's administrators and to any security contact the Controller has registered with privacy@contentmaker.space.

7.2 The notification shall contain, as far as available, the information listed in Article 33(3) GDPR. Information not available at the time may be provided in phases without further undue delay.

7.3 The Processor shall take the measures necessary to contain the breach and mitigate its consequences, keep the Controller informed, and cooperate with the Controller's assessment and any notification to supervisory authorities and data subjects. Notifying supervisory authorities and data subjects is the Controller's decision.

7.4 The Processor shall document all personal data breaches affecting Customer Data, including the facts, effects and remedial action.

7.5 Notification of a personal data breach under this Article is not an acknowledgement of fault or liability by the Processor.

Article 8. Data subject rights

8.1 Taking into account the nature of the processing, the Processor shall assist the Controller by appropriate technical and organisational measures, insofar as possible, in responding to requests from data subjects exercising their rights under Chapter III GDPR. The Platform's functions to view, edit, export and delete records are the primary means of that assistance; where they are insufficient for a particular request, the Processor shall provide reasonable additional assistance on request. Additional assistance that takes more than two (2) hours of the Processor's time for a single request may be charged at reasonable cost, unless the request results from the Processor's breach of this DPA.

8.2 If the Processor receives a request directly from a data subject relating to Customer Data, it shall forward it to the Controller without undue delay and shall not respond to it on its own initiative, except to tell the data subject that the request has been forwarded.

Article 9. Records, information and audits

9.1 The Processor maintains a record of processing activities carried out on behalf of controllers in accordance with Article 30(2) GDPR.

9.2 On reasonable request, the Processor shall make available to the Controller the information necessary to demonstrate compliance with this DPA, including this DPA, Schedules 2 and 3, a completed security questionnaire in a reasonable standard format, and the audit reports or certifications of its principal sub-processors where those sub-processors permit their disclosure.

9.3 If the information under Article 9.2 is not sufficient to demonstrate compliance, or where a supervisory authority requires it or a personal data breach has occurred, the Controller may carry out an audit, including an inspection, itself or through an independent auditor bound by confidentiality who is not a competitor of the Processor. Audits take place no more than once in any twelve (12) month period (unless the exceptions in the previous sentence apply), on at least thirty (30) days' written notice, during business hours, and without unreasonable disruption of the Processor's operations or access to other customers' data. Because the Processor has no premises or data centre of its own (Schedule 3, 1.1), audits and inspections are carried out remotely, through documents, written questions and a video meeting; the facilities of sub-processors are covered by Article 9.4. The Controller bears the costs of the audit, including the Processor's reasonable time, unless the audit reveals a material breach of this DPA by the Processor, in which case the Processor bears its own costs and the reasonable costs of the audit.

9.4 Audits of sub-processors' facilities are carried out through the audit reports and certifications those sub-processors make available.

Article 10. Term, export, return and deletion

10.1 This DPA takes effect when the Main Agreement is concluded, or, for a Workspace created before this DPA was published, when the Controller accepts it, and continues for as long as the Processor processes Customer Data on behalf of the Controller.

10.2 During the term. The Controller can export and delete Customer Data during the term using the Platform's functions. Data the Controller deletes during the term is removed in accordance with the Processor's retention periods: items moved to trash are permanently deleted after thirty (30) days.

10.3 Export on termination. For thirty (30) days after termination or expiry of the Main Agreement, the Controller may request an export of its Customer Data by email to privacy@contentmaker.space. The Processor shall provide it in a structured, commonly used and machine-readable format without undue delay and in any event within thirty (30) days of the request.

10.4 Deletion. The Processor shall delete Customer Data, and procure its deletion by its sub-processors, within ninety (90) days after termination or expiry of the Main Agreement, unless Union or Member State law requires further storage. If the Controller resumes its subscription before deletion, the Main Agreement continues and Customer Data is retained. Customer Data in backups is overwritten in the ordinary backup cycle, which does not exceed seven (7) days; until then, backups are kept secured and are not restored into active processing except to recover from an incident.

10.5 Earlier deletion on instruction. The Controller may at any time instruct the Processor in writing to delete or return specific Customer Data earlier; the Processor shall comply within thirty (30) days.

10.6 Confirmation. On request, the Processor shall confirm deletion in writing.

Article 11. Liability

11.1 Each Party's liability under or in connection with this DPA is subject to the limitations and exclusions of liability in the Main Agreement, except where applicable data protection law does not permit such limitation.

11.2 Nothing in this DPA limits either Party's liability to data subjects under Article 82 GDPR, or the internal allocation of that liability between the Parties under Article 82(5) GDPR.

Article 12. Final provisions

12.1 Precedence. In the event of a conflict between this DPA and any other part of the Main Agreement, this DPA prevails as regards the processing of personal data.

12.2 Severability. If a provision of this DPA is invalid or unenforceable, the remaining provisions remain in force, and the Parties shall replace the provision with one that comes as close as possible to its original intent.

12.3 Law and jurisdiction. This DPA is governed by Belgian law. The jurisdiction provisions of the Main Agreement apply.

12.4 Changes. The Processor may amend this DPA (a) to reflect changes in law or binding guidance of a supervisory authority, or (b) in a way that does not reduce the protection of Customer Data. Any other amendment requires the Controller's acceptance; the Processor shall notify amendments at least thirty (30) days before they take effect. Changes to Schedule 2 follow Article 4. The version in force, its effective date, and earlier versions are published at contentmaker.space/dpa.

12.5 Electronic form and signed copies. This DPA is concluded in electronic form within the meaning of Article 28(9) GDPR. The Processor records, for each Workspace, the version of this DPA accepted, the date and time of acceptance and the user who accepted it, and provides that record to the Controller on request. On request the Processor also provides a copy of this DPA signed by its authorised representative; such a copy has the same content as the version accepted electronically and does not replace or change it.

12.6 Language. This DPA is concluded in English. The English version is the only binding version; any translation is provided for convenience only.

Schedule 1. Details of processing

Categories of data subjects

1. The Controller's own staff, freelancers and other Authorised Users, insofar as they appear in Workspace content (assignments, planning, time entries, messages, notes).
2. The Controller's clients and prospective clients, and their contact persons.
3. External collaborators and reviewers the Controller invites or shares projects, review links or portals with.
4. Sales leads and enquirers who reach the Controller through its public forms, booking pages, advertising lead forms or webhooks.
5. Job applicants in the Controller's hiring pipelines.
6. Talent, crew, actors and other persons in the Controller's casting and production records.
7. Participants in meetings that the Controller records, transcribes or imports.
8. Persons depicted, heard or otherwise identifiable in footage, images, audio and documents the Controller uploads, including members of the public.
9. Any other persons whose data the Controller chooses to store in the Platform.

Categories of personal data

Special categories of personal data and data of minors. The Platform is not designed for special categories of personal data (Article 9 GDPR) or for data relating to criminal convictions (Article 10 GDPR), and the Processor does not request them. Such data may nevertheless be contained in material the Controller uploads, for example health information or religious symbols visible in footage, physical characteristics described in free-text casting notes, or the image of a minor in a production. The Controller is responsible for having a lawful basis, and where relevant parental consent, for such data, and for not storing it in the Platform where that is not necessary.

Schedule 2. Sub-processors

The sub-processors, their purposes, locations and transfer mechanisms are listed at contentmaker.space/subprocessors. That list, as updated from time to time in accordance with Article 4, forms Schedule 2 of this DPA.

Schedule 3. Technical and organisational measures (Article 32 GDPR)

This schedule describes only measures that are in place. The German control categories (Zutritts-, Zugangs-, Zugriffs-, Weitergabe-, Eingabe- und Verfügbarkeitskontrolle, Trennungsgebot) are named in brackets.

1. Confidentiality (Art. 32(1)(b))

1.1 Physical access to systems (Zutrittskontrolle)

• The Processor operates no data centre or server room of its own. All Customer Data is hosted by the sub-processors in Schedule 2, primarily Supabase on Amazon Web Services in Frankfurt, Germany (eu-central-1). Physical security of those facilities is covered by the providers' certifications (AWS: ISO/IEC 27001 and SOC 2; Supabase: SOC 2 Type II).
• No Customer Data is kept on paper. Customer Data is not stored on office premises other than transiently on staff laptops while working (see 1.2).

1.2 Access to systems (Zugangskontrolle)

Users of the Platform

• Every request to Customer Data requires an authenticated session issued by Supabase Auth. Sign-in is by email and password (passwords are stored only as salted hashes), by one-time email link, or by Google sign-in.
• Two-step sign-in with an authenticator app (TOTP) is available to every user. Once a user has enrolled, the database refuses access to Customer Data from any session of that account that has not completed the second step.
• Sessions use short-lived signed access tokens with refresh tokens; a user who signs out or whose account is erased loses the ability to refresh.
• Bot protection (Cloudflare Turnstile) runs on account signup.

Staff and infrastructure

• Administrative access to the production database, file storage and server functions (the Supabase and Vercel dashboards and APIs), to the source code and to the payment system is limited to the Processor's founder, using individual accounts. Two-step sign-in is enabled on these accounts (Supabase, Vercel, GitHub, Stripe and Google).
• The Supabase service-role key, which bypasses row-level security, exists only in server-side function secrets. It is never sent to a browser or app. Server functions recognise service-role callers by comparing the key itself, never by trusting a claim in a token, and an automated test guards this.
• The production database is reachable directly only from an IP allow-list; schema changes are applied by the deployment pipeline through the Supabase Management API.
• Laptops used to access production systems use full-disk encryption and an automatic screen lock.

1.3 Access within the Platform (Zugriffskontrolle)

• Row-level security on every table. Authorisation is enforced in the database, not only in the app: every table in the application schema has PostgreSQL row-level security enabled, and a user can read or change only the rows that their Workspace membership and role allow. An automated test fails the build if a client-readable table without row-level security appears.
• Workspace roles. Each member has one of four Workspace roles (admin, manager, member, limited), and admins can further restrict which sections a member sees. Members cannot change their own role or Workspace; a database trigger enforces this.
• Per-person sharing across Workspaces. A Workspace can share a specific project with named people in another Workspace. Access is granted per person and per project, and can be revoked.
• Server functions. Database functions that run with elevated rights have their default public execute right revoked when they are created, so they cannot be called anonymously; automated security regression tests cover this.
• Platform staff. Platform staff can view a Workspace as its administrator only while one of the Workspace's administrators has switched on support access in the Workspace's settings. Support access is off by default and switches itself off after seven (7) days. In an emergency, such as a security incident or loss of data, a super-administrator may open a Workspace without it, only with a recorded reason, and the Workspace's administrators are notified by email at once. Every session, and every time support access is switched on, extended or ended, is recorded in an append-only access log that cannot be altered or deleted, and Workspace administrators can see the record about their Workspace in its settings. Staff access to data across Workspaces requires two-step sign-in.

1.4 Encryption and pseudonymisation

• In transit: all connections between users, the Platform and the sub-processors use TLS (HTTPS), version 1.2 or higher.
• At rest: the database, its backups and file storage are encrypted at rest by the hosting provider (AES-256).
• Secrets used by scheduled jobs are kept in the database's encrypted secret store (Supabase Vault).
• Customer Data is not pseudonymised in the Platform, because the Controller's users must work with it in clear form. When a user account is erased, its personal fields are anonymised in place (see 4.2).

1.5 Separation of customers' data (Trennungsgebot)

• All Workspaces share one database and are separated logically: every record belongs to a Workspace, and row-level security (1.3) confines each user to their own Workspace and to records explicitly shared with them.
• Files that are part of a Workspace's work (documents, chat attachments, delivered videos and posters, scripts and production files, uploaded call recordings, identity documents) are kept in private storage. Private files are served only after the user's access has been checked, through signed links that expire after a short period.
• Public storage, readable by anyone who holds a file's unguessable link, holds images meant to be shown (profile pictures, company logos, portfolio media, cover images), images placed in knowledge-base articles and moodboards, support attachments, and photos that applicants attach to a Workspace's public job application form.

2. Integrity (Art. 32(1)(b))

2.1 Transfer control (Weitergabekontrolle)

• Customer Data leaves the Platform only (a) to the sub-processors in Schedule 2, over TLS, for their stated purpose, or (b) where the Controller's users configure it: invitations, share links, client portal links, public forms, exports, connected Integrations and notification channels.
• Data is sent to AI and transcription providers only when a user invokes the feature, and only the content that feature needs.
• Incoming webhooks are authenticated before they are processed. Payment, email, video-review, calendar, booking and meeting-recorder services are verified by the sender's cryptographic signature or by a secret specific to the connection; lead-form webhooks are verified by a secret specific to the form. Public application and contact forms accept submissions without sign-in, as any public web form does.

2.2 Input control (Eingabekontrolle)

• Records carry who created them and when; key activity in Workspaces is written to an activity log, kept for a limited period (currently 90 days).
• Platform-staff access to a Workspace is recorded in the append-only access log described in 1.3.
• Errors are reported to error monitoring (Sentry, EU data region) with default personal-data collection switched off.
• The hosting providers keep API, authentication and database logs for their standard retention periods.

2.3 Change management

• Every change to the code and to the database schema is version-controlled and goes through a pull request. Automated checks (type checks, unit tests, database security tests) run before merge.
• Database migrations are applied to production by an automated pipeline on merge, with a record of each applied migration. A new version of the web application reaches production only after the full test set has passed on that exact version.

3. Availability and resilience (Art. 32(1)(b) and (c)) (Verfügbarkeitskontrolle)

• The database is a managed PostgreSQL service in Frankfurt with automated daily backups, kept for a limited rolling period (currently seven (7) days). Uploaded files are stored in the provider's file storage, which is built for durability, and are not part of the database backups.
• Backups are restored through the provider following a written restore procedure.
• Errors in server functions and failed scheduled jobs raise alerts to staff.
• The web application is served from a global content network; a faulty release can be rolled back by re-pointing production to the previous version.

4. Data lifecycle

4.1 Retention and deletion during the term

• Items moved to trash (projects, clients, jobs, media and files) are permanently deleted after 30 days by scheduled jobs. Activity logs are deleted after 90 days. Identity documents uploaded for verification are deleted 90 days after the verification decision.
• Deletion jobs fail safe: a disabled or missing retention rule means nothing is deleted automatically, rather than everything.

4.2 Erasure of a person

• A two-step procedure erases a user account on request: personal fields are anonymised and sign-in is blocked immediately; the remaining personal data is deleted after a 30-day grace period, within the one-month deadline of Article 12(3) GDPR. Records that belong to the Workspace (for example time entries and project history) are kept but no longer identify the person.

4.3 End of the agreement

• Export and deletion at the end of the agreement follow Article 10 of the DPA. They are currently carried out by staff on request and on a deletion schedule kept by the Processor.

5. Regular testing and evaluation (Art. 32(1)(d)), and organisational measures

• Security-relevant database rules are covered by automated regression tests that run on every change.
• The Processor carried out an internal adversarial security review of the database and server functions in July 2026 and fixed the findings; regression tests from that review remain in the test suite.
• Sub-processors are reviewed before engagement (DPA Article 4.5).
• This schedule is reviewed at least once a year and whenever a sub-processor or a significant feature is added.
• Access to Customer Data in production is held by the Processor's founder only. Anyone given such access in future signs a written confidentiality undertaking before access is granted.
• A written offboarding checklist revokes the access of anyone who leaves and rotates the secrets they could see.
• A written personal-data-breach procedure defines who assesses an incident, how the Controller is notified within 48 hours (Article 7) and how the incident is documented.
• The Processor keeps a record of processing activities as processor (Article 30(2) GDPR).