Trust and delivery assurance

What a security review needs to know before we start.

How we handle your data during an engagement, what deployment options exist, the controls designed into every workflow, where ownership sits, and how to get the documents your procurement process needs.

Data handling

Your data during an engagement

What we access

Only what the agreed scope requires. Access is requested per system, granted through your own process, and recorded. Where a workflow can be designed and tested against synthetic or redacted data, we will propose that first.

Where it is processed

Deployment location is a design decision made with you, not a default. Where data residency or sovereignty constraints apply, they are captured as a requirement at the start and the architecture is built to meet them.

Credentials

Issued through your own secure process, scoped to the actions the workflow needs, and revocable by you. We do not ask for shared accounts, and we do not accept credentials by email or chat.

Retention and deletion

What we hold, for how long, and how it is destroyed at the end of the engagement is set out in the contract before work starts. Test extracts are deleted on the schedule agreed there, not kept indefinitely because nobody asked.

Deployment

Where the solution runs is your decision

Each option carries a different data-handling and commercial position. We set out which applies before design starts, not after.

In your environment

The workflow runs inside your own cloud tenancy or data center. You keep the data, the logs and the audit trail; ETT builds, configures and hands over.

Dedicated infrastructure

Where a workload needs specific compute, we design and provision a dedicated environment with named providers. Regions, capacity and commercial terms are confirmed per engagement rather than promised in advance.

Vendor platform

Where the right answer is an existing platform, the vendor's own terms, data handling and sub-processors apply to that platform. We tell you which ones, and what they mean, before you sign anything.

Controls

What is designed into every workflow

These are design requirements, not optional extras added when a reviewer asks. An automation whose failure behavior was never specified is not finished.

  • Permission model: every action the automation may take, and every one it may not, defined and reviewable.
  • Human approval points: which decisions require a person, and what they see when it reaches them.
  • Logging: what was done, from which source, under which identity, at what time.
  • Failure behavior: what the system does when a source is unavailable, a check fails or permission is denied. It stops and escalates; it does not guess.
  • Escalation: a defined route to a named owner, agreed before go-live.
Procurement

Ownership, certification and documentation

Who owns what you build for us?

Ownership of the solution, its configuration and the documentation is set out in the engagement contract before work starts. Where a third-party platform is part of the solution, that platform's licensing terms apply to it, and we identify which components those are rather than leaving the boundary vague.

Do you use our data to train models?

No. Your data is used to deliver your engagement. Where a workflow calls a third-party model provider, the provider and its data-handling terms are named in the design, and we select and configure for the retention position your engagement requires.

Are you certified to a security standard?

We design controls with reference to recognized standards, including ISO/IEC 42001 for AI management systems and ISO/IEC 27001 for information security, and our vCISO practice helps clients reach alignment with them. Alignment is not certification. Where you need to know our current certification and attestation position, ask and we will give you the accurate answer in writing rather than an implication on a web page.

Can we see your security documentation before we engage?

Yes. Security questionnaires, our sub-processor list, insurance details and the contracting entity for your jurisdiction are provided on request, usually under NDA. Email sales@ettgroup.ai with what your procurement process needs and who is asking.

What about the AI-specific risks?

Prompt injection, data leakage through context, over-broad tool permissions, silent model change and unreviewable outputs are the failure modes we design against, and they are covered explicitly in the vCISO for AI engagement rather than treated as ordinary application security.

Security contact and assurance requests: email sales@ettgroup.ai marked for the attention of the security contact. We will confirm the contracting entity, the sub-processor list and our current attestation position in writing.

Bring your security questions to the first conversation.

If procurement or risk needs answers before a commercial discussion is worth having, say so when you get in touch and we will bring the right person.

Region & currency

Changes spelling, terminology, the data-protection regime named in our notices, and the currency used in indicative figures. ETT is based in London — this is not a local office or a price in your currency.