Data Processing Agreement (DPA)

This data processing agreement (“DPA”) governs the processing of personal data that arimaslab srl carries out on behalf of its customers when providing the CodeQuay platform, pursuant to Article 28 of Regulation (EU) 2016/679 (“GDPR”). It follows the structure of the standard contractual clauses between controllers and processors adopted by the European Commission in Implementing Decision (EU) 2021/915.

1. Parties and conclusion of the agreement

• Controller (“Customer”): the natural or legal person who uses CodeQuay for themselves or for their organization, identified by the account details and, for paid plans, by the billing details.
• Processor (“Provider”): arimaslab srl, VAT no. IT02039300666, registered office Via Tiburtina snc, 67061 Carsoli (AQ), Italy. Data protection contact: privacy@codequay.it.

This DPA forms part of the terms under which the Provider makes CodeQuay available (the terms of service accepted at sign-up or when subscribing to a plan, and any order form or custom contract: together, the “Agreement”). The Customer accepts it by creating an account or by subscribing to a plan, whether paid or free, and it remains in force for as long as the Provider processes personal data on the Customer's behalf. If you need a signed copy, ask through the contact page or write to privacy@codequay.it: we will send you the version in force as a PDF signed by the Provider.

2. Purpose, scope and interpretation

1. This DPA ensures compliance with Article 28(3) and (4) GDPR for the processing described in Annex I. Annexes I, II and III form an integral part of this DPA.
2. Terms defined in the GDPR (personal data, processing, personal data breach, data subject, etc.) have the same meaning in this DPA. “Customer Data” means the personal data processed by the Provider on behalf of the Customer as part of the service.
3. In the event of a conflict between this DPA and the Agreement, this DPA prevails as regards the protection of personal data. This DPA does not limit the obligations that the GDPR places directly on the Provider.
4. A custom contract (for example for the Sovereign plan) may contain a negotiated data processing agreement: in that case, for that Customer, the negotiated agreement prevails.

3. Obligations of the Provider

3.1 Instructions

The Provider processes Customer Data only on documented instructions from the Customer, unless required to do so by Union or Member State law to which it is subject; in that case it informs the Customer of that legal requirement before processing, unless that law prohibits it on important grounds of public interest. The Agreement, this DPA and the choices the Customer makes when using the service (configuration of organizations, projects, repositories, members, integrations and optional features) constitute documented instructions. The Provider promptly informs the Customer if, in its opinion, an instruction infringes the GDPR or other data protection provisions.

3.2 Purpose limitation

The Provider processes Customer Data only for the purposes set out in Annex I. It does not sell Customer Data, does not use it for advertising or profiling, and does not use it to train artificial intelligence models.

3.3 Security of processing

The Provider implements at least the technical and organizational measures described in Annex II to ensure a level of security appropriate to the risk under Article 32 GDPR, including protection against a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of or access to the data. The measures may evolve with technical progress, provided that the overall level of protection is not reduced.

3.4 Confidentiality

The Provider grants access to Customer Data only to personnel who strictly need it to provide, maintain and protect the service, through individual named access. These persons are bound by a contractual or statutory obligation of confidentiality.

3.5 Special categories of data

CodeQuay is designed to host source code and development information, not special categories of data (Article 9 GDPR) or data relating to criminal convictions and offences (Article 10). If the Customer uploads such data anyway, it assesses the suitability of the service under its own responsibility; the measures in Annex II apply to that data.

3.6 Documentation, audits and inspections

1. The Provider makes available to the Customer the information necessary to demonstrate compliance with this DPA and with Article 28 GDPR: this document, the description of the security measures, the results of restore tests and, upon a reasoned request, further information and the audit log extracts relating to the Customer.
2. The Customer may carry out audits and inspections, including at the Provider's premises, itself or through an independent auditor bound by confidentiality, with at least 30 days' written notice, during business hours, as a rule no more than once a year and at its own expense, without accessing other customers' data or compromising the security of the service. The notice period and the annual limit do not apply after a personal data breach affecting the Customer or where a supervisory authority requires it.
3. The parties make the information in this section available to the competent supervisory authorities on request.

3.7 Sub-processors

1. The Customer gives the Provider general written authorization to engage the sub-processors listed in Annex III.
2. The Provider gives notice of any intended addition or replacement of sub-processors at least 30 days in advance, by email to the owners of the spaces and by updating Annex III together with its last-updated date. Within the notice period, the Customer may object on reasonable data protection grounds by writing to privacy@codequay.it. The parties will seek a solution in good faith; if none is found, the Customer may terminate the affected service without penalty before the new sub-processor processes its data.
3. The Provider imposes on each sub-processor, by written contract, data protection obligations substantially equivalent to those in this DPA, in particular sufficient guarantees as to technical and organizational measures. On the Customer's request, it provides the relevant information about those contracts.
4. The Provider remains fully liable to the Customer for the performance of its sub-processors' obligations.

3.8 International transfers

Customer Data is stored and processed in the European Union. By default it is not transferred outside the European Economic Area. The exceptions are listed in Annex III (in particular AI review, if the Customer enables it, and payments): in those cases a transfer takes place only on the basis of an adequacy decision, including the EU-U.S. Data Privacy Framework for certified recipients, or of the standard contractual clauses adopted by the European Commission (Implementing Decision (EU) 2021/914), with any supplementary measures, in accordance with Chapter V GDPR. The same applies to any access from third countries by group companies of the sub-processors.

4. Assistance to the Customer

1. Data subject requests. If the Provider receives a request from a data subject concerning Customer Data directly, it forwards the request to the Customer without delay and does not respond to it on the merits without the Customer's authorization. The service lets the Customer handle most requests on its own (managing members and accounts, editing and removing content, exporting repositories with git clone --mirror and through the API); beyond that, the Provider assists the Customer with appropriate technical and organizational measures, insofar as possible, under Articles 12 to 22 GDPR.
2. Security, impact assessments and prior consultation. Taking into account the nature of the processing and the information available to it, the Provider assists the Customer in complying with Articles 32 to 36 GDPR, providing the information needed for a data protection impact assessment and, where required, for prior consultation of the supervisory authority.
3. Inaccurate or outdated data. The Provider informs the Customer without delay if it becomes aware that the Customer Data it processes is inaccurate or outdated.

5. Personal data breaches

1. In the event of a personal data breach concerning Customer Data, the Provider notifies the Customer without undue delay and in any case within 48 hours of becoming aware of it, at the email address of the owner of the affected space and of any contacts designated by the Customer.
2. The notification contains at least: the nature of the breach, including, where possible, the categories and approximate number of data subjects and records concerned; a contact point at the Provider; the likely consequences; the measures taken or proposed to address the breach and mitigate its effects. Information that is not available straight away is provided in phases, without further undue delay.
3. The Provider takes the measures needed to contain the breach without delay and assists the Customer with its obligations to notify the supervisory authority (Article 33 GDPR) and to communicate the breach to data subjects (Article 34), which remain the Customer's. It documents every breach, including the facts, its effects and the remedial action taken.

6. Duration, end of service, deletion and return

1. This DPA lasts as long as the Agreement and remains effective for as long as the Provider holds Customer Data.
2. Throughout the service, the Customer can export its data in standard formats: repositories with git clone --mirror (full history, branches and tags), everything else through the API and the console.
3. At the end of the service, at the Customer's choice, the Provider returns the Customer Data (by assisting with the export) or deletes it, and deletes existing copies unless Union or Member State law requires them to be kept. Deletion from production systems takes place within 30 days of the end of the service or of the Customer's request, whichever is later; on request, the Provider confirms it in writing.
4. Backup copies are not altered individually: Customer Data disappears from them through the normal rotation described in Annex I (encrypted off-site backups: 12 months at most). Until then it remains encrypted, inaccessible to the service and usable only for disaster recovery; should a restore bring it back into production, the Provider deletes it again.

7. Non-compliance and termination

If the Provider is in breach of its obligations under this DPA, the Customer may instruct it to suspend the processing until the breach is remedied. If compliance is not restored within a reasonable time, and in any event within one month of the suspension, or in the event of a substantial or persistent breach of this DPA or of the GDPR, the Customer may terminate the Agreement as far as it concerns the processing of personal data. The Provider may terminate it to the same extent if the Customer insists on compliance with instructions that infringe the law.

8. Liability

The parties' liability under this DPA is governed by the liability provisions of the Agreement (section 17 of the terms of service), except where the law does not allow liability to be limited, and without prejudice to Article 82 GDPR towards data subjects.

9. Changes

The Provider may update this DPA to reflect changes in the law, guidance from the authorities or the evolution of the service, without reducing the level of protection of Customer Data. Each version has a number and a date, shown at the top of the page (version in force: 1.0). Substantial changes are notified at least 30 days in advance; changes of sub-processors follow section 3.7.

10. Governing law and jurisdiction

This DPA is governed by Italian law, without prejudice to the mandatory provisions of the GDPR. Disputes fall within the jurisdiction of the court specified in the Agreement (section 23 of the terms of service) or, failing that, of the court of the place where the Provider has its registered office, without prejudice to any mandatory jurisdiction provided by law. The right to lodge a complaint with a supervisory authority is unaffected. This DPA is drawn up in Italian: in the event of any discrepancy with a translation, the Italian version prevails.

Annex I — Description of the processing

Categories of data subjects

• Users of the service authorized by the Customer: employees, collaborators, consultants, invited guests and service accounts (bots) of the organization.
• People whose data appears in content uploaded by the Customer, for example authors and committers recorded in the git history, or people mentioned in code, issues, comments and wikis.
• The Customer's contact persons for administration and billing.
• End users of the Customer's applications, only if the Customer sends its applications' error events to CodeQuay (error tracking) or publishes sites with Pages (IP addresses in access logs).

Categories of personal data

• Account data: username, display name, email, profile picture, language, password (as an argon2id hash only), public keys of passkeys and SSH keys, two-factor authentication secret (encrypted), access tokens (as a hash only), identifier at the sign-in provider used, memberships and roles, notification preferences.
• Content uploaded by the Customer, which may contain personal data: git repositories including commit metadata (names and emails of authors and committers, dates), issues, merge requests, comments, wikis, snippets, releases and attachments, packages, container images, CI/CD pipeline logs and artifacts, Actions secrets and variables (encrypted), webhook configurations and deliveries, error events, Pages sites.
• Technical data and logs: IP address, user agent, date and time, requested resource (without the query string), sessions and linked devices, request outcome.
• Audit log: who (user, or attempted username), what (action and target), when, where from (IP address), outcome (allowed, denied, error), denied attempts included.
• Billing data: name and email of the contact person, company name, VAT number, billing address, SDI recipient code or PEC, plan, seats and invoices. Card and other payment instrument data is processed by Stripe: CodeQuay never sees it.
• Transactional email: recipient, subject and text of the messages sent by the service (verifications, invitations, notifications, alerts).

The Provider also processes billing data, and the data needed for its tax and accounting obligations, as an independent controller, in order to comply with its own legal obligations.

Nature and purpose of the processing

Provision of the CodeQuay service under the Agreement: hosting, storing and making available repositories and content; authenticating users and enforcing permissions and protections; checking pushes (including blocking secrets in code); running CI/CD pipelines; indexing for search; sending transactional email; recording the audit log; running backups, restore tests and monitoring; managing subscriptions and payments; providing support; preventing abuse and ensuring security. With AI review enabled by the Customer on a repository: sending the changes of merge requests to the model provider to obtain review comments.

Duration and retention

The processing lasts as long as the Agreement. Some data is kept for shorter periods (service defaults):

Annex II — Technical and organizational measures

Encryption

• Encryption in transit: TLS 1.2 and 1.3 only, with AEAD ciphers and HSTS, for the console, the API and git over HTTPS; git also over SSH.
• Off-site backups encrypted with age on the server before upload: the server holds only the public key and cannot decrypt them; the private key is kept by the Provider off the server.
• Passwords stored only as argon2id hashes, access tokens only as cryptographic hashes, secrets at rest (Actions secrets, two-factor secrets, the AI provider key) encrypted with AES-256-GCM.

Identity and access control

• Passkeys (WebAuthn) and two-factor authentication; per-organization single sign-on with the Customer's identity provider.
• Rate limits on the API and on sign-ins, with a temporary lockout after repeated failed attempts; tokens with an expiry date.
• Permissions per organization, project and repository, with inherited roles and per-user restrictions, enforced in the same way in the console, the API and the git protocol; non-members get a 404, as for a repository that does not exist. Isolation is verified by a dedicated automated test suite.

Least privilege and system protection

• The application connects to the database with a restricted role, which can only add and read audit log rows; the database is not exposed to the internet.
• Services run in unprivileged containers, with read-only file systems where possible; instance secrets live in separate files with restricted permissions, never inside images.
• Firewall with only the necessary ports open, protection against repeated access attempts, automatic operating system security updates.
• Administrative access to the servers is reserved to authorized Provider personnel, with personal SSH keys protected by a passphrase.

Traceability

• Append-only audit log at the database level: rows can be added, never changed or deleted, not even with the application's own database user. It also records denied attempts.
• Access logs without the query string; system events with alerts to administrators.

Secure development and vulnerability management

• Branch protection and blocking of secrets in code, enforced by the server on every push.
• Automated checks before every release (tests, dependency audit); documented rollback.
• Responsible disclosure of vulnerabilities to security@codequay.it, also published in security.txt.

Availability and recovery

• Full backup every night (database dump and git bundle of every repository) and before every update, with SHA-256 checksums; encrypted off-site copy verified after upload.
• Automated restore test every week in a separate environment (database, migrations, repository clones and a check with git fsck), with a report and an alert if it fails.
• Instance checks every 5 minutes and external monitoring of availability and certificates, with email alerts.

Data minimization and data protection by design

• No third-party tracking, analytics or advertising in the platform.
• AI review off by default and enabled per repository; recognized secrets are not sent to the model provider.
• Limited retention for logs, artifacts, email and events (Annex I).

Organizational and physical measures

• Personnel bound by confidentiality, with named access limited to what is needed.
• Documented operating procedures for backup, restore, incident handling and key rotation.
• Physical security of the data centers entrusted to the hosting providers in Annex III, under their contractual commitments.
• Periodic review of the measures, in particular after significant changes to the service.

Annex III — Sub-processors

Independent controllers and destinations chosen by the Customer

• Stripe also acts as an independent controller for payment data (fraud prevention, anti-money laundering and regulatory obligations), under its own privacy policy.
• Google, Microsoft, Apple and LinkedIn are involved only as sign-in providers chosen by the user: they are independent controllers and receive only what is needed for sign-in. The same applies to the identity provider configured by the Customer for its organization's single sign-on.
• Destinations configured by the Customer (webhooks, push mirrors to other services such as GitHub, runners managed by the Customer, deployment environments) receive data on the Customer's instructions and are not sub-processors of the Provider.
• GitHub hosts a copy of CodeQuay's own source code, that is, the Provider's software: it contains no Customer Data and is not a sub-processor.