Skip to content

Lesson 10 of 13 · 2 min video

Create and track risk controls

Here you'll turn the evidence sentence from Decide where to act into a risk control with an owner, a date and a status. You choose the control; Etiscope helps make sure it stays visible until it's done.

What you'll be able to do

Create a control choosing its Type from the built-in hierarchy, link it from the assessment, move it through the status lifecycle, and read the overdue card.

  1. 01Choose a control's Type from the product's built-in hierarchy of controls.Taught in The Type field is the hierarchy
  2. 02Create a risk control in form order, with a named responsible user and a real due date.Taught in Create the control
  3. 04Move a control through its status lifecycle and read the overdue card that tracks it.Taught in The status lifecycle, Overdue — and the control's tabs
The written lessonPrefer to read? Open the full lesson, chapter by chapter.The same lesson as the video, chapter by chapter.ShowHide

Chapter 1 · 0:00

The Type field is the hierarchy

Etiscope has the hierarchy of controls built in. A risk control's Type is one of: Eliminate, Substitute, Engineering, Administrative, or PPE — in that order, on purpose.

The order matters. Eliminating the hazardous movement protects everyone who ever does the task, permanently, without depending on anyone remembering anything. PPE protects the person wearing it correctly, today.

Which control you choose is your organisation's own engineering and approval decision. Etiscope gives you the place to record that decision, assign it, and hold it to a date.

It helps to treat the Type field as a prompt rather than a label. If everything on your list is typed Administrative or PPE, that tells you something about the program rather than the tasks.

Chapter 2 · 0:29

Create the control

Select Risk controls in the sidebar, and choose New risk control.

The form runs in order: the business unit, the work task the control addresses, the Type, a name that says what will actually change, the status, the due date, the responsible user, and a description.

Name it for the change rather than the problem. "Raise bottom pallet layer to 400mm on Line A" tells the next reader what was agreed, whereas "Manual handling risk — Line A" only repeats what they already know.

Two fields carry the follow-through: a named responsible user, and a real due date. Without a due date, a control never appears on the overdue card, so nothing flags it if it slips; without a responsible user, there's nobody to follow it up.

Chapter 4 · 1:23

The status lifecycle

Status is three steps: None, In Progress, Implemented.

When work starts, open the control, open the Status field and choose In Progress. When the change is actually in place, set it to Implemented.

Wait until the change is in place on the floor before you set Implemented. The before-and-after comparison in Check whether a change worked depends on it: if the status says the change is in place before it actually is, any assessment captured in between is compared against a control that wasn't there yet.

Chapter 5 · 1:46

Overdue — and the control's tabs

On Home, the Overdue Risk Controls card lists every control that is In Progress and due today or earlier.

Overdue isn't a status anyone sets — it's worked out from the date. You don't have to maintain anything for the program to see what's slipping, which is why it's worth entering a realistic due date rather than an optimistic one.

Each control also carries its own record across four tabs: Details; Attachments, for the before photos, the quotes and the approval; Stats; and the Assessments it covers.

Stats leads into Check whether a change worked — it's where the assessments on this control's work task are charted, and where an accumulating before-and-after eventually becomes visible.

Mistakes that matter

  • Typing everything as Administrative or PPE without considering the higher-order options. The hierarchy is in the field on purpose, and defaulting to the bottom of it can leave a program retraining people around a hazard it could have removed.
  • Controls with no owner and no due date. They never go overdue, so nothing ever flags them.
  • Marking a control Implemented before the change is in place. The before-and-after comparison in Check whether a change worked depends entirely on that date being true.

Not covered here