Professional Services · Sovereign Deployment Design
AI infrastructure designed against UK NCSC, G-Cloud and OFFICIAL first
A UK-headquartered practice that designs sovereign AI deployments for central government, regulated industry, and global enterprise. NCSC Cloud Security Principles, EU sovereign-cloud posture, and FedRAMP-equivalent baselines, mapped control-by-control to your architecture.
Representative posture
OFFICIAL-alignedUK central-gov pilot · 64×H100 cluster · NCSC-aligned
Data residency
UK only · 3 data centres
Key custody
Customer-held HSM · FIPS 140-3 Level 3
Supply chain
SBOM · signed provenance
Audit cadence
Annual external · quarterly internal
Controls mapping
Posture renders against NCSC Cloud Security Principles. Customer holds the keys. Audit evidence package versioned alongside the architecture.
Perimeters we design for
Sovereignty is a perimeter, not a posture statement
Every brief lands inside one (or more) of these perimeters. The architecture decisions, the evidence pack, and the audit cadence all flex against which one. UK public-sector engagements are where this practice was forged; the rest layer on top.
UK OFFICIAL and OFFICIAL-SENSITIVE
NCSC Cloud Security Principles 1–14 · JSP 440 awareness
The default posture we design for central-government pilots, devolved-administration projects, and arm's-length bodies that handle citizen data. Data resident in the UK, customer-held keys, signed supply chain, evidence pack ready for departmental accreditation.
UK G-Cloud lot alignment
G-Cloud Lot 2 (Cloud Software) · Lot 3 (Cloud Support)
When the buyer is a UK public-sector body and the route to market is the Digital Marketplace, the architecture has to speak the framework. We design the deployment, the service definition, and the pricing card so the listing reads cleanly.
EU sovereign cloud posture
GDPR Article 32 · NIS2 · DORA · EU AI Act high-risk
For regulated workloads that have to stay inside the EEA, with documented data flows, technical and organisational measures, incident-reporting wired into the platform, and a clean fit against the EU AI Act category your workload sits in.
FedRAMP-equivalent for global enterprise
ISO/IEC 27001:2022 · SOC 2 Type II · NIST SP 800-53 (FedRAMP Moderate)
When the customer is global and the procurement contract names a FedRAMP-equivalent posture as the baseline. We map to the NIST SP 800-53 control families behind FedRAMP and deliver the evidence package an audit committee will accept.
Financial services and operational resilience
DORA · FCA · PRA · ISO/IEC 27001:2022 · PCI DSS adjacency
For banks, insurers, and fintechs running AI inside a regulated estate. Operational-resilience evidence, third-party risk paperwork, exit plans that an auditor will actually read, and a deployment topology that holds up under a DORA tabletop.
Healthcare and defence-aware estates
HIPAA-equivalent · DCB0129/0160 · ITAR-aware
Patient data, clinical decision-support tooling, and defence-aware workloads with export-control sensitivity. Personnel-clearance posture, hardware-provenance evidence, and a cross-domain pattern when the workload has to bridge classification boundaries.
What sovereignty changes
The architecture decisions a sovereign workload moves the needle on
A sovereign deployment is not a stack of compliance documents bolted onto a default cloud build. It is a different set of architecture decisions, taken deliberately, with the evidence to back each one.
Data residency boundary
Default posture
Region-of-choice with implicit egress
Sovereign posture
Country-locked with documented flows
On a default cloud build, the data sits where the cheapest region is and the egress paths are inherited from the provider. A sovereign design pins residency to a named country (or jurisdiction), documents every byte that crosses a boundary, and proves it to an auditor.
Cryptographic key custody
Default posture
Provider-managed KMS
Sovereign posture
Customer-held HSM · BYOK / HYOK
The default is fine for most workloads and unacceptable for sovereign ones. Customer-held HSMs (FIPS 140-3 Level 3 and up), bring-your-own-key or hold-your-own-key patterns, with key-rotation runbooks and a tested recovery story.
Supply-chain provenance
Default posture
Container images pulled at runtime
Sovereign posture
SBOM + signed provenance per artefact
Every binary that lands on a sovereign cluster needs a software bill of materials, a signed provenance attestation, and a verifier in the admission path. The supply-chain attack surface is the one that catches accreditation reviews out.
Air-gap and cross-domain pattern
Default posture
Public-internet egress, allow-listed
Sovereign posture
Air-gap or cross-domain bridge
Some workloads require a full air-gap. Others tolerate a cross-domain solution with controlled one-way data movement. We design the network posture against the classification, not against developer convenience.
Audit and attestation cadence
Default posture
Annual SOC 2 refresh
Sovereign posture
Continuous evidence + scheduled audit
Sovereign workloads operate inside a calendar of audit events. We instrument the platform to produce evidence continuously, version it next to the architecture, and stage it for the next external review without a sprint of scrambling.
Personnel and clearance posture
Default posture
Standard background check
Sovereign posture
Cleared-personnel access matrix
Who can touch the cluster, with what clearance, under what break-glass. We design the personnel matrix as part of the architecture, not as a paperwork exercise bolted on after go-live.
Hardware provenance and secure boot
Default posture
Whatever the rack arrived with
Sovereign posture
Provenance trail + measured boot
Where the silicon came from, who handled it in transit, what firmware shipped on it, and a measured-boot chain that proves the running platform matches the design. Hardware sovereignty is the layer most designs forget.
The controls map
The frameworks your architecture maps to
UK public-sector first, EU regulated layer second, global enterprise baseline third, industry overlays last. Each layer reuses the evidence from the layer above where it can; we don't repeat work for the sake of a different framework column.
UK public sector and central government
The default reference frame for any UK public-sector engagement. We map architecture decisions to each principle, evidence-by-evidence, in the design pack.
Frameworks
- NCSC Cloud Security Principles 1–14
- G-Cloud framework alignment
- UK OFFICIAL · OFFICIAL-SENSITIVE
EU regulated workloads
When the residency boundary is the EEA and the workload sits inside a regulated industry. The deployment design has to satisfy multiple directives in parallel; we sequence the evidence so they reuse each other.
Frameworks
- GDPR Article 32 (technical and organisational measures)
- NIS2 directive
- DORA (operational resilience for financial entities)
- EU AI Act high-risk category
Global enterprise baseline
The audit-committee baseline that most global procurement contracts name. Controls map produced as a working document, not a one-off slide.
Frameworks
- ISO/IEC 27001:2022 (Annex A themes A.5–A.8: organizational, people, physical, technological)
- SOC 2 Type II (Trust Services Criteria)
- FedRAMP Moderate (NIST SP 800-53 mapping)
Industry-vertical overlays
Layered on top of the base framework when the vertical demands it. The overlay is specific; we don't make you read a generic compliance template that doesn't speak your regulator's language.
Frameworks
- HIPAA-equivalent (healthcare)
- DCB0129 / DCB0160 (clinical safety)
- FCA / PRA (UK financial services)
- PCI DSS (payments-adjacent)
- ITAR-awareness (export-controlled)
Your handover pack
What lands when the design is signed off
A sovereign engagement closes with a document set your accreditor and your platform team can both work from. Versioned in your repo. Updated alongside the architecture so the evidence never falls out of date.
If you take the deployment forward on your own, these are the manual. If our managed-operations team carries the platform into day-two, the same artefacts back the SLA.
Sovereignty design document
The architecture, the perimeter, the assumptions, and the trade-offs. Written so an accreditor and a platform engineer can both read it without translation.
Controls mapping matrix
Every architecture decision pinned to the framework controls it satisfies. NCSC principles, ISO/IEC 27001:2022 Annex A controls, SOC 2 Trust Services Criteria, GDPR Article 32 measures. One document, multiple framework columns.
Data residency map
Where every data class lives, where it can move, and what crosses a boundary under what authority. The map an auditor opens first.
Key custody and crypto runbook
HSM topology, key hierarchy, rotation cadence, break-glass procedure, recovery test plan. Reviewed against the customer's existing PKI before sign-off.
Audit evidence package
Pre-staged evidence for the next external audit cycle. Versioned alongside the architecture. Updated automatically as the platform changes.
Attestation cadence schedule
Annual external, quarterly internal, continuous platform telemetry. A 12-month calendar of audit events with the owner named for each.
Personnel and clearance matrix
Who can do what to the platform, at which clearance level, with which break-glass approval. The matrix sits alongside the IAM design so they cannot drift.
How we engage
Pick the shape that fits your accreditation calendar
From end-to-end design through audit-readiness, to a paired engagement with your CISO, to a focused review of an existing design. The scope call confirms which fits; the statement of work names the deliverables.
Yobitel-led
We own architecture through audit-readiness
Sovereignty design, controls mapping, residency posture, key-custody runbooks, evidence pack, and a dry-run audit. We hand the estate over when it can pass an external review on its own merits.
Pair-architecture
With your CISO and compliance team
Joint design sessions with your security and compliance leads. We bring the AI-infrastructure pattern library; you bring the regulator relationship and the institutional context. Our sovereignty practice lead signs off the design alongside your CISO.
Advisory review
Of an existing design
Time-boxed review of a sovereign design your team has already drafted. We identify gaps against the framework, suggest a tight set of changes, and deliver a written report your accreditor will accept as part of the evidence trail.
Related
AI infrastructure architecture
The reference architecture that sits under the sovereign perimeter. Compute, fabric, storage, and platform decisions that the sovereignty design then constrains.
Related
Platform layer for AI GPU clouds
The bare-metal, VM, and container platform underneath the workload. The layer the sovereignty controls land on once the design clears accreditation.
Tell us which sovereignty perimeter you are designing into.
A short questionnaire covers the perimeter, the residency posture, the classification level, and the engagement model. Our sovereignty practice lead replies inside one working day with a fitted design approach and the controls map you can take to your accreditor.
UK-headquartered practice, leading with NCSC and G-Cloud alignment. Evidence packs versioned alongside the architecture. Same engineering bench that designs the infrastructure and the platform layer below it. Optional 24/7 day-two handover available.