Domains and control library

GTSAF’s 358 controls are grouped into 17 domains. This page explains how to approach each domain, what evidence normally matters and what failure patterns an assessor should look for.

The examples are not substitutes for the unique advisory attached to each individual control.

A — Governance, Strategy and Accountability

Purpose: Establish authority, policy, decision rights, ownership and oversight for the AI estate.

Assess:

• Board and executive authority.
• AI policy hierarchy.
• Governance forums.
• RACI and named accountability.
• Risk appetite.
• Exception and escalation routes.
• Management review.

Typical evidence:

• Board-approved AI charter.
• AI policy suite.
• Committee terms of reference and minutes.
• RACI.
• Decision logs.
• Risk-appetite statements.
• Management-review records.

Typical tests:

• Trace a material AI decision from initiation to approval.
• Confirm committees met at the stated cadence and quorum.
• Sample accountable owners against current organisation records.
• Verify a policy review was triggered after a material change.

Common failures:

• Governance exists only informally.
• Committees have no decision authority.
• Shared accountability with no single accountable owner.
• Policies are outdated or inaccessible.
• Risk appetite is expressed only as general principles.

B — Legal, Regulatory and Contractual Compliance

Purpose: Identify and operate the legal, regulatory, contractual and jurisdictional obligations that apply to the system.

Assess:

• Applicable-law inventory.
• Regulatory role and system classification.
• Prohibited or restricted use.
• Contractual obligations.
• Intellectual-property and licensing conditions.
• Data and cross-border obligations.
• Regulatory change management.

Typical evidence:

• Legal applicability assessment.
• Regulatory inventory.
• Contract clauses.
• Licence records.
• Data-processing agreements.
• Legal review and approval.
• Regulatory-change register.

Typical tests:

• Trace one obligation to an implemented control and evidence.
• Sample supplier and customer contracts for required AI clauses.
• Verify a regulatory change triggered reassessment.
• Confirm prohibited uses are technically or procedurally blocked.

Common failures:

• Generic legal memo with no system-specific conclusion.
• Unclear provider/deployer/customer role.
• Contract wording that does not match actual responsibility.
• Open-source or model licence obligations not monitored.
• No control for jurisdiction changes.

C — AI Use Case Intake, Approval and Risk Tiering

Purpose: Ensure every AI use case is registered, classified, approved and reassessed.

Assess:

• Intake completeness.
• System ownership.
• Risk tiering.
• ACRS.
• Approval gates.
• Exceptions.
• Material-change triggers.
• Retirement and status changes.

Typical evidence:

• AI system register.
• Intake form.
• ACRS record.
• Approval decision.
• Risk-tier rationale.
• Exception record.
• Change and reassessment history.

Typical tests:

• Select a live AI system and trace it to approved intake.
• Recalculate a sample ACRS route.
• Verify a system change caused reassessment.
• Identify unregistered or shadow-AI use.

Common failures:

• Intake performed after deployment.
• Draft ACRS treated as approved.
• Risk tier based on reputation rather than system facts.
• No link between intake and actual architecture.
• Changes do not trigger reassessment.

D — Data Governance, Lineage and Provenance

Purpose: Maintain trustworthy knowledge of where AI data comes from, how it changes and whether it is fit for use.

Assess:

• Data inventory.
• Source approval.
• Lineage.
• Provenance.
• Quality.
• Rights and permitted use.
• Retention.
• Dataset versioning.
• Retrieval corpus governance.

Typical evidence:

• Data catalogue.
• Lineage diagram.
• Source register.
• Dataset cards.
• Provenance metadata.
• Quality reports.
• Rights records.
• Retention schedule.

Typical tests:

• Trace a model output or retrieved document back to source.
• Sample dataset versions against approvals.
• Verify removed or expired sources no longer influence the system.
• Test lineage completeness after transformation.

Common failures:

• Unknown source origin.
• Approved dataset differs from deployed version.
• Retrieval documents bypass source governance.
• Quality checks cover format but not fitness for use.
• Retention rules do not reach embeddings or derived data.

E — Data Security and Privacy Engineering

Purpose: Protect sensitive data throughout AI collection, processing, storage, retrieval and output.

Assess:

• Data minimisation.
• Classification.
• Encryption.
• Segregation.
• Privacy engineering.
• Tokenisation and pseudonymisation.
• Tenant isolation.
• Data-loss prevention.
• Sensitive-output controls.

Typical evidence:

• Data-flow diagrams.
• Privacy assessment.
• Encryption configuration.
• Key-management records.
• DLP rules.
• Data classification.
• Tenant-isolation design.
• Redaction tests.

Typical tests:

• Attempt cross-tenant or unauthorised retrieval in a safe environment.
• Verify sensitive fields are redacted from prompts, logs and outputs.
• Inspect encryption and key rotation.
• Trace deletion across source, cache, vector and log stores.

Common failures:

• Sensitive data copied into prompts without need.
• Logs contain raw personal data.
• Deletion does not reach vector stores.
• Shared indexes permit cross-tenant exposure.
• Privacy controls rely entirely on provider statements.

F — Secure Data Acquisition and Annotation

Purpose: Protect data collection, labelling, annotation and preparation from manipulation, quality failure and unauthorised use.

Assess:

• Source acquisition.
• Consent and rights.
• Annotation instructions.
• Annotator access.
• Quality assurance.
• Poisoning resistance.
• Synthetic data.
• Dataset acceptance.

Typical evidence:

• Acquisition procedures.
• Annotation guidelines.
• Annotator training.
• Quality samples.
• Source approvals.
• Poisoning checks.
• Supplier records.
• Acceptance decisions.

Typical tests:

• Sample annotations for consistency and bias.
• Introduce bounded malformed or unauthorised records and confirm rejection.
• Verify annotator access and removal.
• Reproduce dataset acceptance criteria.

Common failures:

• Annotation quality measured only by volume.
• No segregation between raw and approved data.
• External annotators retain access.
• Poisoning and duplication checks absent.
• Synthetic data is undocumented.

G — Model Development, Validation and Robustness

Purpose: Ensure models are engineered, evaluated, approved and released against defined risk and performance criteria.

Assess:

• Development lifecycle.
• Version control.
• Validation independence.
• Performance and robustness.
• Bias and impact testing.
• Release criteria.
• Change approval.
• Reproducibility.

Typical evidence:

• Model cards.
• Experiment records.
• Validation reports.
• Benchmark results.
• Robustness tests.
• Bias analysis.
• Release approvals.
• Version history.

Typical tests:

• Reproduce a reported benchmark.
• Challenge performance under distribution shift.
• Verify the deployed version matches approval.
• Sample failed validation criteria and release decisions.

Common failures:

• Validation uses the training population only.
• Benchmark results cannot be reproduced.
• Model updates bypass approval.
• Business performance hides safety degradation.
• No defined minimum release criteria.

H — Prompt, Context and Retrieval Security

Purpose: Protect prompts, instructions, retrieved context and grounding from manipulation and untrusted influence.

Assess:

• System-prompt protection.
• Prompt injection.
• Context boundaries.
• Retrieval source approval.
• RAG poisoning.
• Grounding.
• Tool-output injection.
• Context leakage.

Typical evidence:

• Prompt architecture.
• Injection test results.
• Retrieval allowlists.
• Source-integrity controls.
• Context filtering.
• Grounding evaluation.
• Prompt version history.

Typical tests:

• Submit bounded direct and indirect injection patterns.
• Insert an unapproved retrieval document.
• Test whether retrieved instructions override policy.
• Verify sensitive context is not exposed across sessions.

Common failures:

• Retrieved text is treated as trusted instruction.
• System prompts contain secrets.
• No source-integrity check.
• Guardrails test only known phrases.
• Context persists beyond the intended session.

I — Inference, API and Runtime Security

Purpose: Protect the serving surface through authentication, authorisation, validation, session security and runtime enforcement.

Assess:

• API authentication.
• Authorisation.
• Rate limiting.
• Input and output validation.
• Session management.
• Abuse protection.
• Runtime policy.
• Error handling.

Typical evidence:

• API specifications.
• Gateway configuration.
• Authentication flows.
• Rate-limit rules.
• Session settings.
• Validation schemas.
• Runtime logs.
• Error-handling standards.

Typical tests:

• Call an endpoint without credentials.
• Attempt an unauthorised operation.
• Test rate limits.
• Submit malformed and adversarial inputs.
• Verify errors do not expose internals.

Common failures:

• Authentication without action-level authorisation.
• Unlimited model endpoints.
• Front-end validation with no server enforcement.
• Session state leaks between users.
• Provider errors expose sensitive details.

J — Identity, Access and NHI Security

Purpose: Control human and non-human identities, privileges, secrets and access lifecycle.

Assess:

• Identity inventory.
• Service accounts and agents.
• Least privilege.
• Segregation of duties.
• Secret storage.
• Token lifecycle.
• Access reviews.
• Revocation.

Typical evidence:

• Identity register.
• Role and permission exports.
• Access reviews.
• Secret-vault configuration.
• Token rotation.
• Joiner-mover-leaver records.
• Revocation logs.

Typical tests:

• Compare actual permissions with documented need.
• Attempt an unauthorised action.
• Revoke an identity and verify access stops.
• Sample dormant or orphaned non-human identities.

Common failures:

• Shared service accounts.
• Long-lived tokens.
• Agent permissions exceed workflow need.
• Revocation affects the UI but not backend sessions.
• Non-human identities omitted from access reviews.

K — Agentic AI and Autonomous Action Governance

Purpose: Govern tools, memory, delegation, approvals and autonomous action.

Assess:

• Autonomy boundaries.
• Tool permissions.
• Approval gates.
• Memory governance.
• Delegation.
• Multi-step plans.
• Kill switches.
• Human intervention.
• Action logging.

Typical evidence:

• Agent register.
• Tool catalogue.
• Access matrix.
• Approval-gate configuration.
• Memory policy.
• Workflow plans.
• Runtime logs.
• Kill-switch tests.

Typical tests:

• Attempt an action outside approved tool scope.
• Verify approval is required for a consequential action.
• Poison or manipulate memory in a safe test.
• Trigger the kill switch and measure containment.
• Verify an agent cannot self-escalate.

Common failures:

• Tool access inherited from a broad user account.
• Approval exists only in the user interface.
• Memory has no provenance or retention.
• Agent can create or approve its own plan.
• Kill switch does not revoke downstream authority.

L — Third-Party, Model and Software Supply Chain Assurance

Purpose: Govern external models, software, plugins, data providers and shared-responsibility dependencies.

Assess:

• Supplier due diligence.
• Contract controls.
• Model and component provenance.
• Vulnerability management.
• SBOM or inventory.
• Provider change.
• Exit and substitution.
• Assurance reports.

Typical evidence:

• Due-diligence assessment.
• Contracts and SLAs.
• Supplier assurance.
• Component inventory.
• SBOM.
• Vulnerability records.
• Provider-change notices.
• Exit plan.

Typical tests:

• Trace a deployed dependency to approved inventory.
• Verify a critical supplier issue enters risk governance.
• Test provider substitution or degraded operation.
• Sample contract obligations against actual service settings.

Common failures:

• Procurement approval treated as security assurance.
• Unknown transitive dependencies.
• Provider terms change without review.
• No exit path.
• Supplier reports are accepted without scope analysis.

M — Monitoring, Detection and AI Security Operations

Purpose: Detect harmful, anomalous or degrading AI behaviour and coordinate operational response.

Assess:

• Logging.
• Behavioural baselines.
• Detection rules.
• Alert handling.
• Model and data drift.
• Security operations.
• Incident classification.
• Metrics and escalation.

Typical evidence:

• Log inventory.
• Detection rules.
• Dashboards.
• Alert records.
• Drift reports.
• Incident tickets.
• Escalation records.
• Monitoring coverage.

Typical tests:

• Generate a safe detectable event.
• Verify alert delivery and triage.
• Trace an anomaly to investigation and closure.
• Confirm critical logs cannot be disabled without detection.

Common failures:

• Logs exist but nobody reviews them.
• Monitoring covers uptime but not AI behaviour.
• Alerts cannot be tied to a system or action.
• Drift thresholds have no response process.
• Security operations lack AI-specific playbooks.

N — Human Oversight, Transparency and Impact Management

Purpose: Ensure people can understand, challenge, oversee and intervene in consequential AI use.

Assess:

• Human decision authority.
• Meaningful review.
• Transparency notices.
• Explainability.
• Contestability and appeal.
• Fairness and impact.
• Accessibility.
• Cultural and community context.

Typical evidence:

• Oversight procedures.
• User notices.
• Decision explanations.
• Appeal records.
• Impact assessments.
• Fairness tests.
• Stakeholder consultation.
• Intervention logs.

Typical tests:

• Observe a human review and confirm genuine authority.
• Sample explanations against actual decision factors.
• Trace an appeal to resolution.
• Test whether automation bias is addressed in training and workflow.

Common failures:

• Human reviewer merely confirms the AI output.
• Notices are generic or hidden.
• No route to challenge a decision.
• Fairness testing excludes affected groups.
• Explanations do not reflect actual system logic.

O — Resilience, Continuity and Recovery

Purpose: Maintain safe service, containment and recovery when AI components fail or become untrustworthy.

Assess:

• Failover.
• Graceful degradation.
• Rollback.
• Backup and restoration.
• Provider failure.
• Crisis management.
• Recovery objectives.
• Rebuild integrity.

Typical evidence:

• Continuity plan.
• Recovery procedures.
• Backup records.
• Failover tests.
• Rollback records.
• Provider-substitution plan.
• Crisis exercise.

Typical tests:

• Fail a dependency in a controlled environment.
• Restore from backup.
• Roll back a model or configuration.
• Verify the system enters a lower-risk mode.
• Measure recovery time and data loss.

Common failures:

• Recovery covers infrastructure but not models or vector stores.
• Backups are never restored.
• Failover preserves service but removes controls.
• Provider outage creates uncontrolled manual workarounds.
• No evidence-preserving incident recovery.

P — Auditability, Evidence and Assurance

Purpose: Make the assessment reproducible, reviewable and independently challengeable.

Assess:

• Evidence governance.
• Control testing.
• Audit trails.
• Record integrity.
• Review independence.
• Findings.
• Assurance planning.
• Retention.

Typical evidence:

• Evidence register.
• Test plan.
• Workpapers.
• Audit log.
• Review sign-off.
• Findings register.
• Retention schedule.
• Assurance calendar.

Typical tests:

• Reproduce a control conclusion from its records.
• Verify audit-log immutability.
• Sample evidence expiry and review.
• Confirm reviewer independence.

Common failures:

• Conclusion cannot be traced to evidence.
• Testing is described but not recorded.
• Evidence is overwritten without history.
• Reviewer is also the control operator with no challenge.
• Findings close without validation.

Q — Infrastructure, Platform and Environment Security

Purpose: Protect the compute, cloud, network, storage and environment foundations supporting AI.

Assess:

• Cloud and platform configuration.
• Network segmentation.
• Compute isolation.
• Container and workload security.
• Secrets.
• Patch and vulnerability management.
• Environment separation.
• Capacity and resource controls.

Typical evidence:

• Cloud configuration.
• Network diagrams.
• Container policies.
• Vulnerability scans.
• Patch records.
• Environment inventory.
• Secrets configuration.
• Capacity controls.

Typical tests:

• Inspect configuration against secure baseline.
• Attempt prohibited network paths.
• Verify environment segregation.
• Sample critical vulnerabilities through remediation.
• Test resource exhaustion protections safely.

Common failures:

• AI workloads inherit generic cloud defaults.
• Development and production share credentials.
• Model endpoints bypass network controls.
• Unpatched libraries and images.
• GPU or accelerator access is not isolated.

Using the domain guide

For each domain:

1. Confirm it is in scope.
2. Review the domain reason.
3. Prioritise Critical and Gate controls.
4. Read each control’s unique advisory.
5. Collect system-specific evidence.
6. Execute bounded tests.
7. Raise findings.
8. Record the assessor conclusion.

The domain guide helps you navigate. The individual control remains the authoritative assessment unit.