Data Processing Agreement

This Data Processing Agreement ("DPA") forms part of, and is incorporated by reference into, the Rundown Terms & Conditions (the "Agreement") between placeholder_legal_entity_name, registered at placeholder_legal_entity_address, company number placeholder_company_registration_number ("Rundown", "we", "us") and the organisation that has accepted the Agreement ("Customer", "you").

By accepting the Terms & Conditions when creating a workspace, you also accept this DPA on behalf of your organisation. No separate signature is required. If you are accepting on behalf of a company or other organisation, you represent that you have the authority to bind that organisation.

This DPA applies where Rundown processes personal data on your behalf as a processor within the meaning of Article 4(8) of Regulation (EU) 2016/679 ("GDPR") and the Belgian Act of 30 July 2018 on the protection of natural persons with regard to the processing of personal data.

Order of precedence. In the event of a conflict between this DPA and the Terms & Conditions, this DPA prevails in respect of the processing of personal data. In the event of a conflict between this DPA and the Standard Contractual Clauses referred to in the International Transfers section, the Standard Contractual Clauses prevail.

Effective date: placeholder_dpa_effective_date.

Terms such as "personal data", "processing", "controller", "processor", "data subject", "supervisory authority" and "personal data breach" have the meanings given to them in the GDPR.

• Customer Personal Data means personal data contained in the content of your workspace that Rundown processes on your behalf under the Agreement, as further described in Annex I.
• Sub-processor means any third party engaged by Rundown to process Customer Personal Data on our behalf.
• Standard Contractual Clauses or "SCCs" means the standard contractual clauses for the transfer of personal data to third countries adopted by the European Commission in Implementing Decision (EU) 2021/914.
• Workspace means the isolated tenant environment in which your organisation's data is stored, as described in the Terms & Conditions.

Customer as controller. In respect of Customer Personal Data, you are the controller and Rundown is the processor. You determine the purposes and means of the processing, and you are responsible for the lawfulness of the personal data you and your users enter into, or synchronise with, the workspace — including having a valid legal basis and providing any required information notices to your employees and other data subjects.

Rundown as controller. For data we collect and determine the purposes of ourselves — account registration and authentication records, billing and invoicing data, support correspondence, and analytics on our marketing site — Rundown acts as a controller. That processing is governed by our Privacy Policy and not by this DPA.

Scope. The subject matter, duration, nature and purpose of the processing, the types of personal data and the categories of data subjects are set out in Annex I. This DPA applies for as long as Rundown processes Customer Personal Data on your behalf.

Rundown processes Customer Personal Data only on your documented instructions, including with regard to transfers of personal data to a third country, unless required to do so by Union or Member State law to which Rundown is subject. Where such a legal requirement applies, we will inform you of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.

Your documented instructions consist of:

• the Agreement and this DPA;
• your use and configuration of the service through its interfaces and APIs, including the workspace settings you choose, the integrations you enable, and the retention period you configure;
• any additional written instructions agreed between the parties.

Rundown will inform you if, in our opinion, an instruction infringes the GDPR or other Union or Member State data protection provisions. We are not obliged to carry out such an instruction, and we may suspend the affected processing until the instruction is withdrawn, amended or confirmed.

No independent use. Rundown does not sell Customer Personal Data, does not use it for advertising, and does not use it to train machine-learning or artificial-intelligence models.

Rundown ensures that persons authorised to process Customer Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. This obligation survives the termination of their engagement with us.

Access to Customer Personal Data by Rundown personnel is limited to those individuals who require access in order to provide, maintain, secure or support the service, and is granted on a least-privilege basis.

Taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing, as well as the risk to the rights and freedoms of natural persons, Rundown implements appropriate technical and organisational measures to ensure a level of security appropriate to the risk. Those measures are described in Annex II.

Rundown may update the measures in Annex II from time to time, provided that any update does not materially decrease the overall level of security of the service.

Your responsibilities. Security is shared. You are responsible for configuring your workspace appropriately, for assigning roles and permissions to your users, for the confidentiality of your users' credentials, and for promptly removing access for users who leave your organisation.

General authorisation. You give Rundown a general written authorisation to engage sub-processors for the purpose of providing the service. The sub-processors engaged as at the effective date of this DPA are listed in Annex III.

Obligations. Where Rundown engages a sub-processor, we impose on that sub-processor, by way of a contract, data protection obligations that are no less protective than those set out in this DPA. Rundown remains fully liable to you for the performance of the sub-processor's obligations.

Changes. Rundown will inform you of any intended addition or replacement of a sub-processor at least thirty (30) days in advance, by email to your workspace owner and by updating Annex III. You may object to such a change on reasonable data protection grounds within thirty (30) days of being informed. If you object and the parties cannot agree on a resolution, you may terminate the affected part of the service, and receive a pro-rata refund of any prepaid fees covering the period after termination.

Atlassian. Where you choose to connect a Jira workspace, Atlassian acts as a separate controller in respect of the data held in your Jira instance. Rundown exchanges data with Atlassian on your instruction, as described in the Jira Integration section.

Rundown is operated from Belgium. The hosting regions used for each category of processing are identified in Annex III.

Where Customer Personal Data is transferred to, or accessed from, a country outside the European Economic Area that is not the subject of an adequacy decision by the European Commission, that transfer is governed by the Standard Contractual Clauses, which are incorporated into this DPA by reference and completed as follows:

• Module Two (controller to processor) applies to transfers from you to Rundown; Module Three (processor to processor) applies to onward transfers from Rundown to a sub-processor.
• Clause 7 (docking clause) applies.
• Clause 9 (sub-processors): Option 2, general written authorisation, with the notice period set out in the Sub-processors section.
• Clause 11 (redress): the optional independent dispute resolution paragraph does not apply.
• Clause 17 (governing law): the Clauses are governed by the law of Belgium.
• Clause 18 (forum): disputes are resolved before the courts of Belgium.
• Annexes I, II and III to this DPA serve as Annexes I, II and III to the Standard Contractual Clauses.

Rundown applies supplementary measures where required, including encryption in transit and at rest, and will challenge any legally invalid request from a public authority for access to Customer Personal Data.

Taking into account the nature of the processing, Rundown assists you by appropriate technical and organisational measures, insofar as possible, in fulfilling your obligation to respond to requests from data subjects exercising their rights under Chapter III of the GDPR — access, rectification, erasure, restriction, portability and objection.

The service provides self-service functionality that allows you to access, correct and delete personal data within your workspace directly. Where a request cannot be fulfilled using that functionality, Rundown will provide reasonable additional assistance on request at privacy@rundown.be.

If Rundown receives a request directly from one of your data subjects in relation to Customer Personal Data, we will not respond to it substantively, and will instead refer the data subject to you and notify you of the request without undue delay.

Rundown notifies you without undue delay, and in any event within forty-eight (48) hours of becoming aware of a personal data breach affecting Customer Personal Data. Notification is sent by email to the workspace owner and to any security contact you have provided.

The notification will describe, to the extent known at the time and supplemented as further information becomes available:

• the nature of the breach, including where possible the categories and approximate number of data subjects and records concerned;
• the name and contact details of a point of contact at Rundown from whom more information can be obtained;
• the likely consequences of the breach;
• the measures taken or proposed to address the breach and to mitigate its possible adverse effects.

Rundown assists you in ensuring compliance with your obligations under Articles 33 and 34 GDPR, including your obligation to notify the competent supervisory authority within 72 hours where required. A notification under this section is not an acknowledgement by Rundown of fault or liability.

Rundown provides you with reasonable assistance in carrying out data protection impact assessments under Article 35 GDPR and in any prior consultation of a supervisory authority under Article 36 GDPR, in each case relating to the processing of Customer Personal Data and taking into account the nature of the processing and the information available to us.

Rundown makes available to you all information necessary to demonstrate compliance with the obligations laid down in Article 28 GDPR and this DPA, and allows for and contributes to audits, including inspections, conducted by you or another auditor mandated by you.

In the first instance, Rundown will respond to reasonable written requests for information, including security questionnaires, within thirty (30) days. Where that is not sufficient to demonstrate compliance, you may conduct an on-site or remote audit subject to the following:

• audits take place no more than once per calendar year, unless required by a supervisory authority or following a personal data breach affecting your data;
• you give at least thirty (30) days' prior written notice;
• audits are conducted during normal business hours, in a manner that does not unreasonably disrupt our operations, and must not grant access to any other customer's data or to our wider infrastructure;
• any auditor is bound by confidentiality obligations and must not be a competitor of Rundown;
• you bear the cost of the audit, unless it reveals a material breach of this DPA by Rundown, in which case Rundown bears the reasonable cost.

Where you connect a Jira workspace, you instruct Rundown to exchange data with Atlassian on your behalf using Atlassian's OAuth 2.0 (3LO) authorisation framework. The connection is established by a user in your organisation who authorises Rundown against your Atlassian site.

• What we receive. Issue, project, sprint and worklog data from the Jira projects you select, together with the Atlassian account identifiers, display names, email addresses, avatars and time zones of the users associated with that data.
• Tokens. The OAuth access and refresh tokens issued by Atlassian are stored in your workspace schema and encrypted at rest as described in Annex II. Disconnecting the integration in the application deletes Rundown's copy of those tokens. Atlassian provides no programmatic mechanism for an application to revoke a 3LO grant, so to additionally revoke the grant at Atlassian, a user must remove Rundown from "Connected apps" in their Atlassian account.
• Personal data reporting. Rundown participates in Atlassian's personal data reporting programme, under which the account identifiers of Atlassian users whose personal data we store are periodically reported to Atlassian so that account closures and profile updates propagate to our records. Where Atlassian reports an account as closed, the associated personal data is erased from your workspace.
• Roles. Atlassian is an independent controller in respect of the data held in your Atlassian site, and its processing is governed by its own terms and privacy policy.

At your choice, Rundown deletes or returns all Customer Personal Data to you after the end of the provision of services relating to processing, and deletes existing copies unless Union or Member State law requires storage of the personal data.

• During the term. You may delete personal data from your workspace at any time using the application.
• Configured retention. Your workspace has a configurable retention period for workspace content, set in the workspace's general settings, with a default of two (2) years.
• On closure. When a workspace is closed, it is immediately locked and scheduled for permanent deletion. During a grace period of thirty (30) days, the workspace owner may restore it. After the grace period, an automated process permanently destroys the workspace database schema, the files stored for that workspace in object storage, and any stored Atlassian OAuth tokens.
• Backups. Encrypted backups are retained for seven (7) days and rotated within thirty (30) days. Personal data present in a backup taken before deletion is destroyed on that cycle.
• Legal retention. Where we are required by law to retain certain records — in particular invoicing records, which Belgian law requires us to keep for seven (7) years — we retain only the data necessary for that purpose and continue to protect it under this DPA.

On written request made before deletion, Rundown will provide you with an export of Customer Personal Data in a structured, commonly used and machine-readable format.

Term. This DPA takes effect on the date you accept the Agreement and continues until Rundown ceases to process Customer Personal Data on your behalf. The provisions on confidentiality, deletion, audits and liability survive termination.

Liability. Each party's liability under this DPA is subject to the limitations and exclusions of liability set out in the Terms & Conditions. Nothing in this DPA limits either party's liability towards a data subject under Article 82 GDPR, or any liability that cannot be limited under applicable law.

Governing law and jurisdiction. This DPA is governed by Belgian law. Disputes arising out of or in connection with it are subject to the exclusive jurisdiction of the competent courts of Belgium, without prejudice to the jurisdiction provisions of the Standard Contractual Clauses.

Contact. Data protection queries relating to this DPA may be sent to privacy@rundown.be. We are not required to appoint a Data Protection Officer under Article 37 GDPR; see the Privacy Contact section of our Privacy Policy.

Subject matter. The provision of the Rundown project management platform to the Customer under the Agreement.

Duration. The term of the Agreement, plus the deletion periods set out in the Deletion and Return of Data section.

Nature and purpose. Hosting, storage, organisation, structuring, retrieval, consultation, transmission and erasure of workspace content for the purpose of enabling the Customer to plan and track projects, tasks, time entries, costs and budgets, to produce reports and analytics, and, where enabled, to synchronise data with Atlassian Jira.

Categories of data subjects.

• the Customer's employees, contractors and other workspace users;
• users of the Customer's connected Atlassian Jira site whose issues or worklogs are synchronised;
• individual contacts at the Customer's own clients, where the Customer records them in the workspace.

Types of personal data.

• Identity and contact data: name, email address, profile picture, job title, language and time zone.
• Account data: hashed password, role and permission assignments, team and reporting-line membership, legal-acceptance records, authentication and session records.
• Work data: time entries and timers, task and project assignments, planning entries, holidays and absences, comments and uploaded files.
• Financial data relating to individuals: billable and cost rates associated with a user or role, where the Customer configures them.
• Integration data: Atlassian account identifiers and associated profile data, and encrypted OAuth tokens.

Special categories of personal data. The service is not intended for special categories of personal data within the meaning of Article 9 GDPR, and the Customer must not enter such data into the workspace. Note that absence records may indirectly reveal information about health if the Customer chooses to record a reason; the Customer is responsible for deciding whether to do so and for any resulting legal basis.

Frequency of processing. Continuous, for the duration of the Agreement.

The following technical and organisational measures are implemented by Rundown as at the effective date of this DPA.

Encryption in transit. All traffic to the application and to both API services is served over TLS 1.2 or higher. Both API services send a HTTP Strict-Transport-Security header with a maximum age of one year, including subdomains.

Encryption at rest. The production database and object storage are encrypted at rest by the underlying platform. In addition, Atlassian OAuth access and refresh tokens are encrypted at the field level using AES-256-GCM with a key derived using scrypt, before being written to the database.

Credential and secret handling. User passwords are stored as bcrypt hashes with a work factor of 12 and are never recoverable. Password-reset and invitation tokens are stored as SHA-256 hashes and are looked up by hash, so a database disclosure reveals no usable token. Secrets are held in environment configuration, never in source code, and are not written to logs or URLs.

Tenant isolation. Each customer workspace is allocated its own dedicated database schema. Application requests are bound to a single workspace schema at authentication time, so data from one customer cannot be returned to another.

Access control. The application enforces role-based access control. Every API route is gated by an explicit permission check that fails closed, combined with a scope limit that restricts which records a user may see. Access to production systems by Rundown personnel is limited to those who require it.

Session management. Access tokens are short-lived (fifteen minutes). Refresh tokens are rotated on each use, stored as hashes, bound to a device, and transmitted in httpOnly cookies. A per-user token version allows all sessions for a user to be revoked immediately.

Abuse protection. The main API applies tiered rate limiting to authentication, data and bulk endpoints. Cross-origin access is restricted to configured origins.

Resilience and backup. The production database is a managed service with automated encrypted backups, retained for seven (7) days and rotated within thirty (30) days.

Deletion. Workspace deletion runs as an automated process that destroys the database schema, the associated object storage contents and any stored integration tokens in a single transaction, so a partial failure leaves data intact for retry rather than orphaned.

Change management. All changes are version controlled, reviewed before merge, and deployed through separate acceptance and production environments with separate credentials, databases and encryption keys. Production data is not copied into the acceptance environment.

The following sub-processors are engaged by Rundown as at the effective date of this DPA.

• Render Services, Inc. — hosting of the API services and the production PostgreSQL database, including all workspace content. Processing region: Frankfurt, Germany (EU Central). Customer Personal Data is stored and processed in the EEA. Render is a US-incorporated company whose personnel may access data from outside the EEA for support and maintenance; that access is covered by the Standard Contractual Clauses.
• Vercel Inc. — hosting and delivery of the web application and marketing site. Vercel processes request metadata and serves application assets; workspace content is not stored by Vercel. Transfer mechanism: Standard Contractual Clauses.
• Amazon Web Services EMEA SARL — object storage (S3) for files uploaded to a workspace, including profile pictures. Processing region: eu-north-1 (Stockholm, Sweden). No transfer outside the EEA.
• Atlassian Pty Ltd — engaged only where the Customer enables the Jira integration, for the exchange of issue, worklog and user data described in the Jira Integration section. Atlassian also acts as an independent controller in respect of the Customer's own Atlassian site.

An updated list is maintained on this page. Changes are notified in accordance with the Sub-processors section.