Reporting and governance decisions

GTSAF reporting converts the assessment record into an assurance decision package. Reports must preserve the selected scope and make adverse signals visible.

Report types

GTSAF can contribute to:

• Full assessment reports.
• Framework-focus reports.
• Executive summaries.
• Board packs.
• Evidence packs.
• Control-testing packs.
• Workpaper packs.
• Workspace portfolio reports.
• Selected-system reports.

The selected pack controls the level of detail, not the underlying assessment truth.

Selected-system reports

A selected-system report uses the GTSAF assessment bucket associated with the selected system’s intake.

It includes that system’s:

• Derived control scores.
• Answers.
• Ownership.
• Implementation and customer-responsibility records.
• N/A decisions.
• Assessor conclusions.
• Evidence.
• Evidence requests.
• Tests.
• Findings.
• AI analysis where included and correctly scoped.

If no matching GTSAF system bucket exists, the report fails closed to an unassessed position. It does not fall back to whichever workspace-level or browser-active bucket happens to exist.

Workspace reports

A workspace report provides an aggregate view of the AI estate.

It is useful for:

• Governance oversight.
• Portfolio prioritisation.
• Board reporting.
• Identifying repeated weaknesses.
• Monitoring assessment coverage.

It does not prove that every registered system shares the workspace average.

What counts as an action item

GTSAF does not use a generic “below 60%” rule to decide action items.

A control requires attention when one or more of these conditions exists:

• Gate failure.
• Failed, ineffective or exception test.
• Rejected or expired evidence.
• Open finding.
• Unassessed in-scope control.
• Critical control without required evidence.
• Critical control without a passing test.

This is more defensible than treating every score below a single threshold as equally important.

Control-level report content

A full control table can include:

• Control ID and title.
• Domain.
• Requirement.
• Criticality.
• Gate status.
• Assurance score.
• Assessment status.
• Uploaded evidence count.
• Accepted/reviewed evidence count.
• Rejected/expired evidence count.
• Open findings.
• Test procedure.
• Passing and failed test records.
• Effectiveness conclusion.
• Residual risk.
• Assessor conclusion.
• Reviewer and review date.

System-level decision relevance

For a system report, the report should distinguish:

Monitor

No material GTSAF assurance exception currently requires action.

Action, evidence completion, remediation or risk decision required

One or more GTSAF attention conditions exists.

The decision may require:

• Additional evidence.
• Control implementation.
• Retesting.
• Finding remediation.
• Compensating controls.
• Deployment restriction.
• Formal residual-risk acceptance.
• Escalation to governance or board level.

Gate failures in reporting

A Gate failure should be:

• Explicitly named.
• Linked to the affected system.
• Connected to the failed requirement.
• Supported by evidence or assessment rationale.
• Assigned an owner.
• Given a target decision or remediation date.
• Reflected in deployment or use restrictions.

Do not bury a Gate failure in a domain average.

Critical controls in reporting

For Critical controls, report:

• Whether verified evidence is sufficient.
• Whether operating effectiveness has been tested.
• Whether tests passed.
• Whether evidence is current.
• Whether findings remain open.
• Whether residual risk is accepted and by whom.

An Assured label without a passing test should be treated as a defect because the scoring model prevents that outcome.

Evidence reporting

Evidence reporting should state:

• What was uploaded.
• What was reviewed.
• What was accepted.
• What was rejected or expired.
• Which controls lack evidence.
• Which systems the evidence applies to.
• Whether evidence supports design, implementation or operation.
• Whether the evidence period is current.

Avoid statements such as “evidence is complete” based solely on document count.

Testing reporting

Testing reporting should state:

• Controls tested.
• Test period.
• Sample.
• Passing tests.
• Failed tests.
• Exceptions.
• Retests required.
• Critical controls not tested.

Failed tests remain action items even when the weighted score appears strong.

Findings reporting

Summarise findings by:

• Severity.
• Status.
• System.
• Control.
• Owner.
• Target date.
• Overdue state.
• Root cause.
• Residual risk.

Board reporting should focus on:

• Gate failures.
• Critical findings.
• Repeated systemic weaknesses.
• Unaccepted high residual risk.
• Overdue remediation.
• Decisions requiring authority or funding.

Assessor conclusion in reports

The conclusion should explain:

• Scope.
• Work performed.
• Evidence reviewed.
• Testing completed.
• Limitations.
• Effectiveness.
• Exceptions.
• Residual risk.
• Monitoring.
• Reassessment.

It should not merely repeat the score.

Residual-risk decisions

A residual-risk decision should identify:

• Risk owner.
• Decision authority.
• Risk level.
• Open gaps.
• Compensating controls.
• Exposure period.
• Conditions of acceptance.
• Expiry or review date.
• Reassessment triggers.

Risk acceptance is separate from control assurance. A control may remain a Gap even when the organisation formally accepts the residual risk.

Cross-framework reporting

GTSAF mappings can identify related:

• EU AI Act obligations.
• ISO/IEC 42001 clauses and controls.
• ISO/IEC 42005 impact-assessment expectations.
• NIST AI RMF functions and categories.

Use the mappings to support traceability and evidence reuse.

Do not state:

“GTSAF control passed, therefore the organisation is compliant with the mapped law or standard.”

Instead state:

“The evidence and testing for this GTSAF control are relevant to the mapped external requirement and should be reviewed as part of that separate determination.”

Board explanation

A board-level GTSAF summary should answer:

1. What AI systems are in scope?
2. How much of the required control population is assessed?
3. Which Gate controls fail?
4. Which Critical controls lack evidence or testing?
5. What material findings remain open?
6. What residual risks require acceptance?
7. What decisions or investment are required?
8. How will the organisation monitor and reassess?

Quality checks before export

• Correct workspace and system selected.
• Correct framework and pack type.
• System-specific GTSAF bucket present.
• Scope shown clearly.
• No cross-system evidence leakage.
• Gate failures visible.
• Failed tests visible.
• Rejected evidence visible.
• Critical controls reviewed.
• Assessor conclusion complete.
• Residual risk recorded.
• Reviewer and date present.
• Draft or approval status correct.
• Crosswalk caveat included.

Report wording to avoid

Avoid:

• “Fully compliant.”
• “Certified by GTSAF.”
• “No risk.”
• “All controls effective” where controls remain untested.
• “Evidence complete” based on upload count.
• “N/A” without the approved rationale.
• “AI verified” where AI only analysed the record.

Prefer:

• “Assured under the documented scope and assessment period.”
• “No material assurance exceptions identified in the current record.”
• “Subject to the stated limitations and residual risks.”
• “Testing covered the following population and period.”
• “The conclusion requires reassessment when the stated triggers occur.”