Assembling an ISO 27001 Posture End to End
The Compliance group documents each control ISO 27001 evidence draws
from on its own page: the evidence binder,
the sub-processor registry, the
data residency overview, the
SOC 2 controls mapping, and the
trust center evidence pack.
This guide is the sequence across all of them — the order a tenant
actually assembles an ISO 27001 posture in, and what each step leaves
behind as evidence.
This page describes Orbit’s platform controls. It is not legal
advice. Whether ISO 27001 certification is required for your
contracts, which legal entities belong in your ISMS scope, and how to
interpret a buyer’s questionnaire depends on your organization. Confirm
with qualified counsel or your ISMS lead.
The certification-honesty framing
ISO 27001 (ISO/IEC 27001:2022) is a certifiable standard: an
information security management system (ISMS) earns a certificate from
an accredited certification body, scoped to specific sites, services,
and legal entities, and keeps it through surveillance audits. Devotel
states its own posture plainly — ISO 27001 certification is on the
platform’s public compliance-artifact table as planned 2027, and no
certificate is claimed before one exists. The PCI DSS posture
page keeps the artifact table current.
What ships today is the tenant-facing half of the relationship: when a
security questionnaire arrives written in ISO 27001 vocabulary — Annex-A
clause numbers, the organisational / people / physical / technological
families — the evidence binder generates
a pack that answers in that numbering, with rows split between the
platform’s own posture and evidence derived from your tenant.
The assembly sequence
Run these in order. Each step leaves an artifact the next questionnaire
draws on.
1. Generate the ISO 27001 binder pack
Open Settings → Compliance → Binder and generate an ISO 27001
pack. The binder maps the 2022 Annex-A families — A.5 organisational,
A.6 people, A.7 physical, A.8 technological — plus the individually
numbered clauses procurement teams cite most: A.5.19 supplier
relationships (the published sub-processor list and its 30-day
change-notice period) and A.5.30 ICT readiness for business
continuity (daily backup cadence, quarterly restore tests, the recovery
runbook reference).
Rows fall into two classes, and the split is the answer to the most
common follow-up question (“which of this is yours and which is the
platform’s?”):
- Platform-fixed — identical for every workspace: the documented
policy set, background screening and the 24-hour off-boarding SLA,
the production region (Google Cloud
europe-west1), the encryption
posture, the sub-processor list URL, the backup and restore
cadence.
- Workspace-derived — counted from your tenant at generation time:
active API-key counts and contact-record aggregate counts, redacted
by construction so the pack is safe to forward.
The integrity pre-check runs before the pack is assembled. If the
chain replay finds issues, the tamper alert renders as a bordered
banner ahead of the first section — a reader sees the caveat before any
evidence row.
2. Attach the supplier-relationship evidence
Clause A.5.19 (supplier relationships) is where CPaaS traffic
enters a buyer’s questionnaire: the platform is a supplier to you, and
its sub-processors are suppliers to it. The pack cites the
sub-processor registry — the
published list of the entities that process data on the platform’s
behalf, with the 30-day change-notice period the Data Processing
Agreement guarantees. Subscribe to change notices so your supplier
register stays current without re-checking by hand.
3. Position your residency and continuity rows
Two clusters the reviewer reads next:
- A.7 physical controls state where the processing physically
happens. The data-residency overview
documents the production region the binder’s platform-fixed rows
inherit, so the answer you hand over matches the hosting attestation
instead of contradicting it.
- A.5.30 ICT readiness for business continuity cites the backup
cadence and restore-test schedule. Keep a completed ISO 27001
generation on the shelf on a quarterly cadence — platform-fixed
rows change only on a platform change, and the binder’s
move-detection rule flags when one happened — and regenerate the same
day your own tenant settings change, just as for the HIPAA pack.
4. Cross-map to SOC 2 when the reviewer insists
North-American reviewers often arrive with a SOC 2 Trust Services
Criteria spreadsheet; European and enterprise reviewers arrive with
ISO 27001 clause numbering. The underlying evidence is the same set of
control surfaces — the SOC 2 controls mapping
(CC/Common Criteria) and the ISO 27001 Annex-A pack read from the same
audit chain, access model, encryption posture, and sub-processor list.
Hand the reviewer the pack in their numbering rather than asking them
to crosswalk a foreign frame — the binder already does the regrouping.
5. Keep the pack fresh and verifiable
Completed generations carry a signed download link that expires after
24 hours; deliver the file itself to the recipient, not the link.
Record the SHA-256 the generation prints — that value, not the
document’s prose, is what a GRC tool or auditor verifies on upload.
Choose PDF for a human reviewer or ZIP when the questionnaire
accepts per-control files (01_A_5.md, …) on folder upload.
Per-framework checklists exist for the other frames
The same assembly discipline is documented for the adjacent frames —
use the guide that matches the questionnaire in front of you, and the
binder’s framework selector to answer in its numbering:
See also:
