Why Paperwork Can't Prove Your Systems Are Safe

ePIC 2026 brought health and safety leaders to Auckland's NZICC for a day built around rethinking how safety actually gets done.

Two sessions in particular, from lawyer Greg Smith and organisational culture expert Andrew Sharman, landed on the same conclusion from opposite directions: the systems most organisations rely on to prove they're safe don't actually prove anything.

A third, from ecoPortal CEO Manuel Seidel, picked up the question that leaves leaders with: if better questions are what actually surfaces the truth, what makes it easy enough for people to answer them in the first place?

A signed form isn't proof of anything

Greg Smith has spent three decades defending organisations in safety prosecutions, and his argument is simple: a signed form proves someone signed it, not that they understood what they signed.

In one case he worked on, the file's own metadata told the real story: the average time between opening, reading, and signing a fifteen-page safe work method statement was 4.2 seconds. The signature existed. Understanding didn't.

That gap, between what's documented and what's actually understood, is where legal exposure sits. Not in missing paperwork, but in paperwork nobody read.

The same blind spot runs through the metrics most safety teams report upward:

• Management observation counts
• Training completion rates
• Corrective action closeout percentages

None of it says anything about whether a specific risk, on a specific shift, with specific workers, was actually understood and managed. Smith's point is that this is exactly what gets tested when something goes wrong, and it's rarely what the paperwork can answer. A court doesn't ask how many observations were done. It asks:

• What were the observations actually looking at?
• Who did them?
• What did they reveal?

That's a useful test to run before something goes wrong, not after: for the risk you're most worried about right now, could you show, today, that it's understood and controlled? If the honest answer is no, that's the gap worth closing, not the folder.

Ask questions built to find problems, not confirm their absence

Andrew Sharman, an organisational culture and leadership expert, picks up where that gap leaves off. If paperwork can't surface what's actually happening, something else has to, and his argument centres on a specific, practical shift: swapping walkaround questions that invite a shrug for ones that invite an actual answer.

The usual questions don't get a leader anywhere. "Is everything safe?" gets a "yeah, fine." "Have you got any issues?" gets a “no”. "Do you understand what you're supposed to do?" gets an eye roll.

His replacements:

• "What worries you about doing this job safely?"
• "What might you see that I don't see?"
• "What have we started accepting as normal that doesn't feel quite right?"

And after any answer, one more worth adding: "And what else?", which keeps the conversation open instead of closing it after the first response.

The distinction matters because it changes what a leader walks away with. A walkaround built on compliance questions confirms what's already written down. One built on discovery questions finds what isn't. That's a genuinely different piece of information, and it's the only kind a form can't produce on its own.

The harder part, and the one worth building into any safety walk, is following through. Asking someone what worries them and then doing nothing with the answer teaches them, accurately, that answering wasn't worth their time. Voice only stays honest if it's acted on. Skip that step and every future answer gets shorter and less useful, whether or not anyone intended it that way.

Make speaking up cheaper than staying quiet

Better questions still depend on someone being willing to answer, and willingness depends on how much it costs to speak up in the first place. Manuel Seidel's session made that concrete.

Picture a worker nine hours into a shift who spots a hazard. Under most systems, reporting it means:

• Walking back to the office
• Logging into the health and safety system
• Working through a form built for someone who already knows the terminology

Most people, reasonably, keep walking instead. Not because the hazard doesn't matter to them, but because the system made reporting it more expensive than staying quiet.

A conversational reporting tool that lets someone describe a cable across a loading dock in their own words, and turns that into a structured report without asking them to learn the system first, solves the same problem Sharman was pointing at from the stage: information only flows if sharing it costs less than staying silent.

Design for that, and reporting rates stop being a measure of engagement and start being a measure of how easy the organisation has made it to tell the truth.

Three things to check before you trust your own data

1. Pick the risk you're most worried about right now.

Could you show, today, that it's actually understood and controlled on the floor, not just documented? Smith's point was that this is the gap that gets tested when something goes wrong, so it's worth testing yourself first.

2. Sit in on your next walkaround.

Notice whether the questions confirm what's already written down or try to find what isn't. Swap one compliance question for one of Sharman's discovery questions and see what comes back.

3. Time how long it takes someone to report a hazard right now, start to finish.

If it's longer than a phone call to a colleague, that's the delay Manuel's session was warning about, the one costing you reports before they're ever made.

Final words

None of this needs to be overly complicated.

Treat paperwork as a starting point, not an answer. Ask questions built to find problems, not confirm their absence. And make sure speaking up costs less than staying quiet, because neither of the first two points matters if people can't get their answer to someone who can act on it.

That's the job the right health & safety system does: turning what a worker sees on the floor into something a leader can respond to before it becomes an incident. Get that right, and the data finally reflects what's actually happening. Skip it, and it's still just a pile of paper.