Where does our data go during an engagement?

By default, nowhere. The work happens in accounts and infrastructure you provision, under your identity provider and your logging. The systems we build are designed so the documents stay on your side of the network boundary in production, and the same arrangement applies while we are building them.

Will you complete our security questionnaire?

Yes. HECVAT, SIG Lite, CAIQ and institution-specific questionnaires are all fine. Send it over with your timeline and we will tell you straight away whether we can meet it.

No, and it would not tell you much here. A SOC 2 report attests to controls at a service organization running a system on your behalf. This is a different shape: the system runs in your environment, under your controls, and gets assessed as part of it. If your process requires an attestation anyway, tell us early and we will work out what evidence satisfies it. Worth knowing too that SOC 2 is not a certification, it is a report containing a CPA firm’s opinion.

Who works on the engagement?

The practice is two people, and the work is done by those two people. Access, notice and offboarding terms are set out in the engagement letter.

§Security and trust

The deployment sits inside your boundary.

Most vendor risk questions come down to one: where does our data go? Here it stays where it already is, in your infrastructure, under your identity provider, your logging and your change management. The system inherits the controls you have rather than adding a new party for someone to assess.

Request a demo Send a questionnaire

Last updated: 13 August 2026

Data custody

Where your documents sit during the work.

Which arrangement applies is agreed in writing before work starts, so there is never a question about it later. The default is the strict one.

Mode ADefault

In your tenant

We work in accounts you provision, under your identity provider, your MFA, your logging and your session controls. Your data stays in systems you own, and access is revoked by you.

Mode BRarely, and only if you ask

Your data in our environment

This is not how engagements are normally structured, and nothing about the architecture requires it. If your situation genuinely needs it, the terms are negotiated explicitly rather than assumed.

What the system does

Four things that come out of how it is built.

Each of these is a property of the architecture rather than a policy we promise to follow, which is what makes the deployment auditable in a way a hosted assistant is not.

The documents stay put

Retrieval, generation and verification all run inside the boundary the documents already sit in. Nothing about the design requires a copy of your corpus to exist anywhere else.

No training on your text

Nothing is sent to a model vendor, so there is no third party in a position to train on your documents and no retention window to ask about.

Retrieval respects your permissions

The authorization predicate runs inside each retrieval arm rather than filtering results afterwards, backed by row-level security in the database. A restricted passage is never a candidate in the first place.

Every answer is traceable

Citations are constrained to the sources actually retrieved, quotations are sliced from stored offsets rather than written by the model, and each released answer is recorded with its verdicts in an append-only ledger.

Where an engagement genuinely calls for a hosted model, we name the endpoint and tell you what agreement governs it. We do not make the argument that our hosting provider’s authorization covers us.

Compliance

Which frameworks apply here, and which do not.

Each row says what it says because of how the deployment is shaped, with the source that supports it. Your reviewer can check any of them.

TX-RAMP
Applicability
Out of scope
Basis
Program Manual v3.1 §7.3 places professional services — administration, oversight, deployment and maintenance — outside TX-RAMP scope, and §7.4 does the same for bespoke commissioned applications. Your ISO makes the scoping determination; we support it and will complete the acknowledgement questionnaire on request.
FedRAMP
Applicability
Not applicable
Basis
FedRAMP authorizes cloud service offerings. We do not operate one — the system runs in your environment, not ours.
PCI DSS
Applicability
Not applicable
Basis
Cardholder data is not part of any engagement of this kind.
HIPAA
Applicability
Deployment-dependent
Basis
No model is “HIPAA compliant”. The Security Rule governs deployments, not models. A deployment inside your own infrastructure keeps PHI within your existing covered-entity boundary rather than creating a new disclosure to assess.
FERPA
Applicability
Institution-dependent
Basis
Where education records are in scope, the relevant question is the School Official exception under 34 CFR §99.31(a)(1)(i)(B), which requires direct institutional control over use and maintenance. A deployment inside institutional infrastructure is the straightforward way to satisfy it.

Compliance framework applicability
Framework	Applicability	Basis
TX-RAMP	Out of scope	Program Manual v3.1 §7.3 places professional services — administration, oversight, deployment and maintenance — outside TX-RAMP scope, and §7.4 does the same for bespoke commissioned applications. Your ISO makes the scoping determination; we support it and will complete the acknowledgement questionnaire on request.
FedRAMP	Not applicable	FedRAMP authorizes cloud service offerings. We do not operate one — the system runs in your environment, not ours.
PCI DSS	Not applicable	Cardholder data is not part of any engagement of this kind.
HIPAA	Deployment-dependent	No model is “HIPAA compliant”. The Security Rule governs deployments, not models. A deployment inside your own infrastructure keeps PHI within your existing covered-entity boundary rather than creating a new disclosure to assess.
FERPA	Institution-dependent	Where education records are in scope, the relevant question is the School Official exception under 34 CFR §99.31(a)(1)(i)(B), which requires direct institutional control over use and maintenance. A deployment inside institutional infrastructure is the straightforward way to satisfy it.

The architecture is what carries the weight here. The deployment runs inside your boundary, under your controls, and gets assessed as part of your environment rather than as a new third party bolted onto it. Supervisory guidance expects reviewers to weigh exactly that kind of evidence.

Questions

What reviewers ask.

Request a demo

Questionnaires and diligence requests: contact@eigenatomconsulting.com

Where does our data go during an engagement?: By default, nowhere. The work happens in accounts and infrastructure you provision, under your identity provider and your logging. The systems we build are designed so the documents stay on your side of the network boundary in production, and the same arrangement applies while we are building them.
Will you complete our security questionnaire?: Yes. HECVAT, SIG Lite, CAIQ and institution-specific questionnaires are all fine. Send it over with your timeline and we will tell you straight away whether we can meet it.
Do you have SOC 2?: No, and it would not tell you much here. A SOC 2 report attests to controls at a service organization running a system on your behalf. This is a different shape: the system runs in your environment, under your controls, and gets assessed as part of it. If your process requires an attestation anyway, tell us early and we will work out what evidence satisfies it. Worth knowing too that SOC 2 is not a certification, it is a report containing a CPA firm’s opinion.
Who works on the engagement?: The practice is two people, and the work is done by those two people. Access, notice and offboarding terms are set out in the engagement letter.