GTSAF

GTSAF, the Gamut Trust, Security and Assurance Framework, is Gamut’s flagship AI assurance framework. It turns AI governance principles into an assessable, evidence-led control system covering the entire AI lifecycle: governance, data, models, prompts, runtime, identity, agents, suppliers, monitoring, human oversight, resilience, auditability and infrastructure.

GTSAF contains 358 individually authored controls across 17 domains, supported by:

A unique objective and risk statement for every control.
Detailed implementation guidance.
Control-specific evidence expectations.
Control-specific test procedures.
Criticality and gate metadata.
System-specific applicability rules.
Shared-responsibility ownership.
Structured assessor conclusions and residual-risk records.
Audited traceability mappings to the EU AI Act, ISO/IEC 42001, ISO/IEC 42005 and NIST AI RMF.
Validated, system-scoped AI Assist.

Start here

Use this documentation suite according to what you need to explain or do:

If you need to…	Read
Explain badges such as High, Gate, Enhanced, Triggered, Gap and Assured	Concepts, labels and terminology
Understand what each of the 17 domains covers and how to assess it	Domains and control library
Explain why different systems receive different controls and assurance depth	System scope, applicability and assurance depth
Complete a GTSAF assessment from beginning to sign-off	Assessment workflow
Defend how the assurance figures are calculated	Scoring and assurance model
Know what evidence to collect and how to test a control	Evidence, testing and findings
Explain what AI Assist reads, produces and is prohibited from doing	AI Assist explainability
Produce or explain system and workspace reports	Reporting and governance decisions
Walk through a realistic assessment example	Worked example
Look up abbreviations, statuses and formulas quickly	Reference and glossary

GTSAF at a glance

Property	Current GTSAF library
Version	GTSAF v1.3
Controls	358
Domains	17, lettered A to Q
Gate controls	71
Critical controls	70
Criticality distribution	70 Critical, 241 High, 43 Medium, 4 Low
Assessment level	Per AI system, with workspace roll-up
Control identifier	`GTSAF-<domain>-<nn>`, for example `GTSAF-A-01`
Assessment answers	Yes, No or governed N/A
Shared-responsibility roles	MP, OSP, AP, AIC, CSP, Shared or ND
Crosswalks	EU AI Act, ISO/IEC 42001, ISO/IEC 42005, NIST AI RMF

The GTSAF operating model

GTSAF works as a connected assurance process rather than a static checklist:

Register the AI system. Record what it does, who owns it, where it operates, what data it handles, which suppliers it uses and how much autonomy or impact it has.
Complete intake and risk classification. The intake establishes the system context. ACRS captures capability exposure through dependency, action autonomy, access scope and harm potential.
Determine applicability and depth. Complete system facts determine which conditional controls apply. ACRS and the governance weighting profile set proportionate Baseline, Triggered or Enhanced assurance depth without rewriting factual applicability.
Assess the controls. The assessor records Yes, No or N/A; assigns shared-responsibility ownership; documents implementation; and captures customer responsibilities.
Collect and review evidence. Narrative statements explain the control but do not count as verified evidence. Evidence must be linked, reviewed and quality-rated.
Test operating effectiveness. A test determines whether the control actually works under defined conditions. Failed tests and exceptions constrain assurance.
Raise findings and remediation. Gaps, gate failures, rejected evidence and failed tests become actionable findings, risk decisions or remediation work.
Record the human conclusion. The assessor documents design, implementation and operating effectiveness, residual risk, monitoring cadence and reassessment triggers.
Generate system and workspace reporting. System reports use the selected system’s own assessment bucket. Workspace reports provide portfolio-level roll-up without replacing the individual system record.

The four dimensions shown on a control

Several badges can appear beside one control because they answer different questions.

Dimension	Example labels	The question it answers
Criticality	Critical, High, Medium, Low	How consequential would failure of this control be?
Control type	Gate	Can failure of this control prevent a positive assurance conclusion?
Applicability	Mandatory, Triggered, Enhanced, Not applicable	Why and to what depth does this control apply to this system?
Assessment result	Unassessed, Partial, Supported, Assured, Gap, Gate fail, N/A	What does the current assessment record demonstrate?

For example:

High · Gate · Enhanced · Gap

means:

The control has High criticality.
It is a Gate control.
The selected system requires Enhanced assessment depth.
At least one applicable requirement is answered No, producing a Gap.

It does not mean “High Gate Enhanced Gap” is one combined severity rating.

See Concepts, labels and terminology for every label and its decision consequence.

The 17 domains

Domain	Name	Controls	Primary assurance focus
A	Governance, Strategy and Accountability	11	Board authority, policy, ownership, decision rights and governance operation
B	Legal, Regulatory and Contractual Compliance	11	Applicable obligations, prohibited uses, contracts and jurisdiction
C	AI Use Case Intake, Approval and Risk Tiering	11	Registration, classification, approval, exceptions and change triggers
D	Data Governance, Lineage and Provenance	11	Data origin, lineage, quality, rights, retention and traceability
E	Data Security and Privacy Engineering	24	Sensitive data, privacy controls, segregation, minimisation and protection
F	Secure Data Acquisition and Annotation	11	Data collection, labelling, annotation, poisoning resistance and quality
G	Model Development, Validation and Robustness	11	Model engineering, validation, robustness, benchmarks and release controls
H	Prompt, Context and Retrieval Security	25	Prompt injection, RAG, context boundaries, grounding and retrieval integrity
I	Inference, API and Runtime Security	25	Serving security, APIs, sessions, output controls and runtime enforcement
J	Identity, Access and NHI Security	26	Human and non-human identity, secrets, privilege and access lifecycle
K	Agentic AI and Autonomous Action Governance	29	Tools, memory, delegation, approvals, autonomy and kill switches
L	Third-Party, Model and Software Supply Chain Assurance	25	Vendors, hosted models, dependencies, SBOMs and shared responsibility
M	Monitoring, Detection and AI Security Operations	35	Logging, detection, behavioural monitoring, incidents and security operations
N	Human Oversight, Transparency and Impact Management	15	Human review, notices, explainability, fairness, appeal and social impact
O	Resilience, Continuity and Recovery	36	Failover, rollback, crisis response, recovery and provider substitution
P	Auditability, Evidence and Assurance	11	Evidence governance, testing, audit records and assurance independence
Q	Infrastructure, Platform and Environment Security	41	Cloud, compute, network, platform, environment and isolation safeguards

The larger domains reflect modern AI concentration points: infrastructure, monitoring, agentic action, identity, prompt/retrieval security and third-party dependencies.

What is recorded for each control

Every control contains enough information for an assessor to work primarily from the control screen:

Control statement: the required outcome.
Objective: why the control exists.
Risk addressed: what can go wrong if it is absent or ineffective.
Applicability: when the control applies and why.
Criticality and gate status.
Implementation guidance: practical actions expected to establish the control.
Required evidence: the artefacts and operating records to obtain.
Test procedure: how to determine whether the control works.
Control owner and evidence owner.
Cross-framework mappings.
Shared-responsibility role guidance.
Assessment answers and implementation narrative.
Linked evidence, evidence requests, tests and findings.
Structured assessor conclusion and residual risk.
System-scoped AI Assist.

Shared responsibility

GTSAF recognises that AI controls are commonly split across several parties:

Code	Party
MP	Model Provider
OSP	Orchestrated Service Provider
AP	Application Provider
AIC	AI Customer
CSP	Cloud Service Provider
Shared	Responsibility is divided between named parties
ND	Not determined; an ownership gap requiring resolution

The selected guidance role changes the practical implementation guidance shown to the assessor. It does not transfer accountability automatically. Contracts, architecture and actual operating responsibility must support the selected ownership.

Assurance principles

GTSAF follows several rules that prevent an assessment from overstating assurance:

Unanswered controls are not treated as safe. Coverage is included in conformance and assurance.
Narrative is not evidence. A detailed explanation improves narrative sufficiency but does not become verified evidence merely because it sounds credible.
A Yes answer is not proof. Evidence and testing are separate.
Operating effectiveness requires testing or operating records.
Failed tests, rejected evidence and gate failures constrain the result.
Critical and High controls receive greater weighting and assurance caps when evidence is weak.
N/A is governed. Unsupported N/A responses remain in scope and count as not met.
AI Assist cannot approve the assessment. Human review and sign-off remain mandatory.
System boundaries are enforced. A selected system does not inherit another system’s AI analysis or operational evidence.

Crosswalks to public frameworks

Every GTSAF control includes audited traceability references to:

EU AI Act
ISO/IEC 42001
ISO/IEC 42005
NIST AI RMF

The crosswalk helps an assessor reuse evidence and identify related obligations. It does not prove that satisfying one GTSAF control automatically satisfies an external legal or standards requirement.