Your Safety File Looks Complete. So Why Is the Client Still Rejecting It?
You have a safety file.
It is hundreds of pages long.
The forms are signed.
There are policies, risk assessments, training certificates and registers.
So why did the client send it back?
Because a safety file that looks complete is not necessarily a safety file that is compliant, relevant or site-specific.
This is one of the most common misunderstandings in occupational health and safety documentation.
A client is not simply checking whether you have submitted a large folder of documents. They are checking whether your safety file demonstrates that you understand the risks of the work you are about to perform and have systems in place to control those risks.
A thick safety file can still be rejected
One of the easiest mistakes to make is believing that more documents automatically means better compliance.
It doesn't.
A 500-page safety file containing generic documents can be less useful than a well-structured 100-page file containing the right documents for the actual project.
When a client reviews your safety file, they may be asking questions such as:
- Does this documentation relate to our specific project?
- Does the risk assessment address the actual work being performed?
- Are the hazards identified relevant to this site?
- Do the workers have the required training and competencies?
- Are the correct appointments in place?
- Does the method statement describe how the work will actually be done safely?
- Are emergency procedures appropriate for this workplace?
- Is the PPE specified for the actual hazards?
- Are inspections, registers and records relevant and up to date?
- Do the documents agree with one another?
If the answer to these questions isn't clear, the file can be rejected regardless of how impressive it looks.
Generic does not mean site-specific
This is where many safety files fall short.
A generic risk assessment might identify hazards associated with working at height.
A site-specific risk assessment should go further.
It should consider the actual conditions under which the work will take place.
For example:
Generic:
"Risk of falling while working at height."
Site-specific:
The assessment considers the particular work area, access method, work platform, surrounding structures, weather exposure, fall protection requirements, rescue arrangements and other conditions associated with that specific task and site.
The second demonstrates that someone has actually considered the work.
That distinction matters.
A client wants evidence that your safety documentation reflects the project they are responsible for, not simply a template that has been reused from another job.
Your documents need to tell the same story
Another reason safety files are rejected is inconsistency.
Imagine your safety file states that workers will use a specific piece of equipment.
Your risk assessment doesn't mention the equipment.
Your method statement describes a different procedure.
The PPE requirements don't correspond with the identified hazards.
The training records don't demonstrate that the employees are competent to perform the work.
Individually, these documents may look perfectly acceptable.
Together, they create questions.
A strong safety file should tell a consistent story:
What work are you doing?
↓
What hazards does that work create?
↓
What controls are being implemented?
↓
Who is responsible for those controls?
↓
Have the workers been trained and deemed competent?
↓
How will the controls be monitored and maintained?
When the documents connect logically, the client can see how your safety management system actually works.
Certificates alone don't prove competency
Training certificates are important, but they are only one part of the picture.
A certificate can demonstrate that an employee completed a particular training programme. It does not, on its own, demonstrate that every requirement of the job has been addressed.
Your safety file may also need to demonstrate appropriate appointments, experience, supervision, medical fitness where applicable, task-specific instruction, induction and other competency requirements depending on the work and client specifications.
The important question is not simply:
"Do we have certificates?"
It is:
"Can we demonstrate that the people doing this work are appropriately competent and authorised to do it?"
Client specifications matter
There is another reason a safety file can be rejected even when the documents themselves appear correct.
The client's requirements may be different from your standard safety file checklist.
Construction companies, mines, factories, municipalities and other organisations may have their own contractor requirements, submission procedures and minimum documentation.
A safety file should therefore be reviewed against:
- Applicable occupational health and safety legislation.
- The actual scope of work.
- The conditions and hazards of the site.
- The client's contractor requirements.
- Project-specific specifications.
- The documents and records required to demonstrate that controls are being implemented.
Simply submitting the same safety file for every project is risky.
Before submitting your safety file, ask these questions
Before sending your file to the client, don't just ask:
"Is everything in there?"
Ask:
"Does everything in here apply?"
Then check:
1. Is the company information correct?
Check company names, registration information, contacts and other identifying details.
2. Is the project information correct?
Make sure the project name, site address, scope and relevant client information are accurate.
3. Does the risk assessment reflect the actual work?
Don't rely solely on a generic hazard list. Consider the specific activities, environment and conditions.
4. Do the method statements match the work?
The method statement should describe the actual work process and the controls that will be implemented.
5. Are the appointments appropriate?
Check that required health and safety appointments have been made and documented correctly.
6. Can you demonstrate competency?
Review training certificates, competency records and other evidence required for the work.
7. Are emergency arrangements relevant?
Emergency procedures should make sense for the actual workplace, including relevant emergency contacts, evacuation arrangements and rescue requirements.
8. Are inspections and registers ready?
Where applicable, ensure the required inspection records, equipment registers, PPE registers and other monitoring documentation are available and maintained.
9. Have you checked the client's requirements?
This step is often overlooked.
A legally compliant document can still fail to meet a client's specific submission requirements.
10. Is the file internally consistent?
Read the file as if you were the client.
Do the risk assessments, method statements, appointments, training records and control measures all support the same scope of work?
Compliance is not measured by page count
A safety file isn't a competition to see who can submit the biggest folder.
The objective is to demonstrate that health and safety risks have been identified, assessed, controlled, communicated and monitored.
That means a good safety file should be:
Relevant.
It relates to the work being performed.
Site-specific.
It reflects the actual project and workplace conditions.
Current.
The information and records are valid and up to date.
Consistent.
The documents support one another.
Practical.
The controls described in the file can actually be implemented on site.
Defensible.
If the client asks, "Why is this document here?" or "How are you controlling this risk?", you can explain it.
The real test of a safety file
The best way to judge your safety file isn't by how thick it is.
Ask yourself:
If the client removed the cover page and started asking questions about the actual work, could this file demonstrate how we intend to keep people safe?
If the answer is yes, you're moving in the right direction.
If the answer is "we have the document somewhere", "that's our standard template" or "we usually submit this", it may be time to review the file before the client does.
A complete safety file contains documents. A good safety file demonstrates control.
And that difference can be the difference between a file being accepted and being sent back for correction.