Guide

Designing height safety access under a mandatory Code

Has the test for what counts as compliant been elevated?

Short answer: yes. A companion piece to NSW Codes of Practice are now mandatory, focused on the design end — what section 26A does to an access system specification, and what a defensible design package has to contain.

Four things that shift for designers

01

The design is now the evidence

A drawing and a compliance certificate used to be enough. Now the reasoning behind the layout is the compliance record: what task, how often, what was ruled out and why has become sort after evidence.

02

Anchors are a last resort, in writing

Fall arrest is the fourth rung down. Specifying anchors for a monthly task, where a walkway was buildable, is a departure you have to defend rather than a default.

03

Reasonably practicable now has a floor

Cost still counts, but only against the Code's baseline. 'The client's budget wouldn't stretch' has never been a defence and it reads worse against a mandatory standard.

04

Standards and Code have to agree

AS 1657 gives you the dimensions. The Code gives you the order of preference. Meeting the standard for a system the Code says you shouldn't have chosen doesn't get you there.

The short answer

Yes, the test has been elevated — not because the duty changed, but because the benchmark stopped being negotiable.

Before 1 July 2026, a designer could argue what was reasonably practicable and use the falls Code as one input. Now the Code sets the minimum. You either meet what it says should happen, or you prove your alternative is equivalent or higher. There is no third option and no room for 'it's only guidance'. Perhaps many already take this, but if you are not it's time to step up your design process.

What this does to access design

Height safety design is a hierarchy exercise before it's a hardware exercise. The Code wants the need to work at height eliminated first — relocate the plant, service it from ground level, design the roof so nobody has to go near the edge. Then fall prevention: a fixed walkway, a guardrail, a platform. Only then work positioning, then fall arrest, then administrative controls.

Most existing buildings and a fair number of new ones are designed at the bottom of that list. Two anchors, a static line, and a note in the manual. That was always weak for a task done every month. Now it's measurable, and the measurement happens against a document the regulator can quote back at you.

The change for designers is mostly about what leaves your office. The layout might not shift much on a straightforward roof. The report behind it has to shift a lot.

What a defensible design package looks like now

Start with the task, not the roof. What work happens up there, who does it, how often, and what they carry. Frequency is what moves a system up the hierarchy — a once-a-decade inspection and a monthly filter change are not the same problem.

Then work the hierarchy in order and record each step. Elimination considered, why it isn't available. Passive protection considered, why it isn't reasonably practicable here — structural capacity, heritage constraint, roof pitch, whatever the real reason is. Keep going until you land on the control you're specifying, with the ruled-out options above it accounted for.

Name the standards you applied and where. AS 1657 for fixed platforms, walkways, ladders and guardrail geometry. AS/NZS 1891 for the fall arrest components where they're used. Then state the residual risk plainly — what the system does not protect against, and what the user has to do.

Finish with what keeps it compliant: inspection intervals, recertification, and who owns that. A system that was right on day one and unrecorded three years later is a gap under the new rule, not a maintenance oversight.

Where designers get caught

Designing to the hardware you're used to specifying. If the same anchor solution appears on every roof regardless of task frequency, the hierarchy wasn't worked — it was skipped. That pattern is visible across a portfolio.

Letting the installer set the scope. If the scope arrives from a supplier, it arrives shaped around their product. Independence from the hardware is the difference between a design and a quote with a drawing attached.

Silent departures. Choosing a lower control is allowed. Choosing it without recording why is what fails, and it fails on the paperwork before anyone looks at the roof.

For the building owner reading this

You don't need to know the standards. You need the design report to answer three questions: what tasks was this system designed for, what did the designer rule out and why, and what do I have to do to keep it valid.

If your current documentation can't answer those, that's the gap. Under the mandatory Code, the absence of the reasoning is itself a shortfall worth your investigation.

Want your access design checked against the Code?

We specify independently of the hardware, work the hierarchy in order, and hand you the reasoning in a form that holds up.

Free tool: height safety design assessment

Score each roof task with an exposure-weighted risk matrix, work the hierarchy of controls in order, and print a Design Report. Runs in your browser, nothing is stored.

Open the tool

The Spec Hub

Independent roof and facade access specification for Installers, Architects, Builders, Certifiers and Structural Engineers — risk first, product second.

Visit The Spec Hub

Not sure your design package would hold up?

admin@f4ps.com.au