Security and Compliance
Security & Compliance
Version 1.0 · Last reviewed [DATE] · Next review [DATE + 3 months]
This page is the short answer to the questions procurement sends. If you need more than is here, ask and you will get it — [CONTACT ADDRESS].
We are a small consultancy. Some of the answers below are “no”, and they are written as “no” rather than dressed up, because you would find out anyway and the finding out would cost more than the answer.
Where we stand
| Legal entity | Hyper Viral LLC, trading as Totomoko |
| Size | A small team. This is relevant to several answers below and it is not hidden |
| Certifications we hold | None. Not SOC 2, not ISO 27001, not ISO 42001. See Q8 — this is a scope limit, honestly stated, and it is not in progress |
| Certifications our sub-processors hold | Named per provider at DPA stage — see Q2 |
| Insurance | None. Deferred by decision — see Q10, including why the AI-exclusion position would matter as much as the limit |
| Security baseline | Aligned to relevant NIST CSF and ISO 27001 controls. No third-party audit |
| Contact for anything on this page | [CONTACT ADDRESS] |
The ten questions
Q1. Do you train on our data, or share it with third parties for model training?
No. We do not opt client data into model training, we do not enrol in provider programmes that would, and we use zero-retention routes where a provider offers one. ⚠ The specific providers in our stack, with each one’s written no-training commitment, are named at the point we sign a DPA with you — Q-A23-3. Naming a stack here that has moved would be worse than naming it once, to you, in writing.
Q2. Which AI providers and tools see our data, and where is it stored?
You get a complete list — every model provider, automation platform, store and mail service that could touch your data, with each one’s role, the data category it handles, and where it processes it — as part of the data processing agreement, before any of your data moves. We commit to telling you within 30 days of any change to that list.
⚠ We do not publish a standing public sub-processor list today. We have no processing clients, so such a page would name nobody, and an empty list reads as neglect rather than transparency. It goes up when there is something true to put on it.
Q3. What happens to AI-generated output? Is there human review before delivery?
Yes, and it is not a policy statement — it is where the gate physically sits. Every AI-generated artefact that reaches you, or reaches your customers, is reviewed by a person here before it goes. Systems we build for you carry human-in-the-loop approval on customer-facing actions and a validation step before anything irreversible — sending, publishing, paying, deleting, modifying a record of record.
We treat a hallucination as a defect, not as weather. When one occurs we fix the prompt, the harness or the guardrail that let it through, and we tell you what we changed.
Q4. How do you defend against prompt injection and adversarial input?
By assuming it is coming. Every piece of third-party content a workflow ingests — an email, a web page, a document, anything a customer typed — is untrusted by default and is never treated as instruction. We constrain outputs to schemas rather than parsing free text, keep the model that plans separate from the one that executes tools, and require explicit human approval for any irreversible action an AI system proposes. Where a system is unsure, it is built to stop rather than to guess.
Q5. How is data encrypted, and how is access to it controlled?
In transit, TLS 1.2 or better. At rest, AES-256 through the providers we use. Every administrative account is behind multi-factor authentication, and credentials live in a password manager — never in code, never in environment files in a repository, never in a document.
Each engagement is isolated: its own credential vault and its own scoped service-account token, so a credential compromised on one engagement cannot reach another. Infrastructure we run is not exposed to the public internet — no open inbound ports, access through an authenticated tunnel with an explicit allow-list.
Q6. How long do you keep our data, and how do we get it back or deleted?
For the engagement plus 30 days, unless your contract says otherwise. On written request we export or delete your data within 30 days.
Model-provider retention is theirs, not ours, and it varies by provider and by route — the exact window for each provider in your engagement is stated in the DPA rather than summarised here, because summarising it is how it goes stale.
Q7. What is your incident response and breach notification timeline?
If we confirm a security incident affecting your data, you hear from us in writing within 72 hours of that confirmation — what we know, what we are doing, and what you may need to do. You get a named contact, not a support queue.
Behind that commitment is a written runbook — how we contain, what we preserve as evidence, how severity is decided, who is told in what order, and the post-incident review we will offer you afterwards. It is part of the security baseline available on request.
Two things we will not claim. We are not a 24/7 security operations centre, and we do not promise a detection window — the 72-hour clock runs from the moment we confirm an incident, which is what the law measures and the only thing a team our size can honour.
And once a system is handed over to you, we are not watching it — your operators run it, and our access is revoked, which is the right outcome and means we cannot see it. So on a delivered system the clock starts when you tell us. We would rather say that than let “72 hours” sound like something it is not. If you want us to keep visibility of a system after handover, ask — it is a scoping question, not a refusal.
Q8. What standards or certifications do you align to, and what is your audit posture?
We are not SOC 2 or ISO 27001 certified, and no audit is under way. At our size that is an honest scope limit rather than a gap we are hiding, and we will say the same thing on a call.
What is true: our internal baseline is aligned to relevant NIST CSF and ISO 27001 controls, the infrastructure and model providers we build on carry their own certifications, and our written security baseline — access architecture, MFA posture, backup and restore, encryption, incident response — is available to you on request.
If certification is a hard procurement gate for you, tell us early. It is better for both of us to know in the first conversation than in the fourth.
Q9. How do you handle the EU AI Act and other AI regulation?
We are typically a deployer of general-purpose AI systems under Article 3(4) — we build with models that upstream providers built and provide. We are not a GPAI provider, and we do not claim the obligations or the standing of one.
We disclose AI-generated and AI-manipulated content in what we deliver and in what we build for you, per Article 50. Where your use case is high-risk — decisions about employment, credit, access to services, regulated communications — we will tell you that before we scope it, and the human-oversight, logging and disclosure duties that come with deployer status get built into the work rather than bolted on after.
Q10. Do you carry business insurance?
⚠ No. No policy is bound, and buying one is deferred for now — a deliberate decision, not an oversight or a delay we are hoping you will not notice.
When it is bound, this answer will name four things: the cover held, the limits, whether AI work is affirmatively covered, and a certificate on request. The third is there deliberately — a policy can name Technology Errors & Omissions at a healthy limit and still carry an exclusion that removes every claim this kind of work could produce. A supplier who tells you the line and the limit but not the AI position has told you the reassuring two-thirds. Ask us, and ask anyone else you are considering.
We know this is a gate for some buyers, and that a certificate is an ordinary thing to ask for. If it is a gate for you, say so early — it is a decision that can be revisited for an engagement that needs it, and it is far better raised in the first conversation than in the fourth.
How we use AI — the disclosure
This section is the AI disclosure. It sits here rather than on a page of its own, because everything it would say is already an answer above.
Four things, plainly:
- What AI we use. We build on third-party foundation models, on their commercial API terms. ⚠ The specific providers in your engagement are named in your DPA — Q-A23-3.
- What it touches. Nothing you send through this website reaches a model. Inside an engagement, what a model sees is scoped in writing before anything moves — Q1, Q2 and Q6.
- Where the human is. Between every AI system and anything consequential. Every delivered artefact is reviewed by a person; every irreversible action needs an approval — Q3.
- What we are, legally. A deployer, not a provider, of general-purpose AI. We disclose AI-generated content in what we deliver — Q9.
And the commitment underneath the offer itself: we build so that the model is a component you can swap, not a landlord you rent from. That is not a compliance position — it is what the work is for.
It is also in the contract, not just on this page. Our master services agreement gives you a perpetual, irrevocable licence to anything of ours embedded in what we build for you, and commits that deliverables are handed over in a portable, documented form you can take elsewhere. Ask for those clauses before you sign anything with anyone — if a supplier’s portability lives only on a web page, they are selling you lock-in with a policy attached.
More detail
| Terms · Privacy | The public documents |
| Full security baseline | On request — [CONTACT ADDRESS] |
| Data processing agreement, sub-processor list, provider attestations | Provided at engagement, before any data moves |
| Certificate of insurance | ⚠ On request once bound — Q10 |
Reviewed quarterly. If something on this page has gone stale, tell us and we will fix it.