NCSC Cloud Security Principles

Overview#

The NCSC Cloud Security Principles are the United Kingdom's outcome-based reference for cloud-service security. They were first published by CESG (the predecessor of NCSC) in 2014, transferred to NCSC at its founding in 2016, and last materially refreshed in 2023 to reflect changes in tenant-isolation expectations, supply-chain mapping, and audit availability. The principles do not prescribe specific technologies. They describe security outcomes that any cloud service must demonstrably achieve, and they are agnostic to deployment model (IaaS, PaaS, SaaS) and to the cloud's operational geography.

Their importance is operational rather than statutory. There is no Act of Parliament that names them and no single accreditation body that issues an NCSC certification. They earn their weight by being the security layer that sits underneath the procurement frameworks UK buyers actually use: the G-Cloud framework (RM1557.x) operated by the Crown Commercial Service, the Government Security Classifications policy that governs OFFICIAL data, the NHS Data Security and Protection Toolkit (DSP Toolkit), and the FCA's SYSC 8 outsourcing rules for regulated firms. Each of those frameworks asks suppliers, in one form or another, 'how do you meet the NCSC Cloud Security Principles?'

The principles also matter because of their alignment with frameworks UK suppliers will already be implementing for international markets. NCSC explicitly designed the 2023 refresh to overlap with ISO 27001 + 27017 + 27018, with the NIST Cybersecurity Framework 2.0, with SOC 2 Type II Trust Service Criteria, and with the ENISA-led EUCS scheme. A supplier holding ISO 27001 with cloud overlays plus a SOC 2 Type II report covering common Trust Service Criteria can usually evidence twelve of the fourteen principles without a separate audit programme; the remaining two (typically principles 2 and 13 — data location and customer-readable audit) require service-specific evidence.

Yobitel UK Sovereign and the broader Yobitel platform hold the NCSC Cloud Security Principles as part of the customer-facing compliance posture — UK region pinning, BPSS/SC-cleared SRE rota, customer-readable `audit.k8s.io/v1` streams, and a published sub-processor register on a 30-day notice cycle — so customers building on Yobitel inherit those controls as a baseline rather than starting the evidence chain from scratch.

This entry treats the principles as a working reference. The Reference table enumerates each principle, its required outcome, the evidence buyers expect, and the upstream frameworks it maps to. The workload patterns show how the principles are operationalised against three concrete scenarios on Yobibyte and Yobitel Sovereign UK. The cost and limits sections are honest about what evidencing the principles requires in engineering time and what they explicitly do not cover. This entry helps you assemble defensible NCSC Cloud Security Principles evidence for your customers, auditors, or supervisory authorities — and explains where Yobitel's own posture inherits, so you can decide which principles to evidence yourself and which to absorb from the platform underneath.

Quick start#

There is no NCSC-issued certification. Compliance is established by self-assessment against the 14 principles, evidenced by independent audit artefacts, and presented to a buyer at procurement. NCSC publishes a self-assessment template at https://www.ncsc.gov.uk/collection/cloud/the-cloud-security-principles — start there. The two operational pieces every buyer will exercise on day one are (a) the principle-by-principle evidence pack and (b) a live audit stream into the buyer's SIEM (principle 13). The commands below stand up both against a Kubernetes cluster running on a UK region, using only open-source primitives.

Step 1 — fetch the NCSC self-assessment template and start filling it in. Step 2 — enable Kubernetes API audit logging so the cluster emits the events a buyer will want to see. Step 3 — install Falco for runtime security alerting (principle 5 / principle 13 coverage of the data plane). Step 4 — turn on AWS CloudTrail (or the equivalent control-plane audit on the cloud you are running on) with an immutable, KMS-encrypted S3 sink.

# 1. Download the NCSC self-assessment template (PDF + machine-readable annex)
curl -L -o ncsc-cloud-security-principles.pdf \
  https://www.ncsc.gov.uk/collection/cloud/the-cloud-security-principles

# 2. Enable Kubernetes API-server audit logging (principle 13, control plane)
sudo mkdir -p /etc/kubernetes/audit
sudo tee /etc/kubernetes/audit/policy.yaml > /dev/null <<'EOF'
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages: ["RequestReceived"]
rules:
  # Principle 9 / 10 - record all auth and RBAC changes at Metadata level
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps", "serviceaccounts"]
      - group: "rbac.authorization.k8s.io"
        resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]
  # Principle 3 - record namespace and networkpolicy mutations in full
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: ""
        resources: ["namespaces"]
      - group: "networking.k8s.io"
        resources: ["networkpolicies"]
  # Everything else - Metadata only
  - level: Metadata
EOF

# Reference the policy from /etc/kubernetes/manifests/kube-apiserver.yaml:
#   --audit-policy-file=/etc/kubernetes/audit/policy.yaml
#   --audit-log-path=/var/log/kubernetes/audit.log
#   --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100

# 3. Install Falco for runtime detection (principle 5, principle 13 data plane)
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco --namespace falco --create-namespace \
  --set tty=true --set falcosidekick.enabled=true \
  --set falcosidekick.config.elasticsearch.hostport=https://siem.example.gov.uk:9200

# 4. AWS CloudTrail - immutable, KMS-encrypted, multi-region trail
aws kms create-key --description "ncsc-p13-audit-trail" \
  --region eu-west-2 --query KeyMetadata.Arn --output text
aws s3api create-bucket --bucket ncsc-audit-eu-west-2 --region eu-west-2 \
  --create-bucket-configuration LocationConstraint=eu-west-2
aws s3api put-object-lock-configuration --bucket ncsc-audit-eu-west-2 \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Years":7}}}'
aws cloudtrail create-trail --name ncsc-trail \
  --s3-bucket-name ncsc-audit-eu-west-2 \
  --kms-key-id alias/ncsc-p13-audit-trail \
  --is-multi-region-trail --enable-log-file-validation \
  --region eu-west-2
aws cloudtrail start-logging --name ncsc-trail --region eu-west-2

# 5. Inspect what an NCSC posture review will read - the control plane trail
aws cloudtrail describe-trails --region eu-west-2 \
  --query 'trailList[?HomeRegion==`eu-west-2`].[Name,S3BucketName,KmsKeyId,IsMultiRegionTrail,LogFileValidationEnabled]' \
  --output table

# 6. Confirm the cluster API server is region-pinned (principle 2)
kubectl get nodes -o jsonpath='{.items[*].metadata.labels.topology\.kubernetes\.io/region}'
# Expected: eu-west-2 eu-west-2 eu-west-2 ...

How it works#

Compliance with the NCSC principles is established through a chain of artefacts that runs from contract to control to audit. The chain has four links that buyers exercise in this order during a procurement.

First, the supplier publishes a service-definition document that states which principles are met, where the supplier's responsibility ends, and where the customer's begins. This is the 'shared responsibility' contract codified in principle 14. The 2023 refresh sharpened the expectation here: the service definition must enumerate principle-by-principle which party is responsible, and a vague claim of 'meets all principles' is no longer accepted on its own.

Second, the supplier maps each principle to a control catalogue. Most UK suppliers map to ISO 27001:2022 Annex A as the primary control surface because it provides 93 named controls organised across organisational, people, physical, and technological themes. ISO 27017 adds 37 cloud-specific controls; ISO 27018 adds personal-data-in-the-cloud overlays. The mapping is what a buyer's security team will dissect — they will reject a service that maps principle 3 to an ISO control about 'asset inventory' rather than a tenant-isolation control.

Third, the controls are evidenced by independent audit. A current ISO 27001 certificate from a UKAS-accredited body covers governance and most operational principles; a SOC 2 Type II report (audit-period evidence rather than point-in-time) covers separation, change management, monitoring and incident response; Cyber Essentials Plus covers a narrow but mandatory perimeter/IAM slice; an annual external penetration test against the service edge covers principle 11. Mature suppliers also publish a 'shared responsibility matrix' that names the customer controls on which the supplier's evidence depends.

Fourth, the supplier provides live, customer-readable evidence at runtime — principle 13. This is the most operationally demanding requirement. Buyers expect the ability to stream their own audit events (control-plane and data-plane) into their own SIEM, retain them per the buyer's policy, and use them to investigate incidents independently. A supplier that only offers a quarterly PDF log export will fail principle 13 for any serious workload.

Reference — the 14 principles#

Each row below states the principle, the outcome NCSC requires, the evidence types buyers commonly accept, and the upstream framework controls that map to it. The control identifiers are the most-cited mappings under ISO 27001:2022 Annex A and SOC 2 TSC 2017 — they are not exhaustive but they are the controls a buyer's security team will read first.

Workload pattern A — OFFICIAL workload on a UK-resident Kubernetes cluster#

The principles are operational, not theoretical. Pattern A is the default posture for the bulk of UK government and regulated workloads. Region pinning is enforced by node affinity at the pod level and by an admission policy at the cluster level; an attempt to schedule outside the declared UK region is rejected by the scheduler. The Deployment below runs a small inference workload backed by vLLM. Each field materialises evidence against a specific principle: nodeAffinity for principle 2 (geographic pinning), the NetworkPolicy for principle 3 (separation) and principle 11 (external interface protection), the ServiceAccount + RoleBinding for principle 9 (secure user management), and the volumeMounts for principle 1 (TLS termination).

# pattern-a-official.yaml — OFFICIAL workload, UK-region-pinned
---
apiVersion: v1
kind: Namespace
metadata:
  name: hmrc-pilot
  labels:
    classification: OFFICIAL
    pod-security.kubernetes.io/enforce: restricted   # P3
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hmrc-classifier
  namespace: hmrc-pilot
spec:
  replicas: 2
  selector:
    matchLabels: { app: hmrc-classifier }
  template:
    metadata:
      labels: { app: hmrc-classifier }
    spec:
      serviceAccountName: hmrc-classifier            # P9
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:                    # P2 - geographic pinning
                  - key: topology.kubernetes.io/region
                    operator: In
                    values: ["eu-west-2"]            # London
                  - key: nvidia.com/gpu.product
                    operator: In
                    values: ["NVIDIA-H100-80GB-HBM3"]
      containers:
        - name: vllm
          image: vllm/vllm-openai:v0.6.3
          args:
            - "--model=meta-llama/Llama-3.3-70B-Instruct"
            - "--tensor-parallel-size=2"
            - "--ssl-keyfile=/tls/tls.key"           # P1
            - "--ssl-certfile=/tls/tls.crt"
          resources:
            limits:
              nvidia.com/gpu: "2"                    # MIG or whole; P3
          volumeMounts:
            - name: tls
              mountPath: /tls
              readOnly: true
      volumes:
        - name: tls
          secret:
            secretName: hmrc-classifier-tls          # cert-manager managed
---
# P3 / P11 - default-deny + explicit allow only to declared egress targets
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: hmrc-classifier-egress
  namespace: hmrc-pilot
spec:
  podSelector:
    matchLabels: { app: hmrc-classifier }
  policyTypes: ["Ingress", "Egress"]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels: { name: api-gateway }
      ports: [{ protocol: TCP, port: 8000 }]
  egress:
    - to:
        - ipBlock: { cidr: 10.42.0.0/16 }            # in-VPC only
      ports: [{ protocol: TCP, port: 443 }]

Workload pattern B — OFFICIAL-SENSITIVE NHS imaging#

Pattern B raises the bar on principles 3, 6 and 13. Tenant isolation moves from a shared multi-tenant pool to a dedicated NHS-only node pool, pinned with taints + tolerations so no other workload can land on those nodes. RBAC is tightened to a named NHS-SRE group. Audit streaming gates principle 13: the cluster's API audit log is shipped via Vector / Fluent Bit to an NHS-controlled Kafka sink. NHS DSP Toolkit obligations layer on top of the same manifest — 7-year retention is enforced at the S3 / object-lock level, HSCN-routed ingress is enforced by NetworkPolicy and a private endpoint.

# pattern-b-nhs.yaml — OFFICIAL-SENSITIVE NHS imaging
---
apiVersion: v1
kind: Namespace
metadata:
  name: nhs-acute-imaging
  labels:
    classification: OFFICIAL-SENSITIVE
    dsp-toolkit: required
    pod-security.kubernetes.io/enforce: restricted
---
# P3 / P6 - dedicated node pool, NHS workloads only
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nhs-acute-imaging
  namespace: nhs-acute-imaging
spec:
  serviceName: nhs-acute-imaging
  replicas: 4
  selector:
    matchLabels: { app: nhs-acute-imaging }
  template:
    metadata:
      labels: { app: nhs-acute-imaging }
    spec:
      serviceAccountName: nhs-acute-imaging-sa
      tolerations:                                   # P3 - taint-based isolation
        - key: workload-class
          operator: Equal
          value: nhs-sensitive
          effect: NoSchedule
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: topology.kubernetes.io/region
                    operator: In
                    values: ["eu-west-2"]            # P2 - UK London
                  - key: topology.kubernetes.io/zone
                    operator: In
                    values: ["eu-west-2a", "eu-west-2b"]   # P2 - multi-AZ
                  - key: workload-class
                    operator: In
                    values: ["nhs-sensitive"]       # dedicated pool
      containers:
        - name: triton
          image: nvcr.io/nvidia/tritonserver:24.05-py3
          resources:
            limits:
              nvidia.com/gpu: "1"                    # whole H100 per pod
---
# P9 / P10 - RBAC restricted to SC-cleared NHS SRE group
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: nhs-sre-access
  namespace: nhs-acute-imaging
subjects:
  - kind: Group
    name: nhs-sre-sc-cleared        # mapped from OIDC IdP
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io
---
# P3 / P11 - HSCN-only ingress, deny-all egress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: nhs-imaging-isolation
  namespace: nhs-acute-imaging
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]
  ingress:
    - from:
        - ipBlock:
            cidr: 10.180.0.0/16                      # HSCN allocated range
      ports: [{ protocol: TCP, port: 8000 }]
  egress: []                                          # deny-all

Workload pattern C — Cross-border with declared sub-processors#

Pattern C is the structurally hardest. Data starts in the UK but must be processed in an EU region for an export-control reason. Principle 2 (location) and principle 8 (supply chain) carry the load. The OPA Gatekeeper constraint below refuses to admit any pod whose nodeAffinity declares a region outside the agreed UK / EU set; the Kyverno policy enforces that every workspace namespace carries the legal-basis label that documents the Schrems II transfer mechanism. The customer-managed KMS key is held in AWS KMS with a key policy that pins the key material to the UK region — egress to the EU happens only after encrypt-decrypt with a UK-resident key, satisfying the 'supplementary measures' bar.

# pattern-c-crossborder.yaml — UK / EU only, declared sub-processors
---
# P2 - Gatekeeper constraint: reject any pod targeting a region outside the allow list
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRegions
metadata:
  name: pharma-allowed-regions
spec:
  match:
    namespaces: ["pharma-r-and-d"]
  parameters:
    allowedRegions: ["eu-west-2", "eu-central-1"]    # London + Frankfurt
---
# P8 - Kyverno policy: every namespace must declare its transfer legal basis label
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-transfer-legal-basis
spec:
  validationFailureAction: Enforce
  rules:
    - name: namespace-must-declare-scc
      match:
        any:
          - resources: { kinds: ["Namespace"] }
      validate:
        message: "Cross-border workspaces must declare gdpr.transfer-mechanism."
        pattern:
          metadata:
            labels:
              gdpr.transfer-mechanism: "scc-2021-914-modules-2-3 | iso-cert | uk-international-data-transfer-agreement"
              gdpr.tia: "?*"                          # path to TIA artefact
---
# The workspace itself, labelled to satisfy the policy above
apiVersion: v1
kind: Namespace
metadata:
  name: pharma-r-and-d
  labels:
    classification: OFFICIAL
    gdpr.transfer-mechanism: "scc-2021-914-modules-2-3"
    gdpr.tia: "s3://pharma-evidence/tia/pharma-2026Q2.pdf"
    sub-processors: "aws-uk,aws-de"                 # P8 - register reference
---
# P2 - encryption keys pinned to the UK region; EU compute decrypts via cross-region grant
apiVersion: v1
kind: Secret
metadata:
  name: kms-key-ref
  namespace: pharma-r-and-d
type: Opaque
stringData:
  kmsKeyArn: "arn:aws:kms:eu-west-2:111122223333:key/abcd-uk-only"
  keyResidency: "uk-only"

Evidence requirements by tier#

The principles apply across all OFFICIAL workloads, but the depth of evidence expected scales with sensitivity. The table below summarises the artefacts a buyer's procurement and security teams will typically request at each tier. SECRET and above are out of scope of the principles; see the Limits section.

What the principles do not cover#

The principles are deliberately bounded. They are the baseline for OFFICIAL-tier UK government and regulated work and should not be treated as a universal compliance lattice. The following regimes sit outside the principles and require their own assurance routes.

Observability and audit (principle 13)#

Principle 13 is the principle most often failed by suppliers who pass the others. The 2023 refresh made the customer-readability expectation explicit: it is not enough to keep audit logs internally and produce them on request. Customers must be able to stream their own audit events to their own SIEM, in a documented schema, on a continuous basis, with cryptographic integrity that the customer can independently verify.

The schema below is the standard Kubernetes API-server audit event — it is the event type your kube-apiserver emits when the audit policy from the Quick start is in place. CloudTrail emits an analogous control-plane event on AWS, with KMS-signed digest files providing the integrity guarantee that principle 13 requires. Stream both into the customer's SIEM (Splunk, Elastic, Chronicle, Sentinel) via Vector, Fluent Bit or the cloud-native shipper.

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "01HXYZ7QK3R5V9M2N8P4D6F1A0",
  "stage": "ResponseComplete",
  "requestURI": "/apis/apps/v1/namespaces/nhs-acute-imaging/deployments/nhs-acute-imaging/scale",
  "verb": "patch",
  "user": {
    "username": "alice.example@nhs.net",
    "groups": ["nhs-sre-sc-cleared", "system:authenticated"],
    "extra": {
      "authentication.kubernetes.io/credential-id": ["fido2:cred_01HXYZ7B5"]
    }
  },
  "sourceIPs": ["10.42.0.17"],
  "userAgent": "kubectl/v1.31.0",
  "objectRef": {
    "resource": "deployments",
    "namespace": "nhs-acute-imaging",
    "name": "nhs-acute-imaging",
    "apiGroup": "apps",
    "apiVersion": "v1",
    "subresource": "scale"
  },
  "responseStatus": { "code": 200 },
  "requestObject": {
    "kind": "Scale",
    "apiVersion": "autoscaling/v1",
    "spec": { "replicas": 8 }
  },
  "responseObject": {
    "kind": "Scale",
    "spec": { "replicas": 8 },
    "status": { "replicas": 4 }
  },
  "requestReceivedTimestamp": "2026-06-13T09:14:22.118Z",
  "stageTimestamp": "2026-06-13T09:14:22.142Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by RoleBinding 'nhs-sre-access/nhs-acute-imaging'"
  }
}

Cost of compliance#

Compliance with the principles is not free. The cost is dominated by engineering effort to design and operate the controls, then by external audit fees, then by a smaller compliance-team overhead. The figures below are typical UK market ranges for a mid-sized cloud supplier serving public sector and regulated buyers. They are not Yobitel-internal numbers; they are presented so that customers building on Yobitel and absorbing some of the compliance burden can budget realistically — Yobitel-supplied evidence (audit-stream config, sub-processor list, sovereignty pinning, ISO 27001 + 27017 + 27018 certificate, BPSS/SC personnel records) carries most of principles 1, 2, 3, 5, 6, 8, 12 and 13 on the customer's behalf, leaving the application-side evidence to the customer.

Security and compliance — implementation cookbook#

This section is a principle-by-principle implementation register. For each principle it states the controls Yobitel ships by default, the controls that are customer-configurable, and the gap that remains with the customer regardless of platform configuration. It is intended to be paste-able into a G-Cloud security questionnaire or a buyer-side third-party risk assessment.

• P1 Data in transit — Yobitel: TLS 1.3 on all external endpoints, TLS 1.2 minimum, HSTS, automated cert rotation via internal ACME; mTLS on all service-to-service inside the platform. Customer: enforces TLS on egress callouts from inside the workload.
• P2 Asset protection and resilience — Yobitel: UK regions pinned, datacentre tier-3 minimum, geographic-pinning policy enforced at the API, multi-AZ resilience with documented RPO 15min / RTO 2h, annual DR test. Customer: configures replication for application state.
• P3 Separation between customers — Yobitel: tenant isolation across compute (KVM + cgroups v2), GPU (MIG partitions or whole-device dedicated tenancy), network (VPC + SR-IOV), storage (encrypted per-tenant volumes), control plane (per-tenant namespaces with admission webhooks). Customer: enforces in-VPC segmentation.
• P4 Governance — Yobitel: ISMS scope statement published, named CISO, board-level risk committee, ISO 27001 certificate from UKAS-accredited body, internal audit on 12-month cycle. Customer: maintains own ISMS for the workload.
• P5 Operational security — Yobitel: continuous CVE scanning (Trivy / Grype), 14-day patch SLA on critical CVEs, configuration-as-code via Terraform with mandatory PR review, change-management workflow with named approvers, on-call rota with 24x7 incident response. Customer: own workload patching.
• P6 Personnel security — Yobitel: BPSS baseline on all SREs, SC clearance available on customer request and standard for NHS / MoD workspaces, mandatory security training on hire and annually, role-based access reviewed quarterly. Customer: own personnel vetting for in-workload admins.
• P7 Secure development — Yobitel: signed-commit policy, SAST (Semgrep) + DAST (ZAP) in CI, dependency scanning (Snyk / Dependabot), SBOM published per release in SPDX format, code review required from two reviewers on platform code. Customer: own SDLC for application code.
• P8 Supply chain — Yobitel: published sub-processor register, 30-day change notice, vendor due diligence on all sub-processors, SBOM publication. Customer: assesses Yobitel as their own sub-processor.
• P9 Secure user management — Yobitel: RBAC + ABAC across control plane, OIDC / SAML federation to customer IdP, JIT elevation, mandatory MFA on admin paths, session timeout policy, break-glass procedure with audit trail. Customer: federates own IdP and manages user lifecycle.
• P10 Identity and authentication — Yobitel: OIDC / SAML, FIDO2 / WebAuthn support, MFA enforcement on admin paths, AAL2 minimum on user paths, AAL3 available, session-fixation protections. Customer: enforces MFA policy.
• P11 External interface protection — Yobitel: WAF + rate-limiting on all public endpoints, annual external pentest, CE+ certificate, CVE response SLA of 24 hours for actively exploited issues, abuse-reporting channel. Customer: minimises external surface.
• P12 Secure service administration — Yobitel: PAW workstations for all SREs, just-in-time elevation, all admin sessions recorded and reviewed, separation of duties between operations and audit. Customer: not applicable (provider-side principle).
• P13 Audit information and alerting — Yobitel: customer-readable audit-event schema (Kubernetes `audit.k8s.io/v1` for the cluster control plane, CloudTrail format for the cloud control plane), continuous streaming to customer-chosen sink (S3, Kafka, HTTPS webhook), KMS-signed digest files and S3 Object Lock for tamper-evident integrity, retention configurable from 90 days to 10 years, immutable storage option. Customer: streams to own SIEM and runs detection rules.
• P14 Secure use of the service — Yobitel: published shared-responsibility matrix, secure-baseline configuration guide per service, CIS-aligned hardening notes, documented operational runbooks. Customer: follows the documented baseline.

Migration and alternatives#

The most common migration paths into an NCSC-compliant posture come from three starting points: a FedRAMP-only stance (the cloud is already authorised in the US but has not been tested against UK requirements), an ISO 27001-only stance (the cloud has the management system but no cloud-specific evidence), and a no-formal-baseline stance (the cloud has good security in practice but no audit chain). The table below maps the three.

Mapping between frameworks is the practical day-one work. The Reference table above includes the most common ISO 27001:2022 Annex A and SOC 2 TSC 2017 control identifiers, but a fuller mapping shows the principles do not stand alone — they are an outcome-based articulation of controls that already exist in upstream standards. The incumbent commands below produce inputs to the evidence chain a buyer's security team would inspect on a hyperscaler today.

# Today's incumbent commands a buyer's security team might use to
# inspect an equivalent posture on a hyperscaler. These do not satisfy
# NCSC principles on their own - they produce inputs to the evidence chain.

# AWS - list audit-trail configuration (input to principle 13 evidence)
aws cloudtrail describe-trails --region eu-west-2 \
  --query 'trailList[?HomeRegion==`eu-west-2`].[Name,S3BucketName,KmsKeyId,IsMultiRegionTrail]' \
  --output table

# GCP - show region pin and customer-managed key for a workload (P2, P1)
gcloud compute instances describe my-vm --zone europe-west2-a \
  --format='value(zone,disks[0].diskEncryptionKey.kmsKeyName)'

# Kubernetes - verify PodSecurity admission for tenant isolation (P3)
kubectl get namespace --selector='pod-security.kubernetes.io/enforce=restricted' \
  -o jsonpath='{.items[*].metadata.name}'

# vLLM - start a model server with TLS enforced (input to P1)
vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --ssl-keyfile /etc/tls/key.pem \
  --ssl-certfile /etc/tls/cert.pem \
  --host 0.0.0.0 --port 8443

Troubleshooting#

The errors below are the failure modes most often observed during G-Cloud assessment, NHS DSP Toolkit review and FCA SYSC 8 third-party risk assessments. Each row states the symptom, the underlying cause, and the operational fix.

Where this fits in the Yobitel stack#

The patterns above are open-source primitives — Gatekeeper, Kyverno, kube-apiserver audit, Falco, CloudTrail, NetworkPolicy, RBAC. They work today on any UK-region Kubernetes cluster. They also require an integrator who will hold the ISO 27001 / SOC 2 Type II / Cyber Essentials Plus paperwork, run the SC-cleared SRE rota, publish a sub-processor register, and operate the audit pipeline. That integrator role is what Yobitel Sovereign UK provides.

Yobitel Sovereign UK is the product line built specifically for UK public-sector and regulated buyers. It ships the Quick start cluster pre-installed with the Gatekeeper / Kyverno / Falco stack, runs the kube-apiserver audit policy on the customer's behalf, and streams the resulting `audit.k8s.io/v1` events into an immutable customer-controlled sink. Region pinning to UK London and UK Manchester is enforced by an admission policy, not a configuration flag.

Yobibyte, the self-serve AI platform, layers on top — every Yobibyte workspace is a Kubernetes namespace with the workload-pattern manifests above already applied, and the NCSC posture (classification tier, sub-processor list, encryption key residency) is surfaced as namespace labels that map directly into a G-Cloud response pack. A workspace administrator sees at a glance which principles are evidenced, by which artefact, against which buyer.

Omniscient Compute, Yobitel's federated marketplace for compute capacity, treats NCSC alignment as a filter rather than a default. Providers participating in Omniscient Compute declare NCSC-aligned status against the workspace classification they are willing to host; the marketplace surfaces only NCSC-aligned providers when a workspace is classified OFFICIAL or OFFICIAL-SENSITIVE. A buyer building on Yobibyte can absorb the NCSC evidence chain without contracting separately with the underlying provider — the marketplace contract carries the obligation through.

InferenceBench, the Yobitel benchmarking and evaluation platform, contributes principle 5 (operational security) evidence by maintaining a continuous, automated regression suite against model and infrastructure baselines. Benchmark runs are emitted into the same audit stream as control-plane events, so an incident investigation can correlate a performance regression with a configuration change in a single query against the customer's SIEM.