Competence

“Competence” is one of the easiest ISO 22301 requirements to under-implement because it sounds like HR. In an ISO 22301 audit, it behaves more like a control requirement: you must show you identified who can affect business continuity performance, specified what they need to know or be able to do, and verified they can do it. Then you must show you corrected gaps and retained evidence.

The practical challenge is scope. Clause 7.2 is not limited to the business continuity team. It covers anyone doing work under your control that affects BC performance, including IT operators running resilience controls, facilities teams supporting critical sites, crisis communications spokespeople, and third parties performing managed services that matter during disruption. If their decisions or actions can change outcomes in an incident, they belong in your competence model.

This page gives requirement-level implementation guidance you can execute quickly: how to define competence in a defensible way, how to assess it without creating a bureaucracy, what artifacts auditors expect, and how to avoid common hangups that cause nonconformities.

Regulatory text

Requirement (verbatim): “The organization shall determine the necessary competence of persons doing work under its control that affects business continuity performance.” ¹

Operator interpretation: You must (1) identify the population of roles that can affect BC performance, (2) define competence criteria per role (knowledge, skills, experience, and role-specific BC responsibilities), (3) confirm individuals meet the criteria, (4) take action to close gaps, and (5) retain evidence that proves all of the above. ¹

Plain-English interpretation (what auditors are looking for)

Auditors want to see that you run competence like a system, not a one-time training event.

A passing implementation typically shows:

• Defined competence for BCMS-relevant roles (not just “completed annual training”).
• Objective checks (manager attestation, exercise performance, certifications, skills checklists, or work history) that indicate a person can perform required tasks during disruption.
• Corrective action when the person is not yet competent (training plan, mentoring, role reassignment, updated runbooks).
• Records that match your claims.

A failing implementation often looks like:

• A single “BC awareness training” completion report with no role-based competence definition.
• No evidence contractors/third parties were considered.
• No proof that competence was verified beyond attendance.

Who it applies to (entity and operational context)

Entity scope: Any organization implementing or certifying an ISO 22301:2019 business continuity management system. ¹

People scope: “Persons doing work under its control” includes:

• Employees in any function with BC-impacting responsibilities (IT operations, security, facilities, finance/treasury, customer support, contact center leadership, communications, legal, executive leadership).
• Contractors, temporary staff, and consultants if you direct their work.
• Third parties performing operational activities that affect BC performance (for example, managed service providers operating your infrastructure or critical business applications) when you can set competence expectations through contracts, onboarding, or governance.

Operational context (where competence matters most):

• Crisis management and incident command roles (fast decisions, coordinated communications).
• Recovery execution roles (system restoration, manual workarounds, alternate site activation).
• BCMS governance roles (BIA ownership, risk assessment, exercise planning, corrective actions).
• Control operators whose day job maintains resilience (backups, patching, replication, monitoring, facilities maintenance).

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

1) Define the scope of “BC-impacting work”

Build a list of roles, not names, that can affect BC performance:

• Start from your critical activities and dependencies (applications, sites, teams).
• Map which roles own, operate, or recover each dependency.
• Add governance roles (BC manager, crisis communications lead, executive incident lead).

Output: BCMS Role Inventory.

2) Create a role-to-competence matrix

For each role, document competence requirements in a way you can assess. Keep it tight. Use categories:

• Knowledge: understands BC plans, escalation paths, RTO/RPO concepts if relevant, communication protocols.
• Skills: can execute runbooks, failover steps, alternate processing, triage and prioritization.
• Experience: prior on-call, prior incident participation, time in role, or equivalent exposure.
• Authority and decision rights: what they can approve during disruption.
• Tools access: required system access to perform recovery work.

Example matrix row (practical):

• Role: “IT Service Owner – Tier 1 app”
• Competence: can locate and execute recovery runbook; can coordinate with infrastructure provider; understands restoration priorities; has participated in a recovery exercise or real incident; has necessary privileged access approved.

Output: Competence Matrix (owned by BCMS, aligned with HR role profiles where possible).
Tip: If you use Daydream to manage third-party risk and resilience governance, store the matrix and link each role to plan ownership, exercises, and corrective actions so evidence stays connected.

3) Choose acceptable evidence types per role

Decide upfront what counts as proof. Use a menu approach so teams can meet the requirement without forcing a single training path:

• Training completion (internal or external) plus a short knowledge check.
• Certification relevant to BC responsibilities (where appropriate).
• Documented experience (resume/work history, internal role history).
• Exercise participation records and performance notes (especially for crisis roles).
• Manager attestation tied to the competence criteria, not generic “meets expectations.”

Output: Evidence Standard (a one-page rule set).

4) Assess current competence and document gaps

Run a structured gap assessment:

• For each role holder: compare current evidence against the matrix.
• Record gaps as specific statements: “Has not participated in a recovery exercise,” “Runbook walkthrough not completed,” “Missing privileged access approval.”

Keep the assessment lightweight but consistent. A spreadsheet works; a GRC workflow is better if you need audit trails and reminders.

Output: Competence Assessment Register and Gap Log.

5) Remediate gaps with owned actions and due dates

Clause 7.2 expects action where gaps exist ¹. ¹

Common remediation actions:

• Targeted training (role-based, not generic).
• Tabletop or technical exercise assignment.
• Shadowing/mentoring for incident roles.
• Update runbooks to reduce “tribal knowledge.”
• Temporary role reassignment if competence is not achievable in time.

Output: Remediation Plan with owners and completion evidence.

6) Make it durable: integrate into onboarding, change management, and third-party governance

To keep competence from decaying:

• Onboarding: New role holders get assigned required training, plan walkthroughs, and an exercise slot.
• Role change triggers: Promotions, reorganizations, new systems, and outsourcing should trigger re-assessment.
• Third parties: Add competence expectations to statements of work, onboarding checklists, and operational governance (for example, require named roles to demonstrate familiarity with your recovery procedures).

Output: Process hooks in HR onboarding and operational change workflows.

Required evidence and artifacts to retain

Auditors typically ask for proof at three layers: definition, assessment, and remediation. Retain:

• Competence Matrix (roles, criteria, and rationale that ties to BC performance).
• BCMS Role Inventory (who is in scope and why).
• Evidence Standard (what you accept as proof).
• Training records (completion logs, agendas, knowledge checks where used).
• Exercise records tied to individuals and roles (attendance, scenario, outcomes, performance observations).
• Manager attestations that reference specific criteria.
• Gap log and remediation tracking (with completion evidence).
• Third-party competence artifacts where applicable (named recovery contacts, onboarding completion, participation in joint exercises, contractual clauses).

Common exam/audit questions and hangups

Expect these and prepare your binder (or system) accordingly:

1. “Show me how you determined necessary competence.” They want your method, not a list of courses.
2. “Who did you include as ‘persons under your control’?” Be ready to explain contractors and third parties in operations.
3. “Pick two roles at random and prove they are competent.” Have role-based evidence ready.
4. “What do you do when someone is not competent?” Show the gap and the corrective plan.
5. “How do you keep competence current?” Show onboarding triggers, exercise cadence expectations, and role-change reassessments.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating competence as annual awareness training.
  Fix: Define role-based competence tied to actual BC tasks and decision rights.

• Mistake: Only scoping the BC team.
  Fix: Start from critical activities and dependencies; include operators and crisis roles.

• Mistake: No objective verification.
  Fix: Add knowledge checks, exercise participation, runbook walkthrough signoffs, or manager attestations mapped to criteria.

• Mistake: Ignoring third parties who run critical services.
  Fix: Contractually require named roles, onboarding to your recovery approach, and participation in relevant exercises where feasible.

• Mistake: Evidence scattered across HR, IT, and BC with no traceability.
  Fix: Centralize an evidence index. Daydream can act as the system of record by linking roles to plans, exercises, third-party dependencies, and corrective actions.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, competence gaps show up during real incidents as delayed escalation, incorrect recovery steps, and inconsistent communications. In ISO terms, the risk is a nonconformity because you cannot demonstrate you determined and ensured competence for BC-impacting work. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Identify BCMS-in-scope roles based on critical activities and dependencies.
• Draft the competence matrix for the highest-impact roles (crisis management, IT recovery, facilities/site response).
• Decide evidence types you will accept and standardize templates (attestation, exercise sign-in, walkthrough checklist).

By 60 days (assess and remediate)

• Run competence assessments for in-scope role holders.
• Open remediation actions for gaps and assign owners.
• Pilot one role-based drill/tabletop and capture individual participation evidence.
• Add third-party role expectations for your most critical outsourced dependencies.

By 90 days (operationalize and make it repeatable)

• Embed competence checks into onboarding and role changes for in-scope roles.
• Build an evidence index so any sampled role can be proven quickly.
• Review competence requirements after major plan updates, tooling changes, or organizational restructures.
• If you use Daydream, configure workflows for gap tracking, evidence attachments, and reminders tied to BC exercises and third-party governance meetings.

Frequently Asked Questions

Do I need a formal certification program to meet the competence requirement?

No. ISO 22301 requires you to determine necessary competence and retain evidence that people meet it. Certification can be one evidence type, but exercises, work history, and manager attestations mapped to criteria can also work. ¹

Who counts as “persons doing work under its control”?

Employees clearly count, and contractors often do if you direct their work. Third parties can also be in scope when they operate processes or systems that affect your BC performance and you can set requirements through contracts and governance. ¹

How detailed should the competence matrix be?

Detailed enough to assess objectively. If a criterion cannot be verified with some evidence type, it is too vague and should be rewritten into observable knowledge/skills/experience tied to BC tasks. ¹

What’s the fastest way to generate audit-ready evidence?

Start with your highest-impact roles, define criteria, then run a short assessment that results in either “meets” with attached proof or “gap” with an assigned action. Centralize an evidence index so you can answer role sampling requests without hunting across systems.

How do I handle competence for third parties who refuse to share training records?

Don’t insist on their internal HR records. Instead, require role-based outcomes you can verify: named recovery contacts, participation in joint exercises, completion of your runbook walkthrough, and meeting minutes showing responsibilities and escalation paths.

What if a role is competent but the process is undocumented?

You still risk a nonconformity because the requirement expects you to determine competence and retain evidence. Capture the competence criteria and document the evidence you relied on (for example, exercise performance notes and manager attestation). ¹

Footnotes

1. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements