Security is a practice.

Altuon's security posture rests on a small number of controls applied without exception, rather than a long list applied unevenly. Access is granted on the principle of least privilege and reviewed when a person joins, changes role or leaves an engagement; there are no shared accounts and no standing administrative access to client systems. Every account that can reach client material uses hardware-backed or authenticator-based multi-factor authentication. Secrets are held in a managed vault, never in source, configuration files or messages.

Data is encrypted in transit and at rest everywhere the firm controls it, using current, widely reviewed protocols and ciphers. Client material is processed on managed, full-disk-encrypted devices and inside the client's own environments wherever the engagement allows; the firm does not keep copies of client data beyond what a workstream needs, and deletes them when the workstream ends.

The systems the firm builds are held to the same standard as its own. Every new system passes an architecture review that covers identity, network boundaries, secrets, logging and the residency position before a line of production code is written. Every release runs the engagement's evaluation set and its automated security checks. Every voice or AI system that will take real traffic passes an adversarial red-team exercise first, and the findings are closed before the gate, not after it.

Where data may be processed is an architecture decision made at the first review of every mandate, written into the architecture register and enforced by the design rather than by a policy document. The register names the legal territory of every component that holds client data, the entity that operates it and the people who can reach it. If a component is in a territory the client did not choose, the design is wrong.

The firm separates the control plane from the data plane. Identity, policy, orchestration and observability may run centrally; inference, retrieval, storage and anything that touches client-identifying data run inside the plane the client chose. Policy crosses the boundary; data does not. This is what makes it possible to use a vendor's tooling without using a vendor's territory.

Five planes are available on every engagement: Switzerland, the European Union, the United States, the client's own premises and a sovereign or national cloud. The choice is per system, not per client, so a bank may run its internal search in a hyperscaler's Swiss region and its client-facing voice line on its own hardware, with the same control plane above both.

Privacy is designed rather than declared. Every mandate that touches personal data begins with a data map and, where the processing is likely to present a high risk, a data protection impact assessment written as a design document rather than a compliance afterthought. The assessment names the purposes, the legal bases, the retention periods and the data subjects' rights, and it is updated when the system changes.

Personal data is minimised at the boundary: redacted or pseudonymised before it reaches a model unless the purpose requires otherwise, and never used to train or evaluate a model that serves anyone else. Prompts, outputs, transcripts and recordings are retained only for the period the mandate agrees, and the deletion schedule is implemented, tested and evidenced rather than described.

Where the firm processes personal data on a client's behalf it does so as a processor under a data processing agreement that names the sub-processors, the territories, the security measures and the audit rights. Where the firm is the controller, as it is for requests sent through this website, the privacy notice sets out the processing in full.

The firm keeps a single list of the third parties that may process client data on its behalf: hosting providers, model providers, delivery and communication services. Each entry names the provider, the purpose, the territory of processing and the contractual basis. The list is provided with every proposal and attached to every data processing agreement, and clients are notified before an entry is added so that they may object.

The list is deliberately short. Fewer processors means fewer territories to defend, fewer contracts to review and a smaller surface for a procurement committee to assess. A provider that cannot fix the territory of processing or that reserves a right to use client content for its own purposes does not appear on it.

An incident is any event that has or could have compromised the confidentiality, integrity or availability of client data or of a system the firm operates for a client. Incidents are classified by severity at detection, owned by a named responder, and worked through a written playbook: contain, assess, notify, remediate, review. The playbook is rehearsed, not merely filed.

Clients are notified of incidents affecting their data within the period fixed in their agreement and in any case within the time required by the applicable law, with what is known, what is not yet known and what is being done. Where a personal data breach must be reported to a supervisory authority, the firm supports the client's report with the evidence it needs. Every incident ends with a written review, shared with the affected client, that names the cause and the change that prevents its recurrence.

The firm is small by design and continuity is planned for accordingly. Every engagement has a named deputy for its engagement director and for its technical lead, and the architecture register, the evaluation set and the runbooks are the client's property from the first phase, so that no engagement depends on one person's memory or one firm's survival. Key-person provisions are offered in every agreement.

The firm's own systems, source repositories, documents and communication, are backed up to a second provider in a second territory and restored on a fixed rehearsal schedule. Client systems are built to the continuity requirement the mandate states, with recovery objectives written into the architecture register and tested before go-live.

Exit is designed at the start of every engagement. Source, models, prompts, indices, documentation and data are delivered in open formats on request and at the end; a transition period is offered at the existing terms; and the deletion of the firm's copies is certified in writing.

The firm's controls are mapped to the frameworks its clients are examined against: the revised Swiss Federal Act on Data Protection and FINMA's expectations on outsourcing and operational risk; the GDPR and the EU AI Act; Jordan's Personal Data Protection Law and the central bank's expectations on technology outsourcing; HIPAA and the model-risk guidance US supervisors apply to banks. The mapping is a working document that names, for each obligation, the control that meets it and the evidence that shows it does.

Frameworks are cited here by name and obligation. The firm does not claim a certification it does not hold, and the certifications section below is filled from the record rather than from ambition.