Standards in Practice: ISO 20000-1 and ISO 22301

What you'll be able to do

• ›Trace service catalogue and SLA commitments to incident, change and supplier evidence
• ›Build BIA entries with distinct RTO, RPO, MTPD and minimum capacity requirements
• ›Assess continuity strategies and exercises against approved recovery targets
• ›Plan integrated audits while retaining separate SMS and BCMS conclusions

Two systems, one service

Evidence (EV) labels exercise records. A shop may answer your call quickly while its till remains broken. Responding to customers and keeping the business running are different needs. At fictional Kestrel Basin Dispatch, a hosted booking service supports warehouse loading and customer billing. A regional outage exposed a service desk that met its response target while bookings remained unavailable. Leadership wants one integrated audit, but has confused a signed service level agreement (SLA) with proof of continuity capability. Your job is to trace requirements to operating evidence and recovery outcomes.

International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 20000-1:2018 specifies requirements for a service management system (SMS). ISO 22301:2019 addresses a business continuity management system (BCMS). Neither is just an information technology (IT) procedure manual. Establish the organizational scope, services or products covered, sites, interested parties, obligations and interfaces before selecting samples. Outsourced hosting is still a dependency to manage, not a reason to omit the service.

Keep the SMS scope and BCMS scope explicit even where they overlap. A booking service may be in both while payroll sits only in the wider BCMS. Determine relevant context changes, including whether climate change is relevant and whether interested parties have related requirements. Record decisions and review triggers rather than adopting a generic scope.

Catalogue, commitments and measurable service levels

A menu explains what a cafe offers, while a booking confirms what it promises you. Service descriptions and service commitments serve different purposes. A service catalogue identifies the service, intended customers, service owner, support hours, dependencies and available service options. It is not simply an inventory of servers. Kestrel lists booking submission, status lookup and support as customer-facing services and links each to its supporting components and suppliers. Check that the current catalogue matches what customers actually receive.

Service level agreements translate customer needs into agreed commitments, measurement methods, reporting periods, responsibilities and review routes. A 15-minute acknowledgement does not promise restoration in 15 minutes. For a monthly availability target, define the service window, denominator, exclusions and source of downtime records. Recalculate a sample instead of trusting a green dashboard.

Under ISO/IEC 20000-1 clause 8.3, examine customer and supplier relationships alongside service levels. Trace a customer commitment through internal support arrangements and supplier contracts. If a cloud contract promises only an eight-hour response, it does not demonstrate the ability to restore bookings within four hours. Escalate gaps, assign owners and track renegotiation or alternate capability.

Incident restoration is not problem resolution

Restarting a frozen phone may make it work again without explaining why it froze. Restoring service differs from removing the cause. Incident management focuses on resolving incidents and restoring agreed service. Capture detection time, impact, priority, escalation, communications, workaround and closure validation. Prioritization should reflect business impact and urgency, not the seniority of the caller. Major incidents need defined coordination and communication arrangements. Compare desk timestamps with monitoring and customer reports.

Problem management addresses causes of incidents and reduces recurrence. Repeated queue failures can justify a problem record while an incident is restored through a restart. Link related incidents, root-cause analysis, known errors, workarounds and proposed corrective changes. Closing the incident is not evidence that the underlying cause has been removed. ISO/IEC 20000-1 clause 8.6 provides a useful audit trail across these activities.

Change management controls evaluation, authorization and implementation of changes. Sample normal and emergency routes, impact analysis, testing, rollback, authorization and post-implementation review. Emergency handling can expedite approval under defined authority. It does not mean undocumented production changes. Link the queue fix to a controlled change and verify recurrence data after deployment.

Suppliers and operational control

A shop still owes you your order when its courier has a problem. Using a supplier does not remove the shop’s responsibility. Kestrel outsources infrastructure but retains responsibility for its SMS and customer outcomes. Keep named supplier owners, contracts, performance reviews, escalation contacts, interfaces and service dependencies. Verify how the service desk reaches the hosting team outside normal hours and what happens when a subcontractor is unavailable. A provider certificate alone does not establish the performance of Kestrel's configuration.

Choose a completed incident involving the host. Trace customer impact to escalation, supplier response, recovery, SLA reporting and improvement actions. Compare actual timings with customer and supplier commitments using the same clock and time zone. Test whether a service review acknowledged breaches rather than removing inconvenient records from the denominator.

Connect supplier changes to risk and continuity assessment. A migration to a second provider may still depend on the same identity service, network route or region. Record concentration and exit risks, capacity assumptions and evidence that alternate arrangements can operate. Audit design and actual operation, not only the existence of a contract.

BIA starts with impact over time

A broken fridge may cause little harm for minutes but spoil food after hours. Recovery decisions start with how harm grows over time. The business impact analysis (BIA), addressed in ISO 22301 clause 8.2.2, identifies prioritized activities, impacts over time, dependencies and recovery needs. Interview activity owners using a common disruption start point and realistic peak conditions. Capture customer harm, contractual penalties, regulatory effects and operational backlog, not just an arbitrary criticality score. Risk assessment separately considers disruption risks. Likelihood does not replace time-based impact analysis.

maximum tolerable period of disruption (MTPD) is the maximum tolerable period of disruption before impacts become unacceptable. recovery time objective (RTO) is the target time for resuming a specified activity at a defined minimum acceptable capacity. Set an RTO within the tolerable window, leaving time for validation and backlog recovery. A system booting is not the same as the business activity being usable at its required capacity.

recovery point objective (RPO) concerns the acceptable point to which data must be recovered, often expressed as maximum tolerable data loss in time. It is not an outage-duration limit and has no universal numeric ordering with RTO. A four-hour RTO and a 15-minute RPO can coexist. Compare RPO with replication, backup frequency, restore points and reconciliation evidence rather than just comparing it with MTPD.

Translate BIA entries into feasible strategies

A spare key is useful only if someone can reach it before you need to get inside. Recovery arrangements must meet the actual deadline. For this exercise, booking intake must resume at 50 percent normal throughput within four hours. It has an eight-hour MTPD and permits 15 minutes of data loss. Invoice reconciliation must resume at 25 percent throughput within 24 hours, has a 48-hour MTPD and permits four hours of data loss. These are Kestrel's approved exercise requirements, not numbers mandated by ISO. Record owners, units, dependencies and assumptions for each entry.

ISO 22301 clause 8.3 connects analysis to continuity strategies and solutions. Evaluate alternate staff, sites, technology, suppliers, communications and manual workarounds. Compare costs and available resources with recovery requirements. A booking alternate that needs six hours to provision cannot support a four-hour RTO without another arrangement. Replication every hour does not support a 15-minute RPO merely because failover is fast.

Before approving a strategy, test dependency timing and data integrity. If identity recovery takes five hours, a booking application that boots in one hour still misses its four-hour activity target. Define minimum capacity, staff access, customer communication, queue reconciliation and transition back to normal. Keep a documented gap and treatment decision where capability falls short. Do not silently change the BIA to fit an inadequate backup.

Plans and exercises produce different evidence

A fire escape plan shows the intended route. A drill shows whether people can use it. ISO 22301 clause 8.4 addresses continuity plans and procedures. Plans need activation criteria, authority, roles, communication, prioritized recovery steps, resource access, dependencies and return-to-normal arrangements. Assign alternates and offline access where the outage may disable the normal document store. Plan approval shows intended arrangements, not that those arrangements can meet recovery requirements.

An exercise programme under clause 8.5 should have defined objectives and scenarios relevant to the scope. A tabletop can test decisions and contact routes. It cannot alone prove a technical restore time or recovered data integrity. A timed recovery exercise can record disruption start, activity resumption at minimum capacity, restore point, transaction checks, exceptions and observers. Evaluate capabilities under clause 8.6 as well as recording attendance.

Kestrel's exercise starts at 09:00, restores usable booking intake at 50 percent throughput at 12:30 and recovers transactions to 08:50. Elapsed recovery is 3.5 hours and data loss is 10 minutes, meeting the four-hour and 15-minute targets for that scenario. Track gaps, owners and deadlines, retest failed objectives and feed outcomes into management review. One successful scenario does not prove resilience to all disruptions.

Integrated auditing keeps separate criteria visible

You can check two shopping lists on one trip without treating them as the same list. Shared audit work still needs separate requirements. Both standards use the shared management system clause structure. Context is in clause 4, leadership in 5, planning in 6, and support in 7. Operation is in 8, performance evaluation in 9 and improvement in 10. An integrated programme can share interviews, document control sampling, competence records, internal audit scheduling and management review logistics. Similar numbering does not make the operational requirements interchangeable.

Build a matrix with criterion, standard, scope, evidence source, sample and conclusion. A joint management review can address both systems if required inputs and outputs for each are demonstrably covered. Follow one outage across incident handling, customer reporting, BIA assumptions, plan activation and exercise improvements. Retain separate conclusions where only one set of criteria is satisfied.

Do not treat ISO/IEC 20000-1 service continuity practices as automatic conformity with all BCMS requirements, or an ISO 22301 certificate as proof of SLA achievement. Ensure auditor competence, objective evidence and independence for both scopes. State each nonconformity, a failure to meet a requirement, as a requirement, observed evidence and specific gap. Avoid grading severity from a single missing signature without context.

Close the loop with decision-ready findings

If a repair fails, note the problem, agree who will fix it, and check again. Findings need decisions and follow-up. Prepare an evidence pack with the sampled service catalogue version, SLA definitions and recalculation, and incident and problem links. Include change authorization, supplier performance, approved BIA, recovery strategy and exercise results. Preserve dates and scope so the reviewer can reproduce the conclusion. A template with empty fields is not evidence of operation.

Distinguish immediate correction from corrective action addressing the cause. Restoring a failed booking queue is correction. Eliminating the faulty retry behavior through a tested change may address recurrence. Verify effectiveness using subsequent operating evidence. Management review should decide on unresolved target gaps, resources and improvement priorities, with owners and deadlines.

In the labs, encode two approved BIA entries and challenge independent evidence claims. The YAML Ain’t Markup Language (YAML), a structured text format checker verifies this fixed fixture, not arbitrary BIA calculations or actual recovery capability. The review verdicts apply only to each stated claim. Accept a sufficient claim without inventing defects, and reject an overclaim even when its document carries a formal title.