Safe Work Procedures

A Safe Work Procedure (SWP) is a written, versioned method for carrying out a specific task safely — how to work at heights on a particular roof, how to isolate a machine before maintenance, how to enter a confined space. SHEQ Control Plane's Safe Work Procedures register holds every procedure your organisation has written, each with its own owner, version number, and review date, and moves each one through an explicit lifecycle rather than letting a document be edited in place indefinitely.

A procedure that's silently out of date is worse than no procedure at all — it gives a false sense that the risk is controlled. Versioning and an explicit status (draft → review → approved → superseded) mean anyone looking at a procedure can tell, at a glance, whether it's the current, approved way of doing the work or a superseded one being kept for record purposes. Because Permits to Work link directly to a specific procedure record, a permit can only be issued against a procedure that actually exists in the register — not a paper copy someone printed six months ago.

Procedures are created as draft, moved to review while the responsible owner or a reviewer checks them, and marked approved once they're ready to be worked to. When a procedure needs to change, the usual pattern is to create a new version rather than editing the approved one in place, and mark the old version superseded — so the register keeps a full history of what the approved method was at any point in time, which matters if an incident investigation later needs to establish what procedure was actually in force on a given date.

The list page shows every procedure with its status, version, owner and next review date, and can be filtered and sorted by any of those. The detail page shows the full record; the create and edit forms use the same fields.

• Title — required. What the procedure covers, e.g. "Working at Heights — Roof Access". Keep it specific enough that two different procedures never need the same title.
• Version — required, free-text (e.g. 1.0, 2.1). Bump this whenever the procedure's content changes materially, not on typo fixes.
• Status — one of draft, review, approved, superseded. New procedures default to draft.
• Owner — required. Who maintains this procedure and is responsible for keeping it current.
• Next review date — required. When this procedure is next due to be checked, independent of its status.

Creating or editing a procedure validates every required field before it can be saved, and confirms before discarding unsaved changes if you navigate away from the form. There is no separate "approve" button distinct from editing the Status field directly — moving a procedure to approved is done the same way as any other field edit, gated by the same write permission as any other change to this register, not a separate, more restrictive approval permission (see Settings).

An approved procedure becomes available to reference from a new Permit to Work — the permit's relational picker resolves live procedure records, so only procedures that actually exist in this register (in any status) can be linked. There is no automatic notification when a procedure's review date passes or when it's superseded in the current version of the product; review dates are a field to filter/sort on, not yet a triggered reminder.

Can I delete a procedure instead of superseding it? The register supports deleting a record, but superseding preserves the history — prefer it for any procedure that was ever actually approved and used, and reserve deletion for records created by mistake.

Does changing a procedure's status affect permits already linked to it? No. A Permit to Work's link to a procedure is a reference to that specific record; it doesn't re-validate against the procedure's current status after the permit is issued.