The contractor safety file

What a safety file is, and who decides what goes in it

A contractor safety file is the evidence pack you hand a client to show that the work you are about to do has been thought about: the hazards identified, the procedures written, the people trained and medically fit, the appointments made in writing. On a construction site the duties behind it come from the Occupational Health and Safety Act and the Construction Regulations made under it. On a mine they come from the Mine Health and Safety Act instead, which is stricter in most of the places that matter to you.

What those laws do not do is hand you a list. They set duties, and then they leave it to the client and the principal contractor to say what satisfying those duties looks like on their site. That is the part most contractors learn the hard way, usually on the second or third client.

The client’s health and safety specification is the real checklist

The principal contractor issues a health and safety specification for the work. It describes the site, the hazards the client already knows about, the standards they expect and the documents they want to see. Your safety file, and the site-specific health and safety plan inside it, must answer that document point by point. A principal contractor has to give the client a documented, coherent and site-specific plan, and the file has to be on site before construction work begins.

So the first move on a new job is not to open last year’s file. It is to get the specification in writing and read it with a pen. If the client has not sent one, ask for it, and ask the safety officer what their document standard is for certified copies, inductions and medicals. Ten minutes of that conversation saves a resubmission.

It also explains the thing that frustrates everybody: no two clients want the same pack. They are not being difficult and they are not applying different law. They are applying different specifications to different sites.

What is typically expected in the pack

With that caveat in place, there is a recognisable shape to most files. Treat the following as the usual contents rather than a statutory checklist, and check each item against the specification you were given:

• Baseline and task-specific risk assessments
• The health and safety plan for the site
• A fall protection and rescue plan where work at height applies
• Contractual documents
• Safe operating procedures for the work and the equipment
• Emergency contact numbers, evacuation plans and emergency procedures
• Incident reporting and investigation procedures
• COIDA documents, including the letter of good standing
• Employee details: identity documents, driver’s licences, training certificates and medical certificates of fitness
• Registers and checklists for plant and equipment
• Records of daily safety talks, planned task observations and daily inspections
• The company health and safety policy
• Legal appointments
• Any further management plans relevant to the work

A client may want more, may want it in a particular order, and may want an index that matches their own numbering. None of that is negotiable from your side, and arguing it costs more than complying with it.

The two halves of the file, and why one of them rots

Here is the structural point that makes the whole job easier to manage. That list is not one kind of document. It is two, and they behave completely differently.

The first half is written once and reused with light edits. Your policy, your procedures, your risk assessment methodology, your emergency arrangements: these change when the work changes or when a client asks for something specific, not every month. The second half is a snapshot of people on a particular day. Who is on site. What each of them is trained on. When each certificate expires. Whose medical is current. Whose certified identity document copy is recent enough.

The second half is stale almost immediately, and it is the half that gets a pack sent back.

Once you see the file this way, the sensible response is obvious. Stop rebuilding the left column. It is already correct, and rewriting it is how typing errors get in. Spend the effort on the right column, which is the only part that is genuinely different on every submission.

Certified copies and the things that expire quietly

The right-hand column fails in a particular way: nothing announces itself. A certificate does not stop working on its expiry date, it just stops being acceptable to a reviewer, and you find out when the pack comes back.

Certified copies are the classic example. South African clients commonly require a certified copy of an identity document to be recent, often within three months. That requirement comes from the client rather than from the Act, so it is commonly required rather than legally fixed, and it varies. What does not vary is the consequence: a copy certified eight months ago is a rejected page, no matter how valid the identity document behind it is.

The same quiet expiry applies to medical certificates of fitness, site inductions, licences and operator authorisations, and to your letter of good standing, which runs on an annual cycle of its own. Each of those has a different date. That is the real problem. Nobody forgets one deadline; they lose track of forty of them across a crew of fifteen employees.

A practical habit: keep one list of every person on your books with every expiry date against their name, sorted by date, and look at it before you promise a client a submission date. If three medicals expire next month, you want to know that while you still have time to book them.

What a rejection actually costs you

It is worth being blunt about this, because the cost is not the document. A pack rejected for one expired induction or one stale certified copy goes back to the start of the client’s approval queue. That queue can take weeks, and your crew waits while it moves.

So the arithmetic is lopsided in a way that is easy to miss when you are in a hurry. Replacing one certificate is an afternoon. Rejoining the queue behind everybody else is a fortnight of employees not earning and a client whose next call goes to someone else. The expensive failure is almost always a small, boring, completely preventable one.

Which is the argument for checking the perishable half twice and the permanent half not at all.

Building it so the next submission is a reprint

The goal is to get to a point where producing a safety file is printing, not writing. That takes three things.

Separate the two halves physically. Keep the write-once documents as a maintained master set that you version when something genuinely changes, not a folder you copy and overwrite per client. Keep the people records somewhere they can be read as a live list rather than as a stack of scanned pages.

Track expiry dates as data, not as paper. Every training certificate, medical, licence, induction and certified copy has a date. If those dates live only on the documents, the only way to check them is to open every file. If they live in one register, you can see in a minute who is current and who is not, and you can see it a month early instead of on the day the client asks.

Start every submission from the specification. Read the client’s health and safety specification, build the index to match it, and then pull the write-once documents in behind that index. Assembling to the client’s order rather than your own removes most of the back-and-forth, because the reviewer can find each item where they expect it.

Do that, and a new client stops being a week of scanning. It becomes an afternoon: confirm the specification, pull the master documents, refresh anything in the perishable column that has gone out of date, and submit. The file still proves nothing about what happens on site, and no file or system makes you compliant. But it stops being the reason your crew is standing at a gate.