Compliance
How to Define Intended Use of a Computerised System
Define a computerised system's purpose, users, data and decision boundaries with a reusable intended-use template and an Excel quality register example.
To define the intended use of a computerised system, describe the process it supports, who uses it, the information it handles and the decisions people may rely on it to support. State its boundaries, including what it must not decide, which records are authoritative and who owns its use and controls. Write this before selecting features or planning verification.
This guide provides a reusable statement template and a fictional Excel quality register example. It is an assessment aid for quality-system work, not a complete Annex 11 guide, validation protocol or compliance determination.
This is a practical follow-on to Annex 11 in Plain English: that article explains the broader computerised-system control themes; this guide focuses on defining what a system is for and turning that purpose into a statement your team can review.
What belongs in an intended-use statement?
An intended-use statement describes the system's purpose and permitted reliance in a named process. "We use Excel" names a tool; "we track deviations and report overdue actions, but do not approve closure" describes a use and its boundary.
Start with the process owner and people who perform the work. Gather the current procedure, system or configuration description, representative records and reports, and known interfaces. For a proposed system, distinguish planned use from how the current process actually operates.
Capture these elements:
- The named process, system scope and user groups.
- Inputs, activities, outputs and interfaces.
- Decisions supported, authoritative records and explicit exclusions.
- Accountable owners, discrepancy handling and review triggers.
Use the statement to develop detailed requirements and acceptance checks; do not treat a short paragraph as a replacement for them or for executed validation evidence.
Start with the process, not the platform
A register can begin as a list of identifiers and dates, then become part of how a team monitors open work, escalates delays or reports quality trends. That reliance matters even when the register does not contain the full investigation or its approvals.
In this example, the register identifies deviations, tracks status and supports workload oversight. The controlled deviation record remains the source for the investigation, its conclusions and authorised closure. The register does not approve an investigation, release a batch or independently decide that a quality event is complete.
That boundary is not a claim that the register has no quality impact. Missing or misleading metadata could still affect oversight. The organisation must assess how people actually use the information, including reports, copied data and manual hand-offs.
The quality-register overview explains the register/record distinction; this article adds a copyable intended-use statement and ownership challenge.
Define applicability before naming requirements
Regulatory applicability depends on the organisation, product, activity, jurisdiction and actual use of the system. Do not treat every spreadsheet or SharePoint List called a “Good Manufacturing Practice (GMP) register” as automatically subject to the same requirements.
At the 29 October 2026 source check, the TGA's GMP guidance states that the current manufacturing principles specify PIC/S Guide PE 009-17, dated 25 August 2023, with Annexes 4, 5 and 14 not adopted in Australia. Check the TGA's linked guidance and current instrument for applicability and transition conditions before applying a clause to a system. This is not an applicability decision for a particular site, product or register.
The European Commission's Annex 11 consultation page identifies revised Chapter 4 and Annex 11 material as consultation drafts. A proposal is not automatically an effective Australian requirement. This example does not use draft text to set current obligations.
For further reading alongside the worked example, see the PharmOut-hosted presentation on Annex 11 and Annex 22 (PDF). Treat this as supplementary presentation material, not the adopted regulatory text or evidence that a proposed revision applies to an Australian site.
Use the edition adopted for the relevant jurisdiction, not the newest publication or a consultation proposal by default. Cite an Annex 11 locator only after checking it against the applicable official text. Where that verification is missing, leave the obligation unresolved rather than filling the gap with an assumption.
How to define intended use: seven steps
- Name the process, system boundary and user groups; inventory inputs, outputs, reports and interfaces.
- Trace how important information is created, changed, linked to source records and used.
- State the decisions and permitted reliance, including what the system must not decide.
- Assign accountable roles for process definitions, system control, quality oversight and platform support.
- Draft the intended-use statement and challenge it with missing information, conflicting records and unavailable-service cases.
- Compare the current or proposed configuration against the defined use; turn gaps into requirements, acceptance checks and decisions about whether to retain or change the system.
- Obtain the approvals required by the organisation's procedures, record residual risks and revisit the statement when the process or reliance changes.
Map the information and decisions: a quality register example
Trace important data from entry through reports, email hand-offs and decisions to its source record. Include copies, integrations, connectors and service identities: establish what each can read or change, who controls it and which write paths need verification. A column inventory alone will not show how a decision relies on the information.
| Question | Example boundary to test |
|---|---|
| What does the register identify? | A deviation ID, owner, dates, status and reference to its controlled record |
| Which record is authoritative? | The controlled deviation record holds the investigation and authorised closure |
| What may a user rely on the register for? | Tracking and oversight in this example; not approval or batch release |
| What can change that use? | A new automated decision, approval, signature or replacement of the source record |
Intended-use statement template
Use the answers to write a short statement. Keep it specific enough that a new user can tell what the system does, which decisions it supports and when to seek an authoritative record. Adapt the prompts to the system rather than assuming every system is a register.
Intended use:
The [system name and configuration/scope] supports [named process].
It is used by [user groups] to [activities] using [inputs and interfaces].
It produces [outputs/records] to support [named decisions].
The authoritative record for [investigation, approval or other controlled detail] is [record].
Users may rely on the system for [bounded uses], but not for [explicit exclusions].
When information conflicts with its source or the system is unavailable,
[role] initiates [reconciliation or continuity procedure].
The Process Owner reviews [scope, definitions and fit] when [triggers] occur.
Worked statement: an Excel deviation register
The Example Quality Team uses its Excel deviation register to identify deviation records, track assigned owners and dates, and support oversight of open work. Assigned editors enter identifiers and status information from controlled deviation records; Quality reviewers use the register's open-item and overdue reports. The controlled deviation record remains authoritative for the investigation, its conclusions and authorised closure. The register does not approve closure or release a batch. A mismatch between the register and its referenced record is recorded for reconciliation before the register is used to report that event as closed. If the register is unavailable, the Process Owner follows the team's documented continuity procedure. The Process Owner reviews this scope when reporting, interfaces or decision-making responsibilities change.
This is a fictional example, not an approved organisational statement. Replace the roles, records, decisions and escalation path with the actual process and approved procedures. The continuity procedure mentioned in the example must exist and be assessed in the real organisation; writing it into the statement does not establish that it works.
Assign accountability as well as tasks
Titles such as “Process Owner” and “System Owner” need assigned people, authority and escalation paths. This matrix is illustrative, not a universal role model or regulatory assignment.
| Activity | Illustrative accountable role | Supporting roles and evidence |
|---|---|---|
| Define the process, register purpose, data definitions and permitted reliance | Process Owner | Quality reviews the quality-system boundary; retain the approved statement |
| Maintain the configured system baseline and change evidence | System Owner | IT/Microsoft 365 administrator supports platform operations; retain configuration, change and operating records |
| Assess supplier and external-service responsibilities | System Owner or role named by the organisation | IT and the supplier provide service evidence; retain reviewed scope, limitations and open actions |
| Plan and assess verification | System Owner | Process Owner defines intended-use checks; authorised Quality role reviews acceptance; retain protocols, actual results and deviations |
| Set quality oversight, escalation and risk-acceptance decisions | Authorised Quality role | Process Owner supplies the impact assessment and discrepancy examples |
| Enter and reconcile register information | Assigned editor or process role | Follow the controlled procedure; retain the record reference and correction trail |
| Provide identity, access and service support | IT/Microsoft 365 administrator | System Owner defines required access; verify the organisation's actual service arrangements |
| Handle incidents affecting register data or service | Roles named in the organisation's procedures | Record the event, assess affected entries and reports, and retain reconciliation and escalation evidence |
| Plan recovery and continuity for the service and its records | System Owner or other role named by the organisation | IT supports service arrangements; retain approved recovery requirements and executed recovery evidence |
| Decide whether the configured solution is fit for its intended use | Decision-maker authorised by the quality system | Process Owner and System Owner provide assessment and verification evidence; retain the approved decision and residual-risk record |
Confirm who may approve intended use and accept residual risk. A role label here is not an appointment, approval or evidence.
Challenge the statement with failure cases
Walk through realistic discrepancies before choosing an implementation. Define the expected response and the evidence that would show the process works. The checks below are proposals; they have not been executed in a tenant or against a customer system.
| Scenario | Expected handling | Evidence to plan |
|---|---|---|
DEV-2026-0001 has no link to controlled record CR-0001 | Flag the missing reference; do not assume the entry is complete or traceable | Exception record, assigned owner and documented resolution |
| The register says “Closed” while the controlled record remains open | Route the discrepancy for reconciliation; do not use the register status as closure approval | Reconciliation record, authorised correction and retained rationale |
| A new workflow automatically approves closure | Reassess intended use, risk and authority before enabling it | Updated scope, requirements, risk assessment and approved verification plan |
Record each check's input, expected and actual results, deviations and authorised assessor. Until performed and documented in the relevant environment, its result is “not executed”.
Decide whether to retain, assess or change direction
An intended-use statement should help the team compare options, not predetermine a move to SharePoint. Retaining a controlled Excel register may be reasonable if its use, ownership, access, evidence and ongoing controls remain suitable. A SharePoint List may be assessed when its proposed configuration and service arrangements can support the defined process. Another solution may be more appropriate when required controls or responsibilities cannot be justified.
Before deciding, identify the relevant needs for data meaning, ownership, access, source-record links, change control, reporting, recovery and retention. Verify them against local procedures and the actual environment; do not infer a capability from a product name or demonstration.
Reassess the boundary before adding an approval, electronic signature, automated classification, product-release decision, system integration or replacement of the authoritative record. These changes can alter who relies on the information and what evidence is needed.
Put the statement to work
Review the statement with process users, the system owner and the authorised Quality role. For each permitted use, identify the requirements, controls and evidence needed to justify reliance. For a wider verification plan, see practical risk-based computerised system validation.
For the quality register example, assess whether the present register meets the defined need, identify the gaps and decide whether a controlled change is justified. The quality-register assessment pathway is the next step for teams that need help assessing fit and evidence. For broader context, see how a spreadsheet's role can change when it starts influencing GMP decisions.
The goal is not to move every register or produce a large package by default. Make purpose, decision boundaries, responsibilities and residual risks clear enough to choose and maintain a suitable approach.