Important Business Services, the spine of operational resilience.

What it is

An Important Business Service (IBS) is a service whose disruption would meaningfully impact customers, the bank, or the financial system. SAMA's operational-resilience framework asks regulated entities to identify these services, justify the inclusion, and treat them as the unit of resilience work that everything else hangs off.

The IBS register is not a list of products and it isn't a list of applications. It sits one layer above both, close to how a customer would describe what the bank does for them.

Why it matters

SAMA's OpRes guidance treats the IBS register as the spine. Mapping, testing, declaring tolerance, and exporting evidence all reference back to it. A register that is incomplete, over-broad, or out of date weakens every downstream artefact.

It also matters for the bank's own clarity. When a CRO is asked which services would page someone at 3 a.m. and which can wait until business hours, the IBS register is meant to be the source of truth.

How MARSAD frames it

MARSAD uses a structured combined methodology, a register-style approach where each candidate service is evaluated against a set of consistent criteria, with the reasoning recorded alongside the inclusion decision. The criteria considered are the ones a reasonable regulator and a reasonable CRO would weigh together:

• Customer impact: how many customers, of what type, would feel a disruption.
• Financial impact: exposure of the bank, of its counterparties, and of the system. (Distinct from SAMA’s regulator-trigger usage of “material” in BCM 2.4 and the Outsourcing framework.)
• Sovereign mandate: services connected to SAMA-mandated rails (SARIE, SADAD, SPAN, mada, IPS, Etimad) sit in their own bracket and bypass the usual gating.
• Regulatory expectation: services that SAMA, the capital-markets authority, or the AML regime explicitly expect to be in scope.
• Operational continuity: services whose absence would cascade into other IBS.

The output is a register where every entry shows what got it over the line, who agreed, and when it was last reviewed. The "why" is preserved next to the "what" so the register reads well to a reviewer who joined the bank yesterday.

Where the input comes from

MARSAD reads service candidates from whichever Single Source of Truth the bank already maintains, typically the ServiceNow CMDB, an Enterprise Architecture tooling export (Sparx, BiZZdesign, Orbus, iServer), or an established service catalogue. The ingestion is one-way and read-only; MARSAD does not become the system of record for the service inventory. Customer scenarios + the IBS register are first-class on the MARSAD side, the underlying landscape stays where the bank already governs it.

The legacy interdependency-survey pattern (a spreadsheet of service × channel × application rows) is still supported as the fallback when an SSoT is thin or absent, typically for greenfield deployments or for product lines that haven't yet been onboarded into the CMDB. The structure MARSAD extracts is identical either way; the survey is scaffolding, not the methodology.

What customers see

• An IBS register with one row per service, ranked by outcome category and with the inclusion rationale visible.
• A construction wizard that records the methodology-correct admission for each candidate: per-criterion scoring on the four scored dimensions, the SMS-pathway bypass for sovereign-mandated rails, and a free-text rationale captured alongside the decision.
• A per-IBS detail page that shows the dependent processes, applications, third parties, and people, plus the tolerance commitments the bank has made for that service.
• A dual sign-off ledger on each admission decision: CRO + business-owner signature, timestamped, retained as the "who agreed" audit trail the methodology promises.
• A review cadence per admission, surfaced inline with an amber/rose due-date chip and reinforced by an email reminder when the next review falls due.
• A BIAN landscape view that places each IBS on a shared industry map so the register is comparable across banks and across regulator conversations.
• A change history showing when an IBS was added, retired, or rescoped, and on whose authority, useful when SAMA asks "why has this register changed since last cycle?"