Data Processing Agreement

Last updated: July 31, 2026

This Data Processing Agreement ("DPA") applies where DeployYourApp processes personal data on behalf of a customer in the course of providing the Service, and forms part of the Terms of Service. It is our standard DPA offering for business customers and is designed to satisfy Article 28(3) of Regulation (EU) 2016/679 (the "GDPR") and the equivalent provisions of the UK GDPR.

How to put it in place. This DPA takes effect automatically when you use the Service in a way that causes us to process personal data on your behalf — in practice, when you ship an app containing our Capacitor plugin or Electron updater. No signature is required. If your procurement process needs a countersigned copy, or if you need to add the Standard Contractual Clauses as a signed annex, email info@deployyour.app and we will provide one.

In this DPA, "Customer" means the account holder, acting as controller. "We", "us", and "DeployYourApp" means the processor identified as [Legal entity name and registered address — TO BE COMPLETED]. Terms such as "personal data", "processing", "controller", "processor", "sub-processor", "data subject", and "personal data breach" have the meanings given in the GDPR.

1. Scope and Roles

• We are the processor in respect of personal data relating to Customer's end users that our SDKs transmit to the Service — the device records and analytics events described in Annex A. Customer is the controller of that data.
• We are the controller in respect of Customer's own account and organization data (names, email addresses, billing data, audit logs of dashboard and API activity, IP addresses used for security and rate limiting). That processing is governed by our Privacy Policy, not by this DPA.
• Where Customer chooses to place personal data inside a bundle payload, or inside the arbitrary eventData field of an analytics event, we process it as processor on the same terms. We have no visibility into and no control over what Customer's app puts in those fields.

2. Subject Matter, Duration, Nature and Purpose (Art. 28(3))

3. Customer's Instructions

• We process personal data only on Customer's documented instructions, including with regard to international transfers, unless required to do otherwise by Union or Member State law to which we are subject. Where such a legal requirement applies, we will inform Customer before processing, unless that law prohibits the notice on important grounds of public interest.
• Customer's instructions consist of: this DPA, the Terms of Service, the configuration Customer sets in the dashboard, the API and SDK calls Customer's software makes, and any further written instruction the parties agree.
• We will inform Customer if, in our opinion, an instruction infringes the GDPR or other data protection law. We may suspend performance of that instruction pending resolution.
• We do not use Customer's end-user data for our own purposes. We do not sell it, do not use it to train models, do not use it for advertising or profiling, and do not combine it with data from other customers to build products.
• Customer warrants that it has a valid legal basis for the processing, that it has provided the required transparency information to its end users, including disclosure of our SDK's data collection, and that it has obtained any consent required by applicable law, including national implementations of Article 5(3) of the ePrivacy Directive for storage on end-user devices.

4. Confidentiality

We ensure that persons authorised to process personal data on Customer's behalf are bound by a duty of confidentiality, contractual or statutory, that survives the end of their engagement. Access to production systems containing customer data is limited to personnel who need it to operate, support, or secure the Service, and access is granted on a least-privilege basis.

5. Security Measures (Art. 32)

We implement the following technical and organisational measures. This is a description of what is in place today, not an aspiration:

• Encryption of all data in transit using TLS.
• AES-256-GCM encryption at the field level for sensitive stored values, including two-factor authentication secrets and backup codes.
• Passwords stored only as salted cryptographic hashes; API keys stored only as SHA-256 hashes, never recoverable in plaintext.
• Role-based access control enforced on every authenticated API route, with organization-scoped isolation of all customer data.
• Rate limiting on public endpoints, including the unauthenticated update-check and analytics endpoints.
• Audit logging of privileged actions, retained for the life of the organization.
• Integrity protection for update bundles: a SHA-256 checksum and mandatory RSA-4096 signature verification performed on the end user's device before a bundle is opened, followed by a per-file SHA-256 manifest check during extraction. Customer's signing private key is generated on Customer's own systems and is never transmitted to us.
• Update bundles may contain web assets only. The updater enforces a fixed file-extension allowlist and rejects any file whose leading bytes identify a native executable, so a bundle cannot install native executable code on an end user's device.
• Optional two-factor authentication (TOTP) for Customer's dashboard accounts.
• Documented incident response process, including breach notification duties, published at docs/security/incident-response.md.

What we do not have. We hold no SOC 2, ISO 27001, PCI DSS, or HIPAA certification or third-party attestation, and we do not undertake to obtain one. We do not offer a customer-selectable data residency region, a customer-managed encryption key (BYOK) option, or an availability service level agreement outside a separately negotiated Enterprise contract. Customers whose compliance programme requires any of these should contact info@deployyour.app before relying on the Service for regulated workloads.

6. Sub-processors

• Customer gives general written authorisation for us to engage sub-processors. The current list is published at deployyour.app/subprocessors.
• We will give at least 30 days' notice before adding or replacing a sub-processor, by updating that page and emailing the notification address on the account. Customers can subscribe to change notifications by emailing info@deployyour.app.
• Customer may object to a new sub-processor on reasonable data protection grounds within that 30-day period. We will work in good faith to offer a reasonable alternative. If we cannot, Customer may terminate the affected part of the Service without penalty and receive a pro-rated refund of prepaid fees for the unused remainder of the term.
• We impose on each sub-processor, by written contract, data protection obligations no less protective than those in this DPA, and we remain fully liable to Customer for a sub-processor's performance of its obligations.

7. Assistance With Data Subject Rights (Art. 28(3)(e))

• Customer can satisfy access and portability requests without our involvement: device records and their update history are listed in the dashboard and exportable to CSV through the dashboard and API.
• Erasure requires our involvement today. The Service does not currently expose an endpoint to delete an individual device record or its analytics events, and deleting an app is a soft delete that hides the app without erasing its device or analytics rows. The only automated erasure path is deleting the organization, which purges everything approximately 6 months later. Until per-device deletion ships, send erasure requests to info@deployyour.app with the device identifier and we will delete the records manually. We aim to complete them within 5 business days.
• Where Customer cannot fulfil a request through those tools, we will provide reasonable assistance by appropriate technical and organisational measures, taking into account the nature of the processing. Requests go to info@deployyour.app and we aim to respond within 5 business days so Customer can meet its own one-month deadline.
• If a data subject contacts us directly about data we process on Customer's behalf, we will not respond to the substance of the request. We will tell the individual to contact Customer, and we will forward the request to Customer promptly.
• A practical limit Customer should understand: the device identifier our SDK generates is a random UUID with no link to a named person on our side. We cannot connect it to a real-world identity, so we cannot locate a specific individual's records on request. Customer must supply the device identifier for us to act on a request.

8. Assistance With Articles 32 to 36

• Breach notification. We will notify Customer without undue delay after becoming aware of a personal data breach affecting personal data processed on Customer's behalf, and in any event within 48 hours of confirming the breach, so that Customer can meet its own 72-hour deadline to its supervisory authority under Article 33. Our notice will describe the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point. Where we cannot provide all of this at once, we will provide it in phases without further undue delay. We will not delay notification because an investigation is incomplete.
• Security and impact assessments. We will provide reasonable assistance with Customer's obligations under Articles 32 to 36, including data protection impact assessments and prior consultation with supervisory authorities, taking into account the information available to us. Our published documentation on SDK data collection, security, and incident response is intended to cover the common DPIA questions.

9. Deletion and Return of Data (Art. 28(3)(g))

• Deleting a bundle removes the stored object from our object storage at the moment of deletion, along with its database record.
• Deleting an app does not erase its end-user data. App deletion is a soft delete: the app stops serving updates and disappears from the dashboard, but its device records and analytics events remain in the database until the whole organization is deleted and purged. Customers who need those records erased sooner must delete the organization or request manual deletion at info@deployyour.app.
• Customer may export its data at any time through the dashboard's CSV export and the API, in a structured, machine-readable format. Customer should complete any export before deletion, because deletion is not reversible once the purge job has run.
• On termination, an organization is marked deleted immediately and removed from the Service, and an automated job permanently purges it — including all bundle objects and all associated device and analytics records — approximately 6 months (183 days) later. This window exists so that app identifiers stay reserved and our anti-abuse rules keep working. Customer may request an earlier purge by emailing info@deployyour.app.
• Be aware of what this means. The standard Article 28(3)(g) formulation is deletion "at the choice of the controller" at the end of the provision of services. Our default is a 6-month delay, not immediate deletion. Customers who need immediate deletion at termination must request it, and we will honour that request.
• After purge, copies may persist in encrypted infrastructure backups until those backups expire on their normal rotation. Backup copies are not restored into production except as part of a disaster recovery event, and remain subject to this DPA until overwritten. The backup retention period is [backup retention period — TO BE COMPLETED once the hosting provider's backup configuration is fixed].

10. Audits (Art. 28(3)(h))

• We will make available to Customer all information necessary to demonstrate compliance with Article 28 and allow for and contribute to audits, including inspections, conducted by Customer or an auditor Customer mandates.
• In the first instance we will respond to a reasonable written security questionnaire and provide our published security and incident response documentation. We do not hold a third-party audit report, so we cannot satisfy an audit request by producing one.
• Where that is not sufficient for Customer's regulatory obligations, Customer may conduct an on-site or remote audit no more than once every 12 months, on at least 30 days' written notice, during business hours, subject to confidentiality undertakings, and conducted so as not to disrupt the Service or compromise the data of other customers. Customer bears its own audit costs and reimburses our reasonable costs for audits beyond the annual one, except where the audit reveals a material breach by us.
• An additional audit may be conducted without waiting 12 months following a personal data breach affecting Customer's data, or where a supervisory authority requires it.

11. International Transfers

• Our infrastructure is hosted in [hosting region — TO BE COMPLETED]. The sub-processors listed at /subprocessors process data in the regions stated on that page.
• Where processing under this DPA involves a transfer of personal data out of the EEA, the UK, or Switzerland to a country without an adequacy decision, the parties agree that the Standard Contractual Clauses in Commission Implementing Decision (EU) 2021/914 are incorporated into this DPA by reference and apply to that transfer.
• Where Customer is a controller and we are its processor, Module Two (controller-to-processor) applies. Where Customer is itself a processor acting for a third-party controller, Module Three (processor-to-processor) applies.
• For the purposes of the Clauses: Customer is the data exporter and we are the data importer; the optional docking clause in Clause 7 applies; the general authorisation option in Clause 9(a) applies with the 30-day notice period in Section 6; the governing law under Clause 17 and the forum under Clause 18(b) are those of [EU Member State for SCC governing law and forum — TO BE COMPLETED]; Annexes I and II of the Clauses are populated by Annex A of this DPA and Section 5 respectively, and Annex III by our sub-processor page.
• For UK transfers, the UK International Data Transfer Addendum (version B1.0) to the Standard Contractual Clauses applies, with Tables 1 to 4 populated from this DPA and neither party permitted to end the Addendum under Section 19 other than as permitted by that Addendum. For Swiss transfers, the Clauses apply with references to the GDPR read as references to the Swiss FADP and with the Swiss Federal Data Protection and Information Commissioner as the competent authority.
• If a transfer mechanism relied on here is invalidated, the parties will in good faith adopt an alternative lawful mechanism without undue delay.

12. Liability and Precedence

The limitations and exclusions of liability in the Terms of Service apply to claims under this DPA, except that nothing limits either party's liability to a data subject under Article 82 GDPR or to a supervisory authority. In the event of a conflict between this DPA and the Terms of Service on the subject of data protection, this DPA prevails. In the event of a conflict between this DPA and the Standard Contractual Clauses, the Clauses prevail.

Annex A — Details of Processing

A.1 Data received at the update endpoint and stored

Sent by our Capacitor plugin and Electron updater to POST /api/update:

Transmitted but discarded. Our Android SDK also sends the operating system version and the device manufacturer and model. The endpoint validates against a strict schema that excludes those fields, so they are dropped and never written to storage.

A.2 Analytics events

Sent to POST /api/stats and stored per device:

• Event type — a string such as page_view, error, or an update lifecycle event.
• Event data — an arbitrary JSON object whose contents are determined entirely by Customer's application. This is the field most likely to contain personal data, and Customer alone controls what goes into it.
• Bundle version and timestamp.
• Update lifecycle events additionally store bundle and deployment identifiers, failure reason, download duration and byte count, and any error message.

Analytics is enabled by default (analyticsEnabled defaults to true). Customer can disable it by setting analyticsEnabled: false in the SDK configuration. Customer is responsible for deciding whether to enable it and for the lawfulness of doing so.

A.3 Retention

Device records and analytics events are retained for the life of the organization. We do not currently run an automatic expiry job for them, and deleting an app does not delete them. They are erased when the organization is deleted and its 6-month purge runs, or on manual request to info@deployyour.app. Customers who need a fixed shorter retention period should contact us to arrange it.

Contact

• DPA and contract questions: info@deployyour.app
• Data protection and data subject requests: info@deployyour.app
• Security incidents: info@deployyour.app