Encryption at rest applied
AES-256-XTS LUKS volumes for all personal data storage. Key management separated from data storage. Documented in deployment runbook with key rotation schedule and access procedures.
ONE-TIME | ARTICLE 32 TOMs | 7 BUSINESS DAYS | EUR 899
Apply the technical measures GDPR Article 32 actually expects, in one engagement.
Apply the technical measures GDPR Article 32 actually expects, in one engagement.
AES-256 at rest, TLS 1.3 in transit, pseudonymised logs, breach playbook, RoPA template.
GDPR Article 32 requires controllers and processors to apply technical and organisational measures appropriate to the risk. Supervisory authorities across the EU have built consistent expectations of what that means in 2026 even though the regulation does not specify exact algorithms. The German A7 guide updated March 2026 cites AES-256 at rest and TLS 1.2+ in transit as the supervisory authority baseline. The Konfirmity 2026 encryption guide cites the same plus TLS 1.3 as the current best practice. ICO and NIST guidance converges on the same algorithm set. The pattern is: encryption everywhere personal data lives, pseudonymisation in operational logs, multi-factor authentication on administrative access, structured log retention with documented windows, and a written breach response procedure tied to the 72-hour Article 33 notification window.
GDPR Compliance Setup applies this baseline to your existing or new ASH infrastructure in a fixed-scope one-time engagement. Encryption at rest using AES-256 with LUKS or equivalent on all volumes containing personal data. TLS 1.3 with strong cipher suites and certificate pinning where appropriate. Pseudonymisation of recipient identifiers in operational logs through HMAC-SHA-256 with separately stored salt. MFA enforcement on all administrative accounts. Structured log retention with documented windows per category. Written breach response playbook covering detection, classification, notification chain, controller notification content, supervisory authority notification content, remediation tracking. Records of Processing Activities (RoPA) template aligned with Article 30 obligations covering both controller and processor roles. Summary of measures applied to your specific infrastructure for inclusion in your processor evidence package. One-time engagement EUR 899, delivery in 7 business days.
Fixed price EUR 899
Delivery 7 biz days
Encryption AES-256 + TLS 1.3
Breach SLA 72h playbook
Audit your current infrastructure against Article 32 supervisory authority expectations.
Article 32 lists encryption and pseudonymisation as example measures but the supervisory authorities have built consistent expectations of what they want to see during audits. The eight controls below cover the baseline most EU DPAs reference. Check items you currently have; gaps are what this engagement will close.
Article 32 baseline readiness 0 of 8 measures confirmed
Check measures already in place on your infrastructure. The engagement closes the gaps for the remainder.
The technical measures supervisory authorities actually look for.
GDPR Article 32 does not specify exact algorithms or retention windows. It requires controllers and processors to apply technical and organisational measures appropriate to the risk, taking into account the state of the art, costs of implementation, and the nature, scope, context, and purposes of processing. The vagueness is intentional; the regulation is designed to age gracefully across technology changes. The practical effect is that supervisory authorities across the EU have built consistent expectations of what "appropriate" means in 2026 even though the regulation text remains general.
The convergence is striking. The ICO baseline in the UK cites AES-256 at rest and TLS 1.2+ in transit. The Italian Garante uses similar language. The Spanish AEPD has issued guidance citing the same algorithm set. The French CNIL technical guides recommend AES-256 and TLS 1.3. The German A7 guide updated March 2026 specifies AES-256 at rest, TLS 1.2+ in transit, MFA for all users, need-to-know access control, backups following the 3-2-1 rule, pseudonymisation, and a documented incident response process. The Konfirmity 2026 encryption guide cites the same list with TLS 1.3 as the current best practice. NIST SP 800-175B and the ENISA guidelines reach the same conclusions independently. Operations meeting this baseline pass technical review under all major EU supervisory authorities; operations falling short of it create direct enforcement exposure.
The economics of meeting the baseline are favourable relative to the alternative. The DLA Piper GDPR Fines Survey reported cumulative fines exceeding EUR 7.1 billion since 2018 with a growing trajectory year over year. The largest fines target operations with identifiable Article 32 failures (insufficient encryption, inadequate access control, missing breach response procedures). The Spanish AEPD issued over 40 sanctions in 2024 alone referencing Article 32 or related processor obligations. The Finnish DPO fined a healthcare processor EUR 608,000 partly because the operational documentation lacked adequate technical measures evidence. The Danish DPA found in a 2024 audit that 35% of processor agreements reviewed failed to include adequate sub-processor flow-down clauses with corresponding technical measures. The pattern is consistent: operations that cannot evidence the baseline technical measures end up in enforcement action.
What this engagement covers is the technical layer specifically. Encryption at rest applied to all volumes containing personal data using AES-256 with LUKS or equivalent depending on the underlying filesystem. Key management separated from data storage so a stolen disk does not yield cleartext; keys live in a separate keystore with access controls and audit logging. Encryption in transit applied to all external traffic (HTTPS, SMTP STARTTLS) and to internal service-to-service traffic where the architecture supports mutual TLS authentication. Cipher suite selection follows current NIST and ENISA recommendations, excluding all SSL versions, TLS 1.0, TLS 1.1, and any export-grade or weak ciphers. HSTS preload submission for customer-facing domains.
Pseudonymisation deserves specific attention because it is the technical measure most often misunderstood. Article 32 calls out pseudonymisation by name as an example measure. The mechanism: replace personally identifiable information with artificial identifiers (pseudonyms) that cannot be traced back to the individual without separately-held additional information. For email infrastructure, the application is logging recipient email addresses as hashed identifiers rather than cleartext. Operational teams still correlate events across the log stream (same hash equals same recipient) but cannot enumerate the recipient list from logs in isolation. Re-identification requires access to the salt, which lives on separate infrastructure with its own access controls. The hash function is HMAC-SHA-256 with a per-customer salt to prevent rainbow table attacks and cross-customer correlation. The technique dramatically reduces the impact of log compromise while preserving operational utility.
The breach response playbook is the most often neglected component and the most operationally consequential. Article 33 gives controllers 72 hours from awareness to notify supervisory authorities; the window starts from the point of becoming aware, not from the point of detection. Operations without a documented response procedure typically discover they have a breach, then spend the first 12-24 hours arguing about whether it qualifies as a breach, then spend the next 24-36 hours assembling the notification package, then submit at hour 60-70 with significant gaps in the notification content. The playbook engineered around the deadline covers detection signals, classification criteria (the GDPR Article 4(12) definition with practical examples), notification chain (designated incident commander, technical responder, communications lead, legal counsel), content templates for controller notification and supervisory authority notification, and post-incident review structure. Annual tabletop exercises are recommended; the engagement includes the playbook and one tabletop walk-through with the customer.
What gets encrypted, with what algorithm, at what layer.
The matrix below documents the encryption choices applied per data category and data state. The engagement applies these defaults; deviations are documented in the per-customer summary delivered with the engagement.
| Data category | At rest | In transit | Key management |
|---|---|---|---|
| Subscriber email addresses | AES-256-XTS (LUKS volume) | TLS 1.3 | Per-volume key in separate keystore |
| SMTP message bodies in queue | AES-256-XTS (mail spool encrypted volume) | TLS 1.3, STARTTLS enforced outbound | Per-volume key, rotated annually |
| Authentication credentials | Argon2id for passwords, AES-256 for tokens | TLS 1.3, certificate pinning | Token signing keys in HSM-equivalent |
| SMTP transaction logs | AES-256-XTS, pseudonymised recipient identifiers | TLS 1.3 for log shipping | Salt stored separately from logs |
| Backup archives | AES-256-GCM with per-backup nonce | TLS 1.3 for backup transfer | Backup keys in offline escrow |
| Control panel session tokens | Signed with HMAC-SHA-256 | TLS 1.3, HSTS preload | Session key rotated daily |
| DKIM private keys | Filesystem permissions + encrypted volume | Not transmitted; signing happens locally | Rotated per DKIM rotation schedule |
Algorithm choices follow NIST SP 800-175B, ENISA Cryptographic Guidelines, and current ICO technical guidance. The selection is reviewed annually as cryptographic standards evolve; post-quantum migration is on the roadmap for sensitive long-lived data following NIST PQC standardisation progress.
Eight artefacts delivered at engagement completion.
Encryption in transit applied
TLS 1.3 enforced on HTTPS endpoints with strong cipher suites. SMTP STARTTLS configured with opportunistic-mandatory mode. HSTS preload submission for customer-facing domains. Internal mTLS where architecture supports it.
Pseudonymisation deployed
HMAC-SHA-256 hashing of recipient identifiers in operational logs with per-customer salt stored on separate infrastructure. Applied to SMTP transaction logs, authentication logs, and bounce processing logs.
MFA enforcement
Multi-factor authentication required on all administrative accounts. SSH key-only authentication for server access. Control panel requires TOTP or hardware key. No password bypass paths configured.
RBAC and least privilege
Role-based access control across infrastructure with documented role definitions. Operational staff receive only the access required for their role. Privileged elevation requires explicit grant with audit logging.
Structured log retention
Documented retention windows per log category: SMTP logs 30 days, authentication logs 90 days, abuse handling logs 180 days, security incident logs 12 months. Automated purge enforced beyond retention window.
Breach response playbook
Written runbook covering detection, classification, notification chain, content templates for controller and supervisory authority notification, and post-incident review. One tabletop walk-through with the customer included.
RoPA template + summary
Records of Processing Activities template aligned with Article 30 obligations covering controller and processor versions. Written summary of technical measures applied to your infrastructure for inclusion in your evidence package.
Operational profiles where this engagement is the right starting point.
New ASH customer establishing baseline
Operations onboarding to ASH infrastructure who need the GDPR Article 32 baseline applied from day one rather than retrofitted later. The engagement integrates with initial setup so the compliance posture is correct before any production traffic begins.
Existing operation preparing for procurement
Operations selling into enterprise procurement processes that require Article 32 evidence in vendor security questionnaires. The engagement produces the documentation that procurement teams request before signing.
Pre-Compliance Pack technical readiness
Operations planning to subscribe to the Compliance Pack bundle need the underlying technical posture in place first. This engagement is the prerequisite that makes the bundle documentation accurate; you cannot maintain compliance documentation if the technical baseline does not exist.
Audit preparation
Operations facing scheduled supervisory authority review or controller audit (under Article 28(3)(h)) who need the technical baseline closed before the audit begins. The engagement closes the most common findings in advance.
Post-incident remediation
Operations who experienced a data incident and need to demonstrate corrective action to a supervisory authority or affected controllers. The engagement documents the remediation applied and provides the evidence trail for the post-incident review.
M&A due diligence preparation
Operations preparing for acquisition or investment due diligence where data protection posture is part of the diligence checklist. The engagement produces the technical evidence that diligence teams expect to see during the process.
Frequently asked.
What does GDPR Compliance Setup deliver?
A one-time technical engagement that applies GDPR Article 32 technical and organisational measures (TOMs) to your existing or new ASH email infrastructure. The deliverables: encryption at rest using AES-256 with LUKS or equivalent on all server volumes containing personal data; encryption in transit using TLS 1.3 with strong cipher suites and certificate pinning where appropriate; pseudonymisation of recipient identifiers in operational logs (hashed email addresses with separately-stored salt); multi-factor authentication enforcement on all administrative accounts; structured log retention policy with documented retention windows per log category; breach response playbook covering the 72-hour notification window under Article 33; Records of Processing Activities (RoPA) template aligned with Article 30 obligations; written summary of TOMs applied to your specific infrastructure for inclusion in your processor evidence. One-time engagement EUR 899, delivery in 7 business days.
Does GDPR actually require encryption?
GDPR Article 32 does not mandate encryption universally; it requires technical and organisational measures appropriate to the risk. Recital 83 specifically recommends encryption as a risk-mitigation measure. In practice, supervisory authorities expect encryption for any processing where unauthorised access could harm individuals, which covers most email infrastructure scenarios because email touches identifiable data at scale. The Article 32 reference list includes pseudonymisation and encryption as example measures. ICO and NIST guidance both recommend AES-256 for data at rest and TLS 1.3 for data in transit as the current 2026 baseline. The German A7 guide (March 2026) and Konfirmity 2026 encryption guide both cite AES-256 plus TLS 1.2+ as the supervisory authority expectation across European jurisdictions. We apply these standards by default; the engagement documents the choices made and the reasoning for your evidence package.
How is this different from the Compliance Pack bundle?
Different scope and pricing model. GDPR Compliance Setup is a one-time technical engagement that applies the technical measures (encryption, MFA, log structure, breach playbook) and delivers documentation of what was applied. Compliance Pack is an ongoing bundle that adds executed DPA, maintained sub-processor registry, SOC 2 Type II evidence mapping, ISO 27001 alignment, quarterly DPIA support hours, and 4-hour breach notification SLA on an EUR 449 monthly recurring basis. Many customers buy GDPR Compliance Setup first to get the technical baseline right, then add Compliance Pack later as they sell into enterprise procurement processes that require ongoing documentation. The setup is a prerequisite for the bundle in practice; you cannot maintain compliance documentation if the underlying technical posture is not in place.
What about pseudonymisation specifically?
Pseudonymisation is a specific technical measure Article 32 calls out by name (alongside encryption). The mechanism: replace personally identifiable information in operational logs with artificial identifiers (pseudonyms) that cannot be traced back to the individual without separately-held additional information (the salt or mapping key). For email infrastructure the practical application is logging recipient email addresses as hashed identifiers (typically HMAC-SHA-256 with a per-customer salt stored separately from the logs) rather than cleartext. The operational team can still correlate events across the log stream (same hash equals same recipient) but cannot enumerate the recipient list from the logs in isolation. Re-identification requires access to the salt, which is stored on separate infrastructure with its own access controls. We apply this pattern to SMTP transaction logs, authentication logs, and bounce processing logs. Cleartext email addresses remain in the operational sending queue (necessary for actual delivery) but the queue is encrypted at rest and retained for the minimum operational window only.
How do you handle the 72-hour breach notification requirement?
GDPR Article 33 requires controllers to notify supervisory authorities within 72 hours of becoming aware of a breach. Article 33(2) requires processors to notify controllers without undue delay. Our breach response playbook is engineered around these windows. The playbook covers: detection mechanisms (intrusion detection alerts, anomalous access patterns, authentication failures at scale, data exfiltration signals); classification procedure (is this a breach as defined by GDPR Article 4(12), or an incident that does not meet the breach threshold); notification chain (designated incident commander, technical responder, communications lead, legal counsel notification); content of the controller notification (incident classification, affected data categories, recipient count estimate, root cause status, remediation in progress); content of the supervisory authority notification when the controller decides to escalate; remediation tracking and post-incident review. The playbook is delivered as a written runbook with specific contacts and decision criteria. Customers needing 4-hour processor notification SLA (rather than just the documented playbook) should add the Compliance Pack bundle.
What does the Records of Processing Activities template cover?
Article 30 obligations vary by role. Controllers under Article 30(1) must maintain records covering: name and contact of the controller, purposes of processing, categories of data subjects and personal data, categories of recipients, third country transfers with safeguards, retention periods, and general description of security measures. Processors under Article 30(2) maintain a similar but processor-focused record covering categories of processing activities performed on behalf of each controller, third country transfers, and security measures description. Our template covers both versions and pre-populates the rows relevant to ASH-related processing on your behalf. You adapt the template to cover your full operational scope, integrating ASH-specific rows alongside your other processing activities. The template is delivered in editable format (Word and Markdown) with annotations explaining each field.
Does this cover the EU AI Act enforcement starting August 2026?
Partially. EU AI Act enforcement begins August 2026 for high-risk AI systems requiring conformity assessments. Email infrastructure itself is not classified as a high-risk AI system under the Act; standard PowerMTA, MailWizz, and bounce processing pipelines do not meet the AI system definition. However, if your operation runs AI-driven content generation, AI-driven recipient targeting, or AI-based deliverability optimisation, you may have AI Act obligations as a deployer or provider. GDPR Compliance Setup focuses on Article 32 technical measures and Article 30 records; it does not extend to AI Act conformity assessments. We are tracking AI Act enforcement guidance from supervisory authorities and can update the documentation as guidance crystallises. For operations with AI components, we recommend supplementing this setup with specialised AI Act assessment from a qualified consultancy.
What if my data flows outside the EU?
GDPR Chapter V governs international transfers. The setup documents the transfer mechanism applicable to your specific data flows. The three main mechanisms: adequacy decision (transfer to countries the EU Commission has determined provide adequate protection, currently including Switzerland, UK, Japan, South Korea, and a few others, with the EU-US Data Privacy Framework currently in force for certified US recipients); Standard Contractual Clauses (the EU-approved contract template for transfers to non-adequate countries, applicable to our non-EU regions like Panama and Hong Kong); Article 49 derogations (specific situations like explicit consent or contract necessity, narrower in scope). For ASH customers using EU datacenters (Romania, Bulgaria), Chapter V is not triggered for storage and processing within those datacenters. For customers using non-EU datacenters (Panama, Hong Kong, Singapore), we provide the Standard Contractual Clauses package as part of the setup documentation. Customers needing a fully customised transfer impact assessment for high-risk transfers should engage specialised counsel; the setup provides the baseline documentation that most procurement processes require.
Related services and bundles.
Order GDPR Compliance Setup.
Telegram conversation establishes current infrastructure state, jurisdiction of processing, controller-processor role, and any specific supervisory authority focus areas. Engagement begins within 2 business days of confirmation. Delivery in 7 business days including applied measures, tabletop walk-through, and documentation package. One-time EUR 899. No recurring fee.
# Median Telegram response: 12 minutes during operating hours