Competence

ISO/IEC 20000-1 Clause 7.2 requires you to define competence requirements for every role that can affect your Service Management System (SMS), verify people meet them through education, training, or experience, and keep documented evidence. To operationalize it, build a role-to-competence matrix, close gaps with targeted enablement, and run a repeatable review cycle with auditable records. ¹

Key takeaways:

• Define competence per SMS-impacting role, not per person’s job title. ¹
• Verify competence using education, training, or experience, and document your basis for “competent.” ¹
• Keep evidence that stands up in an audit: requirements, assessments, completion records, and authorization decisions. ¹

“Competence” in ISO/IEC 20000-1 is a control requirement disguised as an HR topic. Clause 7.2 ties competence directly to service outcomes: any person doing work under your control that affects SMS performance and effectiveness must have defined competence expectations, must meet them, and you must retain documented proof. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat competence as a governed system: identify SMS-impacting roles, define what “good” looks like for each role, decide how you will evaluate it, and keep records that show your decisions were deliberate and repeatable. This also applies to contractors and other third parties doing work “under your control,” which usually means you direct their work, they operate in your environment, or they perform process steps inside your SMS scope. ¹

Auditors typically look for two things: coverage (did you include all relevant roles, including temp/contract roles and on-call?) and defensibility (can you show objective evidence that the people executing key SMS activities are competent today, not just at hire?). This page gives you requirement-level implementation guidance you can put into motion quickly. ¹

Regulatory text

Clause 7.2 (Competence) states: “The organization shall determine the necessary competence of persons doing work under its control that affects the performance and effectiveness of the service management system, ensure these persons are competent on the basis of appropriate education, training or experience, and retain documented information as evidence of competence.” ¹

What the operator must do:

1. Determine necessary competence: define competence requirements for all SMS-impacting work performed under your control. ¹
2. Ensure competence: confirm people meet those requirements via education, training, or experience, and address gaps. ¹
3. Retain documented information: keep evidence that you defined requirements, evaluated individuals, and can show competence status. ¹

Plain-English interpretation (what “competence requirement” means in practice)

You need a documented, auditable way to prevent unqualified people from performing SMS-relevant work. This is broader than “everyone completed annual training.” You must:

• Name the work that matters (incident, change, problem, service request, monitoring, release, service reporting, customer communications, etc. within scope).
• Define what capability is required to perform that work safely and consistently.
• Prove each person doing that work has the capability, and show how you know. ¹

A workable definition: Competence = documented requirements + documented assessment + documented authorization + documented re-check.

Who it applies to (entity and operational context)

Applies to: any organization operating an ISO/IEC 20000-1 service management system, including internal IT service providers and external service providers. ¹

Applies to people “under your control”:

• Employees in scope for SMS processes
• Contractors and temporary staff executing SMS activities
• Third parties where you direct the work or they perform in-scope operational steps (for example, a managed service provider executing incident triage in your tool) ¹

Where it shows up operationally:

• Access to service management tools (ticketing, monitoring, CI/CD gates)
• Authority to approve changes, close incidents, publish KB articles, update CMDB, or communicate with customers
• On-call rotations and major incident roles
• Service reporting and SLA management ¹

What you actually need to do (step-by-step)

Step 1: Inventory SMS-impacting roles and activities

Create a list of roles that can affect SMS performance and effectiveness. Start from your process maps and RACI charts, then validate against system access and approval rights.

Minimum role list (example):

• Incident Manager / Major Incident Manager
• Change Manager / CAB participants
• Problem Manager
• Service Desk analysts
• Service Owner / Service Level Manager
• Configuration/asset owner roles (CMDB)
• Release/Deployment roles where releases affect live services

Output artifact: SMS Role & Activity Register (role, key activities, tools used, approvals, risk notes).

Step 2: Define competence requirements per role (make them auditable)

Build a Role-to-Competence Matrix. Keep it simple and testable.

Include:

• Required knowledge (process knowledge, tool knowledge, service context)
• Required skills (triage, communication, root cause facilitation, risk-based decisioning)
• Required experience thresholds (qualitative is fine; avoid arbitrary year counts unless your organization already uses them consistently)
• Required certifications (only if truly needed; otherwise you create audit and hiring friction)
• Behavioral expectations tied to outcomes (for example, “follows change risk model; escalates when uncertain”)

Add acceptance criteria per competence item:

• “Demonstrates” criteria: scenario walkthrough, observed execution, work sample
• “Evidence sources”: training record, manager attestation, peer review, ticket QA, runbook drill ¹

Step 3: Assess current staff against the matrix (initial baseline)

Pick an assessment method you can defend:

• Document review: prior training, certifications, CV/role history
• Manager assessment: structured attestation tied to criteria (not a generic thumbs-up)
• Practical validation: observed ticket handling, change review shadowing, tabletop for major incident roles

Output artifact: Competence Assessment Record per person per role, including outcome: competent / competent with conditions / not yet competent.

Step 4: Close gaps with targeted enablement (education, training, experience)

Clause 7.2 allows multiple bases for competence: education, training, or experience. Use that flexibility.

• For process gaps: short, role-specific process training and a scenario-based check.
• For tool gaps: sandbox exercises plus supervised production work.
• For judgment gaps (common in change and incident command): shadowing + decision reviews.

Output artifacts:

• Training plan per role or per individual (if gaps vary)
• Completion records and post-training validation (a quick quiz alone is weak evidence unless it tests applied scenarios). ¹

Step 5: Gate high-risk permissions to demonstrated competence

Tie competence status to access and authority:

• Change approval rights require “competent” status
• Major incident command role requires validated readiness
• CMDB write access requires role competence and process training

This is where audits get easy. Your access control and competence records tell the same story.

Step 6: Retain documented information (build the evidence pack)

Create an evidence binder (digital is fine) with:

• Role-to-Competence Matrix (current approved version)
• Assessment methodology and rubric
• Individual competence records
• Training materials and completion records
• Authorization/gating decisions (access approvals, role assignment records)
• Periodic review evidence (see next step) ¹

Step 7: Run a repeatable review cycle (trigger-based is usually best)

ISO/IEC 20000-1 does not prescribe a frequency in Clause 7.2, so use triggers you can execute consistently:

• New hire/contractor onboarding into an SMS role
• Role change or added responsibilities
• Major process/tool change (new ticketing tool, new change model)
• After major incidents or repeated process nonconformities (targeted re-validation)
• Before re-certification audits or internal audits

Keep a Competence Review Log that shows what changed and why.

Required evidence and artifacts to retain

Auditors want objective evidence that is current and mapped to scope. Retain:

• SMS Role & Activity Register
• Role-to-Competence Matrix (version controlled, approved)
• Competence assessment rubric and completed assessments
• Training records (course title, date, attendee, completion evidence)
• Experience evidence (work samples, supervised sign-offs, probation checklists)
• Role assignment and access approvals tied to competence status
• Exceptions: documented risk acceptance for temporary coverage, plus compensating supervision controls ¹

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me how you determined competence requirements for incident and change roles.” ¹
• “How do you know this person is competent beyond completing training?” ¹
• “How do you handle contractors or third parties performing service desk or operations work?” ¹
• “Where is the evidence retained, and how do you keep it current?” ¹
• “What happens when someone is not competent but coverage is needed?” (looking for temporary controls and supervision)

Common hangup: teams confuse training completion with competence. The clause explicitly requires competence “on the basis of appropriate education, training or experience,” which implies you must explain the basis and retain evidence. ¹

Frequent implementation mistakes (and how to avoid them)

1. Only covering employees, ignoring contractors. Fix: define “under your control” in your SMS context and include contractors/third parties who execute in-scope tasks. ¹
2. Writing vague competence statements. Fix: add observable criteria (“can run a major incident bridge using the runbook”) and map to evidence types.
3. No gating to authority. Fix: tie competence status to tool roles, approval rights, and on-call assignments.
4. Evidence scattered across HR, LMS, and email. Fix: maintain a single competence evidence index with pointers to systems of record.
5. Stale matrices after process changes. Fix: add a trigger so any SMS process/tool change includes a competence impact check.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source catalog. Practically, competence gaps manifest as operational failures: inconsistent change decisions, prolonged incidents, weak root cause analysis, and poor customer communication. For ISO/IEC 20000-1 certification, poor evidence of competence typically shows up as a nonconformity because Clause 7.2 is explicit about documented information retention. ¹

A practical 30/60/90-day execution plan

First 30 days: establish the system

• Define SMS scope boundaries and list SMS-impacting roles.
• Draft Role-to-Competence Matrix for the highest-risk roles (incident, change, service desk).
• Decide assessment approach and create templates (assessment record, manager attestation, evidence index).
• Centralize existing evidence pointers (LMS exports, HR records, certifications) into one index. ¹

Days 31–60: baseline and close obvious gaps

• Run assessments for in-scope staff and contractors in critical roles.
• Implement gating for high-risk permissions (change approval, major incident command).
• Deliver targeted enablement for top gaps; require post-training validation.
• Create exception handling for temporary coverage (supervision, pairing, limited access). ¹

Days 61–90: operationalize and audit-proof

• Expand matrix coverage to all remaining SMS roles.
• Add competence triggers into onboarding, role change, and process change workflows.
• Run an internal spot-check: pick a role, pull evidence end-to-end, verify it matches reality in tool access.
• If you use Daydream for third-party risk and due diligence, store third-party personnel competence attestations and supporting artifacts alongside the engagement record, then track renewals with the same workflow as other compliance evidence. ¹

Frequently Asked Questions

Does ISO 20000 require specific certifications for competence?

Clause 7.2 does not mandate certifications; it requires competence based on appropriate education, training, or experience and documented evidence. Use certifications only where they directly map to role needs and you can maintain the requirement consistently. ¹

How do we prove “experience” as evidence of competence?

Use work samples and structured sign-offs: ticket QA results, observed change reviews, supervised shifts, or runbook drill outcomes. Document the criteria and the reviewer’s decision so it reads like an assessment, not a casual opinion. ¹

Do contractors and third parties fall under “persons doing work under its control”?

Yes if you direct their work or they perform steps inside your SMS scope. Treat them like employees for role competence requirements, even if training delivery differs. ¹

Is training completion enough to meet the competence requirement?

Training can be part of the basis for competence, but you still need to show the person is competent for the role. Pair training records with a validation method such as observation, scenario testing, or manager attestation tied to defined criteria. ¹

How should we handle emergency coverage when someone is not yet competent?

Document a time-bound exception with compensating controls such as supervision, pairing with a competent operator, and restricted access/authority. Keep the exception record with the competence file to show intentional risk management. ¹

What’s the minimum documentation an auditor expects for Clause 7.2?

A role-based competence definition, evidence that individuals meet it (education/training/experience plus assessment), and a retrievable record set. If you cannot produce evidence quickly for a sampled role, expect a nonconformity risk. ¹

Footnotes

1. ISO/IEC 20000-1:2018 Information technology — Service management