SOC for banks in Switzerland: FINMA, DORA and bank-specific detection

A Swiss bank operates under two regulatory regimes: FINMA Guidance 05/2020 and 03/2024 for Swiss supervision and DORA when EU subsidiaries or EU customers are involved. FINMA requires an initial notification of material cyber attacks within 24 hours of discovery and a full report within 72 hours. DORA requires a 4/24-hour initial notification, a 72-hour intermediate report and a 1-month final report. A SOC for banks must meet both regimes' requirements within a single operation and cover bank-specific use cases. These include SWIFT, e-banking and card-channel abuse, insider activity in core banking systems, account takeover and payment anomalies. Banks that do not consolidate these functions in one SOC run three separate structures with three times the effort.

SOC as a ServiceAllSOC for banks in Switzerland: FINMA, DORA and bank-specific detection

How this compares to neighbouring topics

This page bundles the bank-specific angle on a SOC. For the pure FINMA angle, see SOC & FINMA requirements. For DORA detail, see DORA requirements for the SOC. For EU subsidiaries, see NIS2 for Swiss subsidiaries. For operations, see SOC as a Service Switzerland.

Regulatory stack of a Swiss bank

Regime	When it bites	Notification clock	Addressee
FINMA Guidance 05/2020 / 03/2024	Always, for every FINMA-supervised bank in Switzerland.	24-hour initial notification from discovery, full report within 72 hours of the initial notification, plus follow-ups on new developments.	FINMA.
ISG Art. 74a-74f	When the bank is classified as an operator of critical infrastructure.	24 hours after discovery.	BACS.
DORA (EU 2022/2554)	For any EU subsidiary or EU authorisation of the group.	4h initial notification after classification, 24h deadline after awareness, 72h intermediate report after initial notification, 1-month final report.	Competent EU authority.
revDSG Art. 24	On a breach of personal-data protection.	As soon as possible.	FDPIC, affected data subjects where required.

A single ransomware event can trigger all four notifications at once. The SOC must track the reporting clock per regime separately.

Bank-specific detection use cases

SWIFT abuse: anomalies in Alliance Access logins, payment-message patterns (MT103/MT202), unusual beneficiary countries, off-hours transfers.
e-banking channel: session takeover, device change without re-enrolment, clustered MFA failures, push-fatigue patterns, JavaScript injection signals.
Card channel: 3-D Secure bypass, card-not-present anomalies, BIN attacks, authorisation-rate anomalies per terminal.
Core-banking insider: privileged access to account and portfolio master data, bulk exports, breaches of client-secrecy boundaries, four-eyes-principle bypass.
Payment fraud: unusual beneficiary changes, instant-payment anomalies, business email compromise with invoice manipulation.
Third-party access: entry points from core-IT providers, cloud providers and SaaS core-banking modules, tied to the DORA register.
OT and branch security: ATMs, video surveillance, physical access systems, where integrated into the ICT perimeter.

Why a stock SOC is not enough here

These use cases demand banking domain knowledge on the analyst team, not only log craftsmanship. Alliance Access logs, ISO-20022 message patterns and core-banking audit trails are not off-the-shelf connectors but customer-specific integration work.

Operating setup that serves FINMA and DORA at once

24/7 shift operation compatible with either supervisory time zone, with documented handovers.
One single classification decision tree that scores incident materiality against both FINMA materiality (Guidance 05/2020) and the DORA RTS criteria.
Separate notification templates and clocks per regime, drawing on the same evidence trail.
ICT third-party register per DORA Art. 30 as the leading list; FINMA outsourcing inventories derive from it.
The CISO and SOC provider jointly plan DORA TLPT; results also feed into FINMA reviews.
Reporting to the board and audit committee covers KPIs (MTTD, MTTR), notifications, critical third-party signals and training records.

On MTTD/MTTR, see MTTD and MTTR in a SOC. On managed versus in-house in a banking context, see Managed SOC vs. in-house. For onboarding, see SOC onboarding in Switzerland.

Outsourcing a bank SOC to an external provider

FINMA treats SOC outsourcing as material outsourcing when cyber detection runs through it. Due diligence, instruction and audit rights, contingency and exit provisions are mandatory.
DORA contract clauses (Art. 30) are additionally required for EU subsidiaries and cover access, audit, sub-outsourcing and termination rights.
Concentration risk: one provider must not simultaneously be the only detection, only response and only cloud instance. At least one axis must remain diversified.
Data location: log and case data for the bank stay within a documented jurisdiction; cross-border processing requires explicit consent and contract clauses.
Exit strategy: a documented path back to in-house or to another provider, including handover of playbooks, rules and historical cases.

Common purchase mistake

The tempting option is a single provider for everything: SIEM platform, SOC operation, response and backup. Both supervisors monitor this regulatory concentration risk. A clean setup separates the detection platform from the response provider, or anchors that separation contractually.

Placement in SOC operations

See SOC as a Service Switzerland for how a FINMA- and DORA-capable bank SOC runs within a single operation.

Legal basis and sources

FINMA Guidance 05/2020 on reporting cyber attacks (Art. 29 para. 2 FINMASA): finma.ch
FINMA Guidance 03/2024 refining the reporting duty: finma.ch
FINMA Circular 2023/1 «Operational risks and resilience»: finma.ch
FINMASA (SR 956.1): Fedlex
ISG reporting duty at the National Cyber Security Centre (NCSC) including routing: bacs.admin.ch
Reporting data security breaches to the FDPIC: edoeb.admin.ch
DORA (EU) 2022/2554, official overview: EIOPA

Frequently asked questions

Does every Swiss bank need its own SOC?

No. FINMA requires the capability, not its own installation. Smaller institutions typically meet the requirements through a managed SOC with documented outsourcing; larger banks run an in-house or co-managed core.

Can a managed provider have access to SWIFT systems?

A managed provider can access SWIFT systems if the bank documents the required controls. These include a role model, the four-eyes principle on the provider side and logging of all access. The bank must also document inclusion in the outsourcing and ICT third-party register. Without this evidence, the arrangement is unacceptable from a supervisory perspective.

How often must a bank run TLPT?

DORA requires significant entities to conduct TLPT at least every three years. The competent EU authority determines who is significant. FINMA additionally expects event-driven testing and regular purple-team exercises.

How does outsourcing management fit in?

It maintains the consolidated view of ICT third parties, coordinates contracts, audits and exit strategies and works closely with the SOC. The SOC provides the operational view of provider activity; outsourcing management provides the contractual view.

What is the biggest detection blind spot at banks?

In practice, the biggest blind spot is insider activity in core-banking and custody systems. Perimeter and endpoint detection are usually mature. However, banks too rarely feed audit trails from Avaloq, Finnova, Temenos or comparable systems into the SOC. Closing that gap brings both regulatory and operational benefits.

Continue reading in this cluster

SOC & FINMA: What a Swiss financial institution needs to satisfy the supervisor

FINMA requires supervised institutions to document detection and response capabilities and demonstrate operational resilience. Institutions must report material cyber incidents within 24 hours of assessment. FINMA Circular 2023/1 Operational Risks and Resilience is the authoritative reference. It has been in force since 1 Jan 2024 and replaced Circular 2008/21. A SOC delivers 24/7 detection, a ticket and evidence trail and audit-ready evidence. Institutions need all three to meet the requirements reliably.

DORA requirements for the SOC: what the Digital Operational Resilience Act means in operations

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) requires EU financial entities to maintain a continuous ICT risk and resilience framework. It has applied since 17 January 2025. For Swiss groups, DORA applies directly through EU subsidiaries and indirectly through contracts with EU financial customers. These subsidiaries include banks, insurers, payment institutions, crypto-asset service providers, CSDs, CCPs and trading venues. A SOC delivers four DORA cornerstones. It provides continuous ICT detection and classified incident notification to the competent authority under the 24-hour / 72-hour / 1-month cascade. It also provides the evidence trail for supervisory review and the operational foundation for threat-led penetration testing (TLPT).

NIS2 for Swiss subsidiaries: when the EU directive lands in Switzerland

The EU NIS2 directive (transposition deadline was 17 Oct 2024, implemented nationally by member states) does not apply directly in Switzerland. It bites through two channels: first, EU subsidiaries of Swiss groups fall directly under national NIS2 implementations. Second, Swiss providers of essential services to regulated EU customers inherit obligations contractually. A SOC is the operational building block for detection, notification and evidence in both cases.

SOC as a Service in Switzerland: The Complete Guide

SOC as a Service is an externally operated Security Operations Center that monitors your environment around the clock, detects attacks and triggers the response. According to Mandiant M-Trends 2026, attackers went undetected for a median of 14 days in 2025. With a SOC that detects and assesses around the clock, typical detection time becomes much shorter.

Managed vs in-house SOC: which model pays off in Switzerland, and when

An in-house 24/7 SOC needs 8,760 hours of cover per seat; at roughly 1,700 productive hours per full-time role, that means at least 5 to 6 roles, plus platform and training. Economically, running your own SOC only pays off with a large environment and a dedicated team, when regulation, data sovereignty or OT proximity demand it.

Look up short definitions in the glossary