How Is an Auditor Competency Matrix Built with NACE and EA Codes?

Short answer: which decision should the matrix make?

The auditor competency matrix must show not only whether a person meets an EA code, but whether they simultaneously meet the certification program, technical sector, role, assignment date, and current qualification evidence.

NACE classifies the client's activity; the EA/IAF sector helps group the accreditation scope. Neither alone constitutes auditor qualification. An assignment should be opened only when the criteria defined by the organization and the verified evidence all pass at the same time.

What is the difference between a NACE code and an EA code?

NACE classifies economic activity in detail; the EA/IAF sector helps express the QMS and EMS accreditation scope in broader technical sectors.

Eurostat publishes the most recent classification as NACE Rev. 2.1 and describes its phased use in European statistics from 2025 onwards. In contrast, the QMS and EMS sector table in IAF ID 1:2020 is based on NACE Rev. 2. For this reason, your matrix should also retain, along with each code, the classification name and version .

Instead of overriding code conversion by hand, use a versioned mapping table. If a Rev. 2.1 activity splits into multiple old classes or involves a boundary case, do not automatically return "suitable"; route the scope review to the authorized role.

How should the rows and columns of the competency matrix be designed?

Build the rows around the competency unit to be decided, not the person's name, and the columns around verifiable criteria.

Recommended row key program + teknik alan + rol + görev türü is the combination. The person is linked to this row; but the row's criteria and the person's evidence are kept separate. This way, when a criterion changes, it is visible which persons need re-evaluation.

1. Program: The relevant management system standard and the set of normative documents used.
2. Technical sector: EA/IAF sector, supporting NACE activities, and the organization's own risk/complexity breakdown.
3. Role: Application review, audit, team leadership, technical expertise, report review, or certification decision.
4. Criterion: Required knowledge and skills relating to the program, sector, processes, legislation, and audit practice.
5. Evidence: A record with a source, date, assessor, scope, result, and, if applicable, a validity/review date.
6. Authorization decision: A scoped, dated decision given by the authorized role; restrictions, conditions, and the next monitoring date.

ISO/IEC 17021-1 establishes the general competency framework. For QMS, program-specific parts such as ISO/IEC 17021-3 add further criteria. TÜRKAK also states that in management system certification applications, the relevant ISO, IAF, EA, and TÜRKAK documents will be applied together. For this reason, a single-cell model such as "EA 17 passed" loses the distinction between program and role.

Which evidence should fill a cell?

An attendance certificate alone is not a competency decision; an evidence chain is required showing that knowledge and skills were assessed by appropriate methods.

Predefine the accepted assessment method for each criterion. A training record can show the knowledge input; sector experience supports context; an exam, interview, file review, or observation provides assessment evidence that a specific criterion is met. The final decision must be recorded with the authorized assessor and date information.

• Is it clear which program, technical sector, and role the evidence covers?
• Does the assessment method actually measure the relevant knowledge or skill?
• Are the result, the assessor, and the decision rationale recorded?
• Is the evidence date compatible with the planned audit date?
• Is the monitoring, witness, or performance record current?
• Is there a suspension, restriction, conflict of interest, or availability obstacle?

The matrix must not be a "present/absent" table. Suitable, not suitable, evidence missing, expiry/review overdue, restricted —use explainable statuses like these. An ambiguous or missing record must not turn into a suitable outcome.

How does fail-closed assignment control work?

The job's scope is configured first; the candidate's authorization record is then compared against the same scope and assignment date. Until every mandatory gate passes, the assignment is not recorded.

1. At application review, the client's activities and sites are determined; the main code in the trade registry alone is not sufficient.
2. The NACE code and version are recorded; the relevant EA/IAF sector is determined together with the mapping version used and the scope review justification.
3. The certification program, audit type, role, planned date, and required technical competencies are extracted.
4. The candidate's scoped authorization decision, current monitoring evidence, suitable role, and conflict-of-interest checks are retrieved.
5. The individual and the team as a whole are evaluated separately. IAF MD 11:2023 requires that, in integrated audits, the team be sufficient for every standard covered and every relevant technical sector.
6. If a gate is missing, the assignment stops and the required evidence is clearly shown. If there is an exception, its scope, duration, justification, and independent approval are recorded; no silent pass-through is made.

The use of a technical expert does not automatically transfer all of the auditor's responsibilities. Team composition and task distribution must be determined by the organization's valid procedures and program rules; the software should only apply verified rules.

What happens to open assignments when a code or competency changes?

Do not overwrite the old decision; open a new version and put the affected planned jobs into the re-evaluation queue.

The transition from NACE Rev. 2 to Rev. 2.1, an accreditation scope change, a program document revision, a restriction on personnel authorization, or a change in a monitoring outcome can affect existing plans. The matrix version, rule set, mapping table, and assignment decision must be versioned with separate identities.

Re-evaluation does not mean automatic cancellation. The system lists the affected jobs; the authorized person compares the new and old conditions. But until the review is completed, a new assignment or audit plan must not be treated as "suitable".

To manage audit duration within the same plan, you can use the IAF MD 5 audit duration guide; for the entire flow from application to decision, the system certification software guide .

Which scenarios should be tested in a software pilot?

Run the pilot not only with successful assignments but with scenarios where faulty and ambiguous data are safely stopped.

• Does the assignment close when the correct program but the wrong technical sector is selected?
• Does an activity whose NACE version is unknown or whose Rev. 2.1 counterpart is more than one fall to review?
• If the auditor is suitable but the team total lacks a program/technical sector, does the plan stop?
• If there is an authorization decision but current monitoring evidence is missing, does the system show the justification?
• If the audit date is after the authorization review date, is a re-check requested?
• When a rule or scope version changes, do open jobs enter the impact list?
• Are the person making the assignment, the matrix version used, and all check results kept in the audit trail?

Vizyon Alia When evaluated, run these negative scenarios with your organization's real but personal-data-sanitized application, scope, and auditor records. The product does not make accreditation or competency decisions; it applies the organization's approved criteria in a visible, versioned, and fail-closed workflow.