How to conduct a construction site risk assessment

In the UK, a construction site risk assessment is a statutory duty under the Management of Health and Safety at Work Regulations 1999 (regulation 3) and is reinforced by the Construction (Design and Management) Regulations 2015 ("CDM 2015"). The duty sits with every employer and self-employed person carrying out work, with additional coordination duties on the client, principal designer and principal contractor.

The assessment must be "suitable and sufficient", recorded where there are five or more employees, and kept under review whenever the work, the workforce or the site changes materially. It is not a one-time deliverable — it is a living document that should move with the programme.

1. Identify the hazards. Walk the site (or the design, pre-start) and list every credible source of harm: working at height, excavations, plant movements, lifting operations, services strikes, hot works, confined spaces, dust and silica, noise, vibration, manual handling, hand-arm vibration, COSHH substances, traffic management, public interface, weather and ground conditions.
2. Decide who might be harmed and how. Operatives, subcontractors, visitors, neighbours, members of the public, deliveries, emergency services. Identify vulnerable groups — young workers, expectant workers, lone workers, those with language or literacy needs.
3. Evaluate the risks and decide on controls. Apply the hierarchy: eliminate, substitute, engineer, administer, PPE — in that order. PPE is a last line, not a first one. For each residual risk, record likelihood × severity and the resulting risk rating.
4. Record findings and implement them. The assessment, the control measures, who is responsible and the target dates. Communicate via inductions, RAMS, toolbox talks and the site's task briefing routine.
5. Review and update. After every incident, near-miss, design change, sequence change, or material change in personnel. At minimum, at each programme milestone.

A site risk assessment is usually a static PDF generated at mobilisation, re-circulated occasionally, and then quietly diverging from the live programme. Three failure modes recur:

• Risk is not time-aware. A working at height risk in week 4 is materially different from the same phrase in week 36 — different trades, different elevations, different adjacent activities. A single document flattens this.
• Controls drift from the contract. JCT and NEC obligations on temporary works, design responsibility and method approvals sit in the contract; risk assessments rarely reconcile against them, so the operational view and the contractual view tell different stories.
• Change events are not propagated. A compensation event, an early warning, an instruction or a variation can alter the risk profile materially — but the risk assessment is updated on a different cycle, if at all.

The SPACETIME.construction engine takes the same hazards and controls and projects them onto the project lifecycle. Instead of asking "what is the risk?" it asks "when does this risk crystallise, who owns it at that moment, and what triggers it?"

Practically that means:

• Deterministic extraction. JCT, NEC and bespoke contract clauses are parsed for obligations, deadlines, notice periods and ownership of risk. The output is structured, not narrative.
• Risk events on a timeline. Each risk is anchored to a date or trigger event — possession, sectional completion, practical completion, defects rectification — so the view changes as the programme progresses.
• Auditable evidence. Every entry links back to the clause, paragraph or instruction it came from. Reviewers can see the source, not just the conclusion.

• Does every identified hazard have a control mapped to the hierarchy?
• Are controls assigned to a named role, not just a company?
• Is the programme sequence reflected — week-by-week, not at PC only?
• Are CDM 2015 duties (client, PD, PC) explicitly recorded?
• Are the contract obligations (JCT/NEC) reconciled against the operational controls?
• Is there a defined review trigger for each major change event?
• Have the workforce been briefed in a language they read?
• Is the document version-controlled and stored where the site team can find it?