2. Determine risk and scope
ORF separates system risk from telemetry priority. System risk describes the deployment context and potential impact. Priority tier describes how foundational an ORF telemetry item is. Their intersection determines the implementation obligation.
Assign the system risk tier
| Risk tier | ORF description | Typical examples |
|---|---|---|
| Low | Pilot or proof of concept with limited impact and strong human oversight | single-team experimentation; outputs not used for downstream decisions |
| Medium | Internal agency use with minimal operational impact, or low-impact public use with strong human oversight | drafting assistant whose outputs are reviewed before use |
| High | Significant operational impact or high-impact public-facing deployment | consequential public information service; agent acting on an external system |
Use the organisation's formal AI risk process where one exists. Document how the ORF tier relates to that process instead of creating a competing classification.
Apply the requirements matrix
| Priority tier | High-Risk | Medium-Risk | Low-Risk |
|---|---|---|---|
| Tier 1 | Mandatory | Mandatory | Good-to-Have |
| Tier 2 | Mandatory | Mandatory but Waivable | Good-to-Have |
| Tier 3 | Mandatory but Waivable | Good-to-Have | Good-to-Have |
| Tier 4 | Good-to-Have | Good-to-Have | Good-to-Have |
Mandatory items cannot be waived. Mandatory but Waivable items require a documented approval and risk acceptance. Good-to-Have items remain useful when they address a material system-specific risk.
Scope the implementation
Define:
- systems, channels, services, agents, models, retrieval sources, and tools;
- production, staging, evaluation, and disaster-recovery environments;
- user populations and material journeys;
- in-scope organisational teams and third parties;
- telemetry destinations and administrative systems; and
- explicit exclusions with rationale.
Where a shared platform serves several AI products, separate platform controls from product-specific signals. Each product still needs its own risk tier, requirements register, and operating ownership.
Assess telemetry data risk
The system risk tier does not determine how telemetry may be stored. Perform a parallel data-handling assessment.
| Question | Design implication |
|---|---|
| Can prompts contain personal or classified data? | content filtering, redaction, restricted store, shorter retention |
| Can tool parameters contain secrets or tokens? | allowlist safe fields; never record raw credentials |
| Do retrieval results contain protected documents? | store document IDs and classifications rather than full content where possible |
| Are user IDs needed for abuse detection? | pseudonymise; control re-identification; define purpose and retention |
| Must incident records be immutable? | append-only or integrity-protected evidence store |
| Are there residency or cross-border restrictions? | constrain collector routes, processors, and storage regions |
Never log secrets
Credentials, access tokens, private keys, authentication cookies, and full connection strings should be removed at source. Post-ingestion redaction is not an adequate primary control.
Define reassessment triggers
Reassess risk and scope when:
- the system becomes public-facing or reaches a new user population;
- model, prompt, policy, retrieval data, memory, or tool capability changes materially;
- the system gains autonomy or external side effects;
- data classification increases;
- a serious incident or repeated control failure occurs; or
- assurance identifies a previously unmodelled failure path.
Decision record
Record the tier, rationale, scope, data-handling assessment, approvers, date, assumptions, and reassessment triggers. Link the decision to the version of ORF used.
Done when: the risk tier, data-handling constraints, scope boundary, and approval authority are explicit enough to determine every item's obligation.
Next: Select requirements