Intended-use definition and use restrictions

What it does

It fixes what the system was approved to do, so that testing, tiering and legal classification have a defined object and so that a new use is recognisable as new. The business owner writes the definition and is accountable for staying within it; governance approves it and any extension.

How to implement it

• State the decision or task supported, the users, the people affected, and the operating conditions.
• State what the system must not be used for.
• Record the definition in the inventory against the system.
• Enforce it technically where possible, by restricting access and scope.
• Require any consumer of the system's output to register its use.
• Trigger reassessment of tier, validation and classification when use changes.

Evidence it operates

Design: an intended-use statement for each system, approved and held in the inventory. Operation: access lists consistent with the stated users; a register of consuming systems; a record of a proposed new use that was assessed before it started.

Where it fits

Written at the start of the lifecycle, confirmed at approval and revisited on change. It is the primary control for use beyond validated scope, and it supplies the reference point for pre-deployment testing and validation.

Limits

A statement does not stop misuse; it makes misuse identifiable. Definitions written broadly to avoid future approvals defeat the purpose. General-purpose systems will attempt any request, so the restriction has to be enforced around the model and not expected of it. Outputs that are copied into spreadsheets or reports travel beyond any technical restriction.