Data Processing Addendum

1. Roles and scope

In this DPA, “Customer” is the party that agreed to the Terms of Service, and “dply” is Shafer LLC. “Customer Personal Data” is personal data in the content Customer or its users put into dply: code, files, databases, storage, environment variables, and the logs of Customer’s apps. Terms such as “controller”, “processor”, “personal data”, “processing” and “data subject” have the meanings given in the EU General Data Protection Regulation (GDPR).

• Customer is the controller (or a processor acting for its own controller) of Customer Personal Data. dply is its processor (or sub-processor).
• dply is an independent controller for account, billing and usage data about Customer and its users. The Privacy Policy covers that data, not this DPA.
• This DPA meets the requirements of Article 28 of the GDPR and of the UK GDPR.

2. Details of the processing

• Subject matter: hosting and running Customer’s sites, apps and managed resources.
• Duration: the term of the Terms of Service, plus the period until deletion under section 7.
• Nature: storing, hosting, transmitting, building, serving, backing up, logging, counting page views and deleting data.
• Purpose: providing, securing and supporting dply for Customer under the Terms of Service.
• Categories of data and data subjects: determined by Customer. dply does not choose what Customer stores. Typically they include Customer’s end users, visitors and staff, and their contact details, account data, content and technical data such as IP addresses and user agents in request logs. Page-view counts hold no IP addresses: each records the page path, referring host, country and a daily visitor code (a one-way keyed hash of IP address, user agent and date, a different key per site), kept for three months.
• Special categories: Customer should not process special category data or data regulated by HIPAA on dply unless it has decided dply’s measures (Annex II) are appropriate. dply has no security certifications and does not sign HIPAA business associate agreements.

3. Processor obligations

• Instructions. dply processes Customer Personal Data only on Customer’s documented instructions. The Terms of Service, this DPA and Customer’s configuration and use of dply are those instructions. If the law requires other processing, dply will tell Customer first unless the law forbids it. dply will tell Customer if it believes an instruction breaks data protection law.
• Confidentiality. Everyone dply authorizes to process Customer Personal Data is bound by confidentiality.
• Staff access. dply staff look at Customer Personal Data, such as a database’s contents or an app’s secrets, only to give support Customer asks for or to keep the service running and secure. Each look needs a stated reason, lasts at most 30 minutes, is recorded with every query or command run, and appears in Customer’s organization activity.
• Security. dply implements the technical and organizational measures in Annex II, as required by Article 32 of the GDPR. dply may update them, but will not reduce the overall level of protection.
• Customer’s part. Customer is responsible for the lawfulness of its instructions and of the data it provides, for the notices and consents its data subjects need, and for the settings under its control, such as what it makes public, the credentials and share links it creates, and access within its organization.

4. Sub-processors

• General authorization. Customer authorizes dply to use sub-processors. The current list is in Annex III and on the Security & compliance page.
• Contracts. dply binds each sub-processor to data protection terms that protect Customer Personal Data at least as much as this DPA, and remains responsible for their performance.
• Notice of changes. dply emails Customer’s organization owners at least 30 days before a new sub-processor starts processing Customer Personal Data.
• Objection. Customer may object on reasonable data protection grounds by emailing hello@dply.io within that period. We will discuss it in good faith. If we cannot resolve the objection, Customer may terminate the affected service, and dply will refund any prepaid fees for it covering the period after termination.

5. Assistance

• Data subject requests. Customer can access, correct, export and delete its data through dply. Where Customer cannot do that itself, dply will provide reasonable help. If dply receives a request from one of Customer’s data subjects, it will pass it to Customer and not answer it without Customer’s instruction, unless the law requires.
• DPIAs and consultation. dply will give reasonable information to help Customer with data protection impact assessments and consultations with supervisory authorities about its processing on dply.

6. Personal data breaches

dply will notify Customer’s organization owners by email without undue delay, and within 48 hours of becoming aware of a personal data breach affecting Customer Personal Data. The notice will describe what happened, the data and data subjects affected as far as known, the likely consequences, and what dply is doing about it, and will be updated as more is learned. dply will take reasonable steps to contain the breach and help Customer meet its own notification duties. A notice is not an admission of fault.

7. Deletion and return

• Customer can export its data at any time while its organization is active or paused, and can delete it itself.
• Data Customer deletes is removed from the live service. Database backups roll off with the plan’s backup window (at most 30 days), and request logs are kept for 7 days.
• If an organization is paused for non-payment, its data is deleted 30 days after the pause, after emailed warnings 7 days and 1 day before, as described in the Terms of Service.
• dply may keep data where the law requires it, and will keep protecting it under this DPA while it does.

8. Audits

dply will make available the information reasonably needed to show it meets this DPA, by answering Customer’s written questions and security questionnaires. dply has no third-party audit reports, such as SOC 2 or ISO 27001, today. If that information is not enough, or a supervisory authority requires it, Customer may audit dply once a year, with at least 30 days’ notice, during business hours, at its own cost, under confidentiality, and in a way that does not put other customers’ data or the service at risk.

9. International transfers

dply is in the United States. Where Customer Personal Data is transferred from the EEA, the UK or Switzerland to a country without an adequacy decision, the following are incorporated into this DPA by reference:

• EEA: the Standard Contractual Clauses adopted by Commission Implementing Decision (EU) 2021/914 (“SCCs”), Module 2 (controller to processor), and Module 3 (processor to processor) where Customer is a processor. For them: clause 7 (docking) applies; under clause 9, option 2 (general authorization) applies with the notice period in section 4; the option in clause 11 does not apply; under clauses 17 and 18, the law and courts of Ireland apply; Annexes I, II and III of this DPA complete the SCC annexes; and the supervisory authority is the one competent for Customer.
• UK: the International Data Transfer Addendum to the SCCs issued by the UK Information Commissioner (version B1.0), completed with the information in this DPA. Either party may end it as allowed by its section 19.
• Switzerland: the SCCs apply with these changes: the Swiss Federal Data Protection and Information Commissioner is the competent authority for transfers under the Swiss FADP; references to the GDPR include the FADP; and “Member State” includes Switzerland so Swiss data subjects can enforce their rights there.

If the SCCs conflict with this DPA, the SCCs win.

10. US state privacy laws (CCPA)

Where the California Consumer Privacy Act, as amended by the CPRA, or a similar US state law applies, dply is Customer’s service provider (or processor), and dply will not:

• sell or share Customer Personal Data, including for cross-context behavioral advertising;
• retain, use or disclose it for any purpose other than providing dply to Customer (the business purpose), or outside the direct business relationship with Customer;
• combine it with personal data dply receives from others or collects itself, except as the law permits.

dply will comply with those laws, give the same level of protection they require, and tell Customer if it can no longer meet them. Customer may take reasonable steps to stop and fix unauthorized use.

11. Precedence and liability

For the processing of Customer Personal Data, this DPA takes precedence over the Terms of Service if they conflict. Each party’s liability under this DPA is subject to the limits in the Terms of Service, except where the law or the SCCs do not allow it. This DPA ends when dply stops processing Customer Personal Data.

Annex I: Parties and description

A. Parties

• Data exporter: Customer, as identified in its dply account. Contact: the organization’s owners. Role: controller (or processor). Activities: using dply to host its sites, apps and data. Signature and date: by accepting the Terms of Service.
• Data importer: Shafer LLC, Arizona, USA. Contact: hello@dply.io. Role: processor (or sub-processor). Activities: providing dply. Signature and date: by making dply available under the Terms of Service.

B. Description of transfer

• Data subjects, categories of data, and sensitive data: as in section 2, determined by Customer.
• Frequency: continuous, while Customer uses dply.
• Nature and purpose: as in section 2.
• Retention: as in section 7.
• Transfers to sub-processors: as in Annex III, for the same purposes and duration.

C. Competent supervisory authority

The supervisory authority competent for the data exporter under clause 13 of the SCCs.

Annex II: Technical and organizational measures

• Encryption in transit: every site is served over HTTPS; custom-domain certificates are issued by Cloudflare; dply databases and Valkey accept TLS connections only.
• Encryption at rest: Cloudflare encrypts R2, KV and D1 data at rest; dply databases and Valkey run on DigitalOcean volumes encrypted at rest. Environment variables, organization secrets, Git provider tokens, Cloudflare credentials, notification settings and resource connection strings are encrypted in dply’s database with AES-256. Passwords are hashed.
• Tenant isolation: resources belong to the organization that created them, and bindings resolve only inside that organization. A hostname can belong to only one app. SSR apps run as their own Cloudflare Worker scripts in Cloudflare’s isolate sandbox; container apps run in their own containers.
• Build sandboxing: each build runs in its own container as a non-root user, with all Linux capabilities dropped, privilege escalation blocked, memory, CPU and process limits, and a network where builds can’t reach each other. Package caches are per organization. Container images are built in an isolated builder with no deploy credentials present.
• Outbound request protection: when dply calls a customer-supplied URL, it refuses private, loopback, link-local and cloud-metadata addresses.
• Access control: Owner, Admin, Member, Deployer and Viewer roles, plus per-app roles; passkeys and authenticator-app two-factor authentication; API tokens limited to granted abilities and their owner’s role, revoked when the owner leaves.
• Logging and accountability: an organization activity log records who changed what, kept for 365 days; request logs are kept for 7 days.
• Availability and recovery: dply Postgres, MySQL and MongoDB stream changes to storage and take a full backup daily, kept for 7, 14 or 30 days by plan, with point-in-time restore. The platform’s own keys and database backups are escrowed daily off-site with age public-key encryption, and a daily drill checks that the newest backup decrypts.
• Incident response and disclosure: affected organization owners are notified of incidents (section 6). Vulnerabilities can be reported to security@dply.io.
• Data regions: object storage buckets can be created in Cloudflare’s EU jurisdiction and container apps can be restricted to EU regions. dply databases and Valkey are in New York, USA.

Annex III: Sub-processors