The methodology underneath
Ten governed controls, assessed through six modules, mapped to the clauses and domains of the frameworks that apply — with the questions themselves adapting to each AI system.
The ten controls
Every AI system resolves against the same ten. What changes is which of them apply, and why.
- Accountability
- System risk assessment
- Validation
- Human oversight
- Data protection
- Action boundaries
- Monitoring
- Incident and recovery
- Change control
- Traceability
Mapped outward, adapted inward
Each control carries its mapping to the clauses, articles and domains of the frameworks in scope — so one answer serves several obligations. Which questions appear is derived from the system's own profile: purpose, data, autonomy, people affected, supplier exposure and sector.
Every control ends in one governed state
PASSPARTIALGAP MISMATCHREVIEWUNKNOWN NOT APPLICABLE
Applicability is derived from the system's own profile and recorded with a reason, so a client can always see why a control did — or did not — apply to them.
Assessed through six modules
System registration
Every AI system, once per system.
Risk and regulatory screening
Every registered AI system.
Data governance
Activated by data, integration and exposure signals.
Human oversight and transparency
Activated by decision impact, people-effect or transparency duty.
Testing and technical assurance
Activated by impact, model type, public exposure or autonomy.
Monitoring, incidents and change
Activated for deployed systems; deeper for elevated risk.
One engagement, many AI systems, assessed proportionately
Systems stay together for oversight and separate for evidence. Each carries its own risk band, questions, findings and reviewer decisions.
Decision, rights or safety impact, or autonomous execution
Deeper testing, oversight and monitoring questions activate.
People-affecting or autonomous, materially reversible
Proportionate depth — enough to evidence the control, not more.
Productivity or internal support use
A light path. A low-risk assistant is never assessed like a decision system.
Evidence is held to account, and so is the reviewer
Evidence custody
- Requested — a reviewer raises a specific, requirement-linked request.
- Provided — the client uploads or references the item, with content hash, size and version recorded.
- Assessed — the reviewer records a sufficiency decision: accepted, insufficient, or with a reason.
- Reused — an accepted item can serve several requirements without duplicating the file or losing its version.
- Refreshed — when a source changes, dependent outputs are flagged stale rather than quietly left wrong.
The reviewer decision
Every automated finding must be dispositioned by an authorised reviewer before anything reaches the client.
- Confirm — the finding stands as generated.
- Amend — the reviewer rewrites the issue in their own words, and the client sees the reviewer's wording.
- Hold — unresolved. A held finding blocks completion; the review cannot be signed off around it.
The assessment then carries one conclusion — held, review required, or clear — and the client sees the reviewer's, never the machine's.