What about every service that isn't an IBS?

What it is

The IBS register records which services passed the 5-criteria Important Business Service test, with inclusion rationale and dual sign-off. SAMA’s broader question is the one most banks fail: show me you considered the rest, not just what made the cut.

Service classification answers that. Every service in the bank’s SSoT gets a label, a written rationale, and a sign-off ceremony: the same audit-trail rigour the IBS register carries, applied to everything outside the IBS box.

Why it matters

The SAMA feedback that landed loudest in early MARSAD deployments was this: the IBS register is fine, but how do you know your CBS / Supporting / Non-critical assessment is complete? Where’s the trail?

A regulator reading an IBS register sees a list of customer-facing services. They cannot tell, from that list alone, whether the bank considered the underlying GL system, the regulatory-reporting platform, the identity provider, the settlement engine. If a CBS fails and the bank can’t point at the classification rationale, the conversation moves from operational to governance in the worst way.

The four classes

MARSAD’s four classes sit on top of SAMA’s ITGF 3.2.1-CR5 three-tier IT-asset taxonomy (mission critical / critical / non-critical), extended with an explicit out-of-scope state so the regulator-facing evidence pack shows the boundary of the assessment as well as its contents.

Each class carries an example bench so a reader new to the methodology can land, because the boundary cases are where the regulator’s eye lingers, and the rationale field is where the bank’s thinking lands in writing.

How MARSAD frames it

The classification ledger mirrors IBS admission’s shape deliberately. Same regulator vocabulary, same audit grain, same sign-off ceremony, just applied to the non-IBS half of the population:

• Append-only. Each new classification cycle writes a new row. The regulator can read the full evolution, not just current state.
• Rationale required. The DB rejects empty rationales. The disclosure floor is enforced.
• Dual sign-off. CRO + Service Owner. Per-role completeness CHECK so half-filled signatures can’t land. Server-side timestamps; no backdating.
• IBS dependencies as M:N. Each Supporting or Critical Business service can declare which IBS it underpins, with hard / soft kind. The IBS detail page renders this in reverse: each IBS gets a Supporting services strip showing every service that props it up.
• Versioned ledger. Superseding a classification mints a new decision; the prior one stays, immutable, with its sign-offs. The register never rewrites its own history.
• Evidence. Every decision is audit-logged, each service exports as a signed PDF + JSON pair, and the classification story lands in the audit dossier the bank hands SAMA.

What customers see

• The classification ledger on each service: current class, written rationale, and the full decision history with second-line challenge and CRO + Service Owner dual sign-off, realm-role gated where the bank enables it.
• A Supporting services view on every IBS: the reverse lens, showing what underpins each customer-facing service.
• Classification driving the model: the class narrows each service's obligations, feeds MVB candidate intake, and shapes the methodology rollups, so the label does work rather than sitting in a column.
• Signed evidence: per-service PDF + JSON export, the audit log underneath, and the dossier carrying the story to the regulator.
• Notifications: the CRO and Service Owner are notified in-app (and by email where the bank enables the channel) at each sign-off hand-off.