Data Processing Agreement

How to read this

This DPA covers a narrower thing than the Privacy Policy. The Privacy Policy describes how inis.run, acting as controller, handles your own account, billing, and security data. This DPA describes how inis.run, acting as processor, handles Customer Personal Data — whatever personal data your own application sends into a session for execution, on your instructions. Two different roles, two different sets of data.

1. Parties, subject matter, and duration

This Data Processing Agreement is entered into between the customer identified on the applicable account (“Customer”, the Controller) and inis.run (the Processor), and forms part of the Terms of Service. It governs inis.run’s processing of Customer Personal Data in connection with the Service, for as long as that processing occurs, until deletion or return under Section 11.

2. Nature and purpose of processing

inis.run provides on-demand, isolated code-execution sessions. Customer’s application sends code and, at Customer’s discretion, data into a session via the API; inis.run runs it in a dedicated, hardware-isolated virtual machine and returns the result. By design, inis.run does not inspect, classify, or log the content of the code or the input/output data processed inside a session — see the Privacy Policy §2. The purpose of processing is solely to provide the execution infrastructure Customer instructs it to provide.

3. Types of personal data and categories of data subjects

Because inis.run does not inspect in-session data, the types of personal data and categories of data subjects processed under this DPA are determined entirely by Customer’s own use of the Service. Customer is responsible for having a lawful basis for any personal data — including any special category data — it sends into a session.

Separately, and outside “Customer Personal Data” above: inis.run as controller collects limited account and operational metadata about Customer’s own authorized users (billing email, IP address, request logs), described in the Privacy Policy.

4. Controller and processor obligations

Customer warrants it has lawful basis to submit Customer Personal Data via the Service. inis.run will: process Customer Personal Data only on Customer’s documented instructions (the Terms of Service and the API calls Customer makes); keep authorized personnel under confidentiality obligations; implement the measures in Annex 3; assist with data-subject-rights requests and breach notification (Sections 8–9); and make available information reasonably necessary to demonstrate compliance.

5. Sub-processors

inis.run uses the sub-processors listed at inis.run/security/subprocessors. Customer authorizes inis.run’s use of those sub-processors for the purposes described there, and will get at least 30 days’ notice before a new one is added or an existing one is replaced, per the change-notification commitment on that page.

6. International transfers

The infrastructure that runs sessions does not, by design, transfer Customer Personal Data outside the EU. Where a sub-processor’s own processing involves a transfer outside the EEA/UK — see the sub-processor list’s notes on Stripe and legacy email — we rely on an appropriate GDPR Article 46 mechanism, such as Standard Contractual Clauses, once that transfer is confirmed to exist. We will not assert SCCs are in place for a transfer we have not confirmed.

7. Security measures

inis.run implements the technical and organisational measures in Annex 3. These are measures actually built and operating, or explicitly marked in progress — this document does not claim a certification we do not hold. SOC 2 is in progress, not certified.

8. Assistance with data subject rights

Because inis.run does not inspect in-session data, it generally cannot identify or act on a data-subject-rights request about that data on its own — Customer, as controller of it, is best placed to locate and respond within its own application. Where a request needs action on infrastructure inis.run controls (deleting a specific session, checkpoint, or template on Customer’s instruction), inis.run will assist.

9. Personal data breach notification

inis.run will notify Customer without undue delay after becoming aware of a personal data breach affecting Customer Personal Data, and will provide the information reasonably available to help Customer meet its own notification obligations. [NEEDS FOUNDER + LEGAL INPUT] — a specific notification timescale is not fixed here.

10. Audits

inis.run will make available information reasonably necessary to demonstrate compliance with this DPA. [NEEDS FOUNDER + LEGAL INPUT] — notice period, frequency, and cost allocation for on-site/technical audits are not yet defined.

11. Deletion or return on termination

On termination of the Service, or on Customer’s request, inis.run will delete Customer Personal Data using the mechanisms in Annex 3 (session destroy, explicit checkpoint/template deletion, and the session and artifact retention windows Customer configures), except to the extent applicable law requires retention.

12. Liability and precedence

[NEEDS FOUNDER + LEGAL INPUT] — liability allocation, caps, and precedence between this DPA and the Terms of Service are contract terms for counsel to set, not facts to state unilaterally in a draft.

Annex 2 — Sub-processors

See inis.run/security/subprocessors.

Annex 3 — Technical and organisational measures

What is in place today. Anything still in progress is said so, in the entry it applies to. Nothing here claims a certification we do not hold.

• Tenant isolation. Each session runs in its own hardware-isolated virtual machine with its own kernel and memory, not a shared container. VMs are single-use: destroyed after the work, never reissued to another customer.
• Encryption at rest. The tenant-data volume on execution nodes — session rootfs clones, guest-memory snapshots, checkpoints, and persistent volume images — is encrypted at rest (LUKS2, aes-xts-plain64) with a key generated fresh in memory on every node boot and never written to disk. Archived checkpoints and templates in object storage are additionally wrapped under a per-tenant encryption key managed through Scaleway Key Manager, so one customer’s archives cannot be decrypted using another customer’s key.
• Deny-by-default egress control. Networking for a session can be configured deny-by-default: Customer allowlists the exact domains a workload needs, enforced on the host, outside the VM.
• Tamper-evident audit log. Session lifecycle events — and, for sessions Customer runs under a deny-by-default egress allowlist, every outbound network attempt, allowed or denied — are recorded in a log hash-chained per node so tampering with a past entry is detectable, readable via the console and audit API. Sessions left on the default full-egress policy produce no network events. A single exportable auditor evidence pack is in progress.
• Data lifecycle and deletion receipts. Every session destroy, including automatic expiry, emits a deletion receipt in the audit log naming what was destroyed, when, and why. Receipts for checkpoint/template deletion are in progress.
• Jurisdiction. Infrastructure is built and run in the EU, by an EU-owned business with no US parent entity — see the sub-processor list for hosting-region detail.
• Internal access control. Internal and control-plane services reach production infrastructure through individually named credentials, rotatable one at a time. Every authenticated internal request is logged with the calling service’s identity, the customer it is acting on behalf of, and what it did. Deploy tooling runs under scoped, least-privilege credentials.
• Vulnerability management. Every code change is scanned for known vulnerabilities in its dependencies before it merges, plus a standing weekly sweep for newly disclosed CVEs against unchanged code. No third-party penetration test has been commissioned yet.
• Certifications. SOC 2 is in progress. No certification is claimed until it is actually held.