The short answer
Vectyr does not hold a SOC 2 report, and the reason is worth understanding rather than filing as a deficiency: the system your review is about does not exist yet.
A SOC 2 report is not a badge a company earns once. It is an auditor’s opinion on a defined system, describing controls that were in place and — for a Type 2 — operating over a period of months. We build bespoke software per client. At the point you are assessing us, the system that will hold your data is being designed, not running. There is no operating period to examine and no system description to audit, so there is no report to produce. Any vendor in that position claiming a SOC 2 covering your system would be describing something else.
What we commit to instead:
We build to SOC 2 criteria from the first commit. Our control set is written and mapped to the Trust Services Criteria, so the delivered system is auditable by design rather than retrofitted later. Control framework crosswalk shows the mapping control by control, with an honest status for each.
Once your system is built and operating, we will pursue an examination scoped to it if your requirements call for one, including a Type 1 as an earlier milestone and a Type 2 once it has operated long enough. You scope it, and you can require it as a contractual milestone rather than taking it on trust.
We are not going to wave an irrelevant certificate at you. See the next section — this is the part most vendors get wrong.
What we deliberately will not offer as a substitute
A SOC 2 covering our own internal systems. We could in principle put Vectyr’s corporate systems — this website, our internal CRM, our business tooling — through an examination. We are not going to present that as assurance about your system, because those systems are fully isolated from client deployments and hold no client project data. A report on them would tell you nothing about the software that will read your meetings and documents, while looking like it did. That is worse than having no report, because it invites a reviewer to close an item that is actually still open. The isolation itself is a real control and is described in Tenancy and isolation; it is just not an audit substitute.
Our hosting providers’ certificates. Cloudflare holds SOC 2 Type II and ISO/IEC 27001 certification, and our dedicated-compute providers hold their own. Those cover the platform layer, not our practices. Real assurance, wrong scope.
Another client’s security posture. We may name clients as references or in sales material where that client has agreed to be named — that is ordinary commercial social proof. What we will never disclose is any client’s security posture, architecture, controls, assessment results, or compliance status, and we would not offer another client’s audit as evidence about us. The same line protects you: your architecture and your assessment stay between us.
Current status, item by item
| Item | Status | Notes |
|---|---|---|
| SOC 2 for your delivered system | Not yet possible | The system is not built, so there is no operating period to examine. Built to the Trust Services Criteria from the start; examination available once live if required. See above. |
| SOC 2 for Vectyr’s internal systems | Deliberately not offered as a substitute | Our corporate systems are fully isolated from client deployments and hold no client data, so a report on them would not be evidence about your system. We would rather not close an item in your review that is genuinely still open. |
| SOC 2 for the underlying platform | Held by our hosting providers | Covers the platform layer only. Not a substitute for a report on the delivered system, and we do not present it as one. |
| ISO/IEC 27001 (Vectyr) | On the roadmap | Policy set structured against Annex A so certification is a documentation exercise rather than a rebuild. Unlike SOC 2 it certifies an organizational management system rather than a specific system, so it is achievable independently of a client build. |
| HECVAT 4 | Completed response available | Full narrative response covering all applicable domains. The completed workbook is provided on request. See below. |
| CSA CAIQ v4 | Completed response available | Available in the confidential library. |
| Independent penetration test | On the near-term roadmap | Continuous internal testing operating now; client-commissioned testing of your deployment supported at no charge. See Penetration testing program. |
| HIPAA Business Associate Agreement | Available where applicable | We will sign a BAA where an engagement may involve protected health information. Our default posture is to architect so that PHI is not processed at all. See the research institution annex. |
| GDPR / UK GDPR | Data processing agreement available | Standard contractual clauses for transfers where required. See International data transfers. |
| Accessibility (WCAG 2.1 AA) | Conformance report available | Self-assessed accessibility conformance report. See Accessibility conformance. |
Why we are precise about this
It would be easy to write “SOC 2 aligned,” gesture at our platform provider’s certificates, and let a reviewer draw a comfortable conclusion. That approach survives right up until someone asks for the report, at which point the vendor has spent the reviewer’s goodwill on something they were going to discover anyway.
It is also worth being clear that “the system isn’t built yet” is an explanation of scope, not a request for an exemption. It does not reduce what we owe you now: the controls are written, they are implemented as we build, they are mapped to the criteria an auditor would test, and we will submit to that audit once there is a system to audit. If we were asking you to accept intentions in place of controls, you should refuse.
There is a further reason to be careful here. Institutions frequently require a vendor to warrant that its services conform to the information given in its questionnaire response, and treat a material deviation as a material breach of contract. That is a sensible requirement, and it means every claim in our HECVAT and CAIQ responses is a contractual statement rather than marketing. We answer them conservatively for exactly that reason: we would rather answer “partially, and here is what is missing” than answer “yes” and be wrong later.
The path to an audited system
Sequenced by dependency rather than by date, because the early steps depend on your build and committing to dates we only partly control is how roadmaps lose credibility.
1. Build to the criteria. Happening now, on every engagement. Controls are written, mapped to the Trust Services Criteria, and implemented as the system is built. The point of doing this first is that retrofitting auditability into a finished system is expensive and usually visible in the report.
2. Independent penetration test. Of the platform and of a representative client deployment, with a remediation cycle and a summary letter shareable under NDA. This is the highest-value assurance artifact available before a system has an operating history, and it is our next step. It does not depend on your build finishing. See Penetration testing program.
3. Readiness assessment against the delivered system. Once your system is live, a gap assessment against the Security, Availability, and Confidentiality criteria, producing a gap list and an evidence plan for the actual system rather than a hypothetical one.
4. Type 1 examination. An opinion on control design at a point in time. Achievable relatively soon after go-live, and often enough to satisfy a procurement requirement that would otherwise wait a year.
5. Type 2 examination. An opinion on operating effectiveness over a period, typically three to twelve months of operation. This is the report most requirements mean, and the observation window is why it cannot precede the build. Scope, criteria, and period would be agreed with you.
ISO/IEC 27001, in parallel and independent of any client build, where client demand justifies it.
Steps 3 to 5 can be written into your contract as milestones with a named auditor, rather than left as intentions. We would rather be held to that than be believed.
We will update this page as each item completes, and the version and date at the top tell you when it was last true. To be clear about what this page is: it tracks Vectyr’s own programme, not the status of any individual client’s system. Where an examination is scoped to your system, its status is reported to you directly rather than published here.
What to do in the meantime
Several routes work, and we are glad to take any of them.
Bound the exposure with the integration grant. The credential our system uses is one you create, scope, and can revoke unilaterally at any time without contacting us, and you can inspect exactly what it permits in your own tooling. That is a control you hold rather than one you have to take on trust, and narrowing it is the single most effective thing a reviewer can do. See Microsoft 365 integration security.
Rely on the completed HECVAT or CAIQ response, contractually warranted, plus a technical session with our engineering lead. In practice this is what most reviews have needed.
Require the examination as a contractual milestone, scoped by you, with the report delivered before a defined production or expansion date.
Run your own assessment. We will complete your questionnaire, join a technical deep-dive, provide architecture and configuration evidence, support a client-commissioned penetration test of the deployed system at no charge, and accept audit rights in the contract.
Contact trust@vectyr.co with the specific artifact your process requires and we will tell you honestly whether we can provide it, provide an equivalent, or not.
