Security is a practice.

The access review should identify each person, their role, the systems they can reach and the approval for that access. Agree multi-factor authentication, privileged access, secret storage and removal of access. Request configuration evidence and the date of the last review before accepting these controls.

For each data flow, document encryption in transit and at rest, device management, key ownership and retention. The agreed design must include operational logs, backups and support access as well as the main database. Record exceptions and an accountable owner; a policy statement alone does not demonstrate implementation.

Assurance work is scoped to the system’s risk. The statement of work should specify architecture review, automated checks, evaluation data and any independent penetration or adversarial testing. State who performs each test, which environments it covers, the acceptance criteria and how unresolved findings prevent or limit release.

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.

Separating orchestration from client data can reduce exposure, but the boundary must be tested. Identity records, prompts, telemetry and support sessions may themselves contain personal data. The architecture review should document every cross-border flow and the technical and contractual controls applied to it.

Switzerland, the European Union, the United States, on-premises and sovereign cloud are deployment options to assess. Availability depends on the selected components, licences and operating capacity. A location is approved only after mapping all processing, including model calls, identity services, logs, backups and remote support.

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.

Create a register of the providers involved in the proposed work: hosting, models, identity, communications and support. For each entry, identify its role, processing purpose, territories, onward providers and contractual safeguards. Agree how changes are reviewed and communicated. Request the completed register before sharing client data; this website does not establish that a project-specific register or agreement already exists.

The applicable providers must be named with their purpose, processing locations and contractual safeguards before client data is shared. An empty register does not establish that no third parties are involved.

Incident planning should identify contacts, severity levels, notification duties and recovery steps. The agreed plan must record when its procedures were last tested and what remains to be addressed.

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 delivery agreement must name the responsible people, available cover, access arrangements and handover obligations. Staffing and continuity provisions depend on the proposed scope and must be evidenced before work begins.

Backup locations, recovery objectives and restoration tests must be recorded for each system. A second provider or territory is used only where the agreed security and data-location requirements permit it.

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.

Applicable obligations depend on the client, use case and jurisdictions. A procurement review should identify relevant laws and supervisory requirements, map them to the proposed controls and record the evidence and unresolved gaps. Mentioning a framework does not demonstrate compliance or certification.

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.