ISO 27017:2026 When You Are Both Cloud Customer and Provider

Every hyperscaler publishes a shared-responsibility page doing two jobs: saying where its obligations stop, and where yours start. Retire the hyperscaler, run the cluster yourself, and the second job does not go away. It stops having an author.

The Edition Most 27017 Guidance Describes Was Replaced in July 2026

IEC's catalogue record for ISO/IEC 27017 lists edition 2.0, publication date 2026-07-27, 39 pages. Its abstract says the document gives both "additional guidance for relevant controls specified in ISO/IEC 27002:2022" and "additional controls with guidance that specifically relate to cloud services", for "cloud service customers (CSCs) and cloud service providers (CSPs)".

The foreword is blunter: "This second edition cancels and replaces the first edition (ISO/IEC 27017:2015 | Rec. ITU-T X.1631:2015), which has been technically revised." Its listed changes — "the title and the scope have been modified"; the controls now presented "using a simple taxonomy and associated attributes"; and "some controls have been merged, some have been removed and several new controls have been introduced."

That last clause invalidates most of what a search returns. The 2015 document was a first edition dated 2015-12-15, titled a "Code of practice for information security controls based on ISO/IEC 27002 for cloud services", taking ISO/IEC 27002:2013 as its additional normative reference and carrying its cloud additions in an annex titled "Cloud service extended control set". The 2026 document points instead at 5.38, 5.39, 8.35 and 8.36 for material "specific to cloud services", and repurposes Annex A: it "provides the mappings between the set of controls of this document and the previous edition".

A second date needs keeping straight. 27017 is dual-published, prepared by ISO/IEC JTC 1/SC 27 "in collaboration with ITU-T (as Rec. ITU-T X.1631)". On the ITU side, X.1631 (07/15) is Superseded and X.1631 (12/25) the in-force component. That 12/2025 stamp is the twin's own, not the ISO publication date.

Both Roles, One Organisation: What the Vocabulary Actually Permits

Applying a customer/provider split inside one legal entity is usually argued by analogy: the platform team is *like* a provider. The 2026 edition makes that unnecessary, which matters because an assessor will not accept a metaphor.

Clause 2 of the 2026 edition lists exactly two normative references: "ISO/IEC 22123-1, Information technology — Cloud computing — Part 1: Vocabulary" and "ISO/IEC 27002:2022". The 22123-1 reference is undated, and the same clause states that "[f]or undated references, the latest edition … applies." Clause 3.1 adopts them: "the terms and definitions given in ISO/IEC 27002, ISO/IEC 22123-1 and the following apply." ISO/IEC 17788, cited normatively by the 2015 edition as "Recommendation ITU-T Y.3500 | ISO/IEC 17788", is no longer the book a 27017 implementer opens.

Open the current one and the dual-role case is definitional. ISO/IEC 22123-1:2023 is a second edition that "cancels and replaces ISO/IEC 17788:2014 and ISO/IEC 22123-1:2021", among whose listed changes are that "definitions for CSC role, CSP role, and CSN role were added" and that the CSC, CSP and CSN definitions "were revised to leverage" them. A party is a "natural person, legal person or a group of either, whether or not incorporated, that can assume one or more roles". A cloud service customer is a "party … acting in a cloud service customer role"; a provider, a "party … acting in a cloud service provider role". A role is a "set of activities that serves a common purpose" — using cloud services in one case, making them available in the other.

The deployment models close the loop. In 22123-1:2023 a private cloud is a model "where cloud services are used exclusively by a single cloud service customer and resources are controlled by that cloud service customer", against a public cloud where "resources are controlled by the cloud service provider" — the private cloud is *defined* as the case where customer and controller are one party. Clause 1 of the 2026 edition says so directly in a NOTE: the document "applies to all types of cloud deployment models including the private cloud", with the caveat that "adjustments can be necessary to adapt to the relationships and abilities of an organization's internal departments". The 2015 Scope clause named no deployment model.

One honest qualification. Clause 4.3.1 does state that "the organization has both CSC and CSP roles" and that "[e]very organization should consider which controls are applicable to it in its roles as the CSC and the CSP" — but the scenario it works through is a stacked supply chain, a provider of application capabilities consuming another provider's infrastructure, not an internal department. That general sentence carries the weight, with 22123-1's party/role definitions and the Scope NOTE. Present the stacked-provider example as though it described a platform team and a reader holding the document will notice.

Click to zoom

What Holding Both Roles Gains You, and What It Quietly Costs

The gain is the attestation gap. Consume an external provider and much of your control environment sits behind a boundary you cannot cross: a report, once a year, by somebody else's auditor about somebody else's systems, and your assurance is exactly as good as that document. The 2026 edition prints its guidance in two shapes — "Type 1 … used when there is separate guidance for the CSC and the CSP", "Type 2 … used when the guidance is the same for both" — and normally two organisations read the two halves, unable to see each other's operations.

Hold both roles and there is nothing to request. The provider-side evidence is your evidence, generated continuously by systems you operate, at whatever granularity you choose. That is the structural advantage making SOC 2 on self-hosted infrastructure a question of instrumentation rather than procurement, and the reason the ISO 27001 Annex A controls you actually operate are the ones you can prove.

The cost arrives in the same envelope. A commercial provider publishes a responsibility split because thousands of customers need it and a contract requires it. Nobody publishes yours. Every Type 1 control now has two answers you write yourself, and the standard's caveat — that a private cloud can need "adjustments … to adapt to the relationships and abilities of an organization's internal departments" — concedes that the adaptation is work, not a formality.

The subtler cost is independence. When both halves of a control answer to the same director, a self-assessment is a conversation with yourself. Give the customer-side review to somebody who does not carry the platform's uptime target, or the register below always agrees with the cluster because one person writes both.

Write the Split Down: a Responsibility Register That Lives in Git

Build first the artefact the hyperscaler published on your behalf: a record, per applicable control, of which half belongs to the internal customer, which half to the internal provider, what evidence settles it, and where that evidence is produced. Keep it in the repository beside the manifests, not in a wiki — the version history is the change record an assessor asks for, and the reviewers are the approval trail.

# responsibility-register.yaml — the split a commercial provider would publish.
# NOT an artefact ISO/IEC 27017:2026 specifies. Engineering for a platform
# team that holds both the CSC and the CSP role.
apiVersion: stribog.internal/v1
kind: ResponsibilityRegister
metadata:
  name: platform-register
  reviewedAt: "2026-09-06"
  reviewedBy: security-assurance   # deliberately not the platform team
spec:
  provider:
    role: cloud-service-provider
    owner: platform-engineering
    scope: "Managed Kubernetes offered to internal business units"
  tenants:
    - id: payments-core
      namespace: tenant-payments-core   # labelled stribog.internal/tenant=true
      role: cloud-service-customer
      owner: payments-engineering
  controls:
    - ref: "ISO/IEC 27002:2022 5.23"          # use of cloud services
      cscResponsibility: >-
        Define the security requirements for the service it consumes and
        review them at each release of its own workloads.
      cspResponsibility: >-
        Publish the service definition, supported versions and the notice
        period for a breaking change.
      evidence: "docs/service-definition.md at the reviewed commit"
      producedBy: "pull request review"
    - ref: "ISO/IEC 27002:2022 5.15"          # access control
      cscResponsibility: >-
        Nominate the subjects bound in its namespace, re-attest quarterly.
      cspResponsibility: >-
        Enforce that a tenant subject holds no cluster-scoped binding.
      evidence: "rbac-export.json, per namespace"
      producedBy: "nightly CronJob, retained 400 days"

Two decisions matter more than the schema. First, evidence names an artefact, not an intention — "nightly CronJob, retained 400 days" is checkable, "reviewed regularly" is not. Second, the tenant list is keyed by namespace, making the register mechanically comparable to the cluster. Kubernetes helps: a Role is namespaced, and the documentation is explicit that "when you create a Role, you have to specify the namespace it belongs in". That edge is already a hard API boundary, so it is the cheapest place to put the role boundary. Where a namespace is too soft, the register survives a move to per-tenant virtual clusters unchanged, describing responsibilities rather than mechanisms.

Making the Register Enforceable Rather Than Decorative

A register that describes a cluster it cannot constrain decays at the speed of the cluster. Two mechanisms keep them married: admission control refusing a tenant-* namespace that lacks the label CI selects on or an annotation naming its register record, and a CI job that fails when the two diverge either way.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-register-entry
spec:
  background: false
  rules:
    - name: tenant-namespace-declares-register-entry
      match:
        any:
          - resources:
              kinds:
                - Namespace
              names:
                - "tenant-*"
      validate:
        failureAction: Enforce
        message: >-
          A tenant namespace must carry stribog.internal/tenant=true and
          stribog.internal/register-entry naming its record in
          responsibility-register.yaml.
        pattern:
          metadata:
            labels:
              stribog.internal/tenant: "true"
            annotations:
              stribog.internal/register-entry: "?*"

That field is the entire control. Kyverno's documentation states that "[t]he failureAction tells Kyverno if the resource being validated should be allowed but reported (Audit) or blocked (Enforce)". Audit produces a report; Enforce produces a guarantee. Teams routinely ship the first and describe it as the second. Broader trade-offs: Kyverno versus OPA Gatekeeper.

Admission never reads the register — it enforces the naming convention, not the record. It cannot see an entry for a namespace somebody deleted last quarter, and a namespace admitted today can be deleted tomorrow with the entry left behind. Compare on every change:

#!/usr/bin/env bash
# reconcile-register.sh — fail CI when the cluster and the register disagree.
set -euo pipefail

REGISTER="${1:-responsibility-register.yaml}"
live=$(mktemp) declared=$(mktemp)

kubectl get namespaces -l stribog.internal/tenant=true \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}' | sort > "$live"

yq -r '.spec.tenants[].namespace' "$REGISTER" | sort > "$declared"

status=0
undeclared=$(comm -23 "$live" "$declared")
orphaned=$(comm -13 "$live" "$declared")

if [ -n "$undeclared" ]; then
  printf 'FAIL: live tenant namespaces absent from the register:\n%s\n' "$undeclared" >&2
  status=1
fi
if [ -n "$orphaned" ]; then
  printf 'FAIL: register entries with no live namespace:\n%s\n' "$orphaned" >&2
  status=1
fi

[ "$status" -eq 0 ] && echo "OK: $(wc -l < "$live") tenants, register and cluster agree"
exit "$status"

A convention admission does not enforce is a suggestion — the argument for enforced golden paths. The register is a golden path for responsibility.

Click to zoom

Per-Tenant Logs and Audit Trails: the Engineering Half of the Split

One obligation an external provider discharges almost invisibly: giving each customer its own data and nobody else's. Hold the provider role internally and that becomes a design problem in two halves — log data, and control-plane activity. Both are ordinary engineering, the provider-side capability the register points at, not implementation of any clause of the standard.

For logs, Grafana Loki separates natively. Its documentation states that "Loki is a multi-tenant system; requests and data for tenant A are isolated from tenant B", and that "[r]equests to the Loki API should include an HTTP header (X-Scope-OrgID) that identifies the tenant for the request." Set that header at the gateway from the authenticated identity rather than letting a client supply it, and a tenant reading its own logs is a routing decision, not a query filter somebody can forget.

Control-plane activity is the other half, and the Kubernetes audit log is where it lives. The documentation is precise about the policy object: "[a]udit policy defines rules about what events should be recorded and what data they should include." The policy file is the artefact — an intention to log is not a log.

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - RequestReceived
rules:
  # Tenant RBAC changes: the bodies ARE the evidence, holding no secrets.
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["roles", "rolebindings"]
    namespaces: ["tenant-payments-core"]

  # Secrets: who touched what, never the value.
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets"]
    namespaces: ["tenant-payments-core"]

  # Everything else those tenants do.
  - level: Metadata
    namespaces: ["tenant-payments-core"]

  - level: None

Retention and downstream routing are a separate decision with jurisdictional edges, covered in Kubernetes audit logs into a SIEM you operate. The point here is narrower: a tenant reading its own control-plane history, and only its own, is a provider capability the register points at with an artefact rather than a promise.

Five Ways This Goes Wrong

1. Role collapse — "one party, so the split does not apply". The 2026 text says the opposite: every organisation should consider which controls apply to it in its roles as CSC and CSP. A register with one owner column has already made this mistake.
2. A register nobody operates — written once for an assessment, never reconciled, drifting until somebody diffs it against the cluster. Hence a CI check failing both directions and an admission rule shipping in Enforce.
3. Reaching for 27018 by reflex. ISO/IEC 27018:2025 protects "personally identifiable information (PII) … for the public cloud computing environment", for organisations "which provide information processing services as PII processors via cloud computing under contract to other organizations". A purely internal private cloud is not that shape — though the same abstract notes it "can also be relevant to" PII controllers, so this is applicability, not prohibition. Personal data obligations do not wait, as Article 32 technical measures make plain.
4. Stale control identifiers. The 2015 annex identifiers are everywhere online and name a replaced edition. Anchor to the 2026 structure — a control mapping is edition-scoped exactly as a NIST SP 800-53 mapping is revision-scoped.
5. Unreviewed self-assessment. The customer half reviewed by the team owning the provider half is no review. Name a different reviewer.

Certification Scope, and What a 27017 Claim Does Not Buy

27017 is guidance, and so is the standard it extends: IEC's record for ISO/IEC 27002:2022 describes "a reference set of generic information security controls including implementation guidance", published 2022-02-15 as edition 3.0. The requirements live elsewhere. ISO/IEC 27001:2022 "specifies the requirements for … an information security management system", and states that "[e]xcluding any of the requirements specified in Clauses 4 to 10 is not acceptable when an organization claims conformity to this document."

So conformity is claimed against the management system; the cloud guidance is applied within it. One accredited certification body, describing its own 27017 offering, states that "certification to ISO 27001 is also a prerequisite for an extension to ISO 27017" — a single secondary source, not a general rule, on a page still written around the 2015 clause list. The accreditation instruments are the authority, and this article does not read them.

The honest questionnaire sentence is therefore narrow. Not "27017 certified" — the standard is not a certification in its own right. Closer to: the ISMS is certified to ISO/IEC 27001:2022, the internal cloud service is inside its scope, and the cloud-specific guidance of ISO/IEC 27017:2026 is applied to it, with the customer/provider split recorded per control. Every clause there is checkable, which is why it is the stronger claim.

The Register Is Also the Exit Ramp

There is an unplanned dividend here. A register written for an internal provider is structurally a procurement document. Swap the provider column from "platform engineering" to a vendor and you hold an RFP requirements list, in the vocabulary the vendor's own auditors use. The questions otherwise improvised — who rotates that key, who owns that backup, who notices that expiry — are already written, reviewed and dated.

It works inbound too: repatriating a workload means filling in a provider column a vendor page filled before, so the delta is explicit rather than discovered in week three. That is optionality in practice — not a promise you could leave, but a document stating what leaving involves.

Some of this will age. Control identifiers move — 2026 did that to 2015, and Annex A exists to map between them. Kyverno will move failureAction again. What does not age is the split: a customer set of activities, a provider set of activities, one party answering for both. That survived a change of vocabulary standard, of base control set, and of publication decade.

So build for the durable half. Keep the register in git under review, admission refusing tenant namespaces that do not declare themselves, CI failing on drift — and treat control identifiers as a mapping layer re-derived at each edition, not as the structure itself. Ten years out, every number in the ref column will differ. The two columns beside them will not.