Organizational roles, responsibilities and authorities

To meet the ISO/IEC 20000-1:2018 organizational roles, responsibilities and authorities requirement, top management must assign and communicate clear accountability and decision rights for all roles that affect the service management system (SMS), including explicit responsibility for SMS conformance. You operationalize this by defining role owners, documenting authorities, publishing role expectations, and proving people follow them. ¹

Key takeaways:

• You need role clarity plus decision authority, not just org charts. ¹
• Evidence must show assignment, communication, and ongoing use in operations and governance. ¹
• Auditors look for an accountable SMS owner and consistent RACI across incident, change, problem, and supplier processes. ¹

Clause 5.3 is a governance requirement that auditors treat as foundational: if you cannot show who owns the service management system and who has authority to make decisions that affect service delivery, every other control becomes hard to trust. The clause is short, but it drives concrete operational expectations. Top management must ensure that responsibilities and authorities for relevant roles are assigned and communicated, and that someone is accountable for SMS conformance to ISO/IEC 20000-1. ¹

“Relevant roles” means more than the SMS manager title. It includes process owners (incident, change, service level, configuration, continuity, supplier management), operational leaders, and anyone empowered to accept risk, approve changes, or commit resources that affect services. This requirement is also where many organizations stumble during certification because they have documentation but cannot demonstrate that decision rights are understood and consistently applied across teams, locations, and third parties.

The guidance below is written for a CCO, GRC lead, or service management leader who needs to implement Clause 5.3 quickly, produce audit-grade evidence, and reduce operational ambiguity that causes incidents, failed changes, and weak supplier oversight. ¹

Regulatory text

ISO/IEC 20000-1:2018 Clause 5.3 states: “Top management shall ensure that the responsibilities and authorities for relevant roles are assigned and communicated within the organization, including responsibility for ensuring the service management system conforms to the requirements of this document.” ¹

Operator meaning (what you must do):

• Assign responsibilities: Define who is responsible for what outcomes and activities within the SMS. ¹
• Assign authorities: Define who can approve, reject, escalate, accept risk, commit spend/resources, and make binding decisions for SMS processes and services. ¹
• Communicate both: Make the assignments known and accessible to the people who must execute them. ¹
• Name SMS conformance accountability: Identify a role that is accountable for ensuring the SMS conforms to ISO/IEC 20000-1 requirements, with enough authority to coordinate cross-functional action. ¹

Plain-English interpretation

You must be able to answer, consistently and with evidence:

• Who owns the SMS and can require changes to meet ISO/IEC 20000-1 requirements? ¹
• Who owns each service management process, and what decisions can they make without asking permission? ¹
• How do staff and relevant third parties learn their responsibilities and decision boundaries? ¹

If roles are “assigned” only in someone’s head, or “communicated” only via a slide deck nobody can find, auditors will treat the requirement as not met. ¹

Who it applies to

Entities: Any organization or service provider implementing an SMS aligned to ISO/IEC 20000-1. ¹

Operational context (where this bites):

• IT and enterprise service management organizations running live services with incident/change/problem workflows. ¹
• Shared service environments where multiple departments deliver components of one service. ¹
• Hybrid models with managed service providers, cloud/SaaS, or outsourced service desk operations, where internal accountability must still be explicit even if execution is external. ¹

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

1) Define the SMS scope and “relevant roles”

Start from your SMS scope and service catalog. Identify roles that:

• Execute or govern SMS processes,
• Approve or implement changes,
• Own service levels and customer commitments,
• Control supporting assets (CMDB/configuration),
• Manage suppliers/third parties that affect service outcomes. ¹

Practical tip: If a role can block restoration, approve a standard/normal/emergency change, or accept a service risk, it is “relevant.” Document it. ¹

2) Assign accountability for SMS conformance

Create an explicit role (or named position) accountable for SMS conformance to ISO/IEC 20000-1 requirements. This role needs:

• Authority to raise nonconformities,
• Authority to require corrective actions,
• Access to top management for escalation and resourcing decisions. ¹

This can sit in IT, Security, Quality, or GRC, but auditors will test whether it works cross-functionally. ¹

3) Build a role-to-process responsibility model (RACI + decision rights)

For each SMS process, document:

• RACI: Responsible, Accountable, Consulted, Informed.
• Decision rights: approvals, thresholds, escalation paths, and exception authority. ¹

Minimum set most auditors expect to map cleanly: incident management, service request management, change management, problem management, configuration management, service level management, supplier/third-party management, service continuity, and reporting/measurement governance. ¹

4) Convert the model into role descriptions people can execute

For each relevant role, publish a short role description that includes:

• Purpose and outcomes,
• Key responsibilities (what they must do),
• Authorities (what they can approve/deny/escalate),
• Interfaces (who they coordinate with),
• Required competence/training references where applicable. ¹

Keep it readable. If it looks like an HR job posting, operators will ignore it. ¹

5) Communicate assignments in durable channels

Auditors will ask “how do you know people understand their responsibilities?” Make communication repeatable:

• Publish role docs and RACI in a controlled repository (policy portal, QMS, wiki with access control and versioning).
• Embed responsibilities into onboarding for service roles.
• Review role expectations during process owner meetings and operational governance. ¹

Third party note: Where third parties execute parts of the SMS, document internal accountability plus the third party’s operational responsibilities (for example, incident triage or patching) and show how you communicate those expectations through contracts, statements of work, or operating procedures. ¹

6) Prove the authorities are used in real workflows

Clause 5.3 fails most often during interviews because practice does not match the document.

• In your ITSM tool, align approvals and assignments to the documented authorities (CAB membership, change approvers, major incident roles).
• Show examples where escalations followed defined authority paths.
• Show meeting minutes or decisions that demonstrate process owners exercising their roles. ¹

7) Implement governance to keep roles current

Roles drift after reorganizations, tool changes, or outsourcing.

• Add a trigger: any org change affecting service delivery must initiate a role/RACI review.
• Make role review part of management review inputs for the SMS. ¹

Required evidence and artifacts to retain

Maintain evidence that covers assignment, communication, and operation:

Core artifacts

• SMS governance document naming the SMS conformance accountable role. ¹
• RACI matrix by SMS process, including process owners and key interfaces. ¹
• Role descriptions for relevant roles with explicit authorities. ¹
• Org chart or operating model mapping functions to the SMS scope (supporting evidence, not sufficient alone). ¹

Communication proof

• Onboarding/training materials that reference role responsibilities.
• Internal announcements, controlled document publication logs, or attestations of understanding for key roles. ¹

Operational proof

• Samples from the ITSM tool: assignment groups, approval workflows, CAB records, major incident role assignments aligned to role authorities. ¹
• Meeting minutes: CAB, service review, supplier review, or SMS governance meetings showing decisions and owners. ¹

If you need to operationalize evidence collection fast, Daydream is often used to track role-to-control mapping, collect artifacts from process owners on a schedule, and keep an audit-ready record of communications and approvals tied to ISO/IEC 20000-1 clauses. ¹

Common exam/audit questions and hangups

Expect questions like:

• “Who is accountable for SMS conformance, and what authority do they have to drive corrective actions?” ¹
• “Show me where change approval authority is defined, and show me a recent change where that authority was exercised.” ¹
• “How do you ensure responsibilities are communicated to staff in different teams or geographies?” ¹
• “How do you handle responsibilities that sit with a third party? Who is accountable internally?” ¹

Hangups auditors raise:

• RACI exists but is outdated after reorgs.
• Authorities are described vaguely (“can approve changes”) with no boundaries or escalation.
• Process owners exist on paper, but tickets show different approvers and inconsistent routing. ¹

Frequent implementation mistakes (and fixes)

Mistake: Confusing “responsibility” with “authority.”
Fix: For each role, write explicit decision rights (approve/reject/escalate/accept risk) and connect them to workflows and meetings. ¹

Mistake: Treating the org chart as evidence.
Fix: Keep the org chart, but lead with role descriptions, process ownership, and operational records showing the roles in action. ¹

Mistake: No single accountable owner for SMS conformance.
Fix: Name the role formally, document authority to raise nonconformities and coordinate corrective actions, and show escalation to top management when needed. ¹

Mistake: Ignoring third parties in the role model.
Fix: Document internal accountability for third-party delivered activities and show how requirements are communicated through governance and contracting mechanisms. ¹

Enforcement context and risk implications

ISO/IEC 20000-1 is a certifiable standard rather than a regulator-led enforcement regime in the material provided. The practical “enforcement” risk is certification impact: unclear roles and authorities can lead to nonconformities, weak corrective action follow-through, inconsistent change control, and brittle incident response. Those operational failures also raise customer and contractual risk because service commitments depend on predictable decision-making and escalation. ¹

A practical 30/60/90-day execution plan

Time-boxing helps, but avoid treating this as a document sprint. The goal is audit-grade reality.

First 30 days (stabilize governance)

• Confirm SMS scope and list relevant roles across internal teams and third parties. ¹
• Assign the SMS conformance accountable role and confirm escalation path to top management. ¹
• Draft a first-pass RACI for key SMS processes and identify gaps or overlaps. ¹

Days 31–60 (document and communicate)

• Publish role descriptions with explicit authorities for process owners and operational leaders. ¹
• Align ITSM tool routing/approvals to the documented authorities for incident and change first. ¹
• Roll out communication: onboarding updates, operational meeting briefings, and a central repository for controlled documents. ¹

Days 61–90 (prove operation and build durability)

• Collect operational samples: CAB records, major incident assignments, change approvals, supplier review minutes. Validate against the RACI and role authorities. ¹
• Run an internal interview drill: ask operators “who approves X?” and “who escalates Y?” Fix confusion with targeted updates. ¹
• Add maintenance triggers for org changes and supplier changes, and schedule periodic role/RACI review through SMS governance. ¹

Frequently Asked Questions

Do we need a dedicated “SMS Manager” role to satisfy Clause 5.3?

The clause requires that someone has responsibility for ensuring the SMS conforms to ISO/IEC 20000-1 and that responsibilities and authorities are assigned and communicated. ¹ That can be a dedicated role or part of another role, as long as authority and evidence are clear. ¹

Is an org chart enough to show roles and responsibilities?

No. An org chart shows reporting lines but rarely shows process ownership or decision rights. ¹ Pair it with role descriptions, a process RACI, and operational records that demonstrate the roles being executed. ¹

How detailed do “authorities” need to be?

Detailed enough that two different teams would reach the same decision about who can approve, escalate, or accept exceptions for a scenario. ¹ If your approvals in the ITSM tool do not match the stated authority, auditors will challenge the control. ¹

What about third parties who operate part of our service desk or infrastructure?

You still need clear internal accountability for the service and process outcomes, plus documented responsibilities for the third party’s activities. ¹ Keep evidence that these expectations are communicated and governed, not assumed. ¹

How do we “prove communication” to auditors without creating busywork?

Use durable communication channels: controlled document publication, onboarding materials, and recurring governance meetings where roles are reviewed and decisions are recorded. ¹ Auditors accept multiple forms of evidence as long as they show people received and follow role expectations. ¹

Our organization changes frequently. How do we keep RACI current?

Add a formal trigger to review roles and authorities after reorganizations, process changes, tool migrations, and sourcing changes. ¹ Then retain evidence of the review and updated publications so the “assigned and communicated” state stays true. ¹

Footnotes

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