In HSE document management, people often use expressions such as “approved company”, “compliant worker” or “approved equipment”. However, project-specific document requirements show that these statuses depend on context.
These statuses are useful for managing large volumes of information. That said, they can also give an oversimplified view of reality.
Compliance is not always a permanent attribute of the company, the worker or the equipment.
In many cases, it depends on the context in which they will be used.
A company may meet all the general requirements set by an organisation and, even so, need to meet additional document requirements to take part in a specific project.
Similarly, a worker may hold valid individual documents and still lack a specific training course required for a given activity.
Likewise, a piece of equipment may be inspected and fully documented, yet fail to meet an additional requirement set for a particular site.
That is why the key question in document management is not only:
“Is this entity compliant?”
It is also:
“Compliant for what, where and under what conditions?”
Compliance starts with requirements
To understand this difference, we first need to go back to the start of the process: the requirements.
A document requirement exists because an organisation has decided that a piece of evidence is needed to demonstrate a condition.
Some requirements apply fairly broadly.
For example, they may relate to the company itself, the contractual relationship, the worker or the equipment.
Others, however, arise from the specific context in which the work will be carried out.
A project may require additional documents.
A facility may set its own rules.
An activity may call for specific training or a specific qualification.
Equipment used in a particular environment may be subject to additional checks.
Finally, the country where the service is delivered may introduce different legal or document requirements.
In other words, compliance results from the relationship between an entity and the set of requirements that apply in that context.
General and project-specific document requirements
A well-structured document architecture should be able to distinguish between different levels of requirements.
For example, a contractor may first go through a corporate contractor approval process.
At that stage, the organisation reviews the cross-cutting requirements it has defined.
Then, when a client hires that company for a specific project, additional document requirements related to that work may arise.
The same applies to workers.
There may be general documents linked to the person, as well as specific requirements arising from their role, activity, risk or location.
As a result, the logic is no longer simply:
Company → Documents → Approved
and instead allows for richer relationships:
Company → General requirements
Project → Specific requirements
Worker → Individual requirements
Role/activity → Specific competences
Equipment → Technical requirements
Site → Local conditions
It is the combination of applicable conditions that determines the relevant status in each situation.
Valid documents do not mean the requirement is met
In addition, there is another important distinction.
A document may be within its validity period and still not satisfy the requirement being assessed.
Take, for example, a valid training certificate.
Even so, validity answers only part of the question.
We also need to check whether the training actually matches the required competence, belongs to the right worker and meets the criteria set by the organisation.
The same principle can apply to company and equipment documents.
Therefore, tracking expiry dates is essential, but it is not enough to determine compliance.
Instead, document management needs to link the evidence submitted to the requirement that evidence is meant to demonstrate.
Document requirements: Project context changes the outcome
Consider an external worker who provides services to the same organisation at different facilities.
Their individual documents may be exactly the same.
At the first location, the requirements for the activity may be fully met.
At a second site, however, additional training may be required.
On a third project, there may be a specific induction or a document requirement set by the end client.
So we have the same worker and, possibly, the same core documents.
Yet we can get different compliance statuses because the context has changed.
This does not, however, point to an inconsistency in the process.
Rather, it shows that the document process is able to reflect operational reality.
The same worker may perform different roles
The role or activity is another relevant dimension.
A worker may be qualified to carry out one task and still not meet the requirements for another.
For this reason, the mere presence of a worker on the platform should not be read as a general authorisation.
When document management is linked to operational processes, we need to know not only who the person is, but also what they are going to do.
This relationship is particularly important when competences, qualifications or training are tied to specific activities.
In short, the closer document information is to operations, the more this context matters.
Equipment has context too
Likewise, this logic applies to equipment.
An organisation may track documents relating to inspections, maintenance, certifications or other technical evidence.
However, certain projects or facilities may add specific conditions.
Consequently, the relevant question is no longer just:
“Is the equipment compliant?”
and now also includes:
“Does the equipment meet the requirements that apply to the work and to the location where it will be used?”
This difference is especially important when companies, workers and equipment are assessed together to prepare an activity.
The importance of document requirements by project and site
In organisations with multiple facilities, contracts or projects, the platform structure must be able to represent that reality.
Applying every requirement to every entity indiscriminately can create unnecessary bureaucracy.
On the other hand, applying only generic requirements may leave out conditions that are essential for a given job.
Configuration should therefore make it possible to identify which requirements are cross-cutting and which depend on factors such as:
company → project → site → role → activity → equipment.
This does not mean, however, that every organisation needs this level of complexity.
Instead, it means the platform must be able to keep up with the real complexity of the process when it exists.
A single document source, different uses
Context-specific requirements do not necessarily mean duplicating documents.
In fact, one of the advantages of a central document management platform is that evidence already on file can be reused when it is still valid and applies to the new context.
The same document can serve as evidence for different projects or processes, as long as it meets the relevant criteria.
As a result, this approach reduces repeated requests to contractors and avoids keeping several copies of the same documents for no reason.
The difference lies in the relationship between the document and the requirements.
Instead of asking for the same file again, the platform can determine whether the existing evidence applies to the new situation.
From general approval to readiness for work
This shift introduces an important difference between contractor approval and operational readiness.
Contractor approval can demonstrate that a company or entity meets a predefined set of requirements.
However, when a specific job comes up, there may be new conditions to check.
The sequence can follow this logic:
Contractor approval → Project → Worker/Equipment → Specific requirements → Contextual compliance → Operational authorisation
It is precisely this contextual layer that brings document management closer to other HSE processes, such as credentialing, access control or Permit-to-Work.
Each process keeps its own role, but can now use more accurate compliance information.
Project-specific document requirements call for configurable platforms
There is no universal requirements matrix that suits every organisation.
Companies in different sectors have different risks, structures, geographies, activities and contracting models.
In fact, even within the same organisation, different projects may need different configurations.
That is why configurability matters so much in an HSE platform.
Requirements should follow the organisation’s processes, rather than forcing the organisation to adapt all its processes to a rigid document structure.
This flexibility becomes even more relevant when there are international operations, different languages, multiple clients or requirements that change over time.
Example: The same technician at three facilities
The table below shows how project-specific document requirements can produce different statuses for the same worker, with the same core documents:
| Context | Additional requirement | Status |
|---|---|---|
| Logistics warehouse | None beyond the general requirements | Compliant |
| Electrical substation | Electrical work qualification and site-specific induction | Pending: induction missing |
| Chemical plant | Explosive atmospheres training and medical fitness with a specific assessment | Non-compliant: training missing |
So the same person is ready for one job, almost ready for another and barred from a third. Consequently, a single “compliant” status would hide exactly the information each facility manager needs to make a decision.
Frequently asked questions about project-specific document requirements
Do project-specific requirements make the process more bureaucratic?
Quite the opposite, when they are well designed. Instead of asking everyone for everything, the organisation asks each entity only for what the context requires. In addition, reusing evidence that has already been validated avoids repeated requests to contractors.
Who should define the specific requirements for each project?
Generally, the HSE team, working together with project or facility management. However, setting them up on the platform should be the job of whoever knows the requirements model, to avoid duplication and inconsistencies between projects.
Compliance is no longer a simple status
As document management moves closer to operations, “compliant” can no longer be understood merely as a label attached to a record.
Instead, it represents the outcome of an assessment in a given context.
Who?
For which activity?
On which project?
Where?
With which equipment?
Against which requirements?
This approach allows document information to be used more rigorously and prepares it for integration with other operational processes.
After all, in HSE, the most relevant question is not always whether a company, worker or piece of equipment is compliant in general.
It is whether they meet the requirements needed for what they are actually going to do.
Further reading: Contractor and subcontractor management: Complete guide.
See also: Document requirements in contractor approval and Document configuration: Every client has different requirements. For more information on occupational safety, visit the Portuguese Authority for Working Conditions (ACT).