Data Processing Agreement

# Data Processing Agreement **KuiperDesk Backup-as-a-Service** Effective Date: 2026-03-19 Document Version: 1.0 --- ## 1. Parties This Data Processing Agreement ("DPA") is entered into between: - **Controller**: The entity identified in the KuiperDesk Service Agreement ("Customer" or "Controller") - **Processor**: Arivaran Inc., operating the KuiperDesk backup-as-a-service platform at arivaran.ai ("Arivaran" or "Processor") This DPA supplements and forms part of the KuiperDesk Service Agreement between Controller and Processor. --- ## 2. Definitions - **"Backup Data"**: All data captured from Controller's Windows endpoints via Volume Shadow Copy Service (VSS) snapshots, including files, system state, and associated metadata. - **"Block"**: A fixed-size segment of Backup Data identified by its SHA-256 cryptographic hash. - **"Cross-Tenant Deduplication"**: The process by which identical Blocks from different Controllers are stored once in a shared storage prefix (m/) to eliminate redundant storage, available only under Tier C. - **"Hub"**: Arivaran's centralized infrastructure located in the United States (OVH US data centers). - **"Satellite"**: A KuiperDesk deployment located on-premises at the Controller's designated facility, providing local data residency. - **"Personal Data"**, **"Processing"**, **"Data Subject"**, **"Supervisory Authority"**, and **"Sub-processor"** have the meanings given in Regulation (EU) 2016/679 ("GDPR"). --- ## 3. Subject Matter and Duration of Processing ### 3.1 Subject Matter The Processor provides Windows endpoint backup, deduplication, storage, and restoration services through the KuiperDesk platform. Processing involves: 1. **Capture**: VSS snapshot of Controller's Windows endpoint volumes 2. **Segmentation**: Division of volume data into fixed-size blocks 3. **Deduplication**: Computation of SHA-256 hash per block; comparison against existing block inventory via the aaHashSvc gRPC service 4. **Storage**: Upload of unique blocks to S3-compatible object storage (SeaweedFS) with content-addressed keys 5. **Metadata Cataloging**: Recording of file-to-block mappings, snapshot metadata, and volume geometry in the aaTwinSvc catalog (Citus/PostgreSQL) and hash index (PostgreSQL/Citus) 6. **Restoration**: Retrieval of blocks by hash, reassembly of files and volumes, and restoration to target Windows endpoint ### 3.2 Duration Processing continues for the term of the Service Agreement plus the period required to complete deletion obligations under Section 11. --- ## 4. Types of Personal Data Processed The Processor processes all data present on Controller's Windows endpoints, which may include but is not limited to: - Documents containing personal identifiers (names, addresses, national ID numbers) - Email archives and messaging data - Database files containing customer records - Financial records and accounting data - Employee HR records - System configuration files containing credentials or access tokens - Browser data and application caches - Medical or health-related records (if present on endpoints) The Processor does not inspect, classify, or index the content of Backup Data. All data is processed as opaque byte sequences during deduplication and storage. --- ## 5. Categories of Data Subjects Data Subjects whose Personal Data may be contained within Backup Data include: - Controller's employees and contractors - Controller's customers and end users - Controller's business contacts and partners - Any other individuals whose data resides on Controller's Windows endpoints --- ## 6. Obligations of the Processor ### 6.1 Lawful Processing The Processor shall process Personal Data only on documented instructions from the Controller, 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 the Processor is subject. In such case, the Processor shall inform the Controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest. ### 6.2 Confidentiality The Processor shall ensure that persons authorized to process Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. ### 6.3 Security Measures The Processor shall implement the technical and organizational measures specified in Annex A, including: - FIPS 140-2 compliant cryptographic operations - Mutual TLS (mTLS) for all inter-service communication - TLS 1.3-encrypted gRPC over the aaSatGwSvc tunnel between infrastructure nodes - PgEdge multi-master replication (hub) and CNPG streaming replication (satellites) for hash metadata durability - Kubernetes NetworkPolicy enforcement via Cilium CNI - Content-addressed storage preventing unauthorized block enumeration - Role-based access control via Keycloak SSO with OIDC ### 6.4 Sub-processors The Processor shall not engage another processor without prior specific or general written authorization of the Controller. The current list of Sub-processors is provided in Annex B. The Processor shall inform the Controller of any intended changes concerning the addition or replacement of Sub-processors, giving the Controller the opportunity to object to such changes. ### 6.5 Data Subject Rights The Processor shall assist the Controller by appropriate technical and organizational measures, insofar as possible, for the fulfillment of the Controller's obligation to respond to requests for exercising the Data Subject's rights under Chapter III of the GDPR. ### 6.6 Assistance with Compliance The Processor shall assist the Controller in ensuring compliance with Articles 32 to 36 of the GDPR, taking into account the nature of processing and the information available to the Processor. ### 6.7 Audit Rights The Processor shall make available to the Controller all information necessary to demonstrate compliance with this DPA and shall allow for and contribute to audits, including inspections, conducted by the Controller or another auditor mandated by the Controller. The Processor shall immediately inform the Controller if, in its opinion, an instruction infringes the GDPR or other Union or Member State data protection provisions. --- ## 7. Cross-Tenant Deduplication Disclosure (Tier C) ### 7.1 Mechanism Under Tier C service plans, the Processor employs cross-tenant deduplication. When multiple Controllers back up blocks with identical SHA-256 hashes, the block is stored once in the shared storage prefix (`m/`) rather than duplicated per tenant. The hash metadata service (aaHashSvc) maintains a reference count for each shared block. ### 7.2 Data Isolation Guarantees - No Controller can enumerate, discover, or access blocks belonging to another Controller - Block existence queries (CheckHashes) return only a boolean indicator; no ownership metadata is disclosed - The SHA-256 hash alone does not reveal the content of the block to any party that does not already possess the original data - Access to block content requires valid restore credentials and a valid file-to-block mapping from the requesting Controller's own catalog ### 7.3 Opt-Out Controllers may opt out of cross-tenant deduplication at any time by requesting migration to Tier A or Tier B, or by enabling the per-tenant isolation flag within Tier C. Upon opt-out, the Controller's blocks are copied to a tenant-isolated storage prefix, and shared reference counts are decremented accordingly. ### 7.4 Legal Basis The Processor relies on the Controller's instruction (this DPA) as the legal basis for cross-tenant deduplication. A separate Legitimate Interest Assessment is available upon request. --- ## 7A. Agent Access Credential Guardrail Disclosure This section applies only where the Controller uses Beam Agent Access through the **managed inspection gateway** on an Arivaran-managed deployment. It records a processing default the Controller may opt out of. ### 7A.1 What Is Inspected On the managed inspection route, the relay already terminates the agent's connection to forward it. There, the Processor checks each request body for **secrets and credentials only**: - API keys and access tokens with a recognised issuer prefix (for example cloud-provider, source-hosting, payment and AI-provider keys) - JSON Web Tokens - AWS access key IDs - PEM private keys The Processor does **not** inspect request bodies for personal data and does **not** classify prompts (for example, for prompt injection). Provider-blind passthrough and customer-side key broker routes are never inspected, because the relay cannot read their content. The inspection is bounded per request. A body larger than the bound is inspected only in part, and its uninspected remainder is treated as unknown, never as clean. ### 7A.2 What Is Recorded, and Redaction - **A decision records finding type and count, never content.** It is attached to the authorization-decision audit record for the request (the signed record the relay writes for each admitted request) as the credential classes found and how many of each, plus whether the body was fully inspected. - **Each finding is redacted before any log or record.** Where a copy of the request body is kept, for example by the optional request inspector the Controller may enable for a route, every finding is replaced with a marker naming its class before the copy is stored. A body that could not be inspected in full is withheld from the record rather than stored unredacted. - **Requests are forwarded unchanged.** The guardrail does not alter what the Controller's agent sends to its model provider. ### 7A.3 Retention A guardrail decision has **no separate retention period**. It is kept for exactly as long as the authorization-decision audit record it is attached to, and is deleted with that record. ### 7A.4 Default and Opt-Out The guardrail is **on by default** for tenants of an Arivaran-managed deployment. A Controller administrator may opt the tenant out at any time on the Agent Access page of the dashboard ("Credential guardrail"). The change takes effect within five minutes, after which no request body of that tenant is inspected and no guardrail decision is recorded. If the Processor cannot read a tenant's opt-out setting at the time of a request, that request is not inspected. ### 7A.5 Self-Hosted Deployments On a self-hosted relay, the guardrail is **off by default** and stays off unless the operator of that relay configures a posture. A self-hosted relay with no posture configured inspects no request body. --- ## 8. Sub-processors ### 8.1 Current Sub-processors See Annex B for the complete list. As of the Effective Date: | Sub-processor | Purpose | Location | Data Processed | |---------------|---------|----------|----------------| | OVH SAS | Infrastructure hosting (VPS compute, network) | US (Vint Hill, VA) | Backup Data (encrypted at rest and in transit) | | Cloudflare Inc. | DNS resolution, DDoS protection | Global (Anycast) | Domain query metadata only; no Backup Data transits Cloudflare | ### 8.2 Notification of Changes The Processor shall notify the Controller at least 30 days before engaging a new Sub-processor. If the Controller objects, the parties shall negotiate in good faith. If no resolution is reached within 15 days, the Controller may terminate the affected service component. --- ## 9. Data Residency and International Transfers ### 9.1 Hub Deployment By default, Backup Data is stored in Arivaran's Hub infrastructure located in the United States. For Controllers subject to GDPR, the Processor relies on Standard Contractual Clauses (SCCs) adopted by the European Commission (Commission Implementing Decision (EU) 2021/914) to legitimize transfers from the EEA to the US. ### 9.2 Satellite Deployment Controllers requiring data residency within a specific jurisdiction may deploy a KuiperDesk Satellite. A Satellite is an on-premises instance of the KuiperDesk storage and metadata infrastructure deployed at the Controller's designated facility. When a Satellite is deployed: - All Backup Data and metadata remain within the Satellite's physical location - Only anonymized telemetry and license validation traffic reaches the Hub - Cross-tenant deduplication is limited to tenants within the same Satellite - The Controller is responsible for physical security of the Satellite hardware ### 9.3 Transfer Impact Assessment The Processor maintains a Transfer Impact Assessment (TIA) evaluating US surveillance laws (FISA Section 702, EO 12333) and supplementary measures. The TIA is available upon request. Key supplementary measures include: - Encryption of all Backup Data in transit (WireGuard + mTLS) and at rest (AES-256) - Content-addressed storage preventing bulk data access without cryptographic keys - No government access agreements or backdoors - Commitment to challenge any government data access request and notify Controller where legally permitted --- ## 10. Personal Data Breach Notification ### 10.1 Notification Timeline The Processor shall notify the Controller without undue delay and in no event later than **48 hours** after becoming aware of a Personal Data breach affecting the Controller's data. ### 10.2 Notification Content The notification shall include: - Nature of the breach, including categories and approximate number of Data Subjects and records concerned - Name and contact details of the Processor's data protection point of contact - Likely consequences of the breach - Measures taken or proposed to address the breach, including measures to mitigate adverse effects ### 10.3 Cooperation The Processor shall cooperate with the Controller and take reasonable commercial steps to assist in the investigation, mitigation, and remediation of each breach. The Processor shall document all breaches, including the facts relating to the breach, its effects, and the remedial action taken. --- ## 11. Data Deletion and Return ### 11.1 Upon Termination Upon termination of the Service Agreement, the Processor shall, at the Controller's choice: - **Return**: Export all Backup Data in a portable format (block archive with file-to-block mapping) within 30 days of request - **Delete**: Initiate deletion of all Controller-specific data ### 11.2 Deletion Process Deletion proceeds in the following order: 1. **Catalog deletion** (immediate): Removal of all file-to-block mappings, snapshot records, and volume metadata from the aaTwinSvc catalog (Citus/PostgreSQL) 2. **Hash metadata deletion** (within 30 days): Snapshot-level mark-and-sweep GC in aaHashSvc (PostgreSQL/Citus). Blocks with zero remaining references are marked with a tombstone timestamp. 3. **Block deletion** (asynchronous): Blocks marked as tombstoned for more than 14 days are permanently deleted from S3 storage during the next garbage collection cycle For cross-tenant deduplicated blocks (Tier C, m/ prefix), deletion of hash metadata is immediate, but the physical block persists in shared storage until all reference counts reach zero. ### 11.3 Certification The Processor shall certify deletion in writing upon completion of the deletion process, no later than 60 days after initiation. --- ## 12. Governing Law and Jurisdiction This DPA shall be governed by the laws applicable to the Service Agreement, except that mandatory data protection laws of the Data Subject's jurisdiction shall apply to the extent they provide additional protections. --- ## Annex A: Technical and Organizational Security Measures ### A.1 Encryption | Layer | Mechanism | Standard | |-------|-----------|----------| | Data in transit (inter-node) | mTLS over aaSatGwSvc tunnel | TLS 1.3 (AES-256-GCM / ChaCha20-Poly1305) | | Data in transit (gRPC) | Mutual TLS (mTLS) | TLS 1.3, FIPS mode | | Data in transit (client-to-service) | TLS 1.3 via nginx Ingress | FIPS-compliant cipher suites | | Data at rest (S3 blocks) | Server-side encryption | AES-256-GCM | | Client-side encryption (Tier A) | Mandatory, customer-managed keys | AES-256-GCM | | Client-side encryption (Tier B) | Default on, Arivaran-managed keys | AES-256-GCM | | Client-side encryption (Tier C) | Opt-in, Arivaran-managed keys | AES-256-GCM | ### A.2 Access Control - Keycloak OIDC/SSO for all administrative access - Kubernetes RBAC with namespace-level tenant isolation - NetworkPolicy (Cilium) restricting pod-to-pod communication to explicit allowlists - No shared administrative credentials; individual accounts with MFA enforced for Processor personnel - Controller accounts: MFA (an authenticator app or a passkey) is available to every account and is not required at sign-in by default; the Controller's administrator can require it of every Controller user through the Controller's sign-in policy, where the Controller has its own sign-in; a fresh second factor is required before privileged administrative actions in the dashboard; a text-message (SMS) code is never accepted as a second factor ### A.3 Data Integrity - SHA-256 content addressing ensures block integrity (corruption detected on read) - PgEdge multi-master replication for hub hash metadata; CNPG streaming replication for satellite hash metadata - Citus/PostgreSQL with PgEdge (hub) or CNPG operator (satellites) managing replication for catalog data - Automated backup verification via periodic test restores ### A.4 Availability - RKE2 Kubernetes with node-level health monitoring - VictoriaMetrics + Grafana monitoring with AlertManager - Gatus status page (status.arivaran.ai) with uptime tracking - Defined RTO/RPO targets per service tier in the Service Agreement ### A.5 Incident Response - 24/7 automated alerting via AlertManager - Documented incident response runbook - Post-incident review within 5 business days - Annual penetration testing by independent third party --- ## Annex B: Approved Sub-processors | Sub-processor | Registered Address | Processing Activity | Location of Processing | Date Added | |---------------|--------------------|---------------------|------------------------|------------| | OVH SAS | 2 Rue Kellermann, 59100 Roubaix, France | Infrastructure hosting (compute, storage, network) | United States (Vint Hill, VA) | 2026-03-19 | | Cloudflare Inc. | 101 Townsend St, San Francisco, CA 94107, USA | DNS resolution, DDoS mitigation | Global (Anycast network) | 2026-03-19 | The Controller will be notified of any additions or changes to this list per Section 8.2. --- ## Signatures **Controller** Name: ___________________________ Title: ___________________________ Date: ___________________________ Signature: ___________________________ **Processor (Arivaran Inc.)** Name: ___________________________ Title: ___________________________ Date: ___________________________ Signature: ___________________________