Worked example

This example shows how the GTSAF labels and workflow fit together.

Scenario

An insurer deploys Claims Triage Assistant, a GenAI system that:

• Summarises customer claims.
• Retrieves policy and claims information through RAG.
• Recommends triage priority.
• Processes personal and health-related information.
• Is hosted using a third-party foundation model.
• Exposes an internal API.
• Does not autonomously approve or reject claims.

Intake, applicability and ACRS

The intake records:

• Sensitive personal data: Yes.
• RAG: Yes.
• Third-party model: Yes.
• API serving: Yes.
• Automated decision support: Yes.
• Public-facing: No.
• Agentic action: No.

The complete authoritative route makes the system selectable for system-scoped assessment. ACRS is reviewed separately and indicates Moderate capability risk; it may deepen assurance but does not create or remove factual control applicability.

Routing result

The baseline includes governance, intake, monitoring, assurance and infrastructure controls.

The system characteristics trigger:

• Data governance and lineage.
• Data security and privacy.
• Prompt, context and retrieval security.
• Inference and API security.
• Third-party supply-chain assurance.
• Human oversight and transparency.

Higher-risk privacy and oversight controls receive Enhanced depth.

Reading the scope cards

Assume the selected-system view shows:

• Applicable controls: 287
• Baseline: 21
• Triggered: 251
• Enhanced: 15
• Pending: 0
• Out of scope: 71

The assessor first checks:

21 + 251 + 15 = 287 applicable controls

and:

287 + 0 + 71 = 358 total controls

The depth-weighted workload is:

(21 × 1) + (251 × 2) + (15 × 3) = 568

Assurance intensity is:

568 ÷ (287 × 3) × 100 = 65.97%, displayed as 66%

This does not mean the system is 66% compliant. It means the applicable population requires 66% of the maximum possible assessment depth. Control answers, evidence and tests determine effectiveness.

The factual scope drivers may show governed data dependency, sensitive data, RAG, external supplier, API serving and regulated context. Driver counts can overlap and are not added together.

Example control badge

Assume the assessor opens a control for RAG source integrity and sees:

High · Gate · Enhanced · Gap

High

Poisoned or unauthorised retrieval content could influence claims triage and expose sensitive data.

Gate

The system should not proceed to an unrestricted assurance conclusion if retrieval integrity is not controlled.

Enhanced

The system processes sensitive claims information and uses RAG in a consequential workflow. Stronger evidence and testing are required.

Gap

One applicable requirement is answered No.

Assessment questions

Question	Answer	Explanation
Are approved retrieval sources inventoried and owned?	Yes	A source register exists with owners and approval status.
Are retrieved documents integrity-checked before indexing?	No	The ingestion pipeline validates file type but not source signature or approved checksum.
Are retrieval permissions aligned to claims-handler access?	Yes	Index queries use the authenticated employee’s access group.

The No creates:

• Gap status.
• Gate fail because the control is a Gate.
• Assurance cap of 25%.
• Proxy score of 1.

Ownership

The organisation records Shared responsibility:

• AIC: approves sources and user access.
• AP: implements ingestion controls and retrieval filtering.
• CSP: protects the hosted storage and platform.
• MP: has no direct responsibility for the customer’s retrieval source approval.

The implementation narrative explains the division and references the service agreement.

Evidence collected

Accepted

• Retrieval source register.
• Access-control matrix.
• RAG architecture diagram.
• Quarterly access-review record.

Rejected

• Generic vendor security brochure.

Reason:

The brochure describes platform security but does not demonstrate integrity checks in the customer’s ingestion pipeline.

Test performed

Test objective:

Determine whether an unapproved or modified document can enter the production retrieval index.

Bounded procedure:

1. Use the test environment.
2. Create a synthetic claims-guidance document.
3. Do not add it to the approved source register.
4. Submit it through the ingestion path.
5. Confirm whether indexing is blocked.
6. Repeat using an approved document modified after approval.
7. Capture logs and alerts.

Expected result:

• Both documents are rejected.
• An alert identifies the reason.
• The event is logged.

Actual result:

• Both documents are indexed.

Test result:

Failed

The failed test independently caps assurance at 25%.

Finding

Title:

RAG ingestion accepts unapproved and modified source documents

Condition:

The test environment indexed both an unapproved synthetic document and a modified approved document.

Risk:

Untrusted retrieval content could manipulate triage recommendations, expose claims information or produce inconsistent customer outcomes.

Recommendation:

• Enforce approved-source allowlisting.
• Validate integrity through signed manifests or approved checksums.
• Quarantine failed documents.
• Alert the security and claims-data owners.
• Retest before production approval.

Owner:

Application Security Lead

AI Assist result

The per-control AI Assist panel shows:

Scope: AI system: Claims Triage Assistant

It identifies:

• Applicable with High confidence.
• Evidence position Partial.
• Verified facts limited to the linked source register, access matrix and test record.
• Operating effectiveness Ineffective.
• Residual risk High.
• Recommended bounded retest after remediation.
• Monitoring for rejected ingestion attempts and integrity failures.

The assessor reviews the output but does not apply any claim that is unsupported.

Assessor conclusion before remediation

• Design effectiveness: Partially effective.
• Implementation effectiveness: Ineffective.
• Operating effectiveness: Ineffective.
• Evidence conclusion: Partial.
• Residual risk: High.
• Decision: Production approval restricted until remediation and successful retest.

Remediation

The application team implements:

• Signed source manifests.
• Approved checksum validation.
• Source-owner approval workflow.
• Quarantine storage.
• Rejection alerts.
• Immutable ingestion logs.

Retest

The assessor repeats the original procedure.

Result:

• Unapproved document rejected.
• Modified approved document rejected.
• Both attempts logged.
• Alerts sent.
• Approved unchanged document indexed successfully.

Test result:

Passed

Evidence after remediation

• Updated ingestion design.
• Configuration export.
• Source signing procedure.
• Alert rule.
• Retest record.
• Change approval.

Final result

The No answer is changed to Yes only after the assessor confirms remediation.

The control now has:

• No No answers.
• Accepted evidence.
• Passing test.
• Determined ownership.
• Complete coverage.

Its status may move to Assured once calculated assurance reaches at least 75%.

The label sequence becomes:

High · Gate · Enhanced · Assured

This does not mean the risk disappears. It means the current assessment record provides a defensible assurance position under the stated scope and review period.

What this example demonstrates

• Criticality, Gate, applicability and result labels describe different dimensions.
• Applicable-control count measures breadth; workload and intensity measure required rigour.
• ACRS and governance weighting may deepen assurance but do not invent factual applicability.
• A Yes answer is not proof.
• Generic vendor material is not necessarily system evidence.
• Failed tests override optimistic narrative.
• Gate failures cannot be averaged away.
• AI Assist reflects the selected system and linked records.
• Remediation must be validated through retesting.
• Assured is a current assurance conclusion, not certification.