Our starting assumption
Your security team has protocols that exist for good reasons and have been refined over years. Our job is to work within them, not to argue that our situation is special. If your process requires an artifact, we will produce it or tell you plainly that we cannot. If your policy prohibits something, the answer is to change the architecture, not to seek an exception.
That posture is worth stating because AI vendors have earned some suspicion here. A lot of AI tooling arrives with vague assurances and an implicit request to be trusted. We would rather be assessed.
A route that works
Step 1 — Send us your questionnaire, and tell us your data classification. The single most useful thing you can give us early is which tier of your own classification scheme this system will touch, and whether any regulatory regime applies. That determines the deployment model, and the deployment model determines most of the answers. If we start there, we avoid answering a hundred questions about a configuration you would never approve.
Step 2 — Take the documents. Everything in the confidential library is available after a one-minute NDA acceptance. Most reviewers find the useful set is the architecture detail, the connector inventory with exact permission scopes, the AI model register, the incident response plan, the business continuity plan with recovery objectives, and whichever completed questionnaire matches your process. All of it downloads as PDF for attaching to your own case file.
Step 3 — Book a technical session. Our engineering lead joins directly; you will not be handed to a sales engineer reading from a script. Bring your integration and identity people. The most productive sessions we have had spent their time on Microsoft Graph permission scopes, identity federation, what the AI models are actually permitted to see, and the boundary between advisory and actuating behaviour.
Step 4 — Tell us what needs to change. Expect to have requirements. Reasonable ones we implement as conditions of the engagement and record in the contract. If something is not possible we say so at the time rather than agreeing and discovering it later.
Step 5 — Fix the terms in writing. Whatever we commit to in the review belongs in the contract: deployment model, data locations, retention periods, breach notification timelines, subprocessor notice, audit rights, deletion on termination. A commitment that exists only in a slide is not a commitment.
Where the engagement-specific material lives
The trust center is our general documentation. Everything specific to your system — architecture and data-flow diagrams naming your actual sources, the connector inventory with the exact scopes we will request from you, the model register naming versions and regions, evaluation results, and the status of any examination scoped to your system — is prepared for you and shared directly under NDA. It is not published here, and neither is any other client’s.
That is a deliberate split rather than an omission. Publishing per-engagement detail would mean publishing a map of a client’s estate, and no client should have to accept that as the price of our transparency.
What we will provide
Completed HECVAT 4 and CSA CAIQ v4 responses. Our full policy and standard set. Architecture and data-flow documentation, including trust boundaries and egress paths per deployment model. A connector inventory listing every integration and its exact permission scopes. The AI model register with providers, regions, and retention terms. Incident response and business continuity plans with stated objectives. An accessibility conformance report. A SAML 2.0 and Shibboleth readiness profile for institutions requiring federated authentication. Direct access to the engineer who builds the system.
Where our position needs explaining
Two things a reviewer will look for are worth setting out directly, because the reasoning matters more than a yes or no.
A SOC 2 report covering your system. A SOC 2 opinion covers a defined system with an operating history. We build bespoke software per client, so at the point you are assessing us the system that will hold your data is being designed rather than running — there is nothing yet for an auditor to form an opinion about. We build to the Trust Services Criteria from the first commit so the delivered system is auditable by design, and we will submit it to examination once live, as a contractual milestone if you want it that way. Compliance and certifications sets out the reasoning and the sequence.
An independent penetration test report. On our near-term roadmap, and not dependent on your build. Meanwhile we support client-commissioned testing of your own deployment at no charge, which is a stronger assurance for you than a generic report anyway. See Penetration testing program.
We can share client references where that client has agreed to be named, and we are glad to. Any client’s security detail — architecture, controls, assessment results — stays confidential, exactly as yours will.
Requirements we already know some institutions have
A completed HECVAT workbook in its original spreadsheet format, with all tabs intact. Some institutions accept no other format and only the current major version. We maintain our answers as a narrative document in this library and transfer them into the current official workbook on request, so you get the file your process needs. Ask at trust@vectyr.co and tell us the version you require.
SAML 2.0 federation with the institution’s identity service, sometimes non-negotiable where the institution’s own users will authenticate. We support SAML 2.0 and OIDC, and our readiness profile is in the library.
A separate review for health-system data, run by a different team under a different process than the university’s central review. If your institution has both, tell us which applies, because the requirements differ and we would rather run the right one once.
Accessibility review against WCAG. Our conformance report covers the interfaces we build.
Warranting the questionnaire response contractually, with material deviation treated as material breach. We accept that, and it is why our answers are conservative.
What we need from you
The data classification and any regulatory regime, as early as possible. The name of the person who can grant application consent in your identity platform, since integration scope is the crux of the design. Your standard data-processing and security terms, so we can work from your template. Any hard gates in your process, told to us at the start — if a SOC 2 report is mandatory with no compensating route, we would both rather know in week one.
Getting started
Request access to the confidential library, or email trust@vectyr.co with your questionnaire attached and we will come back with a completed response and a proposed technical session.
