Contractor document requirements matrix: what to request and how to build it

What a document requirements matrix is

A company that works with contractors receives third-party people, vehicles, and equipment at its facilities. Each of them must arrive with certain documents up to date. The document requirements matrix is where the company writes down, once, which document is required of each one and under what conditions.

The unit of the matrix isn’t the contractor but the element: whatever enters the facility. One contractor can bring in ten workers, two pickup trucks, and a piece of lifting equipment, and each one needs different documents. That’s why every requirement is defined on three axes.

• Element type Person, vehicle, or machinery, tools, and equipment. It determines which kind of document makes sense to request.
• Activity type What the element is going to do: a general activity that applies to all third parties, and specific activities such as work at heights.
• Element profile A finer classification within the activity, such as the person’s job title or the class of equipment.

On top of those three axes, each requirement answers four more questions: how long the document is valid, who reviews and approves it, which criteria it’s reviewed against, and what happens if it’s missing. A matrix that only lists documents, without those answers, isn’t ready to operate.

Why a single list for all contractors doesn’t work

The most common starting point is a single list: every contractor submits the same documents. That list fails in both directions. It asks too much of the supplier who comes in for an hour to make a delivery and ends up uploading certificates that have nothing to do with the job. And it asks too little of whoever performs a high-risk task, because the documents specific to that task don’t fit in a list designed for everyone.

There’s also a regulatory reason. Article 2.2.4.6.28 of Decree 1072 of 2015 requires employers to adopt measures that ensure suppliers, contractors, and subcontractors comply with occupational health and safety rules while performing the activities under the contract. The minimum requirements include verifying, before work starts and periodically, enrollment in the General Occupational Risk System, and informing contractors of the hazards and risks of the work area, including high-risk tasks.

The columns a document requirements matrix needs

Each row of the matrix is a requirement. These are the columns that let you operate it without having to interpret anything at review time.

The restrictive column has three variants. An entry-restrictive document keeps a person or a vehicle from entering if it’s expired or rejected. A use-restrictive document keeps a machine or piece of equipment from being operated. A contract-restrictive document affects the contracting company as a whole.

The validity-period and advance-notice columns feed expiration control, which has its own method: it’s covered in how to control contractor document expirations.

Which documents to request by element type and activity

Part of the matrix comes from regulations that already require specific documents. Here are some examples with their legal basis; the full list depends on your activity, your OHS management system, and your contracts.

People

Enrollment in the General Occupational Risk System, through an ARL (Colombia’s occupational risk insurer), is the requirement that Decree 1072 of 2015 says to verify before work starts and periodically. It usually goes under the general activity, because it applies to everyone. How to verify social security contributions is a separate topic, explained in verifying contractor social security.

For work at heights, Resolution 4272 of 2021 of the Ministry of Labor requires workers exposed to that risk to hold a work-at-heights training certificate, or a certification of their occupational competence.

Some companies also request proof of the occupational medical evaluation for certain profiles. Those evaluations are now governed by Resolution 1843 of 2025 of the Ministry of Labor, which repealed Resolution 2346 of 2007. Which medical information is requested and how it’s handled is defined by your OHS team.

Vehicles

Article 42 of Law 769 of 2002, Colombia’s National Traffic Code, requires every vehicle on the country’s roads to be covered by valid mandatory insurance, the SOAT (mandatory traffic accident insurance). Article 51, as amended by Decree 19 of 2012, requires motor vehicles to undergo the technical-mechanical and emissions inspection. Both documents expire.

Machinery and equipment

For machinery, tools, and equipment, the requirements usually come from the company’s management system and its contracts: maintenance records or equipment certifications. Here the restrictive document is use-restrictive, not entry-restrictive.

How to build the document requirements matrix

You build the matrix once and then maintain it. The order matters, because each step depends on the one before.

1. Take stock of what enters Which types of third-party people, vehicles, and equipment enter your operation.
2. Define activities and profiles A general activity for all third parties, plus the higher-risk specific activities, with their profiles.
3. List the requirements and their basis For each activity, which document is required and why: a regulation, the OHS management system, the contract, or a client requirement. Your OHS or legal team validates this part.
4. Set validity periods and deadlines Expiration frequency, advance-notice days, and initial upload deadline for each requirement.
5. Assign approvers and criteria Who reviews each document and what they must check, in writing, to approve or reject it.
6. Flag the restrictive documents Which documents block entry, use, or the contract, and which are only recorded.
7. Define retention How long each file is kept, so you can later show what was reviewed and when.

The same matrix works for requirements that aren’t about occupational health and safety. A company subject to SAGRILAFT (Colombia’s anti-money-laundering and counter-terrorist-financing risk system) can include the documents for counterparty due diligence using the same logic: what’s requested, from whom, with what validity period, and who approves it.

Common mistakes when building a requirements matrix

• Defining requirements by site. Requirements are determined by element type, activity type, and profile. The work site is used to categorize and filter reports, but it doesn’t trigger any requirement: the same worker at heights needs the same certificate at any plant.
• Asking everyone for everything, with a single list that overloads low-risk third parties.
• Copying validity periods from another company. Each validity period should come from the regulation, the document itself, or a written internal decision.
• Reviewing without criteria. If the reviewer only checks that the file opens, the document has been uploaded but not verified.
• Citing repealed regulations. A matrix that still refers to Resolution 2346 of 2007 for occupational medical evaluations should be updated to Resolution 1843 of 2025.
• Flagging everything as restrictive, or nothing. If everything blocks, the operation falls back on exceptions; if nothing blocks, the matrix doesn’t control anything.

Contractor induction can work as one more requirement, flagged as entry-restrictive. How to design it is explained in virtual contractor induction.

You can operate the requirements matrix in a system

Written in a spreadsheet, the matrix tells you what to request. Operating it is something else: requesting each document from the third party, receiving it, reviewing it against the criteria, calculating when it expires, and blocking the element when a restrictive document fails. With hundreds of elements, that operation is what falls behind.

In NAVA 360, your company loads the matrix and configures each requirement with the columns described above. The third party creates its elements, uploads each document with its issue date, and the system calculates the expiration date. The reviewer approves, rejects, or leaves it pending with the criteria in view, and every decision is logged with the person responsible and the date.