Security and Compliance

This page states Totomoko's security and compliance position for organizations assessing us as a supplier. Anything not covered here is available on request through the security form at /contact/security/.

1. About Totomoko

1.1 Entity

Hyper Viral LLC, a limited liability company formed in the State of Wyoming, United States, trading as Totomoko.

1.2 Operating model

Totomoko works remotely, worldwide, with teams assembled for each engagement, and inside the client’s environment where the work requires it.

1.3 What we do

We advise on, design, build, and operate AI and automation systems and the data infrastructure behind them. Client data is processed only as an engagement requires, and each engagement is governed by a signed agreement and data processing terms.

1.4 Contact

Security matters: the security form. Procurement and contract matters: the legal inquiries form.

2. Standards and audits

2.1 Security baseline

Our internal controls are aligned to the relevant controls of the NIST Cybersecurity Framework and ISO/IEC 27001, and our AI practice to the NIST AI Risk Management Framework and ISO/IEC 42001.

2.2 Sub-processor certifications

The infrastructure and model providers we build on carry their own certifications. Each provider’s attestations are supplied with the sub-processor list at engagement stage (Clause 4.2).

2.3 Documentation available on request

Further detail on the controls described on this page, covering access architecture, authentication, encryption, backup and restore, incident response, and the controls applied to AI systems, is provided to prospective clients on request under a non-disclosure agreement.

3. Client data and AI models

3.1 No training on client data

We do not use client data to train or fine-tune models for anyone other than that client. We do not opt client data into any provider’s training program, and where a provider offers a zero-retention route we use it.

3.2 Data used only for the engagement

Client data is used solely to perform the engagement it was provided for, and is not used for any other client, for marketing, or for Totomoko’s own product development.

3.3 Private deployment where required

Where a client’s law, policy, or risk position requires that data not leave its environment, models are deployed privately: on-premise, in the client’s private cloud, hybrid, edge, or air-gapped.

3.4 Disclosure of AI use

In most engagements Totomoko acts as a deployer of AI systems within the meaning of Article 3(4) of the EU AI Act, building on models supplied by third-party providers; it is not a provider of general-purpose AI models. Where an engagement makes Totomoko or the client a provider of an AI system, the obligations that follow are identified at scoping. We apply the transparency obligations of Article 50 where they arise, and where a use case falls within a high-risk category we identify that before scoping and build the applicable obligations into the delivery.

4. Sub-processors

4.1 Website

The providers that process data for this website and for our business are on the Subprocessors page and in the Privacy Notice, Clause 6.1.

4.2 Engagements

Before any client data moves, the client receives a complete list of every model provider, automation platform, data store, and mail service that could touch that data, with each provider’s role, the categories of data it handles, and where it processes them. The list is an annex to the data processing agreement.

4.3 Notice of change

We notify the client in writing at least thirty (30) days before adding or replacing a sub-processor that handles the client’s data, and the client may object on reasonable grounds relating to data protection.

5. Human oversight of AI output

5.1 Review before delivery

Every AI-generated artefact that reaches a client, or a client’s customers, is reviewed by a person at Totomoko before it is delivered.

5.2 Approval gates in delivered systems

Systems we build carry human-in-the-loop approval on customer-facing actions and a validation step before any irreversible action: sending, publishing, paying, deleting, or modifying a system of record. Limits on what an automated system may do without a person are agreed in writing before the system goes live.

5.3 Defects

A hallucination or an incorrect automated action is treated as a defect. When one occurs, we correct the prompt, harness, or guardrail that allowed it and tell the client what was changed.

6. Prompt injection and adversarial input

6.1 Untrusted by default

Every piece of third-party content a workflow ingests, including emails, web pages, documents, and anything entered by an end user, is treated as data and never as instruction.

6.2 Controls

Outputs are constrained to defined schemas rather than parsed from free text; the model that plans is separated from the component that executes tools; agents run with credentials scoped to the task and session; and any irreversible action proposed by an AI system requires explicit human approval. Where a system is uncertain, it is built to stop rather than to guess.

6.3 Testing

Systems are tested for prompt injection and goal hijacking before release, and isolated so that a compromised step cannot reach live systems.

7. Encryption and access control

7.1 Encryption

Data in transit is protected by TLS 1.2 or higher. Data at rest is encrypted with AES-256 or equivalent through the providers we use.

7.2 Authentication

Every administrative account is protected by multi-factor authentication. Credentials are held in a password manager and are never stored in code, in repository configuration, or in documents.

7.3 Engagement isolation

Each engagement has its own credential vault and its own scoped service-account tokens, so a credential compromised on one engagement cannot reach another.

7.4 Infrastructure exposure

Infrastructure we operate is not publicly exposed; access is authenticated and restricted.

7.5 Access review

Access to client environments is granted per engagement, limited to the people working on it, reviewed at each milestone, and revoked at handover or when a person leaves the engagement.

7.6 Endpoints

Devices used for client work are full-disk encrypted, protected by a passcode and automatic lock, kept current with operating-system and application updates, and do not hold client credentials outside the password manager.

7.7 Logging

Administrative actions on infrastructure we operate, and actions taken by systems we build, are logged with the actor, the action, and the time. Logs are retained for the period the client and applicable law require and are available to the client for the systems delivered to it.

8. Secure development

8.1 Source control and review

Code is held in version control, changed through reviewed pull requests, and built from a known revision. Secrets are never committed; automated checks block a commit that contains one.

8.2 Code hosting

Code is hosted on a managed source-control platform. Where a client has its own organization on that platform, the work is done there under the client’s controls and belongs to the client from the first commit. Otherwise it is held in a private repository in our organization, one per engagement, and transferred to the client at handover.

8.3 What a repository holds

A repository holds source code, configuration, and documentation. Client personal data, customer records, exports, databases, and production logs are never placed in a repository, in an issue, or in a pull request. Test data is synthetic.

8.4 Repository controls

Repositories are private, two-factor authentication is enforced across the organization, secret scanning and push protection are on, and access is removed when an engagement ends. AI features on the platform are off, or on a plan whose terms exclude training on private code. Where a client’s data residency or approved-tool rules exclude that platform, the client’s own platform is used instead.

8.5 Dependencies

Third-party dependencies are pinned, and security advisories for them are monitored and applied.

8.6 Environments

Development, test, and production environments are separated. Client production data is not used in development or test environments without the client’s written agreement and appropriate anonymization.

8.7 Vulnerability management

Vulnerabilities in systems we operate are triaged by severity on discovery. Critical and high-severity issues are remediated or mitigated as a priority; others are scheduled into ordinary maintenance.

9. Personnel and subcontractors

9.1 Confidentiality

Everyone who works on a client engagement, whether an employee or a contractor, is bound by written confidentiality obligations before receiving any client data.

9.2 Subcontractors

Where a specialist or subcontractor is engaged for client work, the client is told in advance, and the subcontractor is bound in writing to security and confidentiality terms no less protective than those Totomoko has agreed with the client.

9.3 Training

People working on engagements are trained in secure handling of client data, in the controls in Articles 6 and 7, and in the responsible-AI commitments in Article 14.

9.4 Use of AI tools by our people

Our own use of AI tools follows the same rules we apply for clients: no client data is entered into a tool that has not been approved for that engagement, and no client data is used to train any model.

10. Data retention and deletion

10.1 Retention period

Client data is retained for the duration of the engagement plus thirty (30) days, unless the engagement agreement specifies otherwise.

10.2 Return and deletion

On written request, we return or delete client data within thirty (30) days. Data deleted from live systems is removed from backups on the next backup rotation.

10.3 Data classification

Client data is classified at the start of an engagement as public, internal, confidential, or restricted, and the handling, storage, and access rules for each class are agreed in the design the client approves.

10.4 Model-provider retention

Retention by a model provider is governed by that provider’s terms and varies by provider and by route. The applicable window for each provider in an engagement is stated in the data processing agreement rather than summarized here.

11. Incident response and breach notification

11.1 Notification commitment

If we confirm a security incident affecting a client’s data, we notify that client in writing within 72 hours of confirmation, stating what we know, what we are doing, and what the client may need to do. The client receives a named contact.

11.2 Runbook

A written incident-response runbook governs containment, evidence preservation, severity assessment, the order of notification, and the post-incident review offered to the client. It is provided under Clause 2.3.

11.3 Detection

The 72-hour period in Clause 11.1 is a contractual commitment and runs from confirmation of an incident; statutory notification periods that run from awareness are met in parallel.

11.4 Delivered systems

Once a system is handed over, the client’s operators run it and Totomoko’s access is revoked. For such systems, the period in Clause 11.1 runs from the time the client informs us. Continued monitoring after handover is available as a scoped service.

11.5 Cooperation

Where an incident affects a client’s data, we cooperate with the client’s own incident process, preserve evidence, and provide the information the client needs to meet its own notification obligations.

12. Business continuity

12.1 Backups

Client materials held by Totomoko during an engagement are backed up on a regular schedule to encrypted storage.

12.2 Restore

Restore procedures form part of the backup process and are provided under Clause 2.3.

12.3 Provider dependencies

Delivered systems are built on modular, replaceable components so that the failure or withdrawal of a single provider does not leave the client without a path to continue.

13. Vulnerability disclosure

13.1 Reporting

Anyone who believes they have found a security vulnerability in this website or in a system Totomoko operates may report it through the security form.

13.2 Safe harbor

We will not pursue legal action against a researcher who reports a vulnerability in good faith, avoids privacy violations and service disruption, and gives us a reasonable time to remediate before disclosing it publicly.

14. Responsible AI

14.1 Statement

The commitments that apply to every piece of work Totomoko delivers, including human control, client data, inspectable systems, bias testing, applicable law, and the work we refuse, are set out in the Responsible AI statement.

14.2 Portability

Our master services agreement grants the client a perpetual, irrevocable license to anything of ours embedded in what we build for it, and commits that deliverables are handed over in a portable, documented form.

15. Client assurance

15.1 Questionnaires

We complete client security questionnaires and supplier-assessment forms, and answer follow-up questions from the client’s security or legal teams.

15.2 Audit

A client may, on reasonable notice and no more than once a year unless an incident has occurred, review the controls described on this page as they apply to its engagement, by written questionnaire or by interview. Where a review requires access to systems, it is scoped so that other clients’ data is not exposed.

15.3 Contractual commitments

The commitments on this page are given contractually to each client in the master services agreement and data processing agreement for its engagement.

16. Documents

16.1 Public

Terms of Service, Privacy Notice, Cookies Notice, Responsible AI, and Brand Guidelines, collected in the Trust Center.

16.2 On request

The detail described in Clause 2.3, the incident-response runbook (Clause 11.2), and, at engagement stage, the data processing agreement, the sub-processor list, and provider attestations.

17. Review

17.1 Cadence

This page is reviewed quarterly. The version and review dates are shown at the top of the page.

17.2 Corrections

If anything on this page is out of date, say so through the security form and it will be corrected.