GDPR Article 32 — Security of Processing

Overview#

GDPR Article 32 — 'Security of processing' — is the operative security clause of European data-protection law. The General Data Protection Regulation (Regulation (EU) 2016/679) entered into force on 25 May 2018 and replaced the 1995 Data Protection Directive with a directly-applicable regulation across the European Economic Area. After the United Kingdom left the European Union the regulation was retained in domestic law as the UK GDPR (sitting alongside the Data Protection Act 2018), with the Information Commissioner's Office as the lead supervisory authority. The two regimes are materially identical at the Article 32 level and, as of June 2026, mutually recognised as adequate, meaning a single evidence pack discharges both obligations.

Article 32 sits in Chapter IV of the regulation — the chapter that defines the obligations of controllers and processors. Where Articles 1 through 11 define the lawful bases for processing, where Articles 12 through 23 enumerate the rights of data subjects, and where Articles 24 through 31 spell out the general duties of accountability, Article 32 is the one clause that says, in plain language: secure it. It is the article every Data Processing Agreement (DPA) cites, the article every supervisory-authority fine decision quotes, and the article every supplier security questionnaire ultimately routes back to.

The text is deliberately principles-based. It does not name TLS 1.3 or AES-256. It does not specify ISO 27001 or SOC 2. Instead it requires measures that are 'appropriate to the risk' — taking into account the state of the art, the cost of implementation, the nature, scope, context and purposes of processing, and the likelihood and severity of risk to the rights and freedoms of natural persons. That principles-based posture is what makes Article 32 durable across a decade of changing technology, and what makes it operationally demanding: a controller cannot point to a checklist and declare itself compliant; it must document a risk assessment and demonstrate that the chosen measures address it.

Yobitel UK Sovereign and the broader Yobitel platform hold Article 32 evidence as part of the customer-facing compliance posture — ISO 27001 + 27017 + 27018, SOC 2 Type II, customer-managed KMS, mTLS between services, a customer-readable audit stream, tested cross-region restore drills, and a published sub-processor register on a 30-day notice cycle — so customers building on Yobitel inherit the processor-side Article 32 controls as a baseline rather than starting the evidence chain from scratch.

This entry treats Article 32 as a working reference. The Reference section enumerates every clause of paragraphs (1) through (4), the named measures, and the evidence regulators expect for each. The Quick start lays down an OWASP-ASVS-style self-assessment with real kubectl and AWS commands that produce day-one Article 32 artefacts. Workload patterns walk through three concrete scenarios — controller evidence stack on Kubernetes, processor sub-processor evidence chain, and personal-data-in-AI training-set audit. The cost section is honest about what a defensible Article 32 posture costs in audit fees and engineering time. The troubleshooting table is framed around the failure modes regulators have actually fined on, and the closing section makes plain how Yobitel's products discharge the article on the customer's behalf where the customer chooses to consume them as managed services. This entry helps you assemble defensible Article 32 evidence for your customers, auditors, or supervisory authorities — and explains where Yobitel's own posture inherits, so a controller's DPO can fold the platform-side evidence into a DPIA appendix without rewriting it.

Scope — who and what Article 32 binds#

Article 32 binds two actors. The controller is the natural or legal person that decides why and how personal data is processed. The processor is the actor that processes personal data on behalf of the controller. The two duties are layered, not interchangeable. The controller carries the full Article 32 obligation; the processor carries an equivalent obligation in respect of the data the controller has entrusted to it, plus a duty under Article 28 to bind any sub-processor through a back-to-back contract.

A cloud provider operating a managed platform is almost always a processor. When a UK NHS trust runs a patient-records workload on a cloud, the trust is the controller and the cloud is the processor. When that cloud subcontracts storage to a managed-database vendor, the vendor becomes a sub-processor. Article 32 is enforced against whichever actor caused the security failure — but the supervisory authority's first point of contact will always be the controller, because that is who the data subject knows.

Article 32 also defines a meta-duty that is easy to miss. Paragraph (1)(d) requires 'a process for regularly testing, assessing and evaluating the effectiveness' of the other measures. That clause is the reason an Article 32 evidence pack always includes a penetration-test report, a benchmark scan, an internal-audit report, or some equivalent recurring assessment — not just a static control list. Article 32(4) closes the door on lazy delegation: any natural person acting under the authority of the controller or processor who has access to personal data must process it only on instructions from the controller, unless required by law. Practically that means role-based access control, mandatory MFA, and audit logs that show which human did what to which record.

Scope also turns on what counts as a processing activity. Getting this boundary wrong is the most common reason a Data Protection Impact Assessment (DPIA) gets re-opened by the ICO or an EU supervisory authority. Any processing of personal data of identified or identifiable natural persons within the EEA or UK is in scope, regardless of where the processor is established — and the regulation reaches extraterritorially under Article 3(2) to processors outside the EEA/UK that offer goods or services to, or monitor the behaviour of, data subjects inside it. Fully anonymised data sits outside Article 32 under Recital 26, but the bar for anonymisation is high; pseudonymised data is not anonymised. Purely household activity (Article 2(2)(c)) is out of scope, but employer use of personal data for HR never qualifies as household activity. National security processing by EU member states is carved out by Article 2(2)(a); UK national-security carve-outs differ under Schedule 2 of the DPA 2018.

• Controller — decides why and how data is processed; bears the full Article 32 obligation and signs the DPA.
• Processor — processes on behalf of the controller; bound by Article 28 to mirror the controller's Article 32 measures.
• Sub-processor — a vendor a processor uses; controller-notification required; back-to-back contract mandatory.
• Joint controller — two or more entities jointly decide purposes and means; allocate Article 32 responsibility in writing under Article 26. Without that allocation, the data subject can pursue either party for the full damages.
• Data subject — the natural person whose data is processed; the actor whose rights drive the 'appropriate to the risk' calculus.
• Boundary case — group companies sharing personal data are typically processor-to-processor under intra-group SCCs; Article 32 obligations apply at each hop.

The article itself — clause by clause#

The article runs to four paragraphs. The full text is the authoritative source, but the table below distils each clause into the operative obligation, the evidence regulators expect, and the upstream control framework most controllers use to discharge it.

Evidence patterns — what satisfies each clause in practice#

Article 32 is principles-based, but supervisory authorities (the ICO in the UK, the EDPB and each member-state authority in the EU) have produced a body of guidance that turns the clauses into a defensible evidence list. The patterns below are the working evidence pack most controllers and processors assemble, broken down by clause and by actor role. They are not the only credible answer — the regulation is risk-proportionate — but they are the answer that survives an enforcement conversation.

For the controller — the actor that decides why and how personal data is processed — the day-one evidence layer is dominated by encryption, audit, resilience and recurring testing. Encryption at rest is shown by customer-managed KMS keys with documented key-rotation policy and a per-volume / per-bucket attestation that the key is in use; encryption in transit is shown by TLS 1.2-or-higher enforcement at every ingress, an annual cipher-suite review, and mTLS between services where the threat model warrants it. Resilience under Article 32(1)(c) is evidenced not by a backup schedule alone but by a wall-clock RTO recorded from a cross-region restore drill carried out at least annually. Article 32(1)(d)'s 'regular testing' duty is the reason a credible evidence pack always includes a CREST-accredited or NCSC CHECK-accredited penetration-test report, a benchmark scan (CIS Kubernetes, kube-bench, OWASP ASVS), and an internal-audit minute trail.

For the processor — a cloud, a SaaS, or a managed-service vendor — Article 32 binds you to mirror your controller's posture and, under Article 28, to declare every sub-processor and bind them through a back-to-back DPA. Controllers will not accept a one-line statement saying 'we use sub-processors'. They want the list, the location of each sub-processor's data centre, the category of personal data each one touches, and the legal basis for any third-country transfer. A machine-readable sub-processor register published at a stable URL — with a 30-day notice window for additions and a controller-objection email — is now the market-standard evidence here. The same register feeds the controller's own Schrems II transfer-impact assessment for any onward US-bound flow.

Article 32 increasingly intersects with AI workloads. If a training set contains personal data — clinical records, customer-support transcripts, employee feedback, identified user-generated content — the article applies to the training pipeline as much as it does to the live application. The 2026 EDPB Opinion 28/2024 on personal data and AI made plain that pseudonymisation at ingest and a lineage record from raw source to model checkpoint are now expected evidence for training pipelines that touch personal data. A signed training-set manifest — one row per shard, recording the source, the Article 6 legal basis, the pseudonymisation method, the SHA-256 fingerprint and the retention horizon — is the artefact that makes Article 15 right-of-access requests and Article 17 erasure requests operationally tractable against a trained model.

Customers consuming Yobitel managed services can reuse Yobitel-supplied evidence to discharge the processor-side of the pack: the published ISO 27001 + 27017 + 27018 certificates and Yobitel SOC 2 Type II report cover Article 32(3); the customer-readable audit-stream config (`audit.k8s.io/v1` plus cloud control-plane events) covers Article 32(1)(b); the platform sub-processor register with 30-day notice covers Article 28; Yobitel UK Sovereign region pinning covers the Schrems II posture for UK-resident processing. The customer's own DPIA still owns the application-side controls — purpose limitation, lawful-basis selection, retention horizons in the application layer — but the platform-layer Article 32 evidence is shipped, not rebuilt.

• 32(1)(a) pseudonymisation — per-shard salt, salt destroyed after pseudonymisation where re-identification is not needed; tokenisation schema and key-management policy for any retained re-identification map.
• 32(1)(a) encryption — AES-256 at rest with customer-managed keys; TLS 1.2+ in transit; documented cipher-suite policy and annual cryptography review.
• 32(1)(b) confidentiality / integrity / availability / resilience — RBAC + MFA federation; audit log of integrity events; SLO with uptime measurement; chaos-test or DR-drill results.
• 32(1)(c) restore after incident — backup schedule with tested cross-region restore; recorded RTO/RPO; runbook signed off by the DPO.
• 32(1)(d) regular testing — CREST or NCSC CHECK-accredited penetration test (annually minimum); benchmark scans on a documented cadence; trend of findings closure over time.
• 32(2) risk assessment — DPIA explicitly enumerates accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data; controls mapped to each.
• 32(3) codes of conduct / certification — ISO 27001 certificate, SOC 2 Type II report, CISPE Code of Conduct attestation, or sector code (e.g. NHS DSP Toolkit).
• 32(4) staffing-level controls — RBAC policy bound to OIDC identities; signed access agreements; mandatory training records; audit log that attributes every privileged action to a named human.
• Article 28 cross-link — signed DPA with technical-and-organisational-measures (TOMs) annex; sub-processor register; 30-day notice and controller-objection window for any new sub-processor.

Audit and accountability#

Article 32(1)(b) — the confidentiality, integrity, availability and resilience clause — and Article 30's record-of-processing-activities (ROPA) obligation together create the audit-and-accountability spine of any defensible Article 32 posture. An evidence pack is only credible if the controller can demonstrate it operates in steady state. Two artefacts carry most of the weight in an enforcement conversation: a tamper-evident audit stream that attributes every privileged action to a named human, and an Article 30 ROPA that enumerates every processing activity, its legal basis, its retention horizon and its sub-processor footprint.

The audit stream must satisfy three properties to survive scrutiny. It must be complete — gaps in coverage are a candidate Article 32(1)(b) failure; the working threshold most DPOs adopt is that any gap above five minutes is an incident. It must be tamper-evident — object-lock storage on the sink, with cryptographic integrity (KMS-signed digest files on AWS CloudTrail, log-file validation on the cluster control plane) so that an investigator can prove an event was not retrospectively edited. And it must be retained for the lifetime of the processing register — usually seven years for personal-data-touching logs, often longer for healthcare or financial workloads.

Article 32(4) — instruction-only access — is what binds the audit stream to the human layer. Every privileged action must be attributable. MFA must be enforced on every privileged path with no legacy carve-outs; any successful MFA bypass on a privileged account is a P1 incident. RBAC must be tied to OIDC identities so that the audit event names the human (not a shared service account) that took the action.

• Audit-stream completeness — any gap above five minutes is a candidate Article 32(1)(b) failure and must be investigated; gaps are a frequently-cited issue in ICO enforcement decisions.
• Tamper-evident retention — object-lock storage with cryptographic integrity (KMS-signed digest files, log-file validation) so an investigator can prove an event was not retrospectively edited.
• Retention-policy enforcement — alert if any audit-log object's retention drops below the policy floor (typically seven years for personal-data-touching logs).
• MFA bypass attempts — any successful bypass on a privileged account is a P1 incident under Article 32(4); no legacy carve-outs.
• Encryption posture — continuous attestation that every volume, bucket and database is encrypted with the customer-managed KMS key in the correct jurisdiction.
• Article 33 72-hour clock — once a personal-data breach is declared, a notification-deadline timer starts; this is a board-level metric, not just an operations one.
• Article 30 ROPA — the record of processing activities is the document a supervisory authority will ask for on day one of any investigation; keep it under version control and review it quarterly.

# audit-policy.yaml - minimal Article 32(1)(b) + 32(4) evidence policy
apiVersion: audit.policy.example/v1
kind: AuditPolicy
metadata:
  name: gdpr-article-32
spec:
  retentionYears: 7                       # personal-data lifetime floor
  integrity:
    objectLock: COMPLIANCE                # tamper-evident
    digestSigning: kms                    # KMS-signed digest files
  completeness:
    maxGapSeconds: 300                    # > 5 min gap is a P1 incident
  events:
    - art32Clause: "32(1)(b)"             # control-plane mutations
      cover: ["secrets","configmaps","serviceaccounts","rbac.*"]
      level: RequestResponse
    - art32Clause: "32(1)(a)"             # encryption posture
      cover: ["kms.*","ebs.*","s3.*"]
      level: Metadata
    - art32Clause: "32(4)"                # privileged human access
      cover: ["*"]
      level: Metadata
      filter: user.groups CONTAINS "privileged"

Mapping to other frameworks#

Article 32 is principles-based, so it does not duplicate the implementation specifics provided by audit frameworks. The mapping below is the working cross-reference most DPOs and security architects use: each Article 32 clause, the NCSC Cloud Security Principle it overlaps with, the SOC 2 Trust Service Criterion it satisfies, the ISO 27001 Annex A control family, and the equivalent NIST CSF function. UK-led first, then EU and global.

Most organisations approach Article 32 from an adjacent posture rather than greenfield. A US-origin organisation typically arrives FedRAMP-Moderate-or-High-only — solid on technical controls, but missing UK/EU data location, a DPO appointment, an Article 27 EU/UK representative, a published sub-processor register, and the 72-hour breach-notification playbook tied to the ICO or a lead supervisory authority. An ISO-27001-only organisation usually lacks the cloud overlays (27017 cloud controls, 27018 PII processor controls), customer-readable audit, and Schrems II transfer-impact assessments for any non-EEA/UK flow. A SOC-2-Type-II-only organisation typically lacks pseudonymisation evidence, a DPIA process and an Article 30 record of processing activities. Each gap is closable in months, not years, against an existing control set — but each is closable only by deliberately extending the upstream framework's scope to cover the GDPR-specific obligations the principles below enumerate.

• UK sovereignty stack — NCSC Cloud Security Principles 1, 2, 3 and 13 alone evidence the bulk of Article 32(1)(a)-(b) for OFFICIAL-tier data; G-Cloud buyers will accept a principles-mapped self-assessment.
• EU stack — EU GDPR Article 32 sits alongside the NIS2 Directive (Directive (EU) 2022/2555) and the EU AI Act; the same evidence pack discharges large parts of all three.
• US stack — HIPAA Security Rule § 164.308-312 maps almost 1:1 to Article 32(1)(a)-(d); FedRAMP High also covers Article 32 in substance, though it does not formally cite it.
• Joint controllers — Article 26 requires a written allocation; without it the data subject can pursue either party for the full damages, making this an Article 32 risk multiplier.
• Adequacy — UK + EEA recognise each other; the EU-US Data Privacy Framework remains in force as of June 2026 but is under live legal challenge — keep Schrems II transfer-impact assessments live for US sub-processors.

UK, EU and US considerations#

Article 32's text is identical across the EU GDPR (Regulation (EU) 2016/679) and the UK GDPR retained in domestic law after Brexit. The differences are jurisdictional rather than substantive — the supervisory authorities, the representative-appointment regimes and the cross-border transfer mechanisms diverge, and an Article 32 posture that ignores those differences will fail at the deal-review stage even where the technical controls are sound.

In the United Kingdom, the Information Commissioner's Office (ICO) is the lead supervisory authority. The UK GDPR sits alongside the Data Protection Act 2018, which adds national derogations (notably the Schedule 2 national-security carve-out, the Schedule 3 immigration exemption now narrowed by the Court of Appeal, and the Schedule 21 representative regime). UK-resident processors that already hold NCSC Cloud Security Principles posture for OFFICIAL-tier data evidence the bulk of Article 32(1)(a)-(b) on the back of the same evidence pack — G-Cloud buyers routinely accept the principles-mapped self-assessment as Article 32 evidence. As of June 2026 the UK and the EEA are recognised as adequate to each other, meaning a single evidence pack discharges both regimes; the adequacy review is due in 2027.

In the European Union, each member state has its own supervisory authority, and the 'one-stop-shop' mechanism nominates a lead SA for cross-border processing based on the controller's main establishment. The European Data Protection Board (EDPB) coordinates between them; its guidelines (notably Guidelines 9/2022 on breach notification and Opinion 28/2024 on personal data in AI) carry near-binding interpretive weight. Article 32 sits alongside two other regimes that share much of the same evidence pack — the NIS2 Directive (Directive (EU) 2022/2555), which extends cybersecurity obligations to a wider set of essential and important entities, and the EU AI Act (Regulation (EU) 2024/1689) for high-risk AI systems. A single ISO 27001 + 27017 + 27018 evidence base, plus a DPIA register and a sub-processor register, will discharge large parts of all three.

For the United States, the picture is dominated by the cross-border transfer question. After the Schrems II ruling (Case C-311/18), every transfer of personal data from the EU or UK to the United States requires a documented transfer-impact assessment, an appropriate transfer tool (Standard Contractual Clauses, Binding Corporate Rules, or — for certified recipients — the EU-US Data Privacy Framework), and supplementary measures where the assessment identifies a risk. As of June 2026 the EU-US Data Privacy Framework remains in force but is under live legal challenge; prudent controllers keep their Schrems II transfer-impact assessments live and refresh them annually. Inside the United States, the HIPAA Security Rule (45 CFR § 164.308-312) maps almost 1:1 to Article 32(1)(a)-(d), and FedRAMP High covers Article 32 in substance even where it does not formally cite it — but neither displaces the underlying GDPR obligation for data originating in the EU or UK.

• UK — ICO is the regulator; DPA 2018 layers national derogations on top; NCSC + G-Cloud evidence pack is reused for Article 32 in OFFICIAL-tier workloads.
• EU — one-stop-shop nominates a lead SA based on the controller's main establishment; EDPB guidance and opinions carry near-binding interpretive weight; same evidence pack discharges NIS2 and the EU AI Act in part.
• US transfers — Schrems II transfer-impact assessment, SCCs / BCRs / DPF, and supplementary measures where the assessment identifies a risk; refresh annually.
• Adequacy — UK and EEA recognise each other (review due 2027); the EU-US DPF remains in force as of June 2026 but is under live challenge.
• Cross-jurisdictional saving — appointing an EU representative under Article 27 and a UK representative under Schedule 21 of the DPA 2018 is inexpensive (typically $2,500 - $7,500 per year combined) and puts the supervisory authority's first point of contact inside the jurisdiction, materially de-risking the early enforcement conversation.

Common implementation gaps#

Article 32 fines are remarkably consistent in their pattern. The ICO's enforcement decisions over the last several years cluster around the same operational failures, and EU supervisory authorities follow the same pattern. The gaps below are the failure modes regulators have actually fined on, framed as the residual risks a Data Protection Officer should treat as the first targets of remediation. None is novel. All are tractable. Most cost meaningfully more to defend in an enforcement conversation than to close in advance.

The single largest fine pattern in ICO enforcement decisions is the combination of missed 72-hour notification and weak audit logging — they amplify each other. A breach detected late, with no audit trail to scope it, looks negligent and is treated as such. Investing in continuous audit-stream alerting and a rehearsed Article 33 notification playbook is the cheapest reputational insurance an Article 32 controller can buy. The other recurring failure pattern is the sub-processor surprise: a controller discovers, at the worst possible moment, a vendor in the processor's stack they had not authorised. A machine-readable sub-processor register with a 30-day notice window and an objection email closes this in a single afternoon's work.

Encryption-key custody disputes — where a controller cannot prove who held the keys at the moment data leaked — sit close behind. Customer-managed keys in the controller's own KMS, with a documented grant policy and IAM roles that never cross organisational boundaries, are the operative defence. Unencrypted backup vaults and stale TLS ciphers (TLS 1.0 / 1.1, weak suites) are the embarrassingly simple gaps that nonetheless dominate the technical-control side of ICO enforcement narratives. Continuous configuration scanning (AWS Config, Azure Policy, GCP Security Command Center, or an equivalent) catches both.

On the legal and process side, the recurring gaps are absent DPIAs for high-risk processing, missing Article 30 records of processing activities, missing joint-controller allocations under Article 26, and pseudonymisation key reuse across training-set shards. Each is a paper artefact rather than a technical control, and each is consistently named in supervisory-authority decisions.

• Audit-log gaps — Article 32(1)(b), 32(4) — enable cluster API audit and cloud control-plane audit; ship to immutable object-lock storage; alert on gaps above five minutes.
• MFA enforcement gaps on privileged accounts — Article 32(4) — enforce MFA at the OIDC provider; scan periodically for accounts without an MFA factor; revoke immediately.
• Undeclared sub-processors — Article 28(2), 32(1) chapeau — publish a machine-readable sub-processor register; notify controllers thirty days in advance; honour the controller-objection window.
• Missed 72-hour notification — Article 33 — establish 24/7 incident-response on-call; document the moment of awareness; pre-prepare and rehearse the ICO / lead-SA notification template.
• Encryption-key custody disputes — Article 32(1)(a) — use customer-managed keys in the controller's own KMS; document the grant policy; never share IAM roles that decrypt across organisational boundaries.
• Missing DPIA for high-risk processing — Articles 32(2), 35 — maintain a DPIA register; trigger a DPIA whenever Article 35(3) factors apply (large-scale special-category data, systematic monitoring of public spaces, automated decisions with legal effect).
• Unencrypted backup vaults — Article 32(1)(a), 32(1)(c) — apply default encryption to backup vaults; scan continuously; remediate or destroy non-conformant artefacts.
• Stale TLS ciphers — Article 32(1)(a) — enforce TLS 1.2+ at the ingress controller; run a daily external probe; alert on any score below A.
• Absent joint-controller allocation — Article 26 — sign a joint-controller agreement; publish its essence to data subjects; allocate the duty to respond to subject-access requests.
• Pseudonymisation key reuse — Article 32(1)(a) — per-shard salt; destroy salt after pseudonymisation where re-identification is not needed; record the method in a signed training-set manifest.

Cost of compliance#

Article 32 controls cost money. The bulk of the cost lives in three places: KMS key operations, audit-log storage at long retention, and the Cyber Essentials / ISO 27001 audit cycle. The table below is a 2026 USD spread of the running cost of the technical Article 32 controls for a representative 10 TB personal-data estate on a managed cloud, plus the equivalent FOCUS-spec billing line items so finance can reconcile them against the cloud invoice. The figures are typical market ranges, not Yobitel-internal numbers; they are presented so that controllers absorbing some of the compliance burden can budget realistically.

• Total technical-control running cost for a 10 TB personal-data estate sits around $7,000-$15,000/yr; the audit + pen-test cost dominates at $40,000-$110,000/yr; engineering FTE dominates at scale.
• FOCUS-spec billing data lets finance map each Article 32 control to a chargeback unit; this is the practical answer to the perennial 'what does compliance cost?' board question.
• Audit fees scale with the number of in-scope systems, not headcount; a small team with sprawling SaaS is often more expensive to audit than a larger team with a consolidated stack.
• Year-1 carries one-off DPIA, control implementation, training rollout and the first audit; steady-state runs at roughly 60-70% of year-1 in most profiles.
• Yobitel's managed Article 32 surface charges through the workspace subscription only; the controls are pre-evidenced, the audit pack is shipped, and finance sees a single subscription line on the FOCUS export.

Where Yobitel fits#

Yobitel sits at the platform end of the Article 32 evidence chain. Customers consuming Yobitel managed services — Omniscient Compute, Yobibyte, InferenceBench, MediQuery — inherit a pre-evidenced control set for the platform layer of Article 32(1)(a)-(d): customer-managed keys, mTLS between services, policy-driven scheduling, audit streams customers can subscribe to from their own SIEM, tested cross-region resilience drills, and a sub-processor register published with a 30-day notice cycle. The artefacts are mapped to Article 32 clause-by-clause in the workspace welcome pack so a controller's DPO can drop them straight into a DPIA appendix.

Sovereignty-pinned workspaces — Sovereign UK (London + Manchester), Sovereign EU (Frankfurt + Paris), Sovereign US (FedRAMP-equivalent regions) — keep personal data inside the chosen jurisdiction by default. Yobitel UK Sovereign carries the layered UK posture customers consume alongside Article 32: NCSC Cloud Security Principles alignment for OFFICIAL-tier data, UK GDPR + DPA 2018 ROPA templates, and DSP Toolkit alignment for NHS-vertical workloads. Spend caps, region pins and OIDC bindings are configured by the customer through the workspace; the recipe by which Yobitel implements them is the managed-service moat. What the customer sees is a workspace that enforces the policy, a billing export in FOCUS-spec USD, and an audit stream that satisfies Article 32(1)(b) and Article 33 without bespoke engineering on the customer's side.

The customer keeps the Article 32 legal duty — that does not transfer to a processor — but the operational cost of evidencing it drops materially. Yobitel publishes the platform-side ROPA, the platform-side DPIA, the sub-processor register and the audit-stream schema; the customer brings the application-side ROPA and DPIA and the application-side audit events. The result is a working Article 32 posture in days rather than the typical 6-9 months of in-house build.