Data Processing Agreement

ArcRaz LLC, trading as Zyphr ("Processor") Version: 1.5 — 11 September 2026

1. Scope and roles

Controller — the customer. Determines the purposes and means of processing. Processor — Zyphr. Processes personal data only on the Controller's behalf.

This DPA applies to Zyphr's processing of personal data that the Controller submits to the Service: message recipients, end users of the Controller's authentication, and the content and metadata of communications sent through the platform.

It does not apply to the Controller's own account data (name, email, billing details), for which Zyphr acts as an independent controller under its Privacy Policy.

Where this DPA conflicts with the main agreement, this DPA prevails for matters of personal data protection.

2. Article 28(3)(a) — Documented instructions

Zyphr processes personal data only on the Controller's documented instructions, including for transfers to a third country. The Controller's instructions are: (a) this DPA, (b) the main agreement, and (c) the Controller's configuration and use of the Service through its API and dashboard.

Zyphr will inform the Controller if, in its opinion, an instruction infringes the GDPR or other applicable data protection law. Zyphr may suspend the affected processing until the instruction is withdrawn or amended.

Zyphr will not process personal data for its own purposes, and specifically will not use Controller data to train machine-learning models.

Verified: AI features route to Amazon Bedrock within our own AWS account, and content is not used to train models. See the Art. 30 record §3.3.

3. Article 28(3)(b) — Confidentiality

Zyphr ensures that persons authorised to process personal data are bound by an obligation of confidentiality, under employment terms or contract.

Access to production personal data is limited to named administrative accounts in a separate authentication realm from the customer dashboard, so a customer account cannot be escalated into an administrative one. The number of such accounts is kept to the minimum the business requires, and each belongs to a named individual — there are no shared administrative logins, because the audit trail records which administrator acted and that is meaningless if several people share one account.

Support access that views the Service as a specific end user is recorded with the acting administrator, the subject, the stated reason, the originating IP and an explicit expiry.

Multi-factor authentication (TOTP) is enforced on every active administrative account. Enforcement is complete in all environments, not merely available.

No default or seeded administrative account can authenticate in any environment that has a real administrator, so there is no unprotected path into the administrative portal.

4. Article 28(3)(c) — Security of processing

Zyphr implements the technical and organisational measures set out in §5, appropriate to the risk, in accordance with Article 32.

5. Security measures (Annex II)

Stated in terms of what is actually implemented, because a DPA that describes security purely in generalities is worthless to a reviewer.

These are the measures Zyphr commits to maintaining. They are described at the level of the control rather than the current configuration value: specific parameters — key lengths, work factors, header names — are reviewed periodically and strengthened as practice moves, and a clause that pinned a number would either become false the day it was improved or discourage the improvement. Current parameters are available to a Controller under NDA on request.

5.1 Encryption

In transit: TLS on all external endpoints
At rest: AWS-managed encryption on database and object storage
Application-level: authenticated encryption using AES-256 or equivalent for credential material, including MFA secrets, OAuth tokens, third-party integration tokens and webhook signing secrets

5.2 Credentials

Passwords hashed with an industry-standard adaptive hashing function using a per-password salt and a work factor reviewed periodically
Verification, reset and session tokens stored only as cryptographic hashes, never in plaintext
Breach checking by k-anonymity — only a short hash prefix leaves our infrastructure, never a password or a full hash

5.3 Access control

Role-based access; tenant scoping enforced at the query layer
Administrative access in a separate authentication realm from the customer dashboard, so a customer account cannot be escalated into an administrative one
Multi-factor authentication enforced on all active administrative accounts
Secrets held in a managed secrets service and delivered to workloads by an operator, never committed to source

5.4 Data minimisation

IP geolocation resolved from a local database — no IP address is sent to any third party
Precise latitude/longitude and postal codes are not stored
End-user identifiers are masked before any internal alert leaves the platform: email addresses are partially redacted and IP addresses truncated to a network prefix

5.5 Outbound request protection

Customer-supplied webhook URLs are validated after DNS resolution against denied address ranges including the cloud metadata endpoint; HTTPS is required and redirects are re-validated at every hop.

5.6 Resilience and testing

Automated retention enforcement across message, log and audit data
Continuous integration with an automated test suite gating deployment

6. Article 28(3)(d) — Subprocessors

The Controller grants general authorisation for Zyphr to engage subprocessors. The current list is published at zyphr.dev/subprocessors and forms part of this DPA.

Zyphr will give at least 30 days' advance notice before adding a new subprocessor or materially changing what an existing one processes. Notice is given by email to the account owner and by a notice in the dashboard.

The Controller may object on reasonable data protection grounds within the notice period. Zyphr will work with the Controller to find an alternative; if none is available, the Controller may terminate the affected part of the Service and receive a pro-rata refund of prepaid fees for the remainder of the term.

Zyphr imposes on each subprocessor data protection obligations no less protective than those in this DPA, and remains fully liable to the Controller for a subprocessor's performance.

Verified: the notice mechanism is built and in production. The 30-day minimum is enforced by a database CHECK constraint rather than by caller-side validation, so the one interval this whole commitment reduces to cannot be bypassed by a code path that forgets to check it.

Notices are sent as an operational communication, a category deliberately excluded from the opt-outable set — a marketing unsubscribe cannot suppress a compliance notice. Hard-bounce suppression still applies, and a suppressed notice is recorded as such so the failure to reach a customer is itself evidence rather than silence.

A Controller may nominate a compliance contact — typically a legal or compliance inbox — to receive these notices in addition to the account owner, never instead of them, so a stale address cannot silently swallow a notice.

7. Article 28(3)(e) — Assistance with data subject rights

Zyphr provides, as part of the Service:

Access and portability (Arts. 15, 20): an API returning a machine-readable JSON bundle of all data held about an identified end user — profile, sessions, OAuth connections, MFA and WebAuthn enrolment status, claims, organisation memberships, message history, consent records and suppression status. Credential material is deliberately excluded and the exclusions are named in the bundle. Also available from the dashboard.
Erasure (Art. 17): an erasure path that clears every identifying field on the end-user record, hard-deletes all credential and session artifacts, and anonymises the recipient on message logs while retaining counts and timestamps.
Rectification (Art. 16): end-user records are editable through the API and dashboard.

Where a data subject contacts Zyphr directly, Zyphr will not respond substantively and will refer them to the Controller, save to acknowledge receipt and inform the Controller without undue delay.

Suppression records survive erasure by design. An unsubscribe must keep working after the subject is erased, or we would resume mailing someone who asked us to stop. This is an Art. 17(3)(b) carve-out and a legal obligation in its own right.

8. Article 28(3)(f) — Breach assistance

Zyphr notifies the Controller of a personal data breach affecting the Controller's data within 24 hours of awareness, and in no case later than 48 hours.

"Awareness" means the point at which Zyphr has a reasonable degree of certainty that a security incident has led to personal data being compromised.

The notification will describe, to the extent known: the nature of the breach; the categories and approximate number of data subjects and records affected; the likely consequences; and the measures taken or proposed. Where information is not available within the window, Zyphr will notify in phases rather than delay.

Zyphr maintains a documented breach process with named owners (docs/compliance/breach-notification-runbook.md).

9. Article 28(3)(g) — Deletion and return

On termination, at the Controller's election, Zyphr will delete or return the personal data it processes on the Controller's behalf.

Deletion completes within 90 days of termination.
Backups: encrypted database backups are retained for 1 day on a rolling basis. Personal data present in a backup at the point of deletion is therefore fully expired within that window, and is not restored except in a disaster recovery event.
Zyphr may retain personal data where required by law, and will inform the Controller of any such requirement.
Suppression records are retained after deletion where required to honour an unsubscribe or comply with anti-spam law (see §7).

Measured, not assumed. The 1-day figure is read from the live database cluster configuration, not from the Terraform default (which is 30 days for a different module Zyphr does not use).

Verified 14 August 2026; re-verified 21 August 2026 — BackupRetentionPeriod: 1, storage encrypted, on the live cluster. Re-verify before execution and on any infrastructure change: this is the one clause in the DPA whose truth can change without anyone editing the document.

10. Article 28(3)(h) — Audits

Zyphr makes available the information necessary to demonstrate compliance with Article 28, including:

the published subprocessor list
this DPA and its annexes
its Article 30 records of processing (summary form on request)
its US support-access disclosure
responses to reasonable security questionnaires

The Controller may audit no more than once per twelve months, on 30 days' written notice, at its own cost, subject to confidentiality — or more often where required by a supervisory authority or following a personal data breach.

Zyphr does not currently hold SOC 2 or ISO 27001 certification. Stated plainly because a reviewer will ask, and discovering it after signature is worse.

11. International transfers

All personal data is processed in the United States, in AWS region us-east-2 (Ohio). Zyphr does not offer EU data residency and makes no representation that data is stored in the EU, EEA or UK.

Transfers of EU, EEA or UK personal data to the United States are made under:

the EU-U.S. Data Privacy Framework and its UK Extension, under which ArcRaz LLC self-certified on 11 September 2026 and is listed on the U.S. Department of Commerce Data Privacy Framework List; and
the Standard Contractual Clauses, Module Two (controller to processor), adopted by the European Commission and incorporated by reference at Annex A.

Both are maintained in parallel and deliberately. If the adequacy decision underpinning the Framework is annulled or suspended, the SCCs continue to provide a valid transfer mechanism without interruption to the Service.

11.1 Transfer impact assessment

Data categories: as described in §1 — no special-category data is required by the Service (see the caveat at §13).
Onward transfers: only to the published subprocessors, each subject to equivalent obligations. Where a subprocessor is itself listed on the EU-U.S. Data Privacy Framework registry, evidence of that subprocessor's participation is retained. This says nothing about ArcRaz LLC's own status, which is addressed at §11.
Supplementary measures: encryption in transit and at rest; application-level encryption of credential material; access limited to named administrative accounts with logged, reason-recorded, time-boxed support access; data minimisation as described in §5.4.
Government access: Zyphr has never received a government request for Controller personal data. Zyphr will, unless legally prohibited, notify the Controller of any such request, challenge overbroad or unlawful requests, and disclose only the minimum required.

12. US support access

Zyphr's personnel are located in the United States. Support staff may access Controller personal data when providing support. Such access is a restricted transfer and is covered by the mechanisms in §11.

Access is limited to named administrative accounts, is logged with the acting administrator and a stated reason, and is time-boxed. Full disclosure: docs/compliance/us-support-access.md.

Zyphr does not offer EU-resident support staff.

13. Special-category data

The Service accepts arbitrary Controller-supplied metadata on several records. Zyphr cannot constrain the contents of those fields.

The Controller warrants that it will not submit special-category data (Article 9) or criminal-conviction data (Article 10) through these fields without first informing Zyphr and agreeing any additional measures required. Such data would attract obligations Zyphr has not had the opportunity to assess.

Erasure and export cover these fields regardless of contents.

Annex A — Standard Contractual Clauses (Module Two)

The operative clauses of Commission Implementing Decision (EU) 2021/914, Module Two (controller to processor), are incorporated by reference and are to be attached in full at execution. They are deliberately not reproduced here: the Commission text is fixed and must not be paraphrased or partially quoted, and attaching the authoritative version is counsel's step.

A docking clause (Clause 7) is to be included, permitting additional controllers to accede.

The Annexes below are completed from Zyphr's own verified behaviour and are ready for that attachment. Sources are named so each entry can be re-checked rather than taken on trust.

Annex I.A — Parties

Data exporter (Controller) — the customer. Name, address, contact person and signature are completed at execution. Activities relevant to the transfer: use of the Zyphr platform to send communications to, and to authenticate, its own end users.

Data importer (Processor)

Field	Detail
Name	ArcRaz LLC, trading as Zyphr
Address	Completed at execution — see §12
Contact	privacy@zyphr.dev (monitored by two named individuals)
Role	Processor
Activities relevant to the transfer	Message delivery (email, SMS, push, in-app), authentication as a service, and AI-assisted content features, each performed on the Controller's documented instructions

Annex I.B — Description of the transfer

Drawn from the Article 30 record §3, which was itself verified against the running system rather than written from a template.

Categories of data subjects

The Controller's end users and message recipients
End users of the Controller's applications who authenticate through Zyphr
Operators of systems that send mail using the Controller's domain, where a DMARC aggregate report identifies them by source IP. Listed separately because these are not the Controller's recipients and the data does not arise from mail Zyphr delivered

Categories of personal data

Processing activity	Personal data
Message delivery	Recipient email address and display name, phone number, device and push tokens, message subject and body content, raw inbound MIME and attachments, delivery events, open and click tracking, IP address and user agent captured at engagement
Authentication	Email address, name, phone number, avatar URL, password hash, session refresh-token hashes, MFA secrets (encrypted at the application layer), WebAuthn credentials, OAuth connections and provider identifiers, organisation memberships, customer-supplied claims and metadata
AI-assisted content	Customer-authored template content and subject lines; aggregate engagement statistics
DMARC aggregate reports	Source IP addresses of systems sending mail as the Controller's domain, per-source message counts, SPF/DKIM authentication and alignment results, disposition applied by the receiver, and `header_from` / `envelope_from` domains. No message content or recipient addresses

⚠️ Special-category data — Article 9

The Service does not require special-category data, and Zyphr does not solicit it. However several fields accept arbitrary customer-supplied JSON — end_users.metadata, end_user_claims.claims, subscribers.metadata, devices.metadata, messages.metadata — whose contents cannot be schema-constrained. The Controller warrants under §13 that it will not place Article 9 data into them without its own lawful basis and without informing Zyphr. Stated here rather than omitted, because an Annex I.B claiming "no special-category data" would be a representation Zyphr cannot technically enforce.

Frequency of the transfer: continuous, for the duration of the agreement.

Nature and purpose of the processing: transmission and delivery of communications the Controller initiates; registration, authentication and session management of the Controller's end users; on request, drafting assistance for the Controller's own message templates; and receiving and parsing DMARC aggregate reports about the Controller's sending domains, where the Controller has directed those reports to Zyphr by publishing a rua= address in its own DNS. Zyphr processes only on the Controller's documented instructions (§2) and not for its own purposes.

Retention

Data	Period
Message records	Plan-based, enforced automatically: Free 7 days · Starter 14 · Pro 30 · Scale 90 · Enterprise as agreed. An account may shorten its own window below the plan ceiling
End-user accounts	Duration of the end user's account with the Controller. On erasure, identifying fields are cleared and all credential and session artifacts deleted
AI prompt/completion audit records	24 months
Audit logs	24 months
Database backups	1 day, rolling — measured against the live cluster, see §9

Onward transfers: only to the subprocessors at Annex III, each under obligations no less protective than these Clauses.

Annex I.C — Competent supervisory authority

Determined at execution under Clause 13, by the Controller's place of establishment or, for a Controller not established in the EEA, by the Member State of its Article 27 representative.

Not asserted here. Naming a single authority in a template would be wrong for most Controllers, and this is a per-agreement determination.

Annex II — Technical and organisational measures

§5 of this DPA is Annex II and is incorporated here in full rather than restated, so the two cannot drift apart. It covers encryption in transit, at rest and at application level; credential handling; access control; data minimisation; outbound request protection; and resilience and testing.

Two measures worth surfacing at Annex II level because reviewers look for them specifically:

Access control: administrative access sits in a separate authentication realm from the customer dashboard, with TOTP multi-factor enforced on every active administrative account. Support access that views the product as a specific end user is time-boxed and recorded with the acting administrator, the subject, the stated reason and the originating IP.
Data minimisation: IP geolocation is resolved from a local database, so no end-user IP is sent to any third party; end-user identifiers are masked before any internal alert leaves the platform.

Annex III — List of subprocessors

The authoritative list is published at zyphr.dev/subprocessors and forms part of this DPA (§6). It is maintained there rather than duplicated here so a signed agreement cannot carry a stale list.

The Controller grants general authorisation under Clause 9(a), option 2, with the 30-day advance notice and right to object set out in §6. That notice period is enforced by a database constraint, not by convention.