ISO 27001 vs SOC 2: Certificate or Auditor's Opinion

Search the comparison and you get control-mapping tables: Annex A 8.9 beside CC7.1, a percentage of claimed overlap, a closing note on which your market wants. They are not wrong. They answer a question nobody is stuck on, and skip the one that decides what you build — what lands on the desk, and what it can say.

Two Artefacts, Not Two Flavours of One Audit

There is no such thing as being "SOC 2 certified." The AICPA's attestation standards, as amended by SSAE No. 21, define the engagement a SOC 2 sits in as an assertion-based examination engagement: one in which "the practitioner obtains reasonable assurance by obtaining sufficient appropriate evidence about the responsible party's measurement or evaluation of the underlying subject matter against criteria in order to be able to draw reasonable conclusions on which to base the practitioner's opinion." That definition, at AT-C section 105.12, holds the answer: the deliverable is an opinion, expressed rather than conferred, about something already past. "Assertion-based" names who speaks first — management measures and asserts, the practitioner opines on that assertion.

ISO 27001 is the other shape: a management-system standard whose conformity is certified. A third-party body audits the management system, a decision is issued, and out comes a document with a scope and an expiry. It enumerates no controls tested and no findings. It asserts a status. The distinction is the one separating a certifiable standard from its guidance document one level down: certification and attestation are different instruments, not different rigour settings.

The criteria themselves also differ in kind. The trust services criteria are, in the AICPA's own words, "control criteria established by the Assurance Services Executive Committee (ASEC) of the AICPA for use in attestation or consulting engagements" — a professional body's criteria for its members' engagements, not a standard published by a standards body, and not something an organisation is certified against. ISO 27001 is the latter.

Click to zoom

What the Auditor's Opinion Actually Covers

Read the opinion page of a Type 2 report as scope limits, not a verdict. The trust services criteria state what the engagement covers: "the suitability of design and operating effectiveness of controls included in management's description of a service organization's system relevant to one or more of the trust services criteria ... throughout a specified period." Four constraints sit in that sentence: the controls are management's own, the criteria only those the engagement names, operating effectiveness is in scope alongside design, and all of it is bounded by a period.

The same document supplies the reason a Type 2 is worth reading: it "also includes a detailed description of tests of controls performed by the service auditor and the results of those tests" — the substance, naming what was sampled and what happened. A Type 1 has neither half: it "does not contain an opinion on the operating effectiveness of controls nor a detailed description of tests of controls ..." A buyer asking for evidence that controls ran wants a Type 2, whatever the request email says. A SOC 3 keeps the opinion but drops the tests and results, which is what makes it publishable.

Then the part that surprises procurement. Under AT-C section 205.64 the report "should include an alert, in a separate paragraph, that restricts the use of the report" in listed circumstances — among them where "the criteria used to evaluate the subject matter are available only to specified parties." Paragraph .65 then requires that alert to state the report is "intended solely for the information and use of the specified parties," identify them, and state it "is not intended to be, and should not be, used by anyone other than the specified parties." Conditional, not a blanket rule — read the alert paragraph in the report you hold.

What the Certificate Actually Says

A certificate asserts that an information security management system, inside a stated scope, conforms to the standard. Read what it leaves out: no sample sizes, no exceptions, no population. The audit behind it was a management-system audit, and the document is a status rather than a result set. Which controls were tested last year is a question it was never built to answer — that answer lives in the Statement of Applicability and the ISMS records behind it.

Its weight comes from the chain above the issuing body, which is itself accredited against ISO/IEC 17021-1, the general standard for certification bodies. Accreditation bodies run mutual-recognition arrangements so a certificate travels between jurisdictions, and that layer consolidated recently: Global Accreditation Cooperation Incorporated "has commenced full operations as of 1 January 2026, including the launch of its own Multilateral Recognition Arrangement (MRA)" — a change Stribog's earlier ISO 27001 article covers. An unaccredited certificate is a different artefact in similar typography.

One detail inside the certification body is the closest ISO analogue to auditor independence. Per an accreditation body's published restatement of ISO/IEC 17021-1:2015 — the International Accreditation Service's abridged Section 9, used here because the standard is paywalled — clause 9.5.1.1 requires that "Decision makers are different from those who carried out the audits ..." The people who audited you do not decide your certification, and that separation sits in the rules governing certification bodies, not in your ISMS.

The certificate does record which edition it is against, and the 2013 transition is closed. IAF MD 26, the mandatory document that governed it, set in its key-timescale table a deadline for transitions of certified clients at 36 months from the last day of the publication month of ISO/IEC 27001:2022 — 31 October 2025 — and required that "All certifications based on ISO/IEC 27001:2013 shall expire or be withdrawn at the end of the transition period." So an in-date accredited certificate today is a 2022-edition certificate.

The Two Calendars Are the Real Difference

The ISO calendar first. Clause 9.1.3.2 of that accreditation-body restatement sets the programme as "two-stage initial audit, surveillance audits in the first and second years following the certification decision, and a recertification audit in the third year prior to expiration of certification," and fixes the origin: "The first three-year certification cycle begins with the certification decision." Not the audit date, not the certificate's print date. Clause 9.1.3.3 sets the cadence: surveillance "at least once a calendar year, except in recertification years," with the first "not be more than 12 months from the certification decision date." Those are not the same constraint: a calendar year alone would permit a January decision and a December surveillance 23 months later, and the 12-month ceiling forbids it.

Three years is the general default, not a universal rule. NOTE 3 to clause 9.1.3.2 records that "If specified by the industry specific certification scheme, the certification cycle can be different from three years." Confirm the length against your certification body's programme, not against an article. Audit duration for an ISMS comes from ISO/IEC 27006-1:2024 and that programme too — and where exact wording reaches a contract, buy the standard.

The SOC 2 calendar has no cycle, only a sequence of closed periods with an issuance lag behind each. Which raises the question the mapping tables never reach: what does this report say about today? Nothing. The further the question date drifts from the period's end, the less of your current posture it touches. A bridge letter from management narrows the gap but is not an examination and carries no opinion. The honest answer to "are your controls operating?" cites the last closed period and its end date, then says what has changed since.

Moving certification body does not restart the clock: IAF MD 2 requires that where the pre-transfer review finds no problems, "the certification cycle shall be based on the previous certification cycle and the accepting certification body shall establish the audit programme for the remainder of the certification cycle." You inherit your position in the cycle, expiry included. Stribog's ISO/IEC 42001 certification-audit article works those transfer clauses on the same 17021-1 machinery; the point here is that the cycle belongs to the certification, not the certifier — which makes changing bodies a move rather than a restart.

Click to zoom

One Evidence Pipeline, Two Artefact Sets

Here is the payoff the percentage-of-overlap framing obscures: the question is not what fraction of controls coincide, but which artefacts machines generate and which humans write. An audit event recording who deleted a secret at 03:14 UTC is the same fact whether a service auditor samples it inside a period or a certification-body auditor reads it as ISMS operation. Build the generators once, land them in one dated store, let two mappings read it differently.

Start where both programmes start: the control plane's record of who did what. Audit policy decides whether an access event is admissible evidence or merely a count, and rule ordering is the whole design — "When an event is processed, it's compared against the list of rules in order. The first matching rule sets the audit level of the event." The levels are None, Metadata, Request and RequestResponse, and a broad Metadata catch-all above a specific rule silently downgrades exactly the event you will need.

# Passed to kube-apiserver as:
#   --audit-policy-file=/etc/kubernetes/audit/audit-policy.yaml
#
# Rule order IS the policy. The first matching rule wins, so every
# narrow high-value rule must appear ABOVE the broad catch-all.
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - RequestReceived

rules:
  # 1. Drop the highest-volume, zero-evidence-value chatter first, so it
  #    never reaches the rules below and never consumes retention.
  - level: None
    users:
      - system:kube-scheduler
      - system:kube-controller-manager
      - system:kube-proxy
    verbs: ["get", "list", "watch"]

  - level: None
    nonResourceURLs:
      - /healthz*
      - /livez*
      - /readyz*
      - /version
      - /metrics

  # 2. Secret and credential access: metadata only, deliberately.
  #    RequestResponse here would write the secret material into the
  #    audit log, turning the evidence store into a credential store.
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "serviceaccounts/token"]
      - group: "authentication.k8s.io"
        resources: ["tokenreviews"]

  # 3. Authorisation changes: full request AND response. This is the
  #    access-review trail both programmes reconcile against, and
  #    "who granted cluster-admin, and what exactly did they grant"
  #    is unanswerable from metadata alone.
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources:
          - roles
          - rolebindings
          - clusterroles
          - clusterrolebindings

  # 4. Interactive access to a running workload — the event that most
  #    often needs explaining, and the one least often logged usefully.
  - level: RequestResponse
    resources:
      - group: ""
        resources:
          - pods/exec
          - pods/attach
          - pods/portforward

  # 5. Policy and admission configuration: changing the guard is itself
  #    an auditable act.
  - level: RequestResponse
    resources:
      - group: "admissionregistration.k8s.io"
        resources: ["validatingwebhookconfigurations", "mutatingwebhookconfigurations"]
      - group: "kyverno.io"
        resources: ["clusterpolicies", "policies"]

  # 6. Everything else that mutates: bodies kept, reads excluded.
  - level: Request
    verbs: ["create", "update", "patch", "delete", "deletecollection"]

  # 7. Residual catch-all. Last, always.
  - level: Metadata

Retention decides whether any of it is evidence when somebody asks. The three kube-apiserver flags are familiar — --audit-log-maxage for days retained, --audit-log-maxbackup for file count, --audit-log-maxsize for rotation size — and the question is what number goes in them. The defensible floor is the SOC 2 one: the longest period you will be examined over, plus the issuance lag behind it. A period longer than the window leaves its early months unevidenced — controls may have operated perfectly and nothing survives to sample. Reaching a cycle's far edge is a design choice, not a requirement: neither ISO 27001 nor the 17021-1 restatement asks for three years of raw API events, since a surveillance audit samples current ISMS operation. Treat it as conservative headroom, then check maxbackup and maxsize cannot end the window early. A SIEM you operate decouples it from local disk.

# kubeadm-config.yaml
#   kubeadm init --config kubeadm-config.yaml
#   kubeadm upgrade apply --config kubeadm-config.yaml
#
# maxage here is a conservative upper bound rather than a requirement:
# it reaches past the far edge of a three-year certification cycle. The
# defensible floor is smaller - the longest report period plus the
# issuance lag behind it. maxbackup and maxsize are then sized so
# rotation cannot expire the window before maxage does: 400 files x
# 200 MB = 80 GB, which is about 66 MB of audit volume per day across
# the 1200 days. Note that maxsize is the only rotation
# trigger kube-apiserver has; there is no time-based equivalent.
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: v1.36.0
clusterName: sovereign-prod
controlPlaneEndpoint: api.cluster.example.com:6443

apiServer:
  extraArgs:
    - name: audit-policy-file
      value: /etc/kubernetes/audit/audit-policy.yaml
    - name: audit-log-path
      value: /var/log/kubernetes/audit/audit.log
    - name: audit-log-maxage
      value: "1200"
    - name: audit-log-maxbackup
      value: "400"
    - name: audit-log-maxsize
      value: "200"
  extraVolumes:
    - name: audit-policy
      hostPath: /etc/kubernetes/audit
      mountPath: /etc/kubernetes/audit
      readOnly: true
      pathType: DirectoryOrCreate
    - name: audit-log
      hostPath: /var/log/kubernetes/audit
      mountPath: /var/log/kubernetes/audit
      pathType: DirectoryOrCreate

etcd:
  local:
    dataDir: /var/lib/etcd

The rest of the shared set follows the same rule: dated, hashed, indexed once. Backups are the clearest case, because a backup without a restore result is an assertion rather than evidence, and because the dating has a trap in it. Velero lets the time zone live in the schedule — "The format is CRON_TZ=<timezone> <cron>" — and its v1.18 documentation gives the reason: "Specifying timezones can reduce disputes in the case of daylight saving time changes."

#!/usr/bin/env bash
# Collect one day's evidence artefacts into a dated, hashed index.
#
# Programme-agnostic by design: this script knows nothing about trust
# services criteria or ISMS clauses. It produces facts with dates and
# digests. Mapping those facts to either programme happens downstream.
set -euo pipefail

ROOT="${EVIDENCE_ROOT:-/srv/evidence}"
COLLECTED_AT="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
DAY="${COLLECTED_AT%%T*}"
OUT="${ROOT}/${DAY}"
INDEX="${OUT}/index.jsonl"

mkdir -p "${OUT}"
: > "${INDEX}"

# Emit one index row. Digest is computed from the bytes on disk, so a
# later re-hash either reproduces it or proves the artefact changed.
index_row() {
  local path="$1" kind="$2"
  local digest bytes
  digest="$(sha256sum "${path}" | cut -d' ' -f1)"
  bytes="$(wc -c < "${path}" | tr -d '[:space:]')"
  printf '{"path":"%s","kind":"%s","collected_at":"%s","sha256":"%s","bytes":%s}\n' \
    "${path#"${ROOT}/"}" "${kind}" "${COLLECTED_AT}" "${digest}" "${bytes}" >> "${INDEX}"
}

collect() {
  local name="$1" kind="$2"
  shift 2
  local dest="${OUT}/${name}"
  if "$@" > "${dest}.partial" 2> "${dest}.err"; then
    mv "${dest}.partial" "${dest}"
    rm -f "${dest}.err"
    index_row "${dest}" "${kind}"
  else
    # Fail loudly per artefact, but do not abandon the run: a missing
    # artefact discovered now is repairable, one discovered at audit
    # time is a gap in a closed period.
    echo "collect FAILED: ${name} ($(tr -d '\n' < "${dest}.err" | cut -c1-200))" >&2
    rm -f "${dest}.partial"
  fi
}

# Access review: every binding that can escalate, as at this timestamp.
collect rbac-clusterrolebindings.json access_review \
  kubectl get clusterrolebindings -o json

collect rbac-rolebindings.json access_review \
  kubectl get rolebindings --all-namespaces -o json

# Policy reports: admission and background results, per namespace.
collect policy-reports.json policy_report \
  kubectl get policyreports,clusterpolicyreports --all-namespaces -o json

# Backup state, including the restore results that make a backup
# evidence rather than an intention.
collect velero-backups.json backup \
  velero backup get -o json

collect velero-restores.json restore_result \
  velero restore get -o json

# Control-plane audit trail. kube-apiserver has exactly one rotation
# trigger, --audit-log-maxsize, and names each backup after the
# rotation instant. So on any cluster below that threshold no dated
# file appears for days, and the day's events are still sitting in the
# open segment. Collect both: rotated files carrying today's date, and
# the live log.
audit_rows=0

for f in /var/log/kubernetes/audit/audit-"${DAY}"*.log; do
  [ -e "${f}" ] || continue
  cp "${f}" "${OUT}/$(basename "${f}")"
  index_row "${OUT}/$(basename "${f}")" audit_log
  audit_rows=$((audit_rows + 1))
done

# The open segment, under a name that says so: it was live when copied
# and it may overlap tomorrow's copy.
if [ -e /var/log/kubernetes/audit/audit.log ]; then
  cp /var/log/kubernetes/audit/audit.log "${OUT}/audit-open-${DAY}.log"
  index_row "${OUT}/audit-open-${DAY}.log" audit_log
  audit_rows=$((audit_rows + 1))
fi

# Seal the day: a digest over the index itself, so a later reader can
# prove the row set was not edited after collection.
sha256sum "${INDEX}" | cut -d' ' -f1 > "${OUT}/index.sha256"

echo "collected $(wc -l < "${INDEX}") artefacts into ${OUT}"

# Fail closed on the audit trail specifically. A day with zero audit
# artefacts is a collection failure, not a quiet zero, and the
# reconciler downstream cannot catch it: an absent kind produces no
# row, so it raises no rejected-artefact error. Sealed first, so the
# partial day stays verifiable.
if [ "${audit_rows}" -eq 0 ]; then
  echo "collect FAILED: no audit-log artefact for ${DAY}" >&2
  exit 1
fi

Then one reconciler reads that index and emits two mappings. Its most useful property is failing closed: an artefact mapping to neither programme is either a collection step nobody needs or a mapping somebody forgot. The SOC 2 evidence article covers the retention and immutability plumbing underneath; what follows is only the mapping layer.

#!/usr/bin/env python3
"""Map one day's evidence index onto both programmes' artefact sets.

Reads the dated index produced by collect-evidence.sh and emits two
mappings over the same rows: trust services criteria references for the
SOC 2 side, ISMS clause and Statement of Applicability references for
the ISO 27001 side.

Fails closed. An artefact kind that maps to neither programme exits
non-zero, because in practice that means one of two things: a
collection step that serves no audit, or a mapping that was never
written. Both are worth a build failure and neither is worth
discovering during fieldwork.
"""

from __future__ import annotations

import argparse
import json
import sys
from pathlib import Path

# The mapping table is the only programme-aware code in the pipeline.
# Criteria references are illustrative placeholders: confirm every one
# against the criteria your engagement actually names and against your
# own Statement of Applicability before relying on them.
MAPPING: dict[str, dict[str, list[str]]] = {
    "audit_log": {
        "tsc": ["CC6.1", "CC7.2"],
        "isms": ["A.8.15", "A.8.16", "ISMS-9.1"],
    },
    "access_review": {
        "tsc": ["CC6.1", "CC6.2", "CC6.3"],
        "isms": ["A.5.15", "A.5.18", "ISMS-9.1"],
    },
    "policy_report": {
        "tsc": ["CC7.1", "CC8.1"],
        "isms": ["A.8.9", "ISMS-8.1"],
    },
    "backup": {
        "tsc": ["A1.2"],
        "isms": ["A.8.13"],
    },
    "restore_result": {
        "tsc": ["A1.2", "A1.3"],
        "isms": ["A.8.13", "A.5.29", "ISMS-9.1"],
    },
}

# Every row must carry these before it can be cited as evidence. A row
# missing one is a collection bug, and it fails closed like an unknown
# kind rather than raising KeyError halfway through a run.
REQUIRED_FIELDS = ("path", "collected_at", "sha256")


def load_index(path: Path) -> list[dict]:
    rows: list[dict] = []
    with path.open(encoding="utf-8") as handle:
        for lineno, line in enumerate(handle, start=1):
            line = line.strip()
            if not line:
                continue
            try:
                rows.append(json.loads(line))
            except json.JSONDecodeError as exc:
                raise SystemExit(f"{path}:{lineno}: malformed index row: {exc}")
    if not rows:
        raise SystemExit(f"{path}: index is empty — nothing was collected")
    return rows


def main() -> int:
    parser = argparse.ArgumentParser(description=__doc__)
    parser.add_argument("index", type=Path, help="path to a dated index.jsonl")
    parser.add_argument("--out", type=Path, required=True, help="output directory")
    args = parser.parse_args()

    rows = load_index(args.index)

    soc2: list[dict] = []
    iso: list[dict] = []
    rejected: list[str] = []

    for row in rows:
        kind = row.get("kind", "")
        absent = [field for field in REQUIRED_FIELDS if not row.get(field)]
        if absent:
            rejected.append(
                f"{row.get('path', '?')} (incomplete row, missing {', '.join(absent)})"
            )
            continue
        entry = MAPPING.get(kind)
        if entry is None:
            rejected.append(f"{row['path']} (kind={kind or 'missing'})")
            continue
        common = {
            "artefact": row["path"],
            "collected_at": row["collected_at"],
            "sha256": row["sha256"],
        }
        soc2.append({**common, "criteria": entry["tsc"]})
        iso.append({**common, "references": entry["isms"]})

    args.out.mkdir(parents=True, exist_ok=True)
    (args.out / "soc2-evidence-map.json").write_text(
        json.dumps(soc2, indent=2, sort_keys=True) + "\n", encoding="utf-8"
    )
    (args.out / "isms-evidence-map.json").write_text(
        json.dumps(iso, indent=2, sort_keys=True) + "\n", encoding="utf-8"
    )

    print(
        f"mapped {len(soc2)} of {len(rows)} artefacts into both maps, "
        f"{len(rejected)} rejected"
    )

    if rejected:
        print("rejected artefacts (failing closed):", file=sys.stderr)
        for item in rejected:
            print(f"  {item}", file=sys.stderr)
        return 1
    return 0


if __name__ == "__main__":
    sys.exit(main())

What Does Not Reuse: System Description vs ISMS Scope

Two documents here are written by humans about the same infrastructure, and they are not even the same genre. Management's description of the system is a narrative about a period: the system as it operated throughout that window, changes included, with the practitioner examining the description as well as the controls in it. Past tense, temporal boundary. An ISMS scope statement is a standing declaration of what the management system covers now, and the Statement of Applicability is its register — which Annex A controls apply, which are excluded, why. Present tense, organisational boundary.

The SoA is not internal paperwork, which is the common misreading. It "is found in 6.1.3 of the main requirements for ISO 27001, which is part of the broader 6.1, focused on actions to address risks and opportunities," and it is "an integral part of the mandatory ISO 27001 documentation that needs to be presented to an external auditor when the ISMS is undergoing an independent audit." An audited artefact — cited here from a vendor explainer rather than the standard, because clause 6.1.3 sits behind the ISO paywall.

Since both describe one estate, the failure mode is disagreement, not duplication. A system description naming three clusters and an SoA scope naming two is a finding on one side and an awkward question on the other. The fix is not to merge them but to derive the shared facts from one place: one inventory of clusters, namespaces, data stores and third parties, cited by both. The estate changes, the inventory changes once, and both documents go stale detectably. Concentration and substitutability of those vendors is its own discipline, and both programmes ask about it.

Failure Modes That Cost a Period or a Cycle

Each programme breaks in ways the other cannot. Which failures are recoverable and which cost a year is most of the planning value.

• A qualified opinion. AT-C section 205.72: the practitioner "should express a qualified opinion" when misstatements are "material, but not pervasive to the subject matter," or when sufficient appropriate evidence could not be obtained and the possible effects "could be material but not pervasive." Read the second limb: you can be qualified for missing evidence about a control that worked. The report issues, qualified, and the period is closed.
• Retention shorter than the period. The quietest failure of the set: everything looks healthy until fieldwork reaches the far end of the window and finds rotated-away logs.
• A missed surveillance date. The 12-month ceiling on the first surveillance audit runs from the certification decision, not from a convenient internal anniversary. Suspension and withdrawal are the certification body's instruments, and a lapsed certificate is not explained away in a security review.
• A boundary changed mid-cycle. A cluster in a new jurisdiction, or a new production data store, changes the scope both descriptive documents assert. If neither moves, one artefact describes an estate that no longer exists.
• Treating a Type 1 as a milestone. No operating-effectiveness opinion, no tests-and-results section. A design checkpoint before a period starts, useful. An answer to a buyer asking whether controls ran, not the artefact they asked for.

The common shape: none of these are control failures. Every one is an evidence, calendar or scope failure — categories a control-mapping table cannot show, and that a dated store with two mappings over it makes visible months ahead.

Which Buyer Asks for Which, and Why the Asks Differ

The pattern operators notice — US enterprise security reviews reaching for the report, EU and international tenders for the certificate — is an observation about markets, not a measured statistic, and the structure explains much of it. A certificate is issued to be shown: short, attributable to an accredited body, answerable as of today. A Type 2 report is long, rich, and frequently arrives with a paragraph naming who may use it. One suits a form field; the other suits a reviewer under NDA who will read the tests-and-results section.

On the European side there is a thread of hard law pointing at the ISO standards. Recital 3 of Commission Implementing Regulation (EU) 2024/2690 states that the technical and methodological requirements in its Annex "are based on European and international standards, such as ISO/IEC 27001, ISO/IEC 27002 and ETSI EN 319401, and technical specifications, such as CEN/TS 18026:2024." A regulator naming reference points, not a mandate to certify — but a tender asking for the certificate is usually downstream of language like that. The overlapping EU regimes converge on the same standards repeatedly.

Sell into both markets and the answer is both artefacts on one pipeline, which is why the reuse boundary matters more than the control mapping. The mapping says the programmes ask similar questions. The boundary says what you build once.

The Long Game: Cadence Over Certificates

Both programmes punish the same posture: treating an audit as a project. A project has a deadline, a scramble and a gap afterwards, and the gap is where the retention window quietly closes and the surveillance date quietly arrives. Organisations for which neither audit is eventful run the shorter cadence continuously — daily collection, dated and hashed, mapped both ways, failing closed on anything unclassified.

That posture outlasts the specifics on this page, which is the point of building it rather than buying a dashboard. Criteria get revised; exposure drafts become standards; accreditation arrangements consolidate, as they did on 1 January 2026. A pipeline whose output is dated, hashed, programme-agnostic facts survives all of it, because only the mapping layer has to change — and the mapping layer is a table.

Which is the sovereignty argument in its least rhetorical form. The evidence is generated by infrastructure you operate, retained on terms you set, mapped by code you can read. Change certification body and you keep your position in the cycle. Change auditor and the store is unaffected. The certificate and the opinion are other people's documents about your systems. The store underneath is yours.