Assessment workflow

This page describes how to complete a defensible GTSAF assessment from preparation through final assurance reporting.

Before starting

Confirm that:

• The correct workspace is open.
• The AI system is registered.
• The intake record describes the current use case and architecture.
• The system owner and assessment owner are identified.
• The linked System Record and Intake contain complete, conflict-free routing facts.
• ACRS has been reviewed where its additional depth is material to the assessment.
• The intended assessment boundary is documented.
• The assessment is in edit mode and not locked.
• The assessor has access to the required evidence, testing and findings modules.

Step 1: define the assessment boundary

Record:

• The named AI system and system reference.
• Business purpose and intended use.
• Users and affected people.
• Deployment model.
• Models and providers.
• Data categories and sources.
• Interfaces, APIs and integrations.
• RAG, prompts, context stores and retrieval sources.
• Agentic tools, memory and delegated actions.
• Human decision points.
• Environments in scope.
• Jurisdictions and regulatory roles.
• Suppliers and shared-responsibility boundaries.
• Known exclusions.

Avoid boundaries such as “the AI platform” without naming the actual components and operating relationships.

Step 2: select the GTSAF scope

Choose:

• All GTSAF controls
• AI system: authoritative intake route complete

For a formal multi-system assessment, select the named system. ACRS confirmation is not required to determine factual applicability; where ACRS is unavailable, the screen identifies that no confirmed ACRS depth overlay is being used.

Review:

• Applicable-control count.
• Baseline, Triggered and Enhanced depth counts.
• Depth-weighted workload and assurance intensity.
• Factual scope drivers and their overlap warning.
• Applicability-pending controls.
• Out-of-scope controls.
• The reason shown for each control’s applicability.

Confirm that:

Baseline + Triggered + Enhanced = Applicable controls

and:

Applicable controls + Applicability pending + Out of scope = 358

Do not interpret the largest applicable-control count as the highest-risk system. Applicable count measures breadth; workload and assurance intensity explain required rigour. If professional judgement identifies an additional relevant control, include and assess it without changing the underlying Intake merely to obtain a preferred count.

Step 3: work domain by domain

GTSAF is organised A to Q. A practical assessment sequence is:

1. A-C: governance, legal and intake.
2. D-G: data and model engineering.
3. H-I: prompt, retrieval, inference and runtime.
4. J-L: identity, agentic action and supply chain.
5. M-N: monitoring, oversight and impact.
6. O-Q: resilience, assurance and infrastructure.

This order establishes governance and system facts before detailed technical testing.

Step 4: read the full control advisory

For each control, review:

• Control statement.
• Objective.
• Risk addressed.
• Applicability explanation.
• Criticality.
• Gate status.
• Implementation guidance.
• Required evidence.
• Test procedure.
• Control owner.
• Evidence owner.
• Cross-framework mappings.
• Role-specific guidance.

Do not assess from the short title alone.

Step 5: answer each assessment question

Yes

Select Yes only when the requirement is met in the selected scope.

A Yes answer should be accompanied by:

• Clear implementation narrative.
• Named responsibility.
• Relevant evidence.
• Testing where operating effectiveness matters.

Yes is an assessor claim, not proof by itself.

No

Select No when the requirement is absent, incomplete or ineffective.

Then:

• Explain the precise deficiency.
• Identify the risk or consequence.
• Link or raise a finding.
• Record compensating controls.
• Assign remediation.
• Decide whether deployment restrictions or escalation are needed.

No creates a Gap. On a Gate control it creates a Gate fail.

N/A

Select N/A only where the requirement genuinely does not apply to the selected boundary.

Complete:

• Detailed rationale.
• Decision category.
• Decision owner.
• Independent approver.
• Approval date.
• Review date or reassessment trigger.
• Evidence references.
• Compensating controls or boundary safeguards.

Until the governance fields are complete, the N/A is not honoured.

Step 6: assign shared-responsibility ownership

Choose the party that actually operates or assures the requirement:

• MP
• OSP
• AP
• AIC
• CSP
• Shared
• ND

For Shared:

• Identify which party performs each activity.
• Identify which party remains accountable.
• Link contractual or architectural evidence.
• Explain how gaps and incidents are escalated across the boundary.

Resolve ND before sign-off.

Step 7: document implementation

The implementation narrative should state:

• What is implemented.
• Where it is implemented.
• Who operates it.
• Which systems or environments it covers.
• How often it operates.
• How exceptions are handled.
• How changes are approved.
• Which evidence demonstrates operation.
• What the customer or another provider must do.
• Known limitations.

Avoid statements such as:

• “Industry best practice is followed.”
• “The vendor handles this.”
• “Security is enabled.”
• “Compliant.”

Those statements are not testable without further detail.

Step 8: collect and link evidence

Use the control’s Required evidence advisory as the starting checklist.

For each artefact:

• Link it to the correct control.
• Link it to the correct system or intake.
• Record owner and date.
• Review its relevance, sufficiency and currency.
• Record the review status.
• Record evidence quality.
• Reject generic or stale material.

Narrative does not become verified evidence through keyword matching.

Step 9: perform control testing

Use the control-specific test procedure to design a bounded test.

Record:

• Test objective.
• Test steps.
• Population and sample.
• Expected result.
• Pass criteria.
• Safety limits.
• Test date.
• Tester.
• Result.
• Exceptions.
• Retest date.

Do not conduct destructive production tests without explicit authorisation.

Step 10: raise findings

Raise a finding when:

• A question is No.
• A Gate fails.
• Evidence is rejected or materially insufficient.
• A test fails or produces an exception.
• Ownership is unresolved.
• The implementation differs from policy or contract.
• The control cannot be demonstrated in operation.
• A Critical control lacks required test coverage.

A useful finding contains:

• Clear title.
• Affected control and system.
• Condition observed.
• Expected requirement.
• Evidence.
• Root cause.
• Risk consequence.
• Severity.
• Recommendation.
• Owner.
• Target date.
• Status.

Step 11: record the assessor conclusion

Complete the structured conclusion:

• Design effectiveness.
• Implementation effectiveness.
• Operating effectiveness.
• Evidence conclusion.
• Residual risk.
• Assessor conclusion.
• Monitoring cadence.
• Reassessment triggers.
• Reviewer.
• Review date.

The conclusion should identify:

• What was reviewed.
• What was tested.
• What could not be verified.
• Open exceptions.
• Compensating controls.
• The basis for residual risk.
• The conditions under which the conclusion expires.

Step 12: review the derived result

Review:

• Conformance.
• Verified evidence.
• Narrative sufficiency.
• Ownership clarity.
• Audit readiness.
• Assurance percentage.
• Assurance score.
• Gate failures.
• Critical-control evidence and tests.
• Open findings.

Do not use the headline score without reading the underlying gaps and caps.

Step 13: use AI Assist

AI Assist can:

• Summarise the current validated scope.
• Identify evidence and testing gaps.
• Suggest bounded test procedures.
• Draft effectiveness and residual-risk reasoning.
• Identify monitoring and reassessment needs.

The assessor must:

• Confirm the displayed system scope.
• Check every claimed verified fact.
• Reject invented or unsupported conclusions.
• Decide whether to apply suggestions.
• Retain human accountability.

Step 14: perform quality review

Before sign-off, ask:

• Is the correct system selected?
• Is the authoritative Intake route complete and current?
• Has ACRS been reviewed where it changes required assurance depth?
• Do the scope and depth totals reconcile?
• Can the factual scope drivers be explained?
• Are all Mandatory, Triggered and Enhanced controls addressed?
• Are Critical and Gate controls prioritised?
• Are N/A decisions independently approved?
• Are Yes answers supported by linked evidence?
• Are Critical controls tested?
• Are failed tests and rejected evidence reflected in the conclusion?
• Are all findings linked and owned?
• Does residual risk reflect open exceptions?
• Are monitoring and reassessment triggers specific?
• Does the report use the correct system bucket?

Step 15: lock and report

Once reviewed:

• Lock the assessment according to your governance process.
• Generate the appropriate system or workspace report.
• Obtain formal review or approval.
• Record risk acceptance separately where required.
• Schedule the next review.

Locking prevents assessment changes and AI suggestions from being applied without reopening the governed workflow.

When reassessment is required

Reassess after:

• A new model or major model version.
• New training data or a changed retrieval corpus.
• A supplier or hosting change.
• New tools, plugins, memory or autonomy.
• Expanded privileges or system access.
• New personal or sensitive data.
• A move into a new jurisdiction.
• A serious incident, complaint or control failure.
• A material change in intended use.
• A failed control test.
• A regulatory or contractual change.
• Expiry of a N/A decision or evidence item.

Minimum sign-off record

A defensible sign-off should include:

• System and scope.
• Assessment date.
• Assessor and reviewer.
• Applicable control population.
• Gate failures.
• Critical control status.
• Evidence and testing summary.
• Open findings.
• Residual risk.
• Deployment or use restrictions.
• Monitoring cadence.
• Reassessment triggers.
• Approval decision.