Data Processing Agreement

Last modified: 23 July 2026 · Version 1.0

1. Scope and roles

This Data Processing Agreement ("DPA") forms part of and is incorporated into the Nodge Terms of Service or other agreement between you ("Customer") and CoreCubes B.V., trading as Nodge (KvK 94074542, Winklerlaan 363-41, 3571 KE Utrecht, the Netherlands) ("Nodge") (the "Agreement"). By accepting the Terms of Service, the Customer also accepts this DPA.

This DPA applies where and to the extent Nodge processes personal data on behalf of the Customer in the course of providing the Service. In that processing:

• the Customer acts as controller (or as processor on behalf of its own controller); and
• Nodge acts as processor (or sub-processor).

It is entered into under Article 28 of Regulation (EU) 2016/679 (the "GDPR") and applicable Netherlands data-protection law.

2. Deployment models: what Nodge actually processes

Because the Service can be deployed in different ways, the extent of Nodge's processing differs:

• Nodge cloud (the free and standard paid plans): Nodge acts as processor of the personal data the Customer's use of the Service involves, and this DPA applies in full. Nodge's platform control plane is hosted in the Netherlands. The Customer's environment runs in the cluster location the Customer chooses (the default is the Netherlands); some locations are outside the EEA, and a non-EEA choice is the Customer's own decision and responsibility as controller, as set out in Section 9.
• Self-hosted or air-gapped: the Service runs entirely within the Customer's own infrastructure. After installation Nodge has no access to that environment or to the personal data in it, and does not process Customer personal data, except where the Customer expressly grants access for a specific support purpose. In that case Nodge processes only for that purpose and this DPA applies to that limited processing.

3. Definitions

Terms such as controller, processor, personal data, processing, data subject, personal data breach, and supervisory authority have the meanings given in the GDPR. "Customer Personal Data" means personal data that Nodge processes on behalf of the Customer under the Agreement, as described in Annex I. "Sub-processor" means a processor engaged by Nodge to process Customer Personal Data.

4. Processing on documented instructions

Nodge will process Customer Personal Data only:

• on the Customer's documented instructions, including as set out in the Agreement, this DPA, and the Customer's configuration and use of the Service; and
• as necessary to provide, secure, and support the Service.

Nodge will not process Customer Personal Data for its own purposes. Nodge does not use Customer Personal Data, Customer code, prompts, or agent interactions to train any model. If Nodge is required by EU or Netherlands law to process beyond the Customer's instructions, it will inform the Customer of that requirement before processing, unless the law prohibits it. If Nodge considers an instruction to infringe data-protection law, it will inform the Customer without undue delay.

5. Confidentiality

Nodge ensures that persons authorised to process Customer Personal Data are bound by an appropriate duty of confidentiality and are trained in their obligations.

6. Security

Nodge implements appropriate technical and organisational measures to ensure a level of security appropriate to the risk, as described in Annex II and taking into account the state of the art, the costs of implementation, and the nature, scope, context, and purposes of processing. Nodge is certified to ISO/IEC 27001:2022. Nodge may update the measures over time, provided the level of protection is not materially reduced.

7. Sub-processors

7.1 The Customer gives Nodge general authorisation to engage sub-processors to process Customer Personal Data, subject to this Section. A current list of sub-processors is maintained at https://nodge.ai/sub-processors.

7.2 Nodge imposes on each sub-processor, by written contract, data-protection obligations equivalent to those in this DPA, and remains responsible for its sub-processors' performance.

7.3 Nodge will give the Customer at least 4 weeks' prior notice of the addition or replacement of a sub-processor, by updating the sub-processor page. The Customer may object on reasonable data-protection grounds within that period. If the Customer objects and the parties cannot agree a resolution, the Customer may terminate the affected part of the Service and receive a refund of any prepaid, unused fees for that part.

7.4 All sub-processors that process Customer Personal Data are located within the European Union / European Economic Area. Nodge does not engage sub-processors that are US-controlled or otherwise subject to third-country access laws in the runtime path of the Service.

8. Assistance to the Customer

Taking into account the nature of the processing, Nodge will assist the Customer by appropriate technical and organisational measures, insofar as possible, with:

• responding to data-subject requests to exercise their rights under the GDPR (access, rectification, erasure, restriction, portability, objection);
• ensuring the security of processing (Article 32);
• notifying and communicating personal data breaches (Articles 33 to 34); and
• carrying out data protection impact assessments and prior consultation (Articles 35 to 36).

Where the Service provides self-service tools for these tasks (for example, export and deletion), the Customer will use those tools in the first instance. Assistance beyond those tools is provided on reasonable request and within the timeframe the Customer's own legal deadline requires. Nodge may charge a reasonable fee for assistance that is unusually burdensome or that falls outside the standard self-service tools.

9. International transfers and data location

The Nodge platform (control plane). Nodge's own platform data, including account and organisation data, platform metadata, Git repositories, the container registry, logs, and platform backups, is hosted in the Netherlands (Amsterdam) and stays within the European Union. Backups are stored on an offsite target located in the EU; there is no replication of this data outside the EEA. For this platform data, Nodge does not transfer Customer Personal Data to any country outside the EEA and engages no sub-processor outside the EEA. Accordingly, no transfer mechanism under Chapter V of the GDPR (such as Standard Contractual Clauses) is required for Nodge's own processing under this DPA.

Customer-chosen cluster location. Where the Customer provisions compute, the Customer chooses the location of its cluster from the options offered by the underlying hosting provider. The default is the Netherlands. Some of these options are outside the EEA. If the Customer selects a location outside the EEA, its application data and workloads run in that location, and that placement, and any resulting transfer of personal data outside the EEA, is the Customer's decision and the Customer's responsibility as controller, not a transfer made by Nodge. The Customer is responsible for any transfer mechanism its own choice of location requires. Nodge's control plane remains in the Netherlands regardless of the cluster location the Customer chooses. From a Customer cluster, the control plane receives only a defined outbound telemetry stream (pre-aggregated metrics, alert summaries, deploy, health and pipeline events, and billing usage); raw application logs are never sent to Nodge and stay on the Customer's cluster. Backups reach Nodge only as encrypted ciphertext that Nodge cannot decrypt, as the control plane does not hold the decryption key. The control plane has no standing inbound access into the Customer cluster; the cluster ships data outbound only.

Self-hosted and air-gapped deployments. The Service runs entirely within the Customer's own environment and Nodge does not process Customer Personal Data at all after installation (Section 2). Air-gapped deployments do not phone home: no metadata or telemetry reaches Nodge. Data location is determined entirely by the Customer.

If, in future, Nodge proposes any processing on its own part that would involve a transfer outside the EEA, it will notify the Customer in advance under Section 7 and will not proceed without a valid Chapter V transfer mechanism and the Customer's ability to object.

Note: the Customer's own choice of LLM model provider is outside this DPA. If the Customer configures a non-EEA model provider using its own LLM Keys, that provider is the Customer's vendor and any resulting transfer is the Customer's responsibility, not Nodge's.

10. Audits and information

Nodge will make available to the Customer the information necessary to demonstrate compliance with Article 28 and this DPA, and will allow for and contribute to audits, including inspections, conducted by the Customer or an auditor it mandates. To satisfy this obligation Nodge will in the first instance provide its ISO 27001:2022 certificate and Statement of Applicability, an independent penetration-test report, and its documented security pack (available under NDA). On-site audits may be conducted no more than once per year, on reasonable prior notice, during business hours, subject to confidentiality, and at the Customer's cost unless an audit reveals a material breach.

11. Personal data breaches

Under the GDPR, notification of a personal data breach to the supervisory authority (in the Netherlands, the Autoriteit Persoonsgegevens) is the controller's responsibility. Nodge, as processor, does not make notifications to the supervisory authority; instead Nodge informs the Customer correctly, in time, and in full about relevant incidents, so that the Customer as controller can meet its own legal obligations. To assess whether an incident is a personal data breach, Nodge uses the GDPR and the Dutch policy rules on the data-breach notification duty (Beleidsregels meldplicht datalekken) as guidance.

Notification to the Customer. When Nodge has a security incident or data breach, the Customer will hear about it as soon as possible after it becomes known to Nodge, and in any event within 48 hours of Nodge's discovery. A breach at a sub-processor is notified in the same way, with Nodge acting as the Customer's point of contact. The Customer is expected to assist Nodge where relevant.

The Customer's own deadline. The GDPR requires a breach to be notified "without undue delay" and, where feasible, no later than 72 hours after the controller becomes aware of it. The Customer must itself assess whether the incident is a personal data breach and whether notification to the supervisory authority or to data subjects is required. That 72-hour period for the Customer starts once Nodge has informed it.

Information, progress, and measures. Nodge aims to give the Customer all the information needed for any notification to the supervisory authority or to affected data subjects, and keeps the Customer informed of progress and of the measures Nodge takes, including when the situation changes or further information becomes available. Nodge notifies the contact person designated for the account; the Customer is responsible for keeping that contact person, and any additional breach-notification contacts, up to date. Nodge maintains a documented incident-response runbook.

12. Return or deletion on termination

On termination of the Agreement, and at the Customer's choice, Nodge will delete or return Customer Personal Data held in the EU cloud, and delete existing copies, unless EU or Netherlands law requires storage. The Customer may export Customer Personal Data in standard formats before deletion, and Nodge keeps it available for export for 30 days after termination, matching the Terms. For self-hosted deployments, Customer Personal Data remains in the Customer's environment and this Section does not apply to it. Backups containing Customer Personal Data are purged within the backup retention cycle described in Annex II after the data is deleted from the live Service.

13. Liability and precedence

The liability provisions of the Agreement apply to this DPA. In case of conflict between this DPA and the rest of the Agreement regarding the processing of personal data, this DPA prevails.

Annex I: Description of the processing

Annex II: Technical and organisational measures (Article 32)

These measures reflect the platform as described at https://nodge.ai/security and https://nodge.ai/sovereignty.

Access control and governance

• Granular per-action permissions (individual permission flags, not roles).
• Two-person approval for production deployments, with fresh step-up authentication and the initiator blocked from self-approval.
• Full audit log of material platform actions, recorded by actor, target, and time. Records are queryable in the platform for a configurable window (default 3 months), then archived to per-organisation monthly files (verified before hot rows are removed) and retained for a further configurable period (default 365 days), downloadable by organisation admins. Both windows are configurable per deployment.
• Bring-your-own identity provider over OIDC per organisation; identity-provider client secrets stored encrypted at rest.
• Secrets are isolated per environment; AI agents run without access to secrets or raw provider keys.

Encryption

• Encryption of data at rest using AES-256-GCM at the application layer, with the master key held outside the database, plus cluster-layer storage encryption (including the Kubernetes secret store, via etcd secrets encryption), with key material held separately from the data it protects.
• User passwords hashed with bcrypt; bearer tokens stored as SHA-256 hashes, never in plaintext.
• TLS 1.2 or higher on every public endpoint.
• Plaintext secrets are never logged, never written to disk on the platform host, and never shipped to external observability backends.
• Backups encrypted before leaving the platform host, using a key the platform does not hold.

Data residency and isolation

• The platform control plane, its data, metadata, logs, and platform backups are hosted in the Netherlands and stay within the EU. Customer application data runs in the cluster location the Customer chooses (default Netherlands), with no replication outside that chosen location by Nodge.
• No external vendor control plane. Air-gapped deployments do not phone home. For Customer clusters, only a defined outbound telemetry stream reaches the control plane (pre-aggregated metrics, alert summaries, deploy, health and pipeline events, and billing usage), as described in Section 9; raw application logs stay on the Customer's cluster, and the control plane has no standing inbound access into the cluster.
• Per-project isolation: each customer application runs in its own Kubernetes namespace with its own database instance and default-deny networking between projects, with logs and metrics tenant-scoped per project. On shared (EU Cloud) infrastructure these seams are what separate tenants; on dedicated or air-gapped deployments the Customer owns the whole cluster.
• Access to platform metadata (project, membership, and permission records) is enforced by a per-request permission layer scoped to project and user in all models.
• Per-organisation build runners; CI in one organisation cannot read another's source, artifacts, or pipeline secrets.

Network and abuse protection

• Active threat detection over platform logs and host events (CrowdSec), enforced at the host firewall.
• Host firewall configured for IPv4 and IPv6 as part of installation; internal surfaces sit behind a session gate.

Supply-chain security

• Container images scanned, signed (cosign), and accompanied by an SBOM (CycloneDX) with SLSA build provenance; vulnerability scanning blocks the build.
• Static analysis and secret scanning on every code change, and automated licence-compliance checks, blocking the merge on findings.
• Dependencies and build steps pinned to exact versions, with a required lockfile; runtime hardening with privilege escalation disabled, dropped capabilities, and a read-only root filesystem.

Backup and recovery

• Nightly backups of platform databases, Git repositories, and certificate material.
• Backups written to a target that the platform can write to but cannot read back or delete; decryption key held off-host in a vault; restore is a deliberate human action initiated outside the platform.

Organisational

• ISO/IEC 27001:2022 certification, audited annually, with Statement of Applicability available on request.
• Annual external penetration test.
• Documented incident-response runbook; the Customer is notified of a breach within 48 hours of discovery (Section 11), and a documented key-rotation runbook.
• Confidentiality obligations and security training for personnel.

Annex III: Sub-processors

The current list of sub-processors, their purpose, and their location is maintained at https://nodge.ai/sub-processors and forms part of this DPA. All are located within the EU/EEA.

Contact

CoreCubes B.V. (Nodge), Winklerlaan 363-41, 3571 KE Utrecht, the Netherlands. KvK 94074542 · BTW NL866626402B01. Reach us at info@nodge.ai.