FINMA Operational Resilience and CMDB Accuracy for Zurich Banking and Insurance Groups

Zurich groups already run resilience programs, yet FINMA Circular 2023/1 asks a harder question. Can the group prove which systems support each critical function across the full value chain? Policy binders pass reviews. Recovery calls fail when the configuration record is stale, the owner is unclear, or a cloud dependency sits outside the map. This guide shows how banking and insurance groups in Zurich connect CMDB accuracy to operational resilience without replacing the ITSM platform.

Groups in Zurich carry both banking and insurance operations under one governance roof. The regulator expects each unit to identify critical functions, map supporting resources, and restore service within tolerance. A discovery-sourced CMDB makes that proof possible. It links each function to configuration items, owners, and dependencies on scheduled cycles. For deeper background on the category, start with Trusted Runtime Truth.

What FINMA Circular 2023/1 expects from banks and insurers

FINMA published the fully revised Circular 2023/1 on operational risks and resilience in December 2022. The circular defines requirements for banks, securities dealers, and insurance supervised entities on managing operational risk and proving resilience. Supervised groups had to operationalize the framework through 2023 with application from January 2024 for core duties. FINMA Guidance 05/2025, published 10 November 2025, confirmed 1 January 2026 as the hard deadline for full compliance — the two-year transition window from the 2024 initial-inventory milestone is now closing. Zurich groups still working from a 2024-era inventory are already behind. Zurich groups with cross-border branches face the same test in every booking center.

The circular focuses on the full value chain. Resilience does not stop at the data center boundary. It covers outsourced services, cloud workloads on AWS and Azure, and third party links that carry payment, trading, and policy administration traffic. Deloitte Switzerland notes the circular puts resilience along the full value chain at the center of the program.

Critical functions need named owners, mapped resources, and tested recovery paths. Boards must see tolerance levels and disruption scenarios in plain language. Risk teams must show controls actually operate. That evidence chain breaks when asset records live in sheets, when cloud accounts sit outside discovery, or when service maps age between audits.

The circular sets cadence, not only scope. The critical function inventory needs board approval and a review at least once a year, and resilience reporting to the board and senior management follows the same annual minimum. Requirements scale with the institution under FINMA’s proportionality principle, but Grant Thornton Switzerland notes banks and securities firms fall squarely in scope regardless of size. A group already running quarterly drills clears the annual floor with room to spare. A group still working from an undated binder falls short of it before an examiner asks a single technical question.

Groups should treat Circular 2023/1 as an evidence program rather than a document program. Each critical function needs a living record. Each record needs a source. Discovery supplies the source. Attestation supplies the sign off. The combination satisfies auditors who ask for proof rather than intent.

Why CMDB accuracy decides resilience outcomes in Zurich estates

Zurich estates mix core banking hosts, insurance policy platforms, payment gateways, and hybrid cloud services. Mergers add duplicate records. Outsourcing adds blind accounts.

Cloud migration adds short-lived workloads that sheets never catch. The CMDB becomes the central place where these layers meet for most Zurich groups. When it drifts, resilience plans drift with it.

Stale configuration data breaks resilience evidence in three places: recovery runbooks page the wrong owner, change review misses downstream policy or settlement services, and incident response cannot draw the blast radius for a failed database or region.

Each failure extends outage time past tolerance. Each extension becomes a supervisory finding.

The exposure is not abstract. New Relic’s 2025 Observability Forecast found financial services firms reporting high-business-impact outages at $1.8 million per hour on average, in line with the $1.7 million cross-industry mean. Network failures, software deployment issues, and environment changes are the leading causes. All three causes trace back to resources a CMDB is supposed to track. A board does not need to guess at the stakes behind a stale configuration record once that figure is on the table. The same board tends to ask for proof the number is shrinking quarter over quarter, not acknowledged once and set aside.

Accurate configuration data changes the sequence. Discovery finds assets across on-premises estates and cloud accounts on scheduled cycles. Reconciliation merges duplicates by serial number or cloud instance ID, not hostname.

Service definitions link each configuration item to a critical function. Owners attest on a standing cadence. Recovery teams then start from a record that matches production.

This article differs from the Swiss revised data protection piece on nFADP visibility. That article covers personal data scope and subject rights readiness. This article covers Circular 2023/1 resilience proof for critical functions. The nFADP program asks what personal data exists and where it sits. The FINMA program asks whether critical services recover within tolerance and how the group proves it. It also differs from Virima’s Zurich data-residency CMDB coverage, which addresses where data physically resides under cross-border hosting rules — a data-location question, not a function-recovery question.

How to link critical functions to configuration data that auditors trust

Start with the function register. A critical function register links each banking or insurance service — payment processing, securities settlement, core policy administration — to its tolerance time, named owner, and supporting configuration items. Keep the register short enough for board review and detailed enough for recovery use. FINMA requires board approval of this register at least annually, the same cadence established in the circular itself.

Map each function to supporting configuration items:

• Servers, databases, and middleware
• Network paths
• Cloud accounts
• Vendor services

State the dependency type for each link. Runs on, connects to, and processed by each tell a different recovery story. Service dependency mapping holds these links in one place.

Assign one owner per function and one technical contact per supporting item. Vacant owner fields are findings waiting to happen. Discovery confirms a configuration item exists; attestation confirms a human still owns it. FINMA’s evidence standard needs both — automated discovery alone cannot prove ownership, and manual attestation alone cannot prove currency. Business owners confirm the function list each quarter. Technical owners confirm supporting items after material changes.

Test the chain with scenario drills. Take one database offline in staging and trace the affected functions. Time owner paging, failover execution, and customer communication. Record gaps against the configuration record, not against memory. Feed corrections back into discovery scope and service definitions before the next audit window.

What good looks like for Zurich banking and insurance groups

Good looks like one function register with discovery-sourced, owner-attested links. Each critical function opens to its supporting configuration items, current owners, recent changes, and last test result. Auditors click through instead of sampling binders. Boards see tolerance posture by function, not server counts. Operations teams run drills from the same record that audit reviews use. ViVID™ service maps render this view visually, showing blast radius and root cause context in the same map auditors use for evidence.

Discovery scope must cover the full estate. A FINMA-ready configuration record needs cloud accounts and vendor-connected segments, not just on-premises hosts — Circular 2023/1 extends resilience scope across the full value chain, including outsourced and cloud-hosted services. Agentless scanning finds network reachable assets. Optional agents cover remote endpoints. Cloud connectors cover AWS and Azure accounts used by group IT. Bi-directional sync feeds the ITSM system of engagement without creating a second source of record. For the full list of supported ITSM platforms, see the integrations hub.

Vulnerability context belongs on the same map for Windows Server configuration items through NVD lookups. Teams prioritize patches by function impact rather than raw score. Change review checks the dependency path before approval. Incident response starts from the affected function instead of a bare host alert. Recovery evidence accumulates as a byproduct of operations rather than a separate audit project.

Groups that sustain this posture scope discovery to every account that can carry a critical function, keep service definitions current when platforms migrate, and attest ownership on schedule with dated exceptions. FINMA reviewers recognize the pattern because the proof reads the same in every drill.

Where to start before the next evidence request

Confirm the function register covers both banking and insurance critical services. Close owner gaps before tooling debates.

• Extend discovery to cloud accounts and vendor-connected segments that carry settlement or policy traffic
• Reconcile duplicates on durable keys
• Link each function to its supporting items with typed dependencies
• Schedule one drill per quarter and record results against the register

Before any tooling conversation, write down one critical function as the pilot candidate: its name, expected recovery tolerance, and current owner list. That gives a scoped starting point for closing discovery gaps — with or without outside help — rather than a blanket estate-wide rebuild.

Prove recovery from the record that runs it

Resilience evidence should read like operations rather than paperwork. One register, linked configuration items, named owners, and dated drills carry more weight than thick binders.

Frequently Asked Questions

See how a discovery-sourced CMDB keeps one critical function’s record current between audits, then bring your own tolerance targets to a scoped demo.