Data Processing Agreement (DPA)

Last Updated: May 12, 2026

This Data Processing Agreement ("DPA") reflects the parties' agreement with respect to the Processing of Personal Data by {{COMPANY_NAME}} on behalf of the Customer.

1. DEFINITIONS, ROLES, AND SCOPE OF PROCESSING

1.1. Incorporation and Applicable Law

This Data Processing Agreement ("DPA") is an integral addendum to, and is expressly incorporated by reference into, the master Terms of Service ("ToS") entered into between the Provider and the Customer. This DPA governs the processing of Personal Data by the Provider on behalf of the Customer in the context of providing the SaaS e-commerce Platform. The Parties agree that this DPA is governed by the Regulation (EU) 2016/679 (the "GDPR") and the French Data Protection Act (Loi Informatique et Libertés), as amended. Terms such as "Personal Data", "Processing", "Data Controller", "Data Processor", and "Data Subject" shall have the meanings strictly assigned to them by Article 4 of the GDPR.

1.2. Qualification of Roles (Article 28 GDPR)

The Parties acknowledge and strictly agree to the following allocation of legal roles and responsibilities regarding the End-Consumer Data residing within the Customer's isolated tenant_db:

The Customer is the Data Controller (Responsable de traitement): The Customer alone determines the purposes and means of processing the Personal Data. The Customer is solely responsible for establishing a valid legal basis (e.g., consent, contract execution) for collecting this data from their End-Consumers and for complying with all transparency and information obligations.
The Provider is the Data Processor (Sous-traitant): The Provider processes the Personal Data strictly on behalf of, and acting entirely under the instruction of, the Customer to furnish the underlying technical infrastructure and software capabilities of the Platform.

1.3. Scope, Nature, and Purpose of Processing

The Provider’s role is strictly limited to the provision of passive cloud-hosting infrastructure, database orchestration (Kubernetes), and associated SaaS routing functionalities. The Provider shall process Personal Data exclusively for the purpose of executing the master Terms of Service—specifically, to host the Customer's Data Plane, maintain the digital storefront’s uptime, and facilitate the technical transmission of End-Consumer orders. Zero-Monetization Guarantee: The Provider explicitly guarantees that it shall never mine, sell, rent, cross-reference, or utilize End-Consumer Personal Data for its own commercial purposes, algorithmic training, or third-party advertising.

1.4. Categories of Data Subjects and Personal Data

The specific scope of Personal Data processed within the Shared Infrastructure is determined and controlled entirely by the Customer through their configuration of the Data Plane storefront. Typically, this encompasses:

Categories of Data Subjects: The Customer’s End-Consumers (visitors, registered users, and buyers on the storefront), as well as the Customer’s Authorized Users (employees/administrators).
Categories of Personal Data: * Identification Data: First name, last name, email address, phone number.
- Commercial & Transactional Data: Shipping address, billing address, order history, cart contents, and partial payment tokens (excluding full PCI-DSS PANs, which are routed directly to third-party gateways like Payplug or Stripe).
- Technical Data: IP addresses, browser user-agents, and storefront navigation logs utilized for security and basic analytics.
Special Categories of Data (Prohibition): The Customer is strictly prohibited from utilizing the standard Platform to process highly sensitive data (e.g., medical records, biometric data, revealing racial/ethnic origins) under Article 9 of the GDPR without first upgrading to a VIP Dedicated Infrastructure and signing a specialized addendum.

2. OBLIGATIONS OF THE PROCESSOR (PROVIDER)

2.1. Processing on Documented Instructions

The Provider shall process Personal Data only on documented instructions from the Customer. For the purposes of this DPA, the Customer’s documented instructions are defined as:

The Agreement: The provisions of the master Terms of Service (ToS) and this DPA.
Platform Usage: The Customer’s ongoing, active use of the Platform, including the configuration of their Control Plane administrative dashboard and the daily operational routing of End-Consumer transactions.
Out-of-Band Instructions: Specific, documented written requests submitted by the Customer via the Provider’s official technical support ticketing system or designated administrative email channels, provided such instructions are technically feasible within the Platform's Shared Infrastructure architecture.

The Provider shall not process Personal Data outside the scope of these instructions unless explicitly required to do so by European Union or French law to which the Provider is subject. In such a case, the Provider shall inform the Customer of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest. Furthermore, if the Provider reasonably believes that a specific instruction from the Customer infringes the GDPR or other EU data protection provisions, the Provider shall immediately notify the Customer and is authorized to suspend the execution of said instruction until it is modified or confirmed as lawful by the Customer.

2.2. Confidentiality and Personnel Access

The Provider ensures that any internal personnel, contractors, or system administrators (including Superadmins utilizing the JWT Technical Mandate defined in the ToS) authorized to process the Personal Data have committed themselves to strict confidentiality or are under an appropriate statutory obligation of confidentiality. The Provider guarantees that access to the Customer’s tenant_db is restricted on a strict "need-to-know" basis, limited exclusively to highly trained engineering and support personnel required to maintain the stability, security, or performance of the Shared Infrastructure.

2.3. Assistance with Data Subject Rights (DSARs)

Under Chapter III of the GDPR, End-Consumers possess specific rights regarding their Personal Data (including the Right of Access, Right to Rectification, Right to Erasure / "Right to be Forgotten", and Right to Data Portability). Because the Customer acts as the Data Controller, the Customer bears the sole and exclusive legal responsibility for receiving, verifying, and fulfilling these Data Subject Access Requests (DSARs) within the statutory deadlines.

The Provider’s obligations regarding DSARs are strictly limited to the following technical assistance:

Provision of Tooling: The Provider furnishes the Customer with self-service administrative tools within the Data Plane dashboard, enabling the Customer to directly view, export (e.g., via CSV/JSON), anonymize, or permanently delete an End-Consumer's record from the tenant_db without requiring the Provider's manual intervention.
Forwarding of Direct Requests: The Provider does not interact directly with End-Consumers. In the event that an End-Consumer contacts the Provider directly to exercise a GDPR right regarding data hosted on the Customer's storefront, the Provider shall not respond to the End-Consumer substantively. Instead, the Provider shall promptly forward the request to the Customer’s administrative email address on file. The Customer shall assume full responsibility for taking the appropriate action thereafter.

2.4. Data Protection Impact Assessments (DPIA) and Prior Consultation

Upon the Customer's written request, the Provider shall provide reasonable assistance to the Customer in fulfilling the Customer's obligations to carry out Data Protection Impact Assessments (DPIAs) and to consult with supervisory authorities (e.g., the CNIL), taking into account the nature of the processing and the specific technical information available to the Provider.

Cost of Assistance: The provision of standard security documentation, architecture overviews, and existing compliance summaries required for a standard DPIA shall be provided free of charge. If the Customer requests exceptional, customized assistance requiring significant, non-standard engineering or consulting time, the Provider reserves the right to charge for such services at its standard professional rates, subject to the Customer's prior written approval.

3. TECHNICAL AND ORGANIZATIONAL MEASURES (TOMS)

3.1. General Security Commitment (Article 32 GDPR)

Taking into account the state of the art, the costs of implementation, and the nature, scope, context, and purposes of the processing, the Provider guarantees that it has implemented, and will maintain throughout the Term of the Agreement, robust technical and organizational measures (TOMs) designed to ensure a level of security appropriate to the risk of the Personal Data being processed. These measures are designed to protect against accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to the Customer's Personal Data.

3.2. Logical Isolation and Cloud Architecture (Kubernetes)

While the Platform operates on a Shared Infrastructure hosted by OVHcloud, the Provider enforces strict logical segregation to prevent cross-tenant data exposure:

Namespace Isolation: The Customer’s Data Plane environment is deployed within dedicated, logically isolated namespaces utilizing industry-standard container orchestration (e.g., Kubernetes).
Database Segregation: The Customer’s End-Consumer Personal Data is stored in a dedicated, logically isolated database schema (tenant_db). Network policies explicitly forbid internal cross-namespace communication, ensuring that one tenant's web application cannot query or access another tenant’s database.

3.3. Encryption in Transit and at Rest

To protect data from interception or physical hardware compromise, the Provider employs enterprise-grade cryptographic standards:

In Transit: All external data transmissions between the End-Consumer's browser and the Customer's Data Plane, as well as all API communications between the Data Plane and the Control Plane, are strictly encrypted using TLS 1.2 or higher (TLS 1.3 preferred).
At Rest: The underlying block storage volumes (provided by OVHcloud) housing the tenant_db and object storage (MinIO) are encrypted at the disk level utilizing AES-256 encryption or equivalent industry standards.

3.4. Enterprise Secret Management (Zero-Knowledge Configuration)

The Provider strictly forbids the storage of plaintext database credentials, API keys, or critical configuration secrets within application source code or unencrypted configuration files. All critical infrastructure secrets required to run the Customer's Data Plane are dynamically injected, rotated, and secured using enterprise-grade vaulting architecture (e.g., HashiCorp Vault).

3.5. Access Control and the "Express Technical Mandate"

The Provider enforces the principle of least privilege. As established in Chapter 7 of the master Terms of Service, the Provider’s personnel possess zero standing access to the Customer’s plaintext administrative passwords.

Superadmin Access: Technical intervention requiring backend access to the Customer’s Data Plane is strictly prohibited without an explicit trigger (e.g., a support ticket or an automated critical alert).
JWT Impersonation: When authorized, highly restricted senior technical personnel utilize a cryptographically signed, short-lived JSON Web Token (JWT) to temporarily access the dashboard. This action is legally defined as an Express Technical Mandate executed on behalf of the Customer.
Immutable Audit Trails: Every instance of Superadmin access is automatically recorded in a secure, immutable audit log detailing the timestamp, the identity of the engineer, and the specific Data Plane accessed.

3.6. Backups, Resilience, and Disaster Recovery

To ensure the ongoing availability and resilience of processing systems, the Provider maintains automated backup and disaster recovery protocols:

Automated Snapshots: The Provider executes automated, encrypted backups of the Customer's tenant_db at regular intervals.
Retention and Deletion: These operational backups are retained for a rolling maximum period of sixty (60) days to allow for disaster recovery, after which they are automatically overwritten or destroyed, strictly enforcing the GDPR principle of data minimization.

3.7. Continuous Evaluation and Updates

The Provider maintains a process for regularly testing, assessing, and evaluating the effectiveness of these technical and organizational measures. The Provider reserves the right to update or modify these TOMs as technologies evolve, provided that such updates do not materially degrade the overall security posture of the Platform as established in this DPA.

4. SUB-PROCESSING AND THIRD-PARTY INFRASTRUCTURE

4.1. General Authorization for Sub-processing

The Customer acknowledges that the Provider operates a complex, cloud-based Software-as-a-Service architecture that relies on specialized third-party infrastructure. In accordance with Article 28(2) of the GDPR, the Customer hereby grants the Provider general written authorization to engage third-party sub-processors ("Sub-processors") to process Personal Data on behalf of the Customer in order to deliver the Platform and fulfill the obligations set forth in the master Terms of Service.

4.2. Current Approved Sub-processors

As of the effective date of this Agreement, the Customer explicitly approves the Provider's use of the following core Sub-processors to host the Data Plane and process End-Consumer transactions:

Hosting Infrastructure: OVH Groupe SAS (OVHcloud), located in France, utilized for the physical provisioning of the overarching Kubernetes Shared Infrastructure, compute nodes, and block storage for the tenant_db.
Payment Gateways: Integrated third-party payment processors (e.g., Payplug, Stripe) utilized for secure transaction routing. (Note: Depending on the exact flow of PCI-DSS data, payment gateways often act as independent Data Controllers regarding the actual credit card details, but are listed here for complete transparency regarding transactional data flows).

4.3. Addition or Replacement of Sub-processors

The Provider reserves the right to add, replace, or modify its Sub-processors (for example, migrating infrastructure from OVHcloud to AWS or utilizing a new transactional email delivery service) to maintain the performance, security, and scalability of the Platform. The Provider shall notify the Customer in writing (via email or a notification within the Control Plane dashboard) of any intended changes concerning the addition or replacement of a Sub-processor at least thirty (30) calendar days prior to the new Sub-processor processing any of the Customer's Personal Data.

4.4. The Customer's Right to Object

If the Customer has a reasonable, legally grounded objection to the Provider's use of a new Sub-processor (e.g., the new Sub-processor operates in a jurisdiction lacking adequate data protection laws without standard contractual clauses), the Customer must notify the Provider in writing within fifteen (15) days of receiving the notice of change. Because the Platform operates on a homogeneous Shared Infrastructure, the Provider cannot accommodate individualized infrastructure requests for standard tenants. Therefore, if the Customer legally objects to the new Sub-processor, the Customer's sole and exclusive remedy is to terminate the Agreement and cancel their subscription prior to the expiration of the 30-day notice period. Continued use of the Platform following the expiration of the notice period shall constitute unconditional acceptance of the new Sub-processor.

4.5. Flow-Down of Obligations and Liability

The Provider shall ensure that any Sub-processor engaged to process Personal Data on behalf of the Customer is bound by a written contract that imposes the same rigorous data protection obligations as those set out in this DPA, particularly regarding the implementation of sufficient technical and organizational measures (TOMs). In accordance with Article 28(4) of the GDPR, if a Sub-processor fails to fulfill its data protection obligations, the Provider shall remain fully liable to the Customer for the performance of that Sub-processor's obligations, subject strictly to the limitation of liability caps defined in Chapter 10 of the master Terms of Service.

5. PERSONAL DATA BREACH NOTIFICATION

5.1. Notification "Without Undue Delay" (The 48-Hour Commitment)

In accordance with Article 33(2) of the GDPR, if the Provider becomes aware of a probable or confirmed Personal Data Breach (defined as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to the Personal Data stored within the Customer's tenant_db), the Provider shall notify the Customer without undue delay. Specifically, the Provider commits to issuing an initial notification or qualified pre-alert to the Customer's designated administrative email address within forty-eight (48) hours of becoming aware of the probable breach, without waiting for exhaustive technical confirmation, to ensure the Customer has sufficient time to fulfill their own regulatory obligations.

5.2. Content of the Breach Notification

The Provider acknowledges that the Customer requires specific technical information to fulfill their own regulatory filings. The Provider’s initial notification (and subsequent updates) shall include, to the extent such information is available at the time:

Nature of the Breach: A description of the incident, including the technical vector of the attack (if known) and whether it involved the overarching Kubernetes Shared Infrastructure or an isolated vulnerability in the Customer's storefront.
Scope: The categories and approximate number of Data Subjects (End-Consumers) concerned, and the categories and approximate number of Personal Data records concerned.
Consequences: The likely consequences of the Personal Data Breach (e.g., unauthorized exposure of emails vs. exposure of hashed passwords).
Mitigation Measures: A detailed summary of the corrective measures taken or proposed to be taken by the Provider to address the breach and mitigate its possible adverse effects (e.g., rotating Vault secrets, isolating the affected container, deploying emergency patches).

If it is not possible to provide all the information at the same time, particularly during the initial 48-hour alert phase, the Provider shall provide the information in phases without undue further delay.

5.3. Cooperation and Regulatory Assistance (CNIL Reporting)

The Provider recognizes that the Customer, acting as the Data Controller, faces a strict statutory deadline (typically 72 hours from the moment of awareness) to report severe data breaches to the competent supervisory authority (e.g., the French CNIL). The Provider shall provide reasonable and prompt cooperation to the Customer to facilitate this reporting process. Upon request, the Provider shall supply relevant extracts from its immutable audit logs, incident post-mortem reports, and technical context regarding the OVHcloud/Kubernetes architecture required for the Customer to accurately complete their CNIL declaration.

5.4. Sole Responsibility of the Data Controller

The Parties explicitly agree that the Provider’s obligation is strictly limited to identifying the breach, containing the technical threat, and notifying the Customer. The Customer bears the sole and exclusive legal responsibility for:

Evaluating the severity of the breach and determining whether it meets the threshold for mandatory reporting to the CNIL or other relevant European supervisory authorities.
Executing all official filings and communications with said regulatory bodies.
Communicating the breach directly to the affected End-Consumers, as mandated by Article 34 of the GDPR, utilizing the Customer's own communication channels. The Provider shall never directly contact an End-Consumer regarding a data breach.

Here are the rewritten Chapters 6 and 7.

I have fundamentally repaired the legal vulnerabilities.

In Chapter 6, the outright ban on technical audits is gone. You now legally comply with Article 28 by allowing technical audits, but you protect your cluster by putting them behind a strict "defense in depth" (requiring paper audits first, restricting scope to their specific namespace, and charging for your engineers' time). I also added the "Global Incident" clause to save you from a stampede of 500 simultaneous auditors during a zero-day crisis.

In Chapter 7, I added the "Legal Hold" (Mise sous séquestre) mechanism. This prevents your automated deletion script from illegally destroying evidence if a merchant is sued by a consumer or investigated by the DGCCRF, saving you from obstruction of justice claims.

*Disclaimer: This draft is provided for educational and structural purposes by an AI trained in SaaS law. Please have a qualified attorney review this before deployment.*

6. AUDITS AND INSPECTIONS

6.1. Demonstration of Compliance (Article 28 GDPR)

In accordance with Article 28(3)(h) of the GDPR, the Provider shall make available to the Customer all information reasonably necessary to demonstrate compliance with the obligations laid down in this DPA and the applicable data protection laws, and shall allow for and contribute to audits, including inspections, conducted by the Customer or another auditor mandated by the Customer.

6.2. Primary Audit Mechanism (Paper Audits)

The Parties explicitly acknowledge that the Customer's Data Plane operates within a highly secure, multi-tenant Shared Infrastructure orchestrated via Kubernetes. To fulfill the Customer's audit rights while preserving the strict logical isolation of all other tenants, audits shall primarily be conducted as "Paper Audits":

Security Certifications: Upon written request, the Provider shall supply summaries of its latest available security certifications, third-party penetration test executive summaries, or industry-standard compliance reports.
Written Questionnaires: The Customer may submit a comprehensive written security questionnaire no more than once per calendar year, which the Provider's engineering personnel shall answer accurately.

6.3. Technical and On-Site Audits (Strictly Scoped)

If the primary "Paper Audit" is reasonably deemed insufficient by the Customer to verify compliance, or if mandated by a supervisory authority, the Customer may request a technical audit or inspection, subject to the following strict conditions designed to protect the Shared Infrastructure:

Scope Limitation: Under no circumstances shall the Customer or their auditor be granted physical access to the OVHcloud data centers, nor unmanaged root-level access to the overarching Kubernetes cluster. The technical audit must be logically restricted exclusively to the Customer's isolated Data Plane namespace and their specific tenant_db.
Supervision and NDA: The audit must be executed under a strict Non-Disclosure Agreement (NDA) and must be actively supervised by the Provider's engineering staff to ensure the security boundaries of other tenants are not breached.
Notice and Costs: The Customer must provide at least thirty (30) days' written notice. The Customer shall bear all costs of their mandated auditor. Furthermore, the Customer agrees to compensate the Provider for the engineering and compliance time required to safely supervise and facilitate this technical audit, billed at the Provider's standard hourly professional services rate.

6.4. Global Security Incidents and Third-Party Substitution

In the event of a severe, platform-wide security incident (e.g., a "zero-day" vulnerability in the orchestrator) affecting multiple tenants simultaneously, the Provider cannot safely or operationally accommodate simultaneous individual audits from hundreds of affected Data Controllers. In such an event, the Provider shall mandate an independent, certified third-party auditor to conduct a comprehensive forensic investigation. The Provider will share this certified independent report with the Customer, and the Parties agree this report shall satisfy the Customer's audit rights regarding that specific incident.

7. DATA DELETION AND RETURN

7.1. Principle of Data Minimization and Storage Limitation

In accordance with the GDPR principle of data minimization, the Provider shall not retain the Customer's Personal Data longer than is strictly necessary to fulfill the purposes of the Agreement. Upon the termination or expiration of the master Terms of Service for any reason, the Provider shall proceed with the decommissioning and deletion of the Customer's isolated Data Plane environment as set forth in this Chapter.

7.2. The 30-Day Export Window

Upon the effective date of termination, the Customer’s active access to the Control Plane and Data Plane shall cease. However, as established in Section 11.5 of the master Terms of Service, the Provider shall maintain the Customer’s tenant_db in a dormant, non-public state for a period of thirty (30) calendar days (the "Retrieval Period"). During this window, the Customer may request a direct data dump to export their End-Consumer Data. The Customer is solely responsible for executing this export or coordinating the retrieval with the Provider's technical support team.

7.3. The Automated Purge (Irrevocable Deletion)

Subject to the provisions of Section 7.4 (Legal Hold), immediately following the expiration of the 30-day Retrieval Period, the Provider’s automated orchestration systems shall execute a complete and irrevocable deletion of the Customer's Personal Data. This "Purge" includes:

Logical Database: The permanent destruction of the specific tenant_db and its associated Kubernetes persistent volume claims (PVCs).
Object Storage: The deletion of all associated media and files within the isolated object storage buckets (e.g., MinIO).
Secrets: The revocation and deletion of all tenant-specific cryptographic keys stored within the secret management vault.

The Customer explicitly acknowledges that once this automated purge is executed, the data is technically unrecoverable.

7.4. Exception: Legal Hold / "Mise sous séquestre"

The Parties acknowledge that the Customer may require the preservation of their tenant_db beyond the Retrieval Period as evidence for active litigation, a regulatory investigation (e.g., CNIL, DGCCRF), or an ongoing commercial dispute. To prevent the destruction of evidence, the Customer may submit a formal, written "Legal Hold" request to the Provider prior to the expiration of the 30-day Retrieval Period. Upon receipt, the Provider shall suspend the automated purge and maintain the tenant_db in a frozen, dormant state. The Customer agrees to pay a standard monthly maintenance fee, as defined in the Provider's pricing schedule, for the duration of this extended preservation. The data will be purged once the Customer formally releases the Legal Hold.

7.5. Deletion of Residual Backups

The Customer is informed that residual copies of the tenant_db may persist within the Provider’s encrypted, off-site disaster recovery backups for an additional period of up to sixty (60) days following the Purge. These backups are maintained for the sole purpose of ensuring platform-wide resilience and are technically isolated from standard production operations. The Provider guarantees that these residual copies shall be automatically overwritten at the end of the backup retention cycle, and shall not be processed for any other purpose.

7.6. Certification of Deletion

Upon written request by the Customer following the expiration of the Retrieval Period and the execution of the Purge, the Provider shall provide a written statement certifying that it has complied with its data deletion obligations under this Chapter and Article 28(3)(g) of the GDPR.