Modern services need more than a single framework. They need useful customer outcomes, repeatable operations, executive decisions, risk controls, and proven continuity. Seven complementary approaches address these requirements from different angles.

Which framework answers which question?

A combined operating model

Enterprise purpose and stakeholder expectations
                     |
       COBIT: governance and direction
                     |
       ISO 31000: risk decisions
                     |
     VeriSM: consumer value and service design
                     |
 ITIL / FitSM: practical service management
                     |
  ISO/IEC 20000-1: SMS requirements and assurance
                     |
     ISO 22301: continuity and resilience
                     |
           Evidence and feedback
                     |
          Continual improvement

This is an illustrative integration, not an official hierarchy or a requirement to implement the frameworks in this exact order. A smaller organization might begin with FitSM and adopt COBIT objectives only where governance needs justify them. A regulated provider may build ISO/IEC 20000-1 and ISO 22301 management systems with ITIL practices supplying implementation guidance. Different teams may organize this integration in different ways.

Capstone case: make an online payment service resilient

A retailer runs its checkout service through a web application, managed database, cloud infrastructure, and third-party payment provider. Frequent outages affect revenue, changes are poorly coordinated, supplier ownership is unclear, and executives do not know whether continuity promises can be met.

VeriSM — Define the consumer outcome: Customers should complete purchases securely with predictable service behavior. Map the end-to-end experience, including user-facing errors, refunds, support, and incident communication. Select resources, operating practices, and technology through a Management Mesh.

COBIT — Establish decision rights: Leadership defines business outcomes, investment limits, risk appetite, supplier oversight, and the authority to approve consequential changes. Select governance and management objectives appropriate to these risks rather than assessing every objective at once.

ISO 31000 — Understand uncertainty: Identify risks such as supplier outage, deployment failure, authentication issues, fraud-control errors, and inadequate recovery capability. Evaluate each against enterprise risk criteria and assign accountable treatment owners.

ITIL — Operate and improve: Define the service, incident response, restoration, change enablement, problem management, monitoring, and continual improvement. Measure business effects as well as technical stability.

FitSM — Keep the implementation practical: Use lightweight service records, roles, supplier contacts, incident logs, change histories, reporting, and a manageable improvement backlog. FitSM is especially useful when organizations must coordinate multiple providers without a single reporting hierarchy.

ISO/IEC 20000-1 — Establish management-system assurance: Define the SMS scope, requirements, documented service commitments, accountable management, supplier interfaces, operational controls, audit, management review, and corrective action.

ISO 22301 — Validate continuity: Perform a BIA, establish approved recovery objectives, create viable recovery arrangements, test technical and business restoration, and correct gaps discovered by exercises.

What an integrated evidence pack might contain

Use one source of truth for shared evidence where practical. A single controlled incident record may support operational review, management reporting, and audit sampling. Avoid duplicating logs just because two frameworks use slightly different terminology.

A practical 90-day improvement roadmap

The time ranges are illustrative. Formal management-system certification or large-enterprise transformation may require substantially greater preparation.

Avoid the four most consequential assessment mistakes

1. Certification is not process maturity. Conformity to an ISO management-system standard should not be converted into an invented numeric capability score.
2. Personal qualifications are not organizational certificates. A certified practitioner cannot, by themselves, make an enterprise compliant or mature.
3. Rating schemes are not interchangeable. An ITIL maturity level, COBIT process capability level, and FitSM-6 assessment result have different criteria and scopes.
4. Evidence of an activity is not evidence of an outcome. A completed backup job, closed incident, or approved change must still be assessed for actual service effectiveness.

The seven standalone tutorials

1. ITIL — digital products and service management
2. COBIT — enterprise technology governance
3. ISO/IEC 20000-1 — service management system
4. FitSM — lightweight IT service management
5. VeriSM — enterprise-wide service management
6. ISO 22301 — business continuity
7. ISO 31000 — enterprise risk management

Start with the framework that solves your most pressing problem, then add the others where they provide clear business value. Service management succeeds when the organization can explain what customers need, who is accountable, how risks are handled, and whether measured outcomes are actually improving.

ITIL Explained: A Practical Guide to Service Management, Digital Products, Incidents, Changes, and Continual Improvement

An online payment stops working during a busy shopping period. Customers cannot complete orders, engineers are investigating several alerts, support agents are receiving complaints, and managers want an accurate recovery estimate. The technical fix matters, but the organization also needs coordinated communication, clear accountability, prioritization, and a way to prevent the next outage.

This is the kind of problem ITIL helps organizations solve. ITIL is a body of best-practice guidance for managing digital products and services so they create value for the people and organizations that depend on them. It is not a software package, a ticketing tool, or a law requiring every organization to operate in exactly the same way.

1. The mental model: services, value, and outcomes

A service enables a customer to achieve an outcome without having to manage all the underlying costs and risks personally. A payroll service, for example, lets HR pay employees without running the payroll infrastructure itself. The service provider still needs infrastructure, processes, suppliers, people, knowledge, and governance.

Several terms are easily confused:

Value is co-created. Providers supply capabilities, but customers and users participate by providing requirements, using services, and giving feedback. A service can have perfect infrastructure availability yet be unsuccessful if it does not meet the customer’s needs.

2. ITIL 4 and ITIL (Version 5): what changed?

ITIL 4 established a value-oriented view of service management through the service value system (SVS), guiding principles, governance, management practices, continual improvement, and service value chain. Its four dimensions encourage balanced decisions across people, information and technology, partners and suppliers, and value streams and processes.

ITIL (Version 5) builds on those concepts and makes digital products and services more explicitly connected. Its product and service lifecycle model describes eight activities: Discover, Design, Acquire, Build, Transition, Operate, Deliver, and Support. These activities interact and repeat; they should not be imposed as a rigid waterfall process. The updated guidance also places greater emphasis on AI-enabled work, complexity, product management, experience, and governance.

A helpful way to picture the relationship is:

Customer need and business objective
              |
      Discover and design
              |
      Acquire and build
              |
           Transition
              |
    Operate, deliver, support
              |
 Feedback, measurement, improvement
              +----> informs every stage

ITIL (Version 5) is being released in phases. ITIL 4 training and certifications may still be relevant during the transition. Use the edition and official syllabus that match the certification or organizational assessment you actually intend to pursue. Do not assume that a maturity assessment built around an ITIL 4 service value system automatically has identical rules under every new edition.

3. Seven guiding principles translated into behavior

ITIL’s guiding principles are practical decision tests, not slogans:

1. Focus on value: Ask whether an activity improves an outcome customers care about. A faster escalation process may matter more than a prettier dashboard.
2. Start where you are: Examine existing ticket records, monitoring, on-call schedules, and service ownership before buying a replacement system.
3. Progress iteratively with feedback: Pilot incident categories with one service before reorganizing every department.
4. Collaborate and promote visibility: Give support, engineering, security, and business stakeholders one common incident timeline.
5. Think and work holistically: Account for technology, people, suppliers, contracts, customer experience, and compliance together.
6. Keep it simple and practical: Remove approval stages that add delay without controlling meaningful risk.
7. Optimize and automate: Stabilize a process before automating it; automate repetitive classification and routing, not judgment that requires accountability.

4. The practices you should implement first

ITIL has a broad portfolio of management practices. Most teams should begin with the practices that solve their actual problems rather than trying to implement the entire catalog at once.

Incident, problem, and change are different workflows. An incident aims to restore service; a problem investigation finds or manages underlying causes; change enablement controls the risk of introducing a modification. One outage may create records in all three practices, but they have different objectives and may progress at different speeds.

5. Build an incident-management workflow

Consider a checkout API returning errors for 30% of payment attempts.

Step 1 — Detect and log. Monitoring reports an increased error rate. The on-call responder creates an incident containing the affected service, start time, symptoms, customer impact, and initial hypothesis.

Step 2 — Classify and prioritize. Use impact and urgency. A critical checkout failure affecting many paying customers could be designated P1 under the organization’s own severity policy. P1, P2, and similar labels are local definitions, not universal ITIL time limits.

Step 3 — Assign roles. Appoint an incident commander for coordination, a technical lead for restoration, and a communications owner for updates. In a smaller organization one person may perform multiple roles, provided accountability remains clear.

Step 4 — Stabilize and restore. Engineers investigate recent releases, databases, queues, dependency errors, and capacity. A rollback or failover may restore service before the deeper cause is known.

Step 5 — Communicate. Publish confirmed impact and the next update time; avoid invented recovery estimates. Internal and external audiences may require different messages.

Step 6 — Validate and close. Confirm user journeys work, monitor error rates, document actual restoration time, and obtain appropriate service-owner acknowledgment.

Step 7 — Learn. Open a problem investigation if the event is significant or recurrent. Record contributing factors, follow-up changes, and action owners.

An incident record might look like this:

Here the time to restore is 42 minutes. That does not mean the root cause was resolved in 42 minutes.

6. Make change enablement compatible with DevOps

Change enablement should manage risk rather than require the same meeting for every deployment. Distinguish routine, well-understood changes from unusual changes needing more scrutiny. For a low-risk application release, automated test evidence, peer review, feature flags, and a reliable rollback may provide stronger control than a manual change-advisory-board meeting.

Use a small change record covering the service, expected impact, deployment owner, risk, verification plan, customer communication if required, and rollback trigger. An emergency change still needs clear authorization and post-implementation review, but its path may be accelerated.

Example decision rule: Automatically approve a well-tested, repeatable change when pre-agreed conditions are met; require an accountable human review if it changes payment authentication, modifies customer data, or crosses a defined business-risk threshold. These are illustrative company policies, not universal ITIL mandates.

7. Measure what matters

Useful metrics connect service behavior to customer outcomes:

Avoid optimizing ticket-closure counts while users still suffer. Pair operational indicators with customer measures, such as checkout success, employee productivity, or time to obtain access.

8. ITIL maturity and practice capability

ITIL is not synonymous with a universal maturity number. PeopleCert offers a defined ITIL Maturity Model that can assess practice capability and, under relevant assessment scopes, organizational service-management maturity. Its published model includes five levels, commonly presented from Initial through Managed, Defined, Quantitative, and Optimizing. The meaning of each level and the scope of an assessment depend on the official method being applied.

An internal gap review is useful but should never be presented as an official ITIL maturity assessment. Document the chosen assessment method, practices assessed, evidence, evaluator, date, findings, and follow-up actions.

9. Hands-on lab: create a service-management starter kit

Scenario: A 50-person SaaS company has an operations team, a support inbox, basic application monitoring, and frequent deployment-related outages.

Exercise A — Service definition. Create a one-page record for the production API containing a business owner, technical owner, customer groups, critical dependencies, support hours, major failure scenarios, and three measurable objectives.

Exercise B — Incident simulation. Announce that API error rates exceed the team’s trigger threshold. Record detection time, incident commander, user impact, one communications update, recovery action, and confirmation of restoration.

Exercise C — Change guardrail. Define one pre-authorized low-risk change type and one high-risk change type. Specify the tests, approval, monitoring, and rollback evidence for each.

Exercise D — Improvement review. Select a recurring failure and write a single measurable improvement hypothesis, such as: “Deployment-related incidents will decline after rollout health checks and automatic rollback are introduced.” Capture baseline and follow-up results.

A successful lab produces four tangible artifacts: a service record, completed incident timeline, two change-control examples, and an improvement item with an owner and measurement plan.

10. A practical adoption sequence

First month: Identify critical services and owners; collect baseline ticket and monitoring data; agree on incident severity, escalation, and communication conventions.

Second month: Introduce change-risk rules, service requests, knowledge articles, post-incident reviews, and service-level reporting for selected services.

Third month: Connect problem management with the improvement backlog, review supplier dependencies, measure user outcomes, and reassess which practices need investment.

This timeline is illustrative. A complex regulated enterprise may need a longer governance and assurance effort.

Common mistakes

• Buying an ITSM platform and calling the implementation “ITIL adoption.” Tools support practices; they do not create accountability or outcomes.
• Treating every incident as a problem investigation. Investigate according to business risk and recurrence.
• Making all changes follow one heavyweight approval route.
• Measuring uptime without defining service boundaries and user impact.
• Equating an individual ITIL certification with organizational compliance or maturity.
• Adopting the terminology of a new ITIL edition without checking the official assessment or training scope.

Test your understanding

1. A failed deployment causes a checkout outage. Which practice restores the service first? Incident management; a change rollback may be the technical restoration action.
2. Why might a problem record remain open after an incident is closed? The service may be restored while root-cause analysis and risk reduction continue.
3. Does ITIL prescribe one fixed P1 recovery time? No. Severity definitions and service objectives are established by the organization and its agreements.
4. Can a team use both ITIL and DevOps? Yes. Automated delivery and collaborative service management reinforce each other when controls are risk-based.
5. Is an internal score of 4/5 an official ITIL maturity rating? Not unless it follows the applicable official methodology and required assessment conditions.

Further reading

• Official ITIL overview
• What is new in ITIL (Version 5)
• PeopleCert: ITIL evolution and certification transition
• PeopleCert: ITIL practice guidance and capability assessment

The examples, service targets, incident numbers, and rollout schedule are illustrative. For certification or formal maturity assessment, use the official material applicable to the chosen edition and scheme.

COBIT Explained: How to Govern Enterprise Technology, Assess Capability, and Connect IT Decisions to Business Value

Imagine a company that invests heavily in cloud services yet cannot answer three basic questions: Who decides which systems deserve funding? Who accepts the risks of critical suppliers? And how does leadership know whether technology investments are delivering the promised benefits?

These are not primarily help-desk problems. They are governance problems. COBIT provides a structured way to connect enterprise objectives with the decisions, controls, processes, information, people, and technologies needed to achieve them.

1. What COBIT does—and what it does not do

COBIT is maintained by ISACA and is a framework for the governance and management of enterprise information and technology (I&T). Its currently established core model is associated with COBIT 2019, the edition name used in ISACA publications. It is not limited to the IT department: business leadership, procurement, security, finance, compliance, and service owners all participate in technology governance.

COBIT helps an organization balance three outcomes: realize benefits, optimize risk, and optimize resources. It does not replace every specialized discipline. ITIL offers detailed service-management guidance; ISO standards may establish auditable management-system requirements; COBIT helps leaders connect all of these to enterprise direction.

2. Governance versus management

The distinction is fundamental:

For example, a board or delegated governing body may direct that critical customer data must remain recoverable within approved limits. Technology management selects architectures, tests recovery, operates backup systems, and reports whether the desired outcome is achievable.

A governance committee should not become a second help desk. Its job is to make consequential decisions and oversee their results.

3. Understand the five COBIT domains

The COBIT core model contains 40 governance and management objectives organized into five domains.

EDM focuses on governance. APO, BAI, DSS, and MEA focus on management. Each objective is supported by more than a process: organizational structures, policies, information, skills, culture, and technology also matter.

4. The seven governance-system components

An organization can own the correct policy and still fail because staff lack skills or the reporting data is unreliable. COBIT addresses this problem through an interconnected set of governance-system components:

1. Processes.
2. Organizational structures.
3. Principles, policies, and frameworks.
4. Information.
5. Culture, ethics, and behavior.
6. People, skills, and competencies.
7. Services, infrastructure, and applications.

Example: For cloud-cost governance, a finance-approved budget is only one component. Effective execution also needs tagged cloud resources, accountable service owners, usage reports, engineers able to optimize workloads, and a management review that can act on overspending.

5. Start with enterprise goals, not a checklist of all 40 objectives

COBIT uses goal cascading and design factors to tailor governance to the enterprise. The starting point should be a business goal, such as reducing payment failures while expanding into new markets.

A practical cascade is:

Business goal: reliable digital revenue
       |
Enterprise risks and stakeholder expectations
       |
Technology alignment goals
       |
Relevant governance and management objectives
       |
Policies, practices, owners, evidence and metrics
       |
Review of business outcomes

Design factors include enterprise strategy, goals, risk profile, regulatory demands, threat conditions, technology strategy, sourcing arrangements, enterprise size, and other context. A small company that relies on managed cloud services will require different controls from a bank operating legacy systems in several jurisdictions.

Decision rule: Select objectives because they affect an important enterprise outcome, not merely because they exist in COBIT.

6. Worked example: govern a cloud migration

Situation: A subscription business wants to migrate its order-processing platform to managed infrastructure without interrupting customers or losing control of costs.

Step 1 — Define the desired outcome. Leadership agrees that business continuity, acceptable operating cost, and secure customer data are higher priorities than migration speed alone.

Step 2 — Identify relevant objectives. Consider EDM03 for risk optimization, APO10 for supplier management, APO12 for risk, BAI06 for change, DSS02 for incident handling, DSS04 for continuity, and MEA03 for compliance. This is a tailored selection, not the full COBIT model.

Step 3 — Assign accountability. A steering group owns investment and risk decisions; a platform lead owns technical execution; a security lead assesses relevant controls; a service owner accepts readiness for operational handover.

Step 4 — Define evidence. Require a supplier due-diligence record, migration design, cost model, security assessment, recovery-test results, deployment change record, and post-migration scorecard.

Step 5 — Set stop/go criteria. Migration should not proceed if recovery cannot be demonstrated, required data-handling conditions are unmet, or financial exposure exceeds the agreed tolerance without approval.

Step 6 — Monitor and correct. After migration, compare actual monthly spending, service availability, incident trends, and recovery readiness against agreed objectives.

A useful oversight record looks like this:

7. Capability levels and performance assessment

COBIT’s performance-management approach supports assessments of processes and governance performance. The familiar 0–5 process capability scale is associated with its published methodology:

These summaries explain the progression; actual assessment must follow the relevant official criteria, activities, evidence, and scoring rules. A process capability level is not automatically the maturity of the entire enterprise. Moreover, a level 5 target is not necessary for every process. The right target depends on criticality, cost, and risk.

Example capability gap review

These are hypothetical internal assessments, not certified COBIT ratings.

8. Design a governance dashboard

A dashboard must answer what decision a metric supports. An executive committee generally does not need every operational graph.

An effective dashboard names the owner, data source, refresh frequency, target, current result, decision threshold, and latest action. Reducing a risk score without verifying exposure should not count as success.

9. Hands-on governance workshop

Scenario: Your company uses three cloud providers, has no central asset inventory, and has recently suffered a supplier-related outage.

Task A: Write one business objective and two measurable outcomes. For example: maintain a customer-facing service within agreed availability and restore a critical dependency within the approved recovery period.

Task B: Choose four relevant COBIT objectives across at least three domains. Explain why each supports the outcome.

Task C: Draw a simple accountability map: who evaluates the supplier risk, who directs treatment, who performs controls, and who independently reviews results?

Task D: For one objective, collect three evidence items and identify two gaps. Assign one improvement owner and deadline.

Task E: Present a one-page board summary with the top three decisions required, not just the top three technical problems.

Expected result: A tailored governance plan covering objectives, owners, evidence, metrics, and decisions—not a generic 40-objective checklist.

10. Common implementation failures

• Confusing governance accountability with day-to-day process ownership.
• Attempting to assess all 40 objectives before clarifying enterprise priorities.
• Copying controls from a heavily regulated organization into a small firm without tailoring.
• Claiming that a spreadsheet self-score represents an independent COBIT assessment.
• Choosing the highest capability target for every process despite limited business value.
• Reporting operational activity without linking it to enterprise benefits, risk, and resource decisions.

Knowledge check

1. What distinguishes EDM from DSS? EDM concerns governance decisions and oversight; DSS concerns operational delivery, service, and support.
2. Does COBIT replace ITIL? No. The frameworks can complement one another.
3. Why is a 0–5 capability score not a company-wide maturity score? It may apply to an assessed process, within a specified method and scope.
4. Should every COBIT objective be a level 5 priority? No. Determine proportionate targets based on business need and risk.
5. What is the best first artifact for a COBIT initiative? A clear enterprise objective connected to stakeholders, risks, accountable decision makers, and relevant governance objectives.

Further reading

• ISACA: COBIT overview
• ISACA: COBIT Framework Introduction and Methodology
• ISACA: COBIT use case and process capability discussion
• ISACA: Defining target capability levels

All company scenarios, maturity ratings, target values, and decision tables are practical examples rather than official assessment results.

ISO/IEC 20000-1: A Complete Practical Guide to Building and Auditing an IT Service Management System

A service provider may have capable engineers, a functioning ticket system, and well-designed monitoring yet still deliver inconsistent service. Customers do not know what to expect, suppliers are poorly coordinated, changes are introduced without clear controls, and recurring failures do not lead to systematic improvement.

ISO/IEC 20000-1 addresses this gap by establishing requirements for a service management system (SMS). Rather than prescribing a particular tool or every operational procedure, it asks an organization to manage services through a coherent, controlled, measurable, and continually improving system.

What exactly is a service management system?

A service management system is the interrelated collection of policies, objectives, responsibilities, processes, resources, controls, and evidence used to manage services. The SMS is not identical to the ticketing platform. The platform may record incidents and changes, but the SMS also determines who is accountable, which services are in scope, how performance is reviewed, and what corrective action follows failure.

A useful mental model is:

Customers and service requirements
               |
     Service management policy
               |
Scope + ownership + controls + resources
               |
  Design -> Transition -> Deliver -> Support
               |
   Measure -> Audit -> Review -> Improve
               |
     Better service outcomes

ISO/IEC 20000-1 is a requirements standard. An organization can seek independent certification of an SMS within a clearly stated scope. This differs from staff receiving ITIL or FitSM training certificates. ISO itself does not issue company certificates; certification is performed by certification bodies.

Understand the management-system structure

The standard follows a management-system approach: understand the organization, secure leadership commitment, plan the system, provide support, operate services, evaluate performance, and improve.

The published edition includes an amendment addressing consideration of climate change in management-system context. Treat relevant climate-related external issues and stakeholder requirements as part of context analysis rather than assuming that the amendment mandates the same climate-control plan for every organization.

Service-management activities inside the SMS

An effective implementation connects the major service-management activities instead of treating each as a separate document.

Service portfolio and catalog: Identify what the organization manages and delivers. The portfolio supports decisions across planned, active, and retired services; the catalog communicates relevant services and how to request or use them.

Customer and supplier relationships: Understand customers’ requirements, agree relevant service commitments, and manage interfaces with suppliers and internal providers.

Demand, capacity, and costs: Estimate needed resources and their associated budgets so demand can be met sustainably.

Design and transition: Evaluate proposed services or changes, manage the transition into operation, and control releases and deployment.

Resolution and fulfillment: Restore incidents, fulfill service requests, and investigate underlying problems.

Service assurance: Manage availability, continuity, and information security appropriate to service commitments and risks.

A process map is not enough. Each connection needs an accountable role, defined handoffs, measurable results, and retained evidence where necessary.

Step-by-step: establish your first SMS

Step 1 — Define boundaries before creating documents

Choose a scope that describes the organizational unit, the managed services, and relevant locations and interfaces. For example:

The service management system covers the design, transition, operation, and support of the enterprise’s internally managed employee identity and access service, including the internal support team and contracted authentication provider.

An accurate scope is more important than an impressive one. Outsourcing a critical activity does not remove the organization’s responsibility for controlling what occurs within its SMS.

Step 2 — Identify interested parties and requirements

List internal customers, external customers, regulators when applicable, suppliers, operational teams, and leadership. Record which requirements affect the SMS. Avoid confusing a customer’s wish with an agreed commitment: define how requirements are reviewed and accepted.

Step 3 — Agree service policy and measurable objectives

A policy states leadership’s direction. Objectives turn it into testable outcomes. Examples include reducing avoidable access delays, restoring priority incidents within agreed targets, and maintaining an evidence-based supplier review cycle.

For each objective, capture owner, data source, measurement definition, target, review frequency, and improvement response. Targets should reflect business needs rather than figures copied from another organization’s scorecard.

Step 4 — Name owners and make responsibilities executable

At minimum, define who owns the SMS, each service, customer relationships, incident coordination, change control, supplier management, performance review, and internal audits. Roles can be combined in small organizations, but conflicting duties and independence for audits require attention.

Step 5 — Map the service lifecycle

Follow one service from planning and customer requirements through design, supplier interfaces, change authorization, operation, issue resolution, security, continuity, reporting, and improvement. Document only the level of procedure detail necessary for reliable execution and evidence.

Step 6 — Create controlled operational records

The service catalog, agreements, change records, incident records, release evidence, supplier performance results, and continuity arrangements must be current and retrievable. Define access permissions, retention rules, approval, revision, and disposal where relevant. A shared folder with inconsistent filenames is not a robust control system by itself.

Step 7 — Collect performance data

Measure outcomes such as service availability, incident restoration, failed changes, supplier service performance, customer satisfaction, and overdue corrective actions. Define data quality checks so metrics are meaningful.

Step 8 — Perform an internal audit

Plan audits based on importance, change, prior results, and other relevant considerations. An auditor tests whether selected requirements are met and whether processes actually operate as described. Interviews alone are usually insufficient; sample real records and compare them with the requirements and the organization’s own controls.

Step 9 — Hold a meaningful management review

Leadership reviews performance, customer feedback, audit results, nonconformities, supplier issues, changes affecting the SMS, resources, and improvement opportunities. Minutes should show decisions, owners, and follow-up—not simply that a meeting occurred.

Step 10 — Correct causes, not just documents

If incidents are frequently unassigned, replacing a procedure document is unlikely to solve the issue by itself. Examine workflow routing, staffing, skill gaps, and escalation behavior. Implement a correction, verify its effectiveness using later records, and update controls where needed.

Worked example: employee identity service

A mid-sized business provides single sign-on, multifactor authentication, and account access to its employees. The service depends on an identity provider, corporate directory, HR onboarding data, and help-desk support.

A failure scenario is that the identity provider has an outage. The SMS must connect the supplier relationship to incident communication, continuity procedures, user impact, and post-event review. A help-desk ticket on its own does not demonstrate an effective SMS.

Design an audit-ready evidence register

This example illustrates how to organize evidence without reproducing copyrighted standard text.

Evidence should be genuine operational records rather than artificially created audit-day paperwork.

Certification, conformity, and maturity are different

The standard describes requirements, not a universal 1–5 maturity ladder. A certification audit assesses conformity of the defined SMS scope against the applicable requirements. An organization may also run its own maturity assessment or use a separate model, but that score must be labeled with the model and criteria used.

Certification preparation typically involves establishing the SMS, operating it long enough to generate meaningful evidence, conducting internal audits and management review, addressing deficiencies, and then engaging an appropriate certification body. The exact certification process, audit stages, sampling, and timelines depend on the certifier and accreditation arrangements.

Practical lab: audit one service from end to end

Scenario: Your team operates a corporate VPN service with an external networking supplier.

1. Write a precise SMS scope that includes the service, operational team, and supplier interface.
2. Define three customer requirements and convert two into measurable service commitments.
3. Trace a recent VPN incident from detection to restoration and customer communication.
4. Trace one planned configuration change through risk review, testing, implementation, and post-change verification.
5. Inspect one supplier report and the most recent service review.
6. Record two conformity gaps, their causes, owners, corrective actions, and evidence needed to verify improvement.

Example finding: “Three sampled priority incidents lacked a documented escalation owner despite the organization’s own approved incident procedure.” The correction is not simply to fill the blank fields after the fact. Review why assignments were missed, fix routing, train affected roles, and verify new samples.

Frequent errors to avoid

• Claiming the entire enterprise is certified when only a specific service unit is within scope.
• Treating ITIL personnel certification as proof of ISO/IEC 20000-1 conformity.
• Failing to control externally provided service activities.
• Keeping attractive policies that contradict actual workflows.
• Neglecting internal audit and management review after the initial rollout.
• Confusing conformity with an arbitrary maturity score.

Check your understanding

1. What is certified under ISO/IEC 20000-1? A scoped organization’s service management system, not a software tool.
2. Can a company outsource a critical service component and ignore it? No. Relevant external provision must be managed within the SMS.
3. Does the standard mandate a five-level maturity model? No.
4. What closes a corrective action? Evidence that the chosen action addressed the cause and was effective, not simply the closure of a task ticket.
5. Why is SMS scope important? It identifies exactly what requirements, services, and organizational arrangements the conformity assessment covers.

Primary sources

• ISO: ISO/IEC 20000-1 service management system requirements
• ISO: Amendment addressing climate action considerations
• IEC: ISO/IEC 20000-1 amendment listing

This article explains the standard in original teaching language. For formal certification or an authoritative requirements interpretation, obtain the licensed official standard and applicable amendment.

FitSM: A Beginner-to-Advanced Guide to Lightweight IT Service Management and Practical Capability Assessment

Many teams know they need service management but do not have the budget, headcount, or appetite for a large transformation. A research computing center, startup, university department, or shared cloud-platform team may need basic service catalogs, incident ownership, change controls, and supplier coordination without building a complex bureaucracy.

FitSM was designed for exactly this kind of problem. It is a free, lightweight family of IT service management standards and guidance documents, developed with particular attention to distributed and federated service environments. Its practical value lies in making essential ITSM requirements and responsibilities understandable and achievable.

Where FitSM fits

FitSM provides a bridge between informal support practices and a more consistent service management system. It is suitable for organizations that need a practical starting point and for collaborations in which several organizations jointly operate a service.

For example, a scientific computing service might rely on a university help desk, a storage provider, an identity federation, and an external networking partner. Nobody controls every component directly, but the users still need one reliable service experience. FitSM helps teams agree on common processes, interfaces, ownership, and evidence.

FitSM is not a simplified copy of ITIL and is not equivalent to ISO/IEC 20000-1 certification. It is a distinct framework family that can work alongside both.

The seven parts of the FitSM family

The official download area provides the current document editions, including the FitSM 3.x family. Working from different generations of the FitSM requirements and assessment sheets can lead to misleading results; verify that documents and training correspond to your chosen edition.

The 14 processes and what they accomplish

FitSM-1 organizes service management around 14 core processes. Knowing their purpose is more useful than memorizing their abbreviations.

The official FitSM documents provide the requirements and recommended activities. Not every organization needs a separate employee for every process. A small team can assign several roles to one person where it can manage accountability and conflicts effectively.

A complete miniature FitSM implementation

Suppose a small engineering organization supports three services: a Git hosting service, a build platform, and an internal artifact repository.

Phase 1 — Name and understand the services

Start with one-page service descriptions rather than a large configuration database. Each entry should include service name, intended customers, owner, support channel, major dependencies, criticality, and service commitments.

Phase 2 — Agree on incident and request handling

Write a short guide defining where users report failures, what information a ticket must include, how priority is assessed, who investigates, and when to escalate. Separate service interruption from routine work such as asking for new repository access.

A useful minimum record contains: ticket identifier, service, reporter, description, impact, assigned owner, status, actions taken, restoration or fulfillment result, and closure confirmation.

Phase 3 — Establish low-friction change control

For routine, well-tested configuration updates, use a documented low-risk path. For changes to identity integration, permissions, data retention, or production networking, require additional review appropriate to risk. Keep a change log showing request, impact, decision, implementation, validation, and rollback option.

Phase 4 — Coordinate suppliers and continuity

Record which providers support each service, how to contact them, where their incident status is published, what commitments exist, and what the organization will do when they fail. Prepare practical recovery steps: alternate authentication, service restore, backup access, or an agreed degraded operating mode.

Phase 5 — Add reporting and continual improvement

Hold a monthly review of incidents, request delays, service performance, recurring causes, supplier issues, and improvement actions. Collect data that answers decisions, not just what the tools happen to record.

Why role clarity matters in federated environments

Imagine a user in one institution reporting a compute-service failure caused by another institution’s storage platform. Without agreed roles, both providers may close the ticket as “not our issue.”

An interface agreement should answer four questions:

1. Who receives the incident from the user?
2. Who coordinates end-to-end restoration and communication?
3. Which provider owns the affected technical component?
4. Who verifies that the service is usable again?

Use FitSM-3 as a starting point for role assignment, then adapt assignments to your governance and supplier contracts. Shared operational responsibilities do not mean shared responsibility is undefined.

Capability and maturity assessment with FitSM-6

FitSM-6 is a real assessment approach, not merely an informal checklist. The official method assesses how closely current practices match descriptive capability conditions associated with FitSM-1 requirements. Its current guidance describes three narrative levels used to select the closest representation of a team’s practice. This is not the same as automatically applying COBIT’s 0–5 ratings.

An effective assessment should:

1. Select the version of FitSM-6 that corresponds to the FitSM requirements being used.
2. Define the service organization, services, processes, and locations in scope.
3. Gather a sample of actual records and interview people performing the work.
4. Read the official assessment descriptions and select ratings with evidence.
5. Record disagreement or uncertainty instead of inventing precision.
6. Prioritize gaps by user impact, operational risk, and feasibility.
7. Reassess after improvements have been implemented and operated.

Important: An internal exercise can identify useful gaps, but a formal organizational certificate is a separate outcome with its own audit and certification conditions. FitSM also has qualifications for individual practitioners.

Example gap discussion

This table intentionally does not assign official FitSM-6 ratings without conducting the prescribed assessment.

Hands-on lab: FitSM for a small organization

Environment: Use a spreadsheet or an existing issue tracker. No special paid ITSM platform is required.

Exercise 1 — Catalog: Create three service records with an owner, customers, dependencies, and support route.

Exercise 2 — Incident: Simulate an artifact repository outage. Log customer impact, responsible resolver, supplier involvement, mitigation, recovery time, and next user update.

Exercise 3 — Change: Create a change record for rotating a storage access credential. Explain possible failure modes and your rollback or recovery method.

Exercise 4 — Supplier interface: Write five lines describing who responds when external object storage is unavailable.

Exercise 5 — Improvement: Record one measurable action to reduce recurrence, and identify the evidence you will review next month.

Pass criteria: Someone who was not involved in the setup can locate the service owner, log an incident, understand a change decision, and identify who communicates about a supplier outage.

How to grow without turning FitSM into bureaucracy

A practical progression is to establish service ownership and incident handling first; then add change control and basic supplier, availability, and security arrangements; then strengthen capacity, reporting, problem analysis, and improvement. The order should be adjusted to risks and service needs.

Do not require a complex service configuration database before knowing which services are important. Do not purchase a new tool until you have identified a genuine limitation in existing workflows. And do not confuse an extensive procedure library with effective service delivery.

Knowledge check

1. Is FitSM free to access? Its core documents and guidance are available from the official project website without a purchase requirement.
2. Does FitSM define exactly 14 core ITSM processes? The official FitSM-1 process model describes 14.
3. Are the three FitSM-6 narrative assessment levels COBIT capability levels? No; they belong to different assessment schemes.
4. Why is FitSM useful for federated services? It emphasizes shared management expectations and coordination across providers that may not share one hierarchy.
5. Does a FitSM Foundation certificate certify an entire organization’s SMS? No. Individual qualifications and organizational certification are different.

Official resources

• FitSM standard family
• FitSM parts, processes and assessment guidance
• Download FitSM requirements, templates and FitSM-6
• FitSM training and professional certification

All service examples are fictional. For an official FitSM capability or certification claim, follow the current governing assessment and certification requirements rather than a custom scorecard.

VeriSM Explained: Designing Flexible, Value-Driven Service Management Across the Enterprise

A new employee joins a company. Human resources must confirm employment, IT must provision an account and laptop, security must apply access controls, finance may need to approve a device purchase, and the hiring manager expects the employee to be productive on the first day.

From the employee’s perspective, this is one service experience. From the organization’s perspective, it crosses multiple departments, systems, policies, suppliers, and workflows. VeriSM is a service management approach designed to address this broader, cross-functional challenge.

Why a different kind of service management?

Traditional IT service management often begins with IT processes, tickets, and operational controls. VeriSM starts with the value and outcomes consumers need and asks how the organization can combine relevant people, management approaches, resources, technology, and governance to deliver those outcomes.

VeriSM stands for Value-driven, Evolving, Responsive, Integrated Service Management. It is an approach for the digital age rather than a replacement for every existing framework. Its flexibility is intentional: a payroll service, a consumer mobile application, and a manufacturing monitoring service should not necessarily use identical operating practices.

VeriSM makes enterprise service management tangible. Marketing, HR, legal, operations, finance, security, and technology teams may all participate as service providers or service partners.

The fundamental ideas

A product or service should exist to create value. Begin with the intended consumer outcome. For onboarding, the outcome is not “five tickets closed”; it is “a new hire can work safely and effectively at the agreed start time.”

Service management principles create consistency. Enterprise principles might require privacy protection, acceptable cost, legal compliance, accessible support, responsible sourcing, and transparent ownership. Such principles apply even when delivery methods vary.

Management practices should be chosen deliberately. Agile, DevOps, ITIL practices, Lean, project management, risk frameworks, and supplier management can all contribute. The goal is not allegiance to a single methodology but a coherent operating model.

Technology is an enabler. Cloud services, automation, analytics, and AI can improve speed and experience, but only when they fit the organization’s environment and obligations.

Understand the VeriSM model

The VeriSM approach describes four closely related activity areas:

This model is not intended to imply that teams complete one activity forever and then move on. Feedback from consumers and service operation can change the next definition or production decision.

A simplified view:

Consumer outcome and enterprise principles
                     |
       Define -> Produce -> Provide
          ^                  |
          +------ Respond <--+
                     |
        Feedback and improvement

The Management Mesh: the distinctive VeriSM concept

The Management Mesh helps service teams decide what combination of capabilities is suitable for a particular service. Four areas are evaluated:

1. Resources: People, knowledge, money, providers, equipment, time, and skills.
2. Environment: Organizational culture, relationships, regulatory context, competition, and other constraints.
3. Management practices: Relevant practices from ITIL, Agile, DevOps, COBIT, Lean, project management, risk management, and other approaches.
4. Emerging technologies: Technologies that can improve the solution when they are appropriate and controlled.

The mesh is different for each product or service. It should be reassessed when requirements, risks, suppliers, technology, or consumer experience change.

Worked Management Mesh: employee onboarding

The central insight is that the solution is not “install an ITSM tool.” It is an operating model combining business requirements, people, practices, and technology.

Build the service experience from the customer’s point of view

A useful implementation begins by mapping an actual journey.

Step 1 — Define the consumer and outcome

For onboarding, the consumer is the employee, while HR, managers, security, and finance are service participants. A measurable outcome might be: “Employees have the agreed essential equipment and access by the time they start, subject to approvals and required identity verification.”

Step 2 — Find moments of friction

Interview consumers and service providers. Look for duplicate data entry, unclear ownership, unnecessary approvals, long waiting periods, inaccessible documentation, and missing communication.

Step 3 — Establish non-negotiable principles

Examples: no account provisioned without an authorized employment trigger; sensitive identity information is handled under company policy; all exceptions have accountable owners; supplier spend is authorized; and service status is visible to stakeholders.

Step 4 — Create the Management Mesh

Identify available resources, organizational constraints, selected practices, and appropriate technology. Avoid forcing every activity into the same tool when a simple system integration or workflow agreement would work better.

Step 5 — Design the end-to-end operating model

Define triggers, approvals, handoffs, exception routes, customer communications, service ownership, records, escalation, supplier involvement, and measurement.

Step 6 — Pilot with one employee population

Run a limited pilot with a measurable baseline. Observe what employees actually experience rather than relying solely on process documents.

Step 7 — Improve and scale

Evaluate missed start-date commitments, duplicate requests, manual handling time, employee satisfaction, and policy exceptions. Use findings to adjust the mesh and repeat.

Choose operational measures that reflect value

A successful enterprise service model balances experience, security, reliability, cost, and accessibility. Maximizing a single measure can produce undesirable consequences elsewhere.

Hands-on workshop: design a company-wide service

Case: Internal employees wait several days to receive software access. Requests are submitted through email, different managers use different approval rules, and the security team is frequently involved after access has already been granted.

Assignment 1 — Value statement. Write the customer’s desired outcome in one sentence. Do not frame the outcome as a ticket count.

Assignment 2 — Cross-functional journey. Sketch the steps from access request to authorized use. Label every handoff and waiting point.

Assignment 3 — Mesh selection. For each of the four mesh categories, document one existing constraint and one change you would make.

Assignment 4 — Principles. Define three enterprise principles that will remain valid even if workflows differ between software categories.

Assignment 5 — Pilot. Select one high-volume application. Identify the measures you will compare before and after introducing a redesigned request workflow.

A credible workshop outcome includes a consumer journey, Management Mesh, chosen practices, controls, pilot measures, and accountable service owner.

How to assess progress without inventing an official maturity model

VeriSM is not presented as a universal five-level organizational maturity rating. An organization can define an internal assessment against its goals, enterprise principles, service outcomes, and operating capabilities. That is useful as long as it is labeled an internal model rather than an official VeriSM maturity certification.

A lightweight review could assess five dimensions: consumer outcome, service ownership, cross-team coordination, control effectiveness, and evidence-based improvement. Use descriptive findings and evidence, not merely numerical averages. Ask whether the operating model actually reduces friction while respecting security and governance constraints.

Individual VeriSM professional training or certification should not be confused with enterprise certification or proof that a particular service experience is effective.

Common traps

• Calling an existing departmental ticketing system “enterprise service management” without changing handoffs.
• Designing from internal organizational charts rather than consumer outcomes.
• Choosing new technology before understanding the service journey.
• Treating the Management Mesh as a fixed architecture diagram instead of a decision aid.
• Using flexibility as a reason to ignore security, regulatory, and other enterprise principles.
• Optimizing each department separately while the end-to-end customer experience deteriorates.

Short assessment

1. What is the starting point for VeriSM? Value and desired consumer outcomes.
2. What are the four Management Mesh categories? Resources, environment, management practices, and emerging technologies.
3. Can two services use different practices? Yes, provided they respect relevant enterprise principles and responsibilities.
4. What follows Respond? Feedback may cause the team to redefine, improve, or change service production and provision.
5. Does an internal VeriSM score automatically represent a formal maturity level? No.

Authoritative references

• Official VeriSM website and overview
• VeriSM certification overview and syllabus
• VeriSM information and public resources

The onboarding example and Management Mesh are original instructional examples, not official assessments or a substitute for licensed VeriSM publications.

ISO 22301: A Complete Tutorial on Business Continuity, Impact Analysis, Recovery Planning, and Resilience Testing

A data center loses power, a cloud provider suffers an extended failure, a major supplier becomes unavailable, or a key office cannot be accessed. In these situations, “we have backups” is not a complete business continuity plan. The organization must understand which activities matter most, how long disruption can be tolerated, what resources are necessary, who makes decisions, and how stakeholders will be kept informed.

ISO 22301 establishes requirements for a business continuity management system (BCMS): a structured management approach to preparing for, responding to, and recovering from disruptive incidents. Its purpose is to enable an organization to continue delivering prioritized products and services at acceptable predetermined levels during disruption and to improve its resilience over time.

Business continuity is not the same as disaster recovery

Business continuity addresses the ability of the organization to sustain prioritized business activities and services. Disaster recovery commonly focuses on restoring technology, infrastructure, applications, and data. Technology recovery supports continuity, but continuity also covers people, workspace, suppliers, physical processes, communications, and alternate ways of working.

Consider an online retailer. Restoring the order database is important, but the business may still be unable to operate if payment authorization, fraud checks, warehouse coordination, or customer communication are unavailable.

The core concept is:

Business objectives and critical activities
                    |
      Business impact analysis (BIA)
                    |
         Disruption risk assessment
                    |
    Continuity strategies and resources
                    |
      Plans, roles, communications
                    |
       Exercises and recovery tests
                    |
      Review, correction, improvement

What a BCMS contains

A BCMS connects leadership, policy, context, planning, support, operational continuity activities, performance evaluation, and improvement. Its scope matters: a company may establish a BCMS covering selected services, business units, or locations, and must be clear about the boundaries and dependencies.

A working BCMS typically includes:

The current published standard has an amendment addressing climate-related considerations in management-system context. Consider relevant issues, such as flooding, extreme heat, or supplier-region exposure, where they could materially affect the BCMS. A revision of the standard may be under development; use the published edition and applicable amendments for formal conformity work.

Learn the critical recovery terms

Business impact analysis (BIA): Examines how the effect of disruption grows over time and identifies prioritized activities, dependencies, and resource needs.

Maximum tolerable period of disruption (MTPD): A commonly used planning concept expressing how long a disruption can continue before impact becomes unacceptable. Organizations should use terminology and criteria consistently with their chosen guidance.

Recovery time objective (RTO): A target elapsed period for resuming an activity or system after disruption. RTO is not a guarantee unless design and tests support it.

Recovery point objective (RPO): A technology/data-recovery measure expressing the maximum acceptable age of recovered data. It is especially relevant to disaster recovery and should not be confused with business activity recovery time.

Minimum business continuity objective (MBCO): A minimum acceptable level of products or services that an organization aims to deliver during disruption, where that concept is applied in its continuity planning.

Workaround: A temporary alternative method that allows some business activity to continue without full technical restoration.

Perform a business impact analysis step by step

Step 1 — Identify prioritized products and services

Begin with business outcomes, contractual commitments, safety needs, legal obligations, and customer impact. Avoid beginning and ending with a list of servers.

Step 2 — Understand disruption over time

For each activity, consider the impact at several elapsed durations: 15 minutes, two hours, one business day, and longer intervals if relevant. Impacts may include safety, lost revenue, missed contractual obligations, regulatory exposure, data integrity, and reputational harm.

Step 3 — Establish tolerances and priorities

Decide the point at which consequences become unacceptable and the level of service needed before that point. These decisions should have business-owner approval, not only technical estimates.

Step 4 — Record dependencies

Identify people, skills, facilities, access, suppliers, applications, networks, information, and equipment. Highlight single points of failure and constraints that affect multiple services.

Step 5 — Validate assumptions with operational teams

Check whether recovery goals match technical reality. A promise of 30-minute recovery is not credible if rebuilding the service takes three hours and has never been tested.

Worked BIA example

The following goals are hypothetical business decisions, not ISO-mandated targets.

The payment-processing activity is more time-sensitive than routine expense reporting. That does not mean it is always more important in every organization; the BIA establishes priorities based on context.

Convert the BIA into an actual continuity strategy

Suppose payments must resume within one hour and data loss must be limited to 15 minutes.

Evaluate possible approaches: active-passive failover, replicated databases, alternate payment routing, manual order capture with later reconciliation, spare network connectivity, or a provider contract with tested resilience. Every option has cost, technical, security, and operational trade-offs.

Create a capability validation table:

If a backup job runs every hour, it does not automatically meet a 15-minute RPO. If a backup is successfully created but cannot be restored, it has not demonstrated recoverability.

Build the continuity plan

An actionable plan should be concise enough to follow under stress and complete enough to guide response. Include:

1. Activation criteria: When to initiate the plan, by whom, and based on what evidence.
2. Command structure: Incident leadership, deputies, responsibilities, and delegated authority.
3. First actions: Protect people and safety first; establish the current situation and business impact.
4. Communication: Customer, staff, supplier, regulatory, and executive communication routes as applicable.
5. Priority activities: What must continue first and at what acceptable level.
6. Recovery instructions: Dependencies, steps, prerequisites, verification, and fallback options.
7. Return to normal: Criteria for restoring normal operations and checking data consistency.
8. After-action review: Decisions, timings, deficiencies, and assigned improvements.

Protect sensitive contact information and credentials. Ensure an authorized copy of the plan is accessible when the primary collaboration platform or identity service is unavailable.

Run a realistic continuity exercise

Exercise: A primary cloud region becomes unavailable at 10:00 during peak business activity.

Exercise design: Announce the failure, prevent participants from assuming that their normal dashboard or chat platform works, and inject a supplier escalation delay. Assign an observer to record the decision timeline.

Actions to test: Incident activation, leadership delegation, user impact assessment, recovery strategy selection, failover authorization, business validation, and stakeholder communication.

Stop conditions: Halt the exercise if it poses unacceptable production risk. Live production tests require explicitly approved boundaries and rollback measures.

Evidence: Record when the scenario began, when recovery started, actual restoration time, verified business functionality, recovered data point, missing dependencies, and lessons learned.

Sample post-exercise finding

“Customer records were recoverable, but the recovery team could not use the secondary authentication channel because access depended on the failed region.”

A meaningful corrective action includes establishing an independent access mechanism, testing it, updating the plan, assigning ownership, and verifying the fix at the next suitable exercise.

ISO 22301 conformity versus maturity

ISO 22301 is a requirements standard and can support independent organizational certification within a defined BCMS scope. It does not mandate a universal five-level maturity scale. Organizations may use additional capability models to prioritize improvement, but they must name the model and avoid portraying a custom numerical assessment as an ISO 22301 rating.

For formal conformity evaluation, auditors examine how the BCMS is defined, operated, evaluated, and improved. A glossy continuity document is not sufficient if recovery arrangements are untested or the organization cannot demonstrate that decisions match the BIA.

Implementation lab: a complete tabletop exercise

Scenario: Your only office is inaccessible for two days, and remote employees cannot use the normal VPN.

Task A — BIA: Identify the three most important business activities, including the maximum tolerable disruption and dependencies for each.

Task B — Strategy: Choose an alternate work method, including secure access and communications.

Task C — Activation: Write the first five actions a crisis leader should take and name who has authority to activate the continuity plan.

Task D — Communications: Prepare a factual internal update stating confirmed impact, current action, and next review point. Do not invent a recovery estimate.

Task E — Verification: Decide how to verify that prioritized activities have resumed at their required minimum capacity.

Task F — Learning: Identify two plausible weaknesses and write a corrective action with an owner and testable success condition.

Common continuity planning failures

• Equating a backup policy with an end-to-end business continuity strategy.
• Assigning aggressive RTO and RPO figures without technical testing or business approval.
• Ignoring key staff, buildings, suppliers, identity systems, and communications channels.
• Testing only a database restore and claiming that full business continuity has been validated.
• Holding exercises without tracking and verifying corrective actions.
• Confusing a continuity-plan review with a practical recovery capability test.

Knowledge check

1. Is a working database backup proof of business continuity? No. The business activity and all its material dependencies must also be considered.
2. What is the difference between RTO and RPO? RTO concerns elapsed time to resume; RPO concerns how far back recovered data may be.
3. Which comes first: selecting a recovery technology or understanding business disruption impact? Understand business requirements through a BIA first.
4. Does ISO 22301 prescribe the same recovery time for all organizations? No. Objectives are determined from the organization’s context and impacts.
5. Is an internal maturity score an ISO 22301 certification? No.

Sources and further reading

• ISO: ISO 22301 business continuity management requirements
• ISO: ISO 22301 climate action amendment
• ISO: ISO 22313 guidance on using ISO 22301

The scenarios, time objectives, business impact values, and examples are for instruction. Formal conformity requires the relevant licensed standard and applicable amendments.

ISO 31000 Explained: A Hands-On Guide to Risk Identification, Analysis, Treatment, and Enterprise Decision-Making

A company wants to adopt a new identity provider. The project could reduce maintenance cost and improve employee access, but it may also introduce supplier dependency, migration errors, unexpected licensing costs, or service disruptions. Should the company proceed, delay, modify the rollout, or choose a different provider?

This is a risk-management decision. ISO 31000 provides internationally recognized guidelines for making decisions under uncertainty. It is relevant to technology, finance, suppliers, cybersecurity, operations, product strategy, safety, and organizational transformation.

The most important starting point is that risk management is not about eliminating every risk. It is about understanding how uncertainty can affect objectives and making proportionate, informed decisions.

What is risk?

In ISO 31000, risk is understood as the effect of uncertainty on objectives. That effect can involve downside threats, upside opportunities, or a combination of both. A risk is not merely an item in a vulnerability scanner or an event that has already occurred.

A strong risk statement connects cause, uncertain event, and effect on an objective:

Because the new identity platform is the only authentication provider for several critical services, a prolonged provider outage could prevent employees from accessing systems and interrupt customer support operations.

Compare that with the weak statement “identity platform outage.” The longer statement identifies the dependency, event, and business consequence, making treatment decisions much easier.

Principles, framework, and process: three different layers

ISO 31000 can be understood as three connected elements:

The framework should support business decisions, not create an isolated compliance function. Risks may be owned by the leaders accountable for the relevant objectives, with specialists assisting analysis and control design.

Understand the complete risk management cycle

The process can be represented as an iterative cycle:

Objectives and decision context
            |
   Scope, context, and criteria
            |
      Identify risks
            |
      Analyze risks
            |
      Evaluate risks
            |
       Treat risks
            |
   Monitor, review, and improve
            |
      New decision context
Code language: PHP (php)

Communication and consultation occur throughout the process. Recording and reporting also occur throughout it. The diagram simplifies sequencing; actual risk work is iterative. A newly identified supplier weakness may require going back to change the decision criteria or treatment options.

Step 1 — Establish scope, context, and risk criteria

First ask what decision is being made. “Assess every risk in the company” is too broad for a useful first exercise. A narrower scope such as “approve the identity provider migration and its production operating model” enables more concrete analysis.

Document:

• The business objective and expected benefits.
• Internal and external constraints, including contractual and legal obligations.
• Stakeholders, decision owners, and affected services.
• The period being considered and material assumptions.
• Risk criteria: what level of exposure requires management treatment, escalation, or explicit approval.
• How likelihood, impact, uncertainty, and effectiveness of controls will be analyzed.

Risk appetite describes the broad amount and type of risk an organization is willing to pursue or retain in pursuit of its objectives. Risk tolerance generally refers to acceptable variation or bounds around specific objectives. Define these terms explicitly in company policy because implementation vocabularies differ.

Step 2 — Identify risks using several methods

Interview service owners, engineers, customer teams, finance, security, and procurement. Inspect incident history, architectural dependencies, contracts, audit observations, control gaps, previous migrations, and credible disruption scenarios.

For the identity-provider migration, risks could include:

1. A migration error locks employees out of essential applications.
2. The supplier experiences a prolonged regional outage.
3. Approval workflows provision excessive permissions.
4. A license-model change increases recurring costs.
5. A missed integration requirement delays the product launch.
6. A successful automation initiative frees support staff for higher-value work—an opportunity that can be developed rather than just defended against.

A useful workshop asks how each event affects an objective, who would notice it, what already prevents it, and how reliably the organization would respond.

Step 3 — Analyze likelihood, consequences, and existing controls

Analysis estimates the nature and level of risk, considering consequences, likelihood, uncertainty, existing controls, dependencies, and possible scenarios. Depending on the decision, the method may be qualitative, semi-quantitative, quantitative, or scenario based.

A simple 5-by-5 risk matrix can help a team start a conversation, but ISO 31000 does not mandate one universal risk matrix, scoring equation, or set of colors.

For illustration only:

• Likelihood: 1 = rare under the selected time horizon; 5 = very likely.
• Impact: 1 = limited effect; 5 = critical effect on the defined objective.
• Illustrative score = likelihood × impact.

A likelihood of 3 and impact of 5 gives a score of 15. That number has no independent meaning until the rating definitions, time frame, impact dimensions, and decision thresholds are established. A 3×5 matrix also cannot, by itself, tell you the financial probability of an event.

Sample risk register

All ratings are hypothetical and should not be used as default compliance thresholds.

Step 4 — Evaluate which risks require decisions

Risk evaluation compares analysis results with the organization’s stated criteria to determine whether a risk can be retained, needs further treatment, requires more evidence, or should be escalated. The risk owner is accountable for the decision under the delegated governance model.

Do not confuse analysis with evaluation. A score of 15 is analysis output. Whether 15 is acceptable depends on the organization’s criteria, objectives, exposure, affected parties, and obligations.

Certain legal or safety obligations may impose constraints that cannot be waived simply because a manager accepts the risk.

Step 5 — Choose and implement treatment

Typical options include avoiding an activity, reducing likelihood, reducing consequence, sharing some consequences through contractual or financial arrangements, or knowingly retaining a risk within authorized boundaries. Positive uncertainties may warrant taking or increasing exposure to an opportunity where justified.

A meaningful treatment plan identifies:

A treatment is not complete merely because an action ticket was closed. It must be operational and its effectiveness evaluated.

Step 6 — Monitor, review, record, and report

Risks change when suppliers, customers, technology, regulation, incidents, or enterprise goals change. Review should therefore occur at planned intervals and after relevant events.

Report the information needed for a decision: material risk scenarios, business impact, control effectiveness, trends, treatment progress, unresolved exposure, and requests for risk acceptance or investment. A long list of colored squares without decisions is not an effective risk report.

Use key risk indicators where they are meaningful. For the identity platform, examples include untested critical integrations, recovery-test failures, single-provider dependencies, overdue high-risk actions, and emergency access exceptions. Distinguish indicators of exposure from actual realized losses.

Hands-on lab: a 60-minute risk workshop

Situation: A SaaS business is preparing to adopt a new managed database provider.

Exercise A — Context (10 minutes). Define the business reason for migration, protected objectives, decision authority, and evaluation period.

Exercise B — Identify (15 minutes). Write at least six risk statements using cause, uncertain event, and effect on an objective. Include one upside opportunity.

Exercise C — Analyze (10 minutes). Choose clear likelihood and impact definitions; evaluate three risks and record confidence and assumptions.

Exercise D — Evaluate (10 minutes). Decide which exposures are unacceptable under the company’s actual criteria, and who must approve exceptions.

Exercise E — Treat (10 minutes). For two important risks, choose control measures, accountable owners, dates, and success evidence.

Exercise F — Report (5 minutes). Create a three-sentence leadership update: the decision requested, material exposure, and condition for safe progress.

Expected output: A short decision brief and a risk register that leads to action. The exercise is successful when leadership can make a better-informed decision, not when every row has a numeric score.

Advanced considerations: avoid false certainty

Scales need calibration. Two departments may both rate impact “high” while thinking of completely different financial or operational consequences. Harmonize definitions before aggregating scores.

Risk is often correlated. A single identity or networking failure may simultaneously disrupt many services. Risk registers that treat related events as fully independent can underestimate exposure.

Residual risk needs evidence. A control described on paper is not the same as a functioning control. Consider design, implementation, and observed operating effectiveness.

Quantitative models need assumptions. Expected financial loss, simulations, and scenario analysis can be useful, but use defensible distributions and data. A numeric result generated from unsupported assumptions is not more reliable than a qualitative conclusion.

Risk ownership is not risk reporting. A central risk team can coordinate methodology and challenge findings, but the executive accountable for an activity generally needs to own the corresponding decision within the governance structure.

What ISO 31000 does not certify

ISO 31000 is a guidance standard, not a certifiable management-system requirements standard for organizations. ISO states that it cannot be used as the basis for ISO 31000 certification. Training providers may award individual learning credentials, but these must not be described as ISO certification of an organization’s risk management system.

ISO 31000 also does not mandate a universal maturity scale. Organizations can assess the effectiveness and integration of their risk-management arrangements using a separately defined model, but should identify that model and its evidence.

Common failures

• Writing risks as vague topics without causes or business consequences.
• Giving every risk a 5×5 number while ignoring assumptions and uncertainty.
• Treating all high scores identically, regardless of obligation or objective.
• Assigning risk ownership to a committee with no empowered decision maker.
• Claiming that purchased insurance eliminates operational or reputational exposure.
• Closing a risk because the treatment action was scheduled rather than verified.
• Calling an internal risk rating an official ISO 31000 maturity or conformity certificate.

Quick assessment

1. Can risk include an opportunity? Yes; uncertainty may have beneficial or adverse effects on objectives.
2. Does ISO 31000 require a 5×5 matrix? No.
3. What is the difference between analysis and evaluation? Analysis characterizes exposure; evaluation compares it with criteria to support decisions.
4. Who should decide whether to accept a material risk? The appropriately authorized accountable risk owner, subject to applicable obligations.
5. Can a company be certified to ISO 31000 as a management system? No; it is a guidelines standard, not a certifiable requirements standard.

Official references

• ISO 31000: Risk management — Guidelines
• ISO: Risk management principles and guidance
• ISO 22301: Business continuity management system requirements

Risk scores, tables, examples, and suggested criteria in this tutorial are illustrative. ISO 31000 does not impose these numerical choices, thresholds, or maturity ratings.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.