‘Staff informed’ is written in the action log. What should happen at the next change, who should do it, and what would count as evidence?
ORR IMS is an evolving learning example, currently connecting five starter kits. It is not a complete implementation of the four standards in its intended scope.
The entry may accurately describe something that happened. It tells us very little about the ongoing safeguard.
An implementation discussion becomes more useful when people can identify a particular action under particular conditions, performed by someone with a defined responsibility. They can then examine whether that action occurred and whether it supported the intended outcome.
The output of this article is one usable control statement: a named role, a recognisable trigger, an action, criteria, evidence and a response to failure. Someone should be able to read it and explain what to do on the next eligible occasion.
Describe the occasion when it matters
A control needs a trigger or timing condition. Without one, people can disagree about whether the control was required on the occasion being examined.
Consider a fictional agency preparing a client deliverable. Before the sender releases the final file, a designated reviewer compares the recipient list and file version with the approved job brief. This is a proposed learning example, not a claim that the arrangement has been tested.
That wording connects the control to an event. It also identifies the users and information that matter.
“Check documents regularly” would leave much more open. How often? Which documents? For what purpose? What constitutes a satisfactory check? If one person interprets the instruction differently from another, the record may conceal variation rather than establish consistency.
The first step is to make the occasion recognisable to the person doing the work.
State what the control is intended to prevent
The agency wants the agreed deliverable to reach the authorised recipients. A stale recipient list or superseded file could defeat that outcome. The proposed comparison addresses those specific mismatches; it does not establish that every other delivery risk is covered.
This lets someone challenge the design. Is the approved brief available? Does the reviewer examine the actual attachment and recipient list that will be used? Could either change after review? What mismatch requires the sender to stop and seek a decision?
These questions concern whether the arrangement makes sense for the defined risk. They do not establish that the arrangement actually operated.
A well-designed control can be missed. A diligently performed action can also be poorly designed for the problem. Keep both possibilities available during the review.
Make the evidence attributable
For the agency exercise, propose a record identifying the job, approved brief, file version, recipient list, reviewer, time and result. Include a reference to any unresolved mismatch and the decision that resolved it.
Those details connect the record to a claim. They help someone examine what was checked, for which occasion and with what result.
The right evidence for another organisation may look different. A system event, a physical test result or an observation may be more appropriate than a signed form. The question is whether the evidence supports the particular conclusion, with enough reliability and context.
Avoid assuming that more records automatically create more confidence. Several records may repeat the same unsupported statement. A large attachment can be less useful than one clear entry tied to the relevant event.
Ask what would distinguish a performed check from a form completed later without the underlying activity.
Define what happens when the check fails
A control statement is incomplete if it describes only the successful path. The performer needs to know how to respond when a condition is not satisfied.
In this fictional agency exercise, a mismatch keeps the deliverable unsent while the job owner resolves the recipient or version question. The example needs an explicit decision route; the reviewer should not silently amend a client’s instructions.
For an actual organisation, the response must fit the risk, the activity and the authorised arrangements. The person performing the check should not have to invent the decision boundary under pressure.
Examine the receiving side of the escalation too. Who acknowledges the issue? What information is needed? Who can resolve it? Where is the resulting decision retained?
An escalation that produces no answer leaves the control unfinished.
Test a missed execution
The ORR IMS acceptance protocol includes a failed-control scenario. In a fictional tabletop exercise, remove the evidence for one eligible occasion and ask the team to follow the response.
Does the absence become visible? Does the measure include it? Does someone retain the original result? Can the issue reopen the parent risk or trigger an accountable review?
Observe what the instructions lead people to do. Do not coach them through every uncertainty and then report that the instructions were clear.
A tabletop test can reveal ambiguity in the design. It cannot establish that people will perform the control reliably in real conditions. Actual operation requires its own evidence, including the relevant context and period.
That boundary keeps the learning result useful without exaggerating it.
Account for the conditions of execution
When a check is missed, examine the circumstances before concluding that the performer simply needs another reminder.
Was the trigger visible? Was the information available? Did the person have sufficient time and competence? Were two duties scheduled at once? Did the relief arrangement transfer the responsibility?
These are questions to investigate. They do not remove accountability, and they should not be used to invent explanations unsupported by evidence.
The practical purpose is to understand what must change for the control to operate as intended. If the activity cannot fit the available work, a more forceful instruction may leave the underlying difficulty untouched.
Management may need to change resources, design, responsibilities or the sequence of work. Record the decision and define how its effect will be checked.
Rewrite one control statement
A fictional agency checks the agreed recipient list before sending a client deliverable. “Check the email” leaves the event and criteria unclear. Naming the sender, release point, approved list and response to a mismatch makes the proposed check open to challenge.
Rewrite one vague control with six fields: responsible role, trigger, action, criteria, evidence and failure response. Ask someone to describe a case the wording cannot resolve.
Start with the risk-and-control worksheet. Which of the six fields is missing from your fictional example? Leave a comment below; a question or fictional example is enough. If you want to propose a document change, the contribution guide explains the optional GitHub route.
Use fictional examples only. Do not share employer or client records, personal information or copied standards text.
Images are AI-generated illustrations, not photographs or evidence of actual implementation.
Part 7 of 12 in Making IMS Work with ORR IMS. Explore the series.
Leave a Reply