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. For portability, the workspace export described under Deletion and Return of Data produces the whole workspace in a structured, commonly used and machine-readable format; a data subject's own records can be identified within it by their user identifier. 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.

The AI Reporting Studio lets a user describe a report in plain language instead of assembling it by hand. Where a user sends a message in that feature, you instruct Rundown to transmit the content described below to Anthropic PBC, which acts as a sub-processor for that transmission. The feature is used only when a user chooses to use it; no data is sent to Anthropic in the course of ordinary use of the service.

• What is sent. The messages the user types in the feature; the report configuration currently on the user's screen; and a catalogue of the names and internal identifiers of the clients, projects, teams, job roles, epics and — limited to those within the user's own access scope — the people in your workspace, so that a request naming an entity can be resolved to that entity.
• What is not sent. No time entries, no hourly or cost rates, no budgets, no revenue, cost or margin figures, and no report results. The model produces a report definition — a structured query — which Rundown then executes on its own infrastructure. Every figure a user sees is computed by Rundown and has never left it.
• Retention. Conversations are stored in the customer's own tenant schema so that a user can leave the page and resume the thread later. Each user has one conversation, visible only to them, deleted automatically 90 days after it was last used, and clearable by that user at any time from the Studio. Nothing about a conversation is written to application logs. A user may also save a report configuration — a name and a report definition — which is likewise private to that user and kept until they delete it. Neither artefact contains time entries, rates, budgets or report results; both are removed with the tenant schema when the customer terminates the Agreement.
• Training. Rundown uses the Anthropic API under commercial terms. Anthropic does not use data submitted through that API to train its models.
• Access boundaries are enforced by Rundown, not by the model. The report definition returned by the model is validated against your workspace and its scope is reduced, where necessary, to what the requesting user is authorised to see, before any query runs. A user cannot obtain data through this feature that they could not obtain through the ordinary reporting interface.
• Availability. The feature is a plan entitlement and can be absent from a workspace. Where it is not enabled, or where an environment is not configured for it, no data is transmitted to Anthropic and the remainder of the service is unaffected.

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 no longer than 7 days and are rotated automatically. Personal data present in a backup taken before deletion is destroyed no later than the end of that period.
• 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.

Return of data. The service provides a self-service workspace export, available to workspace members holding the export permission under Settings ▸ Export workspace. It produces a single archive containing every table of your workspace database as both newline-delimited JSON and CSV, the images uploaded to your workspace, the entries from Rundown's shared catalogue that your data references, and a manifest listing the row count and a SHA-256 checksum for every file in the archive, so that the export can be verified as complete and unmodified.

The archive excludes credentials only — Atlassian OAuth tokens, session refresh tokens, password-reset secrets, stored password hashes and invitation tokens. Everything else your workspace holds is included. Credentials are excluded because their inclusion would make the archive a means of access rather than a copy of your information.

The generated archive is stored privately, is downloadable only through an authenticated request by your own workspace, and is deleted seven (7) days after it is generated. Each export is recorded with the identity of the person who requested it, the time and the originating IP address; that record is retained after the archive itself is deleted.

Please take your export before closing your workspace. Closing a workspace locks it immediately, and the export function is not reachable during the thirty (30) day grace period. Rundown will also, on written request made before the end of that grace period, provide 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 and to transmit report requests to a language model provider as described in the AI Reporting Studio section.

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.
• AI Reporting Studio data: the text a user writes in a chat, the assistant's replies, the report definition the conversation is building, and saved report configurations. A report definition is a query — which figures to group and filter, not the figures themselves — and may name projects, teams or users the requesting user is already permitted to see. All of it is stored per user, is visible only to that user, and is subject to the retention described in the AI Reporting Studio section.

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.

Language model boundary. Where the AI Reporting Studio is used, what may leave the platform is limited in code, not by instruction to the model: the request carries the user's messages, the report configuration on screen, and entity names and identifiers drawn from the catalogue the requesting user is already permitted to see. No time entry, rate, budget, financial figure or report result is included. What comes back is validated against a closed schema before use — a configuration referring to an unknown identifier is rejected rather than executed — and the access scope of the resulting report is re-derived from the user's own permissions, so a request for a wider scope than the user holds is narrowed rather than granted. The report itself is executed by Rundown against the customer database; the model never queries it. Requests to the model are stateless: the provider retains nothing between turns. Rundown stores the transcript in the customer's tenant schema so a user can resume it, subject to the 90-day retention and the per-user access described above.

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 no longer than 7 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.

Data export. A workspace export is a complete copy of a workspace and is treated as such: it is gated behind its own permission rather than general settings access, rate limited, excluded from containing any credential, stored privately, downloadable only through an authenticated request scoped to the workspace that produced it, and deleted automatically seven (7) days after generation. Every export is recorded with requester, time and IP address.

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.
• Resend, Inc. — delivery of transactional email: workspace invitations, password-reset links and service notifications. Resend processes the recipient's email address, their display name where one is set, and the contents of the message (which includes single-use invitation and password-reset links). It does not receive workspace content. Processing region: United States. Transfer mechanism: Standard Contractual Clauses.
• 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.
• Anthropic PBC — engaged only where a user uses the AI Reporting Studio, and only for the duration of that request. It receives the user's messages and a catalogue of workspace entity names and identifiers, as described in the AI Reporting Studio section; it receives no time entries, rates, budgets, financial figures or report results. Processing region: United States. Transfer mechanism: Standard Contractual Clauses. Data submitted through the Anthropic API is not used to train Anthropic's models, and Rundown does not retain the conversation.

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