Quick answer: A vendor security review on a communications platform is a document chase your procurement team should be able to complete from public pages, not a three-week thread of red-lined emails. Devotel Orbit publishes the four surfaces a reviewer asks for — a Trust Center, a Security page, a subprocessor list, and the SLA attestation with downloadable agreements — and maintains a set of buyer-facing compliance walkthroughs on this blog. This post maps the common questionnaire bullets to those surfaces so the review runs on evidence, not on a sales answer.
Everything below is a workflow, 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 certification claim this post cannot make. A formal SOC 2 Type II audit is in planning and named as such on the Trust page, which is exactly the posture a reviewer should see stated plainly.
What a security review must receive
Procurement and infosec teams ask for the same five things on nearly every questionnaire, regardless of the framework name on the cover page:
- The vendor's own security posture. A public page that states how the platform encrypts, scopes access, and handles data — not an attestation letter behind a sales email, because the reviewer's first check is whether the claim is findable.
- A subprocessor list with current data residency. Where the personal data the platform touches actually processes, and the downstream providers a message or call passes through before reaching the network. Each subprocessor's role, data classes, and residency should be stated, not a brand name with no qualifier.
- Instrument-attested service levels. Uptime, delivery rates, and support SLA attainment drawn from production records, downloadable without a paid tier — a reviewer discounts a status page that needs a sales call to read.
- Framework answers the questionnaire actually accepts. Whether the reviewer's checklist wants SOC 2, ISO 27001, GDPR DPA articles, HIPAA BAAs, or a regional regime like India's DPDP, the vendor should name which document its reviewer can accept and which controls on its side support that answer.
- The tenant-side runbook. The controls the reviewer attributes to the tenant — consent capture, quiet hours, retention, audience registry — with a plain statement that they are the tenant's to configure, because the split of responsibility is the first thing a good reviewer tests.
A vendor that hands over those five things on public pages clears the screening round. A vendor that answers every bullet with "open a support ticket" stays in the red pile regardless of its actual posture.
Orbit's published trust surface
Devotel Orbit publishes the trust surface on four standalone pages, each reachable without a login and kept current on a stated cadence:
- The [Trust Center](/trust). The hub: data residency, the subprocessor list rendered the same way as the standalone page, the control mapping against the SOC 2 framework, downloadable agreements, and the SLA attestation described below. It is also where Orbit names the assurance framework status plainly — the SOC 2 Type II audit is in planning, and the page says so.
- The [Security page](/security). The posture statement: encryption in transit and at rest, access control model, incident handling, and the operational controls a reviewer's own checklist enumerates.
- The [subprocessor list](/subprocessors). Every downstream provider a message or call touches before it reaches the carrier, with each subprocessor's role, the data classes it handles, and its processing region — the granularity a DPA schedule asks for.
- The [SLA attestation](/trust). Uptime targets, per-channel delivery rates, and support SLA attainment instrumented from production records and downloadable as PDF or CSV — not a marketing status page.
These pages exist so a reviewer can complete the screening round from the public site. The buyer's checklist for choosing an assurance framework walks the framework question itself — what SOC 2 and ISO 27001 each prove, and how to decide which one the questionnaire wants.
Mapping the common infosec bullets to Orbit pages and walkthroughs
Below is the mapping a reviewer can run against Orbit's public surfaces without a meeting. The blog walkthroughs are the long-form counterparts to each topic — the reviewer links them once and bookmarks the page that stays ungated.
| Questionnaire bullet | Public page | Buyer walkthrough |
|---|---|---|
| Data residency and GDPR posture | Trust Center | GDPR data residency checklist |
| Audit evidence and deterministic compliance pack | Trust Center | Evidence-binder walkthrough |
| HIPAA healthcare scope and BAA picture | Security page | HIPAA-ready CPaaS checklist |
| Consent architecture under India DPDP | Security page | DPDP consent-receipt walkthrough |
| Assurance-framework questions (SOC 2 / ISO 27001) | Trust Center | SOC 2 vs ISO 27001 guide |
| Subprocessor data classes and residency | Subprocessor list | GDPR data residency checklist |
| Service levels and attestable uptime | Trust Center SLA attestation | SOC 2 vs ISO 27001 guide |
| Tenant-side controls the reviewer attributes to you | Security page runbook below | — |
The table's claim is modest on purpose: each row points to a public page you can read now, and the checklist names what it does not as plainly as what it does.
Evidence cadence recommendations
A vendor trust surface is only as useful as its refresh cadence. These are the rhythms to look for and to hold the vendor to:
- Subprocessor list. Urgent additions announced ahead of subprocessor onboarding; the list reflects the current processing chain, not the one from the last annual review.
- SLA attestation. Generated from production records on a standing cadence, downloadable on demand — a quarterly PDF behind a paywall tells a reviewer the number is being staged.
- Control mappings and agreements. Reviewed on the same annual cycle as the vendor's own policy review, with the review date stamped on the page.
- Buyer walkthroughs. Maintained against the frameworks, not against the vendor's release calendar — a reviewer should be able to rely on the mapping months after the post date, which is why every checklist above links back to the canonical page and the canonical page links back out.
Where the cadence is not visible, treat the page as marketing and ask for the dated artifact instead.
Checker tools to run before the questionnaire
Two free, ungated tools let you rehearse the tenant-side answers a reviewer asks for before the questionnaire arrives:
- The HIPAA checklist tool scores your workspace's healthcare posture against the questions a healthcare reviewer usually leads with — a buyer-side mirror of the checklist post above.
- The Trust Center is itself the surface to re-run against the mapping table every cycle, so the reviewer's checklist links stop shifting with each vendor update.
Both are deliberately ungated: a compliance answer that requires a login or a paid tier is a compliance answer designed to be negotiated over, and the security review should not have to negotiate for the artifact.
Frequently asked questions
Does Orbit hold a SOC 2 Type II report today? The Trust page names the posture plainly: the formal SOC 2 Type II audit is in planning. A reviewer should see that on the page rather than in a sales answer, and the mapping table above points the framework question to the shipped public pages.
Can the reviewer complete the screening round without contacting sales? Yes. The Trust Center, Security page, subprocessor list, and SLA attestation are all public pages; the blog walkthroughs the mapping table links are ungated as well. The questionnaire replies that are not covered by those pages are the ones that genuinely need a conversation.
Which controls are the tenant's to configure? Consent capture, quiet-hours windows, retention windows, audience registries, and similar posture are tenant-owned by design — the reviewer attributes them to you, and Orbit documents them as tenant-configurable on the Security page and the checklist posts above.
What if the questionnaire names a framework the checker tools do not cover? Run the same mapping exercise: find the public page or walkthrough that speaks to the control set the framework names, and link it into the reviewer's checklist. When a framework question genuinely has no public answer, that gap is the conversation to have — not a document to invent in the questionnaire.