| Key Takeaways |
| Important business services mapping identifies the services whose disruption would cause intolerable harm to customers, markets, or the firm itself. |
| UK regulators (PRA, FCA) required firms to complete IBS mapping and testing within impact tolerances by 31 March 2025, with full operational resilience compliance due by March 2025. |
| A structured six-step process moves organizations from service identification through dependency mapping to continuous improvement. |
| Effective mapping covers five resource dimensions: people, processes, technology, data, and third-party providers. |
| Impact tolerances set the maximum acceptable disruption for each important business service, measured by time, volume, and customer harm metrics. |
| Organizations that embed IBS mapping into enterprise risk management reduce recovery times and improve regulatory confidence. |
| Common failures include mapping at too high a level, ignoring cross-service dependencies, and treating the exercise as a one-time compliance project. |
Gartner estimates that IT system downtime costs organizations an average of $5,600 per minute, with enterprise-level outages regularly exceeding $300,000 per hour.
Yet many organizations still cannot answer a basic question: which business services truly matter, and what keeps them running? Important business services mapping provides the answer.
This structured discipline forces organizations to look beyond individual assets and systems, shifting focus to the end-to-end services that customers, counterparties, and markets depend on.
Regulators have accelerated the urgency. The Bank of England, the FCA, and the PRA required financial institutions to identify important business services, set impact tolerances, and complete mapping and testing by 31 March 2025.
The EU’s Digital Operational Resilience Act (DORA) imposed comparable obligations on the entire European financial services sector from January 2025.
Beyond financial services, organizations in healthcare, critical infrastructure, and government are adopting similar approaches anchored in ISO 22301 and ISO 31000 principles.
This guide walks through the full important business services mapping process in six practical steps. Each step includes tables, frameworks, and worked examples you can adapt to your organization.
By the end, you will have a clear methodology for identifying critical services, mapping their dependencies, setting tolerances, and embedding the process into your enterprise risk management and business continuity management programs.
Figure 1: Average hourly cost of service disruption by organization size. Sources: Gartner, ITIC, Splunk/Oxford Economics (2024).
What Is Important Business Services Mapping?
An important business service (IBS) is any service provided to an external end user or market participant whose disruption could cause intolerable harm.
The Bank of England defines an IBS as a service that, if disrupted, could pose a risk to a firm’s safety and soundness or to the financial stability of the UK.
The concept extends beyond financial services: any organization can define its critical external-facing services using the same logic.
Important business services mapping is the process of tracing each IBS from customer touchpoint back through every resource, process, technology component, data flow, and third-party dependency that supports delivery.
The goal is to build a complete, end-to-end picture so the organization understands exactly what must function, and to what standard, for each service to remain available.
This is fundamentally different from traditional business impact analysis, which typically starts from internal processes rather than external service outcomes.
| Dimension | Traditional BIA | IBS Mapping |
| Starting point | Internal processes and departments | External services delivered to customers/markets |
| Scope | Individual business units | End-to-end, cross-functional service chains |
| Focus | Recovery time objectives (RTO/RPO) | Impact tolerances measured by customer harm |
| Dependencies | Often limited to direct IT systems | People, processes, technology, data, third parties |
| Regulatory driver | ISO 22301, sector-specific rules | PRA SS1/21, FCA PS21/3, DORA, Basel III.1 |
| Output | BIA reports and recovery plans | Service maps, dependency registers, tolerance metrics |
Regulatory Landscape Driving IBS Mapping
Regulators across multiple jurisdictions now mandate some form of important business services mapping. Understanding these requirements helps organizations scope their programs correctly and demonstrate compliance to supervisors.
The table below summarizes the primary regulatory frameworks and their mapping expectations.
Organizations operating in the operational risk management space should track these requirements as part of their regulatory risk management program.
| Framework | Jurisdiction | Key Mapping Requirements | Compliance Date |
| PRA SS1/21 / FCA PS21/3 | United Kingdom | Identify IBS, set impact tolerances, map resources, test within tolerances | 31 March 2025 |
| DORA (EU 2022/2554) | European Union | Map ICT dependencies for critical/important functions, test digital resilience | 17 January 2025 |
| Basel III.1 OpRisk | Global (BCBS) | Identify critical operations, map third-party dependencies | Phased from 2025 |
| APRA CPS 230 | Australia | Define critical operations, map material service providers, test disruption scenarios | 1 July 2025 |
| ISO 22301:2019 | International | BIA-driven identification of critical activities and supporting resources | Voluntary (certification) |
| NIST CSF 2.0 | United States | Map critical infrastructure dependencies under Identify function | Ongoing (voluntary) |
The Six-Step IBS Mapping Process
A practical important business services mapping program follows six sequential steps. Each step builds on the previous one, creating a layered understanding of service delivery and vulnerability.
Organizations with mature risk management processes can often accelerate Steps 1-2 by leveraging existing BIA data and risk registers.
Figure 2: The six-step important business services mapping process with typical durations per phase.
| Step | Activity | Key Output | Typical Duration |
| 1 | Identify important business services | IBS inventory with owner assignments | 2-4 weeks |
| 2 | Set impact tolerances | Tolerance thresholds per IBS (time, volume, customer harm) | 2-3 weeks |
| 3 | Map resources and dependencies | End-to-end service dependency maps | 4-8 weeks |
| 4 | Assess vulnerabilities and scenarios | Vulnerability register, scenario library | 3-4 weeks |
| 5 | Test within impact tolerances | Test results, gap analysis, remediation plan | 4-6 weeks |
| 6 | Monitor, report, and improve | KRI dashboards, board reports, continuous update cycle | Ongoing |
Step 1: Identify Important Business Services
Start by cataloguing every service the organization delivers to external customers, counterparties, or market participants. This requires a top-down perspective: begin with the customer experience, not internal org charts.
Engage senior leadership and front-line business owners in workshops to answer three questions: What services do we provide? Who depends on them? What harm results if they fail?
Apply materiality filters to narrow the list. A service qualifies as an IBS when its disruption could cause significant harm to consumers, threaten market integrity, endanger the firm’s viability, or trigger regulatory sanctions.
Financial services firms should align with the PRA’s definition: a service that, if disrupted, could pose a risk to the firm’s safety and soundness.
Non-financial organizations can adapt the concept using business risk assessment criteria tied to strategic objectives and stakeholder obligations.
Document each IBS with a service description, the primary customer segment, the responsible business owner, and a preliminary harm assessment.
A robust risk taxonomy helps standardize the language used across different business units during this step.
Step 2: Set Impact Tolerances
Impact tolerances define the maximum acceptable level of disruption for each IBS. Unlike recovery time objectives (RTOs), which measure internal recovery targets, impact tolerances measure customer-facing harm.
The PRA describes them as the point at which a disruption to an IBS would cause intolerable levels of harm to external stakeholders or risk to market integrity.
Define tolerances across three dimensions: time (maximum duration of disruption), volume (maximum transactions or customers affected), and harm (severity of financial, data, or safety consequences).
Each tolerance should reference a severe-but-plausible scenario. Organizations with mature risk appetite statements can derive impact tolerances directly from board-approved risk appetite.
| IBS Example | Time Tolerance | Volume Tolerance | Harm Level | Scenario Basis |
| Retail payments processing | Max 4 hours | < 50,000 customers | High | Core payment platform failure |
| Customer onboarding | Max 24 hours | < 500 new applications | Medium | Identity verification outage |
| Claims settlement | Max 48 hours | < 1,000 claims | Medium-High | Third-party data feed failure |
| Treasury and liquidity management | Max 2 hours | < 10 counterparties | Critical | SWIFT connectivity loss |
| Regulatory reporting | Max 24 hours | All scheduled reports | High | Data warehouse corruption |
Step 3: Map Resources and Dependencies
This is the core of important business services mapping. Trace each IBS from the customer interaction point back through every resource layer that supports delivery. Mapping should cover five dimensions: people (roles, skills, locations), processes (workflows, handoffs, decision points), technology (applications, infrastructure, networks), data (sources, flows, storage, quality requirements), and third-party providers (outsourced functions, vendors, utilities).
Use both top-down and bottom-up approaches. Top-down mapping starts with the IBS and asks: what processes support this service?
Bottom-up mapping starts with known assets and asks: which services depend on this resource? Combining both approaches catches dependencies that either method alone would miss.
Organizations managing third-party risk should pay particular attention to external dependencies, as these represent the boundaries where the organization’s direct control ends.
| Dimension | What to Map | Key Questions | Example Dependencies |
| People | Roles, headcount, skill concentrations, locations | Who performs each step? Where are single points of failure? | Specialized treasury traders, compliance sign-off staff |
| Processes | End-to-end workflows, manual steps, escalation paths | Where are handoffs? Which steps are manual vs. automated? | Customer identity verification, exception handling |
| Technology | Applications, servers, networks, cloud services | What is the tech stack? Where are shared components? | Core banking platform, API gateway, SWIFT network |
| Data | Sources, formats, flows, storage, quality controls | Where does data originate? How does it move between systems? | Customer master data, market price feeds, regulatory data |
| Third Parties | Vendors, outsourcers, utilities, shared services | Which providers are critical? What SLAs apply? Are alternatives available? | Cloud provider, payment processor, KYC vendor |
Figure 3: Radar chart comparing dependency intensity across five resource dimensions for two example IBS. Payments processing shows heavier technology and data dependency, while customer onboarding is more people-intensive.
Step 4: Assess Vulnerabilities and Scenarios
With dependency maps in place, identify vulnerabilities: points where a failure, degradation, or attack could disrupt service delivery beyond the impact tolerance.
Common vulnerability patterns include single points of failure (one person, one system, one vendor), concentration risk (multiple IBS depending on the same resource), and substitutability gaps (no fallback for a critical process).
Develop a scenario library of severe-but-plausible disruptions for each IBS. Scenarios should cover internal failures (technology outage, key-person loss), external events (cyber attack, third-party failure), and systemic shocks (widespread outage, pandemic-scale disruption).
A structured risk assessment process helps prioritize scenarios by likelihood and potential harm. Use scenario analysis and stress testing techniques to quantify the potential impact of each scenario on service delivery.
Step 5: Test Within Impact Tolerances
Testing validates whether the organization can actually remain within impact tolerances during disruption.
Employ a progression of test types: desktop walkthroughs confirm the logic of dependency maps and response procedures, simulation exercises test human decision-making under pressure, and technical tests (failover, switch-over, data recovery) validate technology resilience.
Document test results against each IBS impact tolerance. Where testing reveals that the organization would breach a tolerance, capture the gap in a remediation register with a risk owner, root cause analysis, and a SMART remediation action plan.
Organizations already running business continuity plan exercises can extend their existing exercise program to cover IBS-specific scenarios.
Regulatory expectations under the PRA’s SS1/21 require firms to demonstrate testing at a level of sophistication that provides assurance about the ability to stay within impact tolerances.
Step 6: Monitor, Report, and Improve
Important business services mapping is not a one-time project. Services evolve, dependencies change, new risks emerge, and technology landscapes shift. Build a continuous monitoring loop using key risk indicators tailored to each IBS.
Define thresholds that trigger escalation when a service approaches its impact tolerance. Integrate IBS monitoring into your KRI dashboard alongside enterprise-level risk reporting.
Report to the board at least quarterly. Board packs should show the status of each IBS, recent test outcomes, open remediation actions, and any tolerance breaches.
Use risk quantification techniques to translate operational resilience data into financial impact language that directors understand.
Update dependency maps whenever a material change occurs: new vendor onboarding, system migration, organizational restructure, or regulatory change.
Key Risk Indicators for IBS Monitoring
Tracking the right KRIs ensures that important business services remain within their impact tolerances between formal testing cycles.
The table below provides starter KRIs across each resource dimension. Adapt thresholds to your organization’s risk appetite and service-level commitments.
Understanding the difference between leading and lagging KRIs helps balance early-warning signals with outcome-based measures.
| KRI | Measurement | Green | Amber | Red |
| Service availability uptime | % availability per IBS per month | > 99.9% | 99.5-99.9% | < 99.5% |
| Mean time to recover (MTTR) | Average recovery time per incident | < 30 min | 30-120 min | > 120 min |
| Single-point-of-failure count | Number of SPOFs per IBS | 0 | 1-2 | > 2 |
| Third-party SLA breach rate | % of third-party SLA breaches per quarter | < 2% | 2-5% | > 5% |
| Dependency map currency | Days since last map update | < 90 days | 90-180 days | > 180 days |
| Tolerance test pass rate | % of IBS passing tolerance tests | > 95% | 80-95% | < 80% |
| Key-person dependency ratio | Critical roles with < 2 trained substitutes | 0 | 1-3 | > 3 |
| Change impact assessment coverage | % of material changes with IBS impact review | 100% | 80-99% | < 80% |
Integrating IBS Mapping with Enterprise Risk Management
Important business services mapping works best when embedded within the organization’s broader enterprise risk management framework.
Treating IBS mapping as an isolated compliance exercise creates duplication and gaps. The three lines model provides the governance backbone: first-line business owners maintain service maps and monitor KRIs, second-line risk and compliance functions set standards and challenge, and third-line internal audit provides independent assurance over the mapping and testing program.
Align IBS mapping outputs with existing risk tools. Service-level vulnerabilities should feed into the risk register.
Remediation actions should be tracked through the same issues and actions register used for risk treatment. Scenario analysis results should inform the organization’s risk assessment matrix and board risk reporting.
The RCSA process is a natural integration point: when business units perform their periodic risk and control self-assessments, include questions about IBS dependency changes, tolerance breaches, and outstanding remediation actions.
Implementation Roadmap
The following roadmap outlines a practical timeline for organizations launching or refreshing their important business services mapping program.
Adjust durations based on organizational size and existing maturity.
| Phase | Actions | Deliverables | Success Metrics |
| Days 1-30: Foundation | Appoint IBS mapping sponsor and working group. Conduct initial workshops with business owners to identify candidate IBS. Gather existing BIA data, risk registers, and service catalogues. Establish mapping methodology and tooling. | IBS candidate list. Mapping methodology document. Stakeholder RACI. Project plan with milestones. | Sponsor appointed. 80%+ of business units represented in workshops. Methodology approved by risk committee. |
| Days 31-60: Core Mapping | Finalize IBS inventory. Set draft impact tolerances for each IBS. Perform end-to-end dependency mapping across all five resource dimensions. Identify single points of failure and concentration risks. Begin scenario development. | Approved IBS register. Impact tolerance schedule. Dependency maps per IBS. Vulnerability register. Draft scenario library. | All IBS mapped to at least 3 dependency dimensions. Impact tolerances defined for 100% of IBS. SPOF count documented. |
| Days 61-90: Testing and Governance | Execute initial tolerance testing (desktop and simulation). Capture remediation actions for tolerance breaches. Build KRI monitoring framework. Prepare first board report on IBS mapping status. Establish ongoing governance cadence. | Test results report. Remediation action register. KRI dashboard. Board-ready IBS status report. Governance terms of reference. | First round of testing completed for all IBS. Remediation plan in place for each breach. Board report delivered. Quarterly review cycle scheduled. |
Pitfalls and How to Avoid Them
Organizations new to important business services mapping frequently stumble on the same issues.
The table below captures the most common pitfalls, their root causes, and practical remedies based on lessons observed across regulatory reviews and industry practice.
| Pitfall | Root Cause | Remedy |
| Mapping at too high a level | Treating IBS mapping as a strategic exercise without operational detail. Dependencies are captured generically rather than specifically. | Mandate granularity standards: map to specific applications, named roles, and individual vendor contracts, not categories. |
| Ignoring cross-service dependencies | Each IBS mapped in isolation without examining shared resources. A failure in a shared component cascades across multiple services undetected. | Run cross-service dependency analysis after individual mapping. Build a shared-resource register that flags concentration risk. |
| Treating mapping as a one-time compliance project | Mapping completed to meet a regulatory deadline, then left static. Dependency maps become outdated within months as technology and vendors change. | Embed map maintenance into change management. Require IBS impact assessment for every material change request. |
| Setting impact tolerances without data | Tolerances chosen based on management intuition rather than quantitative analysis of disruption scenarios and customer harm thresholds. | Use historical incident data, scenario modeling, and customer feedback to calibrate tolerances. Stress test using Monte Carlo simulation where feasible. |
| Under-mapping third-party dependencies | Internal processes mapped in detail while outsourced and vendor-dependent activities receive superficial treatment. | Apply the same mapping rigor to third-party activities. Require vendors to provide their own dependency data and participate in testing. |
| Siloed ownership without governance | IBS mapping owned entirely by IT or operational risk, without engagement from business lines, legal, compliance, or the board. | Establish a cross-functional IBS steering committee with board-level sponsorship. Assign first-line business owners for each IBS. |
| No link between mapping and testing | Dependency maps exist as documents, but testing does not use them to design scenarios or validate completeness. | Design test scenarios directly from dependency maps. Validate that test coverage addresses all mapped SPOFs and concentration risks. |
Figure 4: IBS mapping maturity model. Regulators expect organizations to operate at Level 3 (Defined) or above by 2025. Level 5 organizations use automated dependency discovery and continuous testing.
Looking Ahead: Trends for 2025-2027
The operational resilience landscape continues to evolve rapidly. Several trends will shape how organizations approach important business services mapping over the next two years.
Regulatory convergence is accelerating. The UK’s PRA framework, the EU’s DORA, Australia’s CPS 230, and the Basel Committee’s operational resilience principles share common DNA: identify critical services, map dependencies, set tolerances, and test.
Organizations operating across borders will increasingly adopt a single, harmonized IBS mapping methodology that satisfies multiple regulators simultaneously. This creates an opportunity to reduce duplication and build a genuinely integrated resilience function rather than maintaining separate compliance tracks.
Technology-enabled mapping is replacing manual effort. Purpose-built resilience platforms now automate dependency discovery by scanning configuration management databases, network topology, and cloud service configurations.
These tools maintain living dependency maps that update automatically when infrastructure changes, reducing the staleness problem that plagues manual approaches.
Organizations investing in ERM technology should evaluate whether their platforms support IBS-level mapping and reporting natively.
The scope of IBS mapping is expanding beyond financial services. Healthcare regulators, energy sector authorities, and government agencies are adopting service-based resilience models.
The concept of mapping what matters to external stakeholders translates directly from payments systems to patient care pathways, power grid operations, and citizen-facing government services.
Organizations in these sectors that adopt IBS mapping proactively will be better prepared when formal regulatory mandates arrive. Those building their GRC frameworks today should include IBS mapping as a core component.
Ready to map your important business services? Visit riskpublishing.com for step-by-step frameworks, ready-to-use templates, and expert risk management consulting services to accelerate your operational resilience program.
References
1. Bank of England – Operational Resilience of the Financial Sector – Regulatory framework for operational resilience in the UK financial sector.
2. FCA PS21/3 – Building Operational Resilience – FCA policy statement on operational resilience requirements for UK firms.
3. PRA SS1/21 – Impact Tolerances for Important Business Services – PRA supervisory statement on setting and testing impact tolerances.
4. ISO 22301:2019 – Business Continuity Management Systems – International standard for business continuity management systems requirements.
5. European Commission – Digital Operational Resilience Act (DORA) – EU regulation on digital operational resilience for the financial sector.
6. APRA CPS 230 – Operational Risk Management – Australian prudential standard on operational risk and business continuity.
7. Basel Committee on Banking Supervision – Principles for Operational Resilience – BCBS principles for sound operational resilience practices.
8. NIST Cybersecurity Framework 2.0 – US framework for improving cybersecurity risk management across critical infrastructure.
9. Splunk and Oxford Economics – The Hidden Costs of Downtime (2024) – Research on the financial impact of unplanned downtime on Global 2000 companies.
10. Gartner – Cost of IT Downtime – Industry benchmark data on average downtime costs per minute and per hour.
11. ISO 31000:2018 – Risk Management Guidelines – International standard providing principles, framework, and process for managing risk.
12. BSI – ISO 22301 Business Continuity Management – Guidance on implementing business continuity management systems.
13. Protecht Group – Mapping Important Business Services – Practical guidance on IBS mapping approaches for operational resilience.
14. Disaster Recovery Journal – Defining Important Business Services – Article on prioritizing services for organizational resilience.
Chris Ekai is a Risk Management expert with over 10 years of experience in the field. He has a Master’s(MSc) degree in Risk Management from University of Portsmouth and is a CPA and Finance professional. He currently works as a Content Manager at Risk Publishing, writing about Enterprise Risk Management, Business Continuity Management and Project Management.