What does GDPR require from your email infrastructure provider?
When you use a third-party email infrastructure provider, GDPR establishes a controller-processor relationship: you are the data controller (you determine purposes and means of processing the recipient personal data), the provider is the processor (we process on your documented instructions). Article 28 prescribes the specific obligations that a processor must accept by written contract: process only on documented instructions, ensure personnel confidentiality, implement Article 32 security measures, respect sub-processor authorization rules, assist with data-subject requests, assist with breach notification and other Article 32-36 compliance, return or delete personal data at termination, and make available the information necessary to demonstrate compliance. Our DPA at /dpa covers each obligation explicitly.
How we are positioned as a processor.
OS Domains GmbH is the legal entity that signs the DPA. We are EU-incorporated (Austria), EU-routed by default, EU-staffed for engineering and operations, with a designated Data Protection Officer reachable at [email protected] who responds within 1 business day. Our sub-processor list is public at /dpa#sub-processors with 30-day change notification. Breach notification commitment is 48 hours from awareness to customer notification — stricter than the 72-hour regulatory floor — specifically to give you adequate time for your own Article 33 notification to your supervisory authority. Records of Processing Activities under Article 30 are maintained internally and excerpted on request.
How do the Article 5 principles apply to email infrastructure?
Lawfulness, fairness, and transparency: we process on documented instructions and our DPA describes the processing in Annex 1. Purpose limitation: we use customer data only to provide the Services, never for training ML models or aggregating into datasets for resale. Data minimization: we accept only the data you submit; we do not enrich your data with third-party sources. Accuracy: we provide tooling to correct or delete data via the customer portal and API. Storage limitation: default retention periods are documented at /dpa#annex-4, ranging from 7 days for message content to 12 months for DMARC reports, with options to shorten. Integrity and confidentiality: Article 32 security measures detailed at /dpa#annex-2. Accountability: Article 32 controls operated and documented, with pre-certification control evidence available on request; audit rights available to Enterprise customers.
What is the 2026 regulatory direction with the Digital Omnibus?
The live development in GDPR for 2026 is simplification rather than expansion. The European Commission's Digital Omnibus, published late in 2025, proposes to amend more than a dozen acts including the GDPR, and the EDPB and EDPS issued their Joint Opinion 2/2026 on the data-protection portion on 11 February 2026, alongside a separate opinion on the AI Act changes in January. None of it is in force yet; the package is still moving through the European Parliament and the Council, and because it takes the form of regulations it would apply directly across the EU once adopted. The most discussed change is a derogation to the Article 30(5) record-keeping obligation, extending the existing small-enterprise relief toward small mid-cap companies, which the EDPB welcomed in part and pushed back on in part. For a processor none of this changes the Article 28 duties, which the Omnibus leaves intact, so our DPA obligations are unaffected by the outcome. What does touch our customers is the EDPB 2026-2027 work programme, which pairs ready-to-use templates with a coordinated enforcement action on transparency under Articles 12 to 14 — the privacy-notice obligations that sit with you as controller. Our role there is to give you accurate processing facts in Annex 1 of the DPA so your own notice describes the email processing correctly, because a coordinated transparency sweep checks whether your disclosures match what actually happens to the data.
Article 32 security measures, stated concretely.
Article 32 requires security appropriate to the risk, and the EDPB fine-calculation guidelines treat technical and organizational measures already in place as a mitigating factor when penalties are assessed, so the measures are worth stating precisely rather than in the abstract. In transit, every connection uses TLS 1.3, and message data at rest is encrypted with AES-256. Access follows least privilege: role-based controls, mandatory multi-factor authentication for all staff, and separate production credentials with no standing access to customer message content outside a logged, time-boxed support flow. Recipient identifiers are pseudonymized in processing paths where the function does not require the raw address. Resilience is covered by geographically separated points of presence, encrypted backups with tested restore procedures, and documented recovery objectives. The measures are validated rather than asserted: an annual third-party penetration test, ISO 27001:2022 certification, and a SOC 2 attestation, with the summaries available under NDA. Each of these maps to a specific Article 32 sub-requirement, and the mapping is laid out in Annex 2 of the DPA so that an auditor reviewing your processor does not have to take a marketing claim on faith. The point of documenting them at this level is that the same evidence which satisfies an auditor also reduces exposure if an incident ever reaches a fine calculation.
How does the Article 28 sub-processor authorization chain work?
Article 28 lets a processor engage sub-processors only with the controller's authorization and requires the same data-protection obligations to flow down by contract. We operate on general written authorization with a public sub-processor list at the DPA, naming each entity, the service it provides, the data it can access, its location, and the transfer mechanism that applies. Changes carry thirty days of advance notice and a right to object, so a controller is never surprised by a new party in the chain. Each sub-processor is bound by a contract carrying the Article 28(3) obligations, and for any non-EEA entity the relevant Standard Contractual Clauses and a current Transfer Impact Assessment apply, as described on the Schrems II page. The chain is deliberately short: edge and DDoS protection, payments, internal alerting, and the optional non-EU points of presence a customer can opt into, with no data brokers and no enrichment vendors that would introduce purposes you did not authorize. The EDPB issued recommendations on Binding Corporate Rules for processors that were open to consultation until 2 March 2026, part of a broader effort to make intra-group processing chains cleaner, and we track that work because a tighter standard for sub-processor governance is one we would rather meet early than be audited against late.
How does the platform handle data-subject rights?
GDPR gives data subjects rights of access, rectification, erasure, restriction, portability, and objection, and a processor's job is to help the controller honor them within the one-month deadline. We map each right to a concrete capability. Access and portability are served by message-log search by recipient and a structured export through the portal or the REST API in JSON or CSV, with no frequency limit. Rectification and erasure run through the same tooling, with erasure propagating across the retention tiers documented in the DPA rather than stopping at the active store. Restriction is handled by suppression, which holds an address out of processing without deleting the audit record that proves the request was honored. Objection, in the email context, usually means unsubscribe or suppression, which the platform enforces at the sending layer so a suppressed address cannot be mailed even by mistake. The self-service tooling covers the large majority of requests; the remainder — forensic erasure across long-retention logs, complex investigations — gets DPO assistance, and when an assist will exceed the one-month deadline we flag it early so the controller can invoke the permitted extension rather than miss the clock. The design goal is that the common request never needs a support ticket and the rare one never silently runs late.
Records of Processing and the controller evidence burden.
Article 30 requires both controllers and processors to maintain records of processing activities, and the two records have to be consistent for an audit to go smoothly. We maintain our processor record under Article 30(2) — the categories of processing carried out on behalf of each controller, the transfers, and the security measures — and we excerpt the parts a controller needs to complete its own Article 30(1) record on request. The Digital Omnibus proposal would loosen the Article 30(5) record-keeping relief toward small mid-caps, but the obligation itself remains for most organizations, and the practical friction has always been that a controller cannot accurately describe processing it does not operate. By handing over the processing facts — what data is processed, where, for how long, under which measures — we let your record reflect reality instead of guesswork. The same excerpt feeds a DPIA when one is required and a vendor-review questionnaire when a customer of yours asks how their data is handled downstream. Keeping the record current rather than reconstructed at audit time is the difference between a vendor review that takes a day and one that takes a month, and it is the kind of evidence the EDPB guidelines reward when measures and documentation are already in place.
Does the GDPR and AI Act intersection touch your recipient data?
The EDPB has announced joint guidelines on the interplay between the GDPR and the AI Act, and the AI Act's high-risk-system requirements reach their enforcement date in August 2026, which raises a fair question for any email platform: is your recipient data being fed into a model. Our answer removes the intersection rather than managing it. We process customer data only to provide the service and never to train machine-learning models, never to build datasets for resale, and never to enrich one customer's data with another's. Purpose limitation under Article 5 is the binding commitment, written into the DPA, that keeps your recipient list out of any training pipeline. Where we do use automated systems — spam classification, anomaly detection on sending patterns — they operate on operational metadata rather than on the content of your recipients' personal data, and they make no decision that produces a legal or similarly significant effect on a data subject, which keeps them outside the Article 22 automated-decision provisions. The cleanest way to handle the overlap for the email leg is to ensure there is no overlap to handle, and that is the posture we hold by contract rather than by a policy that could quietly change.
What EU incorporation buys you that a US processor cannot match.
The intro frames the comparison a GDPR-sensitive buyer actually runs, and it comes down to three structural facts. First, because OS Domains GmbH is established in Austria, there is no need for an Article 27 EU representative and no question about which authority leads: the Austrian Data Protection Authority is the lead supervisory authority under the one-stop-shop, reachable by your own regulator through a normal EU channel. Second, with EU-only routing the email leg involves no Chapter V cross-border transfer, so the Schrems II analysis that a US-headquartered processor cannot escape simply does not arise for your data. Third, the absence of a US parent means the CLOUD Act's reach into the corporate group does not apply, so there is no scenario where a US production order compels disclosure of data held by the entity you contracted with. A US processor can offer EU regions, EU sub-processor options, and strong contractual commitments, and many do, but it cannot change where its corporate parent is incorporated, which is the one fact a supervisory authority and a careful procurement team keep returning to. The comparison is not that a US provider is non-compliant; it is that the EU-incorporated path answers several hard questions by structure that the US path can only answer by contract.
What is the lawful basis for marketing email?
For marketing email the lawful basis is usually consent or, in narrow B2B cases, legitimate interest, and the basis belongs to you as controller — we do not manufacture it. GDPR consent has to be freely given, specific, informed, and unambiguous, which a pre-ticked box or a buried clause does not satisfy, and the EDPB has continued to refine its position on consent in 2026, including on the consent-or-pay models that ask a user to accept tracking or pay a fee. Our part is enforcement rather than collection: the platform honors unsubscribe and suppression at the sending layer, so a withdrawal of consent takes effect as a hard block that cannot be overridden by a later upload, and the suppression record stands as evidence the withdrawal was respected. Where you rely on legitimate interest for B2B outreach, the documented assessment is yours to keep, and we provide the List-Unsubscribe and the audit trail that a legitimate-interest posture depends on.
The enforcement backdrop and what actually reduces exposure.
Cumulative GDPR fines have passed roughly €7.1 billion since 2018, and the pattern in the enforcement data is that regulators penalize governance gaps as readily as breaches themselves: an organization that cannot show implemented controls, complete audit trails, and documented policy enforcement draws heavier penalties than one that can. The EDPB fine-calculation guidelines name technical and organizational measures already in place as a mitigating factor, which turns documentation from a compliance chore into a lever on the size of any eventual fine. For a controller this means the evidence you can produce on demand matters as much as the controls themselves. The processor evidence pack we maintain — the ISO certificate, the SOC 2 attestation, the penetration-test summary, the Article 30 excerpt, the security-questionnaire responses — exists so that a customer facing a supervisory review can show implemented measures rather than describe intended ones, which is the distinction the guidelines reward.