ISO/IEC 17025 clause 6.2.6: authorise specific laboratory activities

What clause 6.2.6 requires in practice

Clause 6.2.6 requires the laboratory to authorise personnel for specific laboratory activities. The standard lists areas that must be covered but says the list is not exhaustive: developing, changing, verifying and validating methods; analysing results, including statements of conformity, opinions and interpretations; and reporting, reviewing and authorising results.

Authorisation is the laboratory's formal decision that a named person may do a defined task. It differs from competence, which is the underlying ability. A person may be competent but not yet authorised, and a person cannot be authorised properly without evidence of competence.

The clause does not say that performance, review and release must be done by different people in every case, nor does it set a form for authorisation. What matters is that for each activity the laboratory has decided who may act and within what limits.

The output is a clear, current statement of who may do what, and it must agree with the permissions that people actually hold in practice.

Define what the person may decide

Avoid a blanket entry such as “authorised analyst” if it leaves the permitted work unclear. Consider the relevant methods, instruments, materials, ranges and types of decision. Someone competent to carry out a routine test may not be authorised to validate a modified method or issue an interpretation for a new application.

Link the authorisation to the competence requirements and evaluation under clause 6.2. A training certificate can support the evidence, but attendance is not the same as demonstrated ability. Assess whether the person understands deviations and can make the decisions assigned to them.

Separate performance, review and release

The laboratory should know who may perform work, evaluate the result and authorise its issue. The standard does not universally require different people for every stage; arrangements depend on the work and applicable requirements. What matters is that the people carrying out each activity are competent and specifically authorised.

Where reporting software provides approval permissions, align access with the technical authorisation. A system administrator's ability to change permissions does not make that person a technical signatory. Conversely, a paper authorisation is ineffective if the person cannot access the controlled tools necessary for the assigned work.

Maintain the boundaries as work changes

Review authorisations when methods, equipment, decision rules or responsibilities change and when competence monitoring identifies a concern. A controlled authorisation matrix with approval dates and limits can help, but ISO/IEC 17025 does not prescribe that particular format. Clause 6.2.5 requires procedures and retained records covering authorisation and other competence activities.

Use proportionate supervision while people develop capability. Describe what may be done under supervision and who remains responsible for the technical decision. Do not confuse a planned training pathway with permission to perform unsupervised work immediately.

Why specific authorisation matters to the business

Blanket authorisations are a quiet source of risk. If every experienced analyst can sign off every report, the day a modified method or an unfamiliar sample type arrives, nobody has stopped to ask whether the signature is justified. Errors can pass through a system that looks controlled.

Specific authorisation provides protection for people as well as customers. A technician knows exactly where their remit ends, and a manager can explain to a customer why a particular conclusion needed a different signatory. It also makes it easier to organise cover and training in a way that does not weaken technical control.

How to implement clause 6.2.6

Keep authorisation precise enough to be useful and simple enough to be maintained.

1. List the activity types in your laboratory, using the standard's three groups as a starting point and adding your own.
2. For each person, identify methods, materials, ranges and decision types they may handle and what they may not.
3. Check that each authorisation is supported by competence evidence from the assessment process.
4. Align system permissions, such as report approval rights, with the technical authorisations so the two agree.
5. Define supervised working for people in development and state who remains responsible for the technical decision.
6. Review authorisations when methods, equipment, decision rules or responsibilities change, or when monitoring raises a concern.
7. Make the authorisation list accessible to supervisors and to anyone allocating work, and remove or restrict entries promptly when a person leaves or changes role. Keep a record of each change with the date and the person who approved it.

Two illustrative authorisation decisions

Common mistakes and useful evidence