Quick answer: SOC 2 and ISO 27001 are the two assurance frameworks procurement teams write into CPaaS RFPs, and they answer different questions — SOC 2 Type II is an auditor's opinion that a control set operated over a period, ISO 27001 is a certificate that a whole information-security management system exists and works. Knowing which one the questionnaire wants, and what your own tenant-side controls contribute to either answer, turns the evaluation from a document chase into a checklist. This guide gives you the difference, the checklist of questions to ask any vendor, and pointers to the two pages where Devotel Orbit publishes its posture: the Trust Center and the Security page.
Everything below is buyer-side guidance, not legal advice. On the framework facts we stay neutral; on Orbit we point to shipped public pages and tenant-configurable settings — never to a compliance claim this post cannot make.
Why assurance frameworks show up on CPaaS RFPs
A communications platform touches the two data classes a security reviewer cares most about: message content and the personal data inside it (phone numbers, identifiers, free text), and voice recordings with the same exposure. That puts CPaaS into the "vendor that touches personal data" bucket, and procurement routes every vendor in that bucket through the assurance questionnaire.
The frameworks survive the scoping conversation because they compress it. Instead of a 300-line spreadsheet asking about encryption, access control, incident handling, and change management one control at a time, procurement asks for two things: an attestation or certificate, and the evidence pack that backs it. A vendor that can hand over both moves to pricing; a vendor that answers "open a support ticket" leaves the short list.
The two names that handle this compression on nearly every RFP are SOC 2 (common in North American procurement) and ISO 27001 (common in European and global procurement). Knowing which one arrived in the envelope tells you which artefact the reviewer's checklist actually accepts.
SOC 2 Type II vs ISO 27001 — what each one actually is
SOC 2 is a report, not a certificate. An external auditor examines a defined control set — organized around the AICPA Trust Services Criteria (security, availability, processing integrity, confidentiality, privacy) — and issues an opinion letter. A Type I report covers the control design at a point in time; a Type II report, the one procurement wants, covers operating effectiveness over an observation window, typically six to twelve months. The opinion travels with the exact scope and period the auditor examined — a SOC 2 letter scoped to "the voice product" does not attest to the messaging product.
ISO 27001 is a certificate, and it certifies a system. An accredited certification body audits the organization's information security management system (ISMS) — the policies, risk-treatment process, and control cycle — against the ISO/IEC 27001 standard, whose Annex A catalogues the reference controls (114 in the 2013 edition, consolidated to 93 in the 2022 revision). Certificates carry a validity window (commonly a three-year cycle with annual surveillance audits) and a stated scope, and the certificate attests that the ISMS operated, under audit, within that scope.
The buyer-side translation. A SOC 2 Type II report tells you a defined set of controls ran over a period, and an auditor confirmed that they did. An ISO 27001 certificate tells you a management system for security, audited at certification time. Neither one covers the other — SOC 2 evaluates a control set, ISO 27001 certifies a management system — so when you ask a vendor which framework it holds, the answer tells you which document your reviewer can accept. Match what your questionnaire names, and expect the vendor to hold at least one.
One caution common to both: scope and observation windows are read, not assumed. A certificate valid until 2027 issued under the 2013 revision, or a SOC 2 report covering last year's quarter, tells you different things than the current period. Ask which.
On Orbit: this guide intentionally makes no claim about Devotel Orbit's own SOC 2 or ISO 27001 posture. The Trust Center publishes SOC 2 control mappings with per-control status labels; the downloadable-pack request form is on the same page. That page is the source of truth — this post exists to tell you what to read there, not to read for you.
Tenant-owned controls — what you bring to either framework
Whichever framework the RFP names, part of the answer lives on your side of the account. The controls below are settings your organization configures — none are platform-mandated, and an organization that never touches them keeps working.
- Access controls. SCIM 2.0 provisioning paired with SAML SSO — SAML controls sign-in, SCIM controls which members exist and keeps membership following your IdP, so departed employees lose access on deprovision, not on a manual checklist. Per-API-key IP allowlists contain a leaked credential at the network layer, and the append-only audit log records who did what with before/after detail. The enterprise security checklist walks these as a due-diligence sequence.
- Audit evidence binders. A one-click export maps the workspace's own data — audit-log aggregates, access-posture counts, consent and retention configuration — onto a public framework's control matrix: SOC 2, ISO 27001, GDPR, or HIPAA. Every row is aggregate counts and hashed references; the pack carries a SHA-256 checksum. The binder walkthrough covers generation mechanics; the GDPR audit evidence checklist shows the same checklist discipline applied to a privacy framework.
The boundary matters in both directions: your auditor grades your controls, the vendor's letter grades the vendor's. A binder is the envelope your evidence ships in — it is not a substitute for the vendor's attestation, and it is not a substitute for your auditor.
The checklist — questions to ask any CPaaS vendor
Run these nine against every vendor on the short list. A vendor that answers with documentation, not adjectives, survives the questionnaire stage.
- Which assurance framework do you hold — SOC 2, ISO 27001, or both, and which scope does the attestation cover? The answer names the artefact your reviewers will actually accept, and the scope line tells you whether the product you are buying sits inside it.
- For SOC 2: is it Type II, and what observation period does the report cover? Type I is a point-in-time design check; procurement's "SOC 2" checkbox almost always means Type II.
- For ISO 27001: which standard revision is on the certificate, and what is left on the validity window? A certificate audited under the superseded revision, or one approaching expiry, is a different answer than a current one.
- Can we see the actual report or certificate under NDA — not a marketing summary of one? The artefact, not a screenshot of the artefact.
- Which tenant-side controls can we configure — SSO, SCIM provisioning, key allowlisting, audit export? Part of either framework's answer lives on your side; the vendor should hand you the levers.
- Can we generate our own audit evidence — and verify it? A binder with a checksum beats an email with a spreadsheet; a checksum you can verify beats a checksum you have to trust.
- Is the evidence pack scoped to our tenant's data — aggregate counts and hashed references, no neighbor's posture blended in? A pack that mixes tenants is a privacy incident, not an artefact.
- Where do your sub-processors live, and is the list public or behind a request form? Public lists get updated on a schedule reviewers can check; request forms get stale.
- Who handles our data on the path to carriers — and how far does your assurance scope extend down that path? A communications flow eventually crosses carrier and provider boundaries; a credible vendor says where its controls end.
How Orbit's trust page fits the checklist
The Devotel Orbit Trust Center is organized as the checklist above would consume it: a data-residency section, the published sub-processor list (mirroring the standalone /subprocessors page so the answer is the same wherever the reviewer lands), SOC 2 control mappings with per-control status labels, and a downloadable-pack request form on the same page — the form that ships the artefact a reviewer's NDA covers.
The operational posture behind the checklist lives on the Security page: encryption at rest and in transit, per-tenant data isolation, authentication, and the tenant-owned settings above are documented there, with links from the Trust Center. The two pages together are the answer this post points to — if a question on your questionnaire names a framework, the Trust Center's mappings and the Security page's documentation are the surfaces to read, and the checklist above tells you which questions those surfaces have to survive.
Frequently asked questions
Does a CPaaS vendor need both SOC 2 and ISO 27001?
No. One current artefact, scoped to the product you're buying, usually answers the questionnaire. Vendors that sell into both North American and European procurement often hold both because each side's checklist names a different one. The buyer-side move is to match the framework the RFP names, not to demand both.
My RFP says 'SOC 2' and the vendor has ISO 27001 — is that a pass?
Usually, yes — most checklists accept either as "formal assurance in place." Confirming acceptance rules with your reviewer before disqualifying a vendor saves a re-shortlist; a vendor that holds one framework is a different answer than a vendor that holds neither.
Does the vendor's attestation cover my tenant's controls?
No. The vendor's report covers the vendor's controls; your auditor grades yours. Tenant-side controls like SCIM, key allowlists, and the audit log are the surfaces you configure and your auditor examines. On Orbit those controls are documented in the guides linked from the Security page.
Which settings should we configure before our own audit?
Identity and access first (SSO and SCIM if your IdP supports them, per-key allowlists for machine credentials), then evidence generation. The binder walkthrough covers the generate-and-verify cadence; the checklist above tells you which questions your auditor is likely to ask.
The takeaway
Assurance frameworks are a document-compression device: they let a procurement team ask two questions instead of three hundred. Your job as the buyer is to know which artefact the RFP actually accepts, what each framework proves, and which parts of the answer live as tenant-side settings you configure. Run the nine questions against every vendor on the short list, read the scope and observation windows on whatever artefact comes back, and the questionnaire stops being a chase.
For Orbit's own posture the two pointers are the Trust Center and the Security page; for the tenant-side evidence workflow, start with the binder walkthrough and the GDPR audit evidence checklist, and close the loop with the enterprise security checklist for the identity-plumbing pass.