Switzerland software supply chain and AI security rules: a 90-day plan

If you build, buy or run software in Switzerland, three Swiss rules already reach your code and your suppliers. Since 1 April 2025 the Information Security Act (ISA) has required critical infrastructure operators, and some software makers, to report cyberattacks to the Federal Office for Cybersecurity within 24 hours, with fines possible since 1 October 2025. FINMA Circular 2023/1 has applied to banks and securities firms since 1 January 2024, with its last transition ending on 1 January 2026. The revised Federal Act on Data Protection (FADP) has applied since 1 September 2023. Switzerland is not in the EU or the EEA, so EU rules such as the Cyber Resilience Act reach Swiss firms only through EU market access or contracts with EU entities.

This guide takes each regime from its primary text, names the supervisor, sets out what it asks of software and open source, and ends with a 30/60/90-day plan that works with any tooling. It is a practical reading of public texts as of 25 October 2026, not legal advice.

Key takeaways

• Reporting is law. Articles 74a to 74h of the ISA (Informationssicherheitsgesetz, ISG) require cyberattack reports within 24 hours of discovery; the Cybersecurity Ordinance (Cybersicherheitsverordnung, CSV) allows 14 days to complete them. The CHF 100,000 fine applies only after an ignored formal order.
• Software makers can be in scope. Article 74b(1)(u) ISA covers makers of hardware or software used by critical infrastructure where the product has remote maintenance access or controls operational systems.
• There is a 90-day vulnerability clock. Under Article 6 CSV the federal office normally gives a maker 90 days to fix a reported vulnerability, and may publish it afterwards.
• Banks run on FINMA Circular 2023/1: a real-time ICT asset inventory (margin nos. 53 and 54), vulnerability assessments and penetration tests (no. 69), and cyberattack notice to FINMA within 24 hours, with a report within 72 hours (no. 68).
• FADP fines hit individuals, up to CHF 250,000, including for wilfully missing the minimum data security requirements (Article 61(c)).
• No horizontal Swiss AI law yet. FINMA Guidance 08/2024 sets AI expectations for finance today.
• EU rules arrive through the market. CRA reporting has applied since 11 September 2026 and its full product rules apply from 11 December 2027 to products sold in the EU, Swiss-made ones included.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis, SCA and vulnerability management with EPSS and KEV, reachability analysis, policies and gates, the Compliance and GRC suite with revFADP and EU CRA framework pages, TPRM SBOM requests, Package Firewall, CSAF and VEX upload, Trust Center, AI-BOM discovery, AI-SPM, AI Gateway, MCP Guardrail, agent identity, autonomous remediation (ships switched off), the local runner, Zero AI mode, bring your own model, and private VPC, on-prem and air-gapped deployment.

Who this applies to in Switzerland

Switzerland has no single law like the EU's NIS2 Directive. Duties come from the ISA for critical infrastructure, financial market law for supervised institutions, the FADP for anyone processing personal data, and EU law for firms selling into the EU. One organisation often sits under three of them.

Critical infrastructure operators. Article 74b(1) ISA lists who must report, including universities, federal, cantonal and communal authorities, water, wastewater and waste bodies, energy companies, hospitals on cantonal lists, medical laboratories, medicine makers, social insurers, the national broadcaster, postal, rail, bus, aviation and Rhine shipping operators, essential goods suppliers, registered telecoms providers, and domain registries and registrars.

Banks, insurers and financial market infrastructures appear twice: in Article 74b(1)(e) ISA, and under FINMA supervision. Circular 2023/1 applies to banks, securities firms and financial groups and conglomerates (margin no. 2).

Cloud, data centre and digital trust providers with their seat in Switzerland are covered by Article 74b(1)(t) ISA.

Software and hardware makers. The clause most product teams miss is Article 74b(1)(u) ISA: makers whose products critical infrastructure uses, where the product has remote maintenance access or is used to control and monitor operational systems or to ensure public safety. A Swiss vendor of energy control or remote support software can be a reporting entity itself.

Everyone processing personal data. Under Article 3 FADP, the act applies to circumstances that have an effect in Switzerland, even if they started abroad. Under Article 14, some foreign controllers must appoint a Swiss representative.

Swiss firms selling into the EU meet the CRA as manufacturers, DORA through EU bank contracts and the AI Act as providers, because of what they sell, not because Switzerland is a member of anything.

The rules, regulator by regulator

The Information Security Act and the cyberattack reporting obligation

The Federal Act of 29 September 2023 amended the ISA (SR 128) to introduce the reporting obligation. The Federal Council set commencement and adopted the Cybersecurity Ordinance on 7 March 2025. The consolidated fedlex text shows the amendments in force since 1 April 2025, and the enforcement Articles 74g and 74h since 1 October 2025.

• Article 74a: listed organisations must ensure cyberattacks are reported to the Federal Office for Cybersecurity (Bundesamt für Cybersicherheit, BACS), which will rule on scope on request. A report gives the organisation a right to the office's incident support under Article 74(3) (Article 74a(3)). Article 74a(4) says the duty exists only so the office can spot attack patterns early, warn possible victims and recommend defences.
• Article 74b(3): attacks with an effect in Switzerland count even if the affected IT is abroad.
• Article 74d: report an attack that endangers the functioning of the infrastructure, led to manipulation or leakage of information, stayed undetected for a long period, or involves blackmail, threats or coercion.
• Article 74e: report within 24 hours of discovery, covering the organisation, the attack, its effects, measures taken and next steps, and add facts as they emerge.
• Article 74f: the office's secure system can forward a report, in whole or in part, to other authorities.
• Articles 74g and 74h: the office first contacts an organisation that missed a report and sets a deadline, then issues a formal order. Only wilful failure to obey a final order is punishable, with a fine of up to CHF 100,000, prosecuted by the cantons.

The Cybersecurity Ordinance (SR 128.51) adds detail. Under Article 14 CSV, functioning is endangered when staff or third parties face outages or the organisation runs on emergency plans; leakage includes any case notified under Article 24 FADP; and "long period" means more than 90 days. Article 15 CSV adds the times of discovery and attack, attacker details, extortion and criminal complaint status, and severity. Article 16 CSV gives 14 days to complete a report. Article 12 CSV exempts some entities, such as universities with fewer than 2,000 students. Article 17 CSV allows outsourcing the reporting process.

In English the office still calls itself the National Cyber Security Centre (NCSC). On 29 September 2025 it reported 164 notices in the first six months: DDoS (18.1 percent), hacking (16.1 percent) and ransomware (12.4 percent) led, and finance filed the most (19 percent). Reports go through its Cyber Security Hub or an email form.

Coordinated vulnerability disclosure: the 90-day clock for makers

Under Article 73b(3) ISA, when the office learns of a vulnerability it must inform the maker and set a reasonable deadline for a fix, warning that ignoring it can be sanctioned under federal procurement law (Article 44(1)(f bis) of the Federal Act on Public Procurement) and that, under Article 73c(2), it may then publish the vulnerability and name the product.

Article 6 CSV sets the default at 90 days. The office may shorten it if the vulnerability endangers critical infrastructure, affects widely used systems, is being exploited or is easy to exploit, and may extend it for complex fixes. It may also warn operators before disclosure. A Swiss software company therefore needs a reachable security contact, a way to find affected products and versions within days, and a release process that ships fixes inside 90 days.

FINMA Circular 2023/1: operational risks and resilience for banks

FINMA issued Circular 2023/1 on 7 December 2022; it entered into force on 1 January 2024, replacing Circular 2008/21. It applies proportionately: margin nos. 20 and 21 exempt smaller categories from listed requirements. The parts that matter for software and suppliers:

• Change management (nos. 50 to 52): controls for developing or procuring ICT, development and test separated from production, and security requirements defined, tested and validated.
• ICT asset inventory (nos. 53 and 54): hardware and software assets, critical data locations, internal dependencies and interfaces to significant external providers, available in real time and reviewed regularly. End-of-life ICT is handled by risk (no. 57).
• Incident management (nos. 58 to 60): including incidents arising from external providers; significant ones go to FINMA without delay.
• Cyber risk (nos. 61 to 70): assess exploited vulnerabilities against inventoried assets (no. 63), protect, detect, respond with rapid containment and remediation (no. 66) and recover. Under no. 68, a preliminary notice to FINMA within 24 hours, a report on FINMA's survey and application platform within 72 hours, then a root cause analysis. No. 69 requires regular vulnerability assessments and penetration tests of internet-facing assets and of internal assets supporting critical processes.
• Critical data (nos. 71 to 82): risks of storage or access from abroad must be mitigated (no. 79), and providers that can see critical data need thorough due diligence before contracting and periodic monitoring (no. 82).
• Operational resilience (nos. 101 to 111): board-approved critical functions and tolerances, an annual inventory of their dependencies (no. 107), and tests in severe but plausible scenarios (no. 110), which a footnote says include the prolonged failure of a key provider.

Under margin no. 113, nos. 106 to 109 and the first tests had one year and full resilience under no. 102 had two, so the whole circular has applied since 1 January 2026. FINMA's 2024 cyber review reports successful or partially successful attacks up about 30 percent on 2023, with about 30 percent of them aimed at institutions' external service providers. Outsourcing itself falls under Circular 2018/3, cross-referenced in margin no. 104.

FINMA Guidance 08/2024: AI in finance

Published on 18 December 2024, the guidance states that Switzerland has no AI-specific legislation and that technology-neutral governance rules already cover AI. It names model risks (robustness, correctness, bias, explainability), IT and cyber risks, and dependence on third-party models and cloud services, and sets out observations under seven headings: governance, inventory and risk classification, data quality, tests and monitoring, documentation, explainability and independent review. The inventory comes first, because you cannot classify AI you have not found.

The revised FADP, the Data Protection Ordinance and the FDPIC

The FADP (Datenschutzgesetz, DSG; SR 235.1) and the Data Protection Ordinance (Datenschutzverordnung, DSV; SR 235.11) have applied since 1 September 2023, supervised by the Federal Data Protection and Information Commissioner (FDPIC, in German EDÖB). The articles that touch software:

• Article 7: data protection by design and by default, from the planning stage.
• Article 8: security appropriate to the risk; the ordinance (Articles 1 to 6) sets minimums, including that breaches are recognised rapidly (Article 3) and logging for large-scale sensitive processing (Article 4).
• Article 9: the controller must satisfy itself that a processor can guarantee data security; subcontracting needs prior approval.
• Article 12: records of processing, including security measures and transfers abroad.
• Articles 16 and 17: disclosure abroad only to adequate states (ordinance Annex 1) or with safeguards.
• Article 22: an impact assessment before high-risk processing.
• Article 24: notify the FDPIC "as quickly as possible" of a breach likely to be high risk; processors notify controllers. Ordinance Article 15 sets content and two-year breach documentation.

Under Articles 60 to 66, fines of up to CHF 250,000 fall on individuals, for wilful conduct and mostly on complaint. Article 61 covers unlawful transfers abroad, processor assignments that breach Article 9, and failing the minimum data security requirements. On 8 May 2025 the FDPIC stated that the FADP applies directly to AI-supported processing, with transparency duties and impact assessments for high-risk AI.

Swiss AI regulation: the Federal Council's approach

On 12 February 2025 the Federal Council decided that Switzerland intends to ratify the Council of Europe AI Convention and amend Swiss law, while continuing sector-specific work in areas such as healthcare and transport. No AI-specific federal statute is in force today; the FADP, FINMA's guidance and, for EU business, the EU AI Act are what bind.

Which EU rules reach Swiss firms, and how

Switzerland is neither an EU member nor in the EEA, and none of these EU rules has been taken into Swiss law. They reach Swiss organisations only as follows.

The Cyber Resilience Act (Regulation (EU) 2024/2847) applies to products with digital elements made available on the EU market, wherever made. The Commission states it entered into force on 10 December 2024, reporting applies from 11 September 2026 and the main obligations from 11 December 2027. Manufacturers now report actively exploited vulnerabilities and severe incidents under Article 14, and from December 2027 Annex I Part II requires vulnerability handling with an SBOM. A Swiss maker that does not sell into the EU has no CRA duty, though the Swiss 90-day clock may still apply.

NIS2 (Directive (EU) 2022/2555) reaches Swiss suppliers through the security clauses EU customers impose under Article 21(2)(d), and directly through Article 26(3) where a Swiss firm offers services such as cloud or managed security in the EU without an EU establishment and must name an EU representative.

DORA (Regulation (EU) 2022/2554) has applied to EU financial entities since 17 January 2025. A Swiss bank's EU subsidiary is in scope; a Swiss ICT provider meets DORA through the Article 30 contract terms and its customers' Article 28 register.

The EU AI Act (Regulation (EU) 2024/1689) applies under Article 2(1) to providers placing AI on the EU market and where output is used in the EU. The Commission's page states prohibitions have applied since 2 February 2025, general-purpose model rules since 2 August 2025 and most rules since 2 August 2026, with high-risk Annex III uses from 2 December 2027 and Annex I products from 2 August 2028 after the AI Omnibus.

GDPR Article 3(2) reaches Swiss firms that offer goods or services to people in the EU or monitor them, with a 72-hour breach clock.

EUR-Lex did not serve pages to automated requests while this guide was written, so the NIS2, DORA and GDPR article references come from the official texts as previously published; confirm the wording there.

What the rules ask of software and open source

An inventory you can trust. FINMA wants a real-time ICT asset inventory that includes software assets and interfaces to significant providers. The FADP wants records of processing and security proportionate to risk. The CRA wants an SBOM for EU products. An SBOM per product, refreshed on every build, is the cheapest common answer to all three.

Vulnerability handling with a clock. The federal office gives makers 90 days by default, FINMA expects rapid containment and remediation, and the CRA requires remediation without delay for EU products. Each needs the same input: which products and versions contain the affected component.

Incident reporting. Up to three Swiss clocks can run on one incident, and Article 74f ISA anticipates the overlap by letting the office's system pass a report on to other authorities. Plan one timeline, several forms.

Suppliers. FINMA's 2024 review found about 30 percent of reported attacks aimed at service providers, and both the Xplain and Radix cases below involved data held by a supplier. Due diligence before contracting and monitoring after it are now examined, not assumed.

In short, the rules ask for an inventory you can trust (FINMA nos. 53 and 54, FADP Article 12, CRA SBOM), vulnerability handling against a clock (CSV Article 6, FINMA nos. 66 and 69), incident reporting where up to three Swiss clocks run on one event (ISA, FINMA no. 68, FADP Article 24), supplier diligence (FINMA no. 82, FADP Article 9), secure development (FINMA nos. 50 to 52, FADP Article 7), control over where data and code go (FINMA no. 79, FADP Articles 16 and 17), and an AI inventory (Guidance 08/2024). Neither FINMA nor the FADP forbids foreign tooling; both require you to know where data and code go.

Real public incidents in or affecting Switzerland

Xplain (2023). Xplain makes software for security authorities and emergency services. According to fedpol, Xplain informed it of the attack on 23 May 2023, the Play group published the data in mid-June, and fedpol-related data made up under 10 percent of the published volume as of September 2023. Xplain did not pay the ransom, in consultation with prosecutors and the federal government, reported the attack to the national cyber security centre and filed a complaint with the Bern cantonal police. Fedpol filed its own criminal complaint and informed the FDPIC. The FDPIC found data protection breaches linked to errors in the support process: personal data reached Xplain "without the required data protection precautions" and was stored in breach of data protection requirements and, in some cases, contracts. The FDPIC issued recommendations to all three parties, and the Federal Council ran a separate administrative investigation into how the administration selected, instructed and supervised the supplier. Fedpol said federal procurement was reviewing IT service contracts for cybersecurity obligations.

Radix (2025). On 30 June 2025 the federal office reported that Radix, a non-profit health promotion foundation whose customers include several federal administrative units, was hit by ransomware, with data stolen, encrypted and published on the dark web. It said the attackers never gained entry to federal systems because Radix has no direct access to them, and that it was coordinating the federal investigation with the affected units and prosecutors.

In both cases the data sat with a supplier, the pattern FINMA describes in finance. The sources do not say what the victims should have done, and neither does this guide.

The personas who own the problem

Swiss rules land on different desks, often on the same day.

The CISO owns the 24-hour ISA report and, at a bank, the FINMA notice. Needs an Article 74b scope decision before an incident, one incident timeline for both reports, and a board-ready view of critical functions and their supplier dependencies. Trigger: the first serious incident, or the board's annual risk tolerance approval (margin no. 23).

The head of AppSec owns the vulnerability clock: a reachable security contact, affected versions in hours, fixes inside 90 days. Trigger: a notice under Article 73b(3) ISA, or an EU customer asking about the CRA.

The VP of Engineering owns the pipeline: SBOMs in CI, separate environments (no. 51), gates that stop known critical vulnerabilities without a manual step per release. Trigger: a change management audit finding or a missed deadline.

GRC owns the mapping from text to evidence for FINMA's audit firm, the FDPIC and EU customers. Trigger: the annual audit, a FINMA on-site review or a scope ruling.

Procurement and vendor risk owns pre-contract criteria (no. 82), processor checks (FADP Article 9) and scheduled SBOM collection. Trigger: a renewal, a supplier incident, or an EU customer's DORA questionnaire.

The DPO owns Article 24 notices and impact assessments, and needs to know which systems and components touched the affected data. Trigger: a breach or a new AI deployment.

A practical 30/60/90-day plan

Days 1 to 30: scope, inventory and ownership

1. Decide scope in writing against each Article 74b category, including letter (u); ask the office for a ruling if unclear (Article 74a(2)) and record any Article 12 CSV exemption.
2. List every clock that could run on one incident (ISA 24 hours and 14 days, FINMA 24 and 72 hours, FDPIC as quickly as possible, CRA and GDPR for EU business) and name an owner and deputy for each.
3. Register on the office's platform before you need it.
4. Generate an SBOM in SPDX or CycloneDX for every product and critical application, transitive dependencies included, linked at banks to the margin no. 53 inventory.
5. Publish a security contact and disclosure policy.
6. Start an AI register with owners and a first materiality rating.

Days 31 to 60: vulnerability handling and suppliers

1. Set targets inside 90 days, for example known exploited issues in internet-facing products within 7 days, critical within 30, high within 60, and name who can grant exceptions.
2. Gate releases on CISA KEV entries and unexcepted critical vulnerabilities.
3. Order the queue by exploit likelihood and reachability.
4. Rehearse the 24-hour report with a supplier compromise tabletop against Article 74e, Article 15 CSV and FINMA no. 68.
5. Ask critical suppliers for SBOMs and security contacts, starting with providers that see critical data.
6. Map data and code flows abroad with their safeguards.

Days 61 to 90: evidence, AI and sign-off

1. Assemble an evidence pack per regime from the table above.
2. Test a critical function against a supplier failure (no. 110).
3. Set AI controls under the Guidance 08/2024 headings and run FADP impact assessments where needed.
4. Close the CRA gap for EU products before 11 December 2027.
5. Report to management on scope, owners, open critical vulnerabilities, supplier gaps and AI status; at banks this feeds margin no. 105 reporting.

Common mistakes

• Thinking ISA reporting is only for utilities. Banks, hospitals, Swiss cloud providers and some software makers are in Article 74b.
• Waiting for full facts. The first report is due in 24 hours; completion can follow within 14 days.
• Running three processes for one incident. Keep one timeline and fill each form from it.
• Ignoring the vulnerability clock because you are not critical infrastructure. Article 73b ISA reaches any maker with a reported flaw.
• Reading FADP fines as company fines. They target individuals.
• Assuming EU law applies because Switzerland is in Europe. It applies through market access and contracts.
• Waiting for a Swiss AI Act while FINMA and the FDPIC already apply existing rules.
• An annual spreadsheet inventory where FINMA asks for real time.

How Safeguard does this

Everything above works without Safeguard. This section shows the same steps in Safeguard, using only what Safeguard's offering and documentation describe. Every capability named is generally available (GA). Commands are shown as the docs show them; they were not run for this guide.

1. Switch on the framework pages. In the Compliance and GRC suite (GA), the Switzerland revFADP and EU Cyber Resilience Act pages are on unless you switch them off under Compliance › Manage. Each lists the requirements a scan decides and policy templates, including revFADP templates on privacy notices, cross-border transfers and breach notification. The mappings are Safeguard's own, not the regulator's numbering. There is no FINMA or ISA page today.
2. Generate SBOMs on every scan. SBOM generation and analysis (GA) produces SPDX and CycloneDX, and SCA with deep transitive dependency scanning (GA) builds the component inventory. The revFADP page checks each scan against FADP Articles 8, 7, 12, 9, 24 and 16, for example integrity evidence, pinned versions and identifiable suppliers.
3. Scan without sending source code. The local runner (GA) is part of the Safeguard CLI. The runner docs show installing it with the one-line installer, running safeguard and typing /login; it then scans locally and uploads only the SBOM and findings over outbound HTTPS. For headless use the docs show:

# Start without the terminal UI and serve assistant turns for this workspace
safeguard runner start --workspace ./path/to/repo
# Is it running, and what is it doing
safeguard runner status
# Drain in-flight work and stop
safeguard runner stop

4. Prioritise. Vulnerability management (GA) adds EPSS and CISA KEV context, and reachability analysis (GA) ranks the vulnerable code paths your application calls, so a 90-day notice turns into a list of products and versions in order.
5. Gate releases and record exceptions. Policies and gates (GA) are created under Settings › Policies with a visual builder or YAML, per the policies and gates docs. Actions are Block, Warn or Notify, and approvals run through exceptions with a justification. In CI the docs show:

safeguard ci scan --wait --fail-on-gate <gate>

6. Collect supplier evidence. TPRM (GA) SBOM requests go out singly or in bulk with a format and deadline, are tracked from Sent to Validated or Rejected, and get reminders and an escalation, the trail behind FINMA no. 82 and FADP Article 9.
7. Block bad packages at install. Package Firewall (GA) is an install-time proxy for npm and pip that blocks malicious, typosquatted and dependency-confusion packages.
8. State what is affected. CSAF and VEX upload (GA) holds exploitability statements for customers, auditors and the federal office.
9. Fix with a human in charge. Autonomous remediation (GA) opens tested, policy gated fix pull requests. It ships switched off, with every category set to Manual.
10. Inventory and govern AI. AI-BOM discovery (GA) inventories models, AI SDK imports, prompts, notebooks, agents and MCP servers across code, cloud and SaaS. AI-SPM (GA) scans model artifacts. AI Gateway (GA) evaluates LLM traffic against guardrails for prompt injection, jailbreak and PII egress. MCP Guardrail (GA) generates guardrail proxy URLs for MCP servers, and agent identity (GA) tracks which agent holds what access.
11. Share posture. Trust Center (GA) publishes compliance status, controls, policies, subprocessors and a security contact on a public page.
12. Choose where it runs. SaaS is multi-region across US, EU and Gov regions; no Swiss region is offered. For residency, the GA options are private VPC or dedicated tenancy, full on-prem and fully air-gapped with the AI models inside your environment, plus the local runner, Zero AI mode (GA) with no LLM in the loop, and bring your own model (GA). Safeguard states customer code, SBOMs and telemetry are not used to train shared models.

Safeguard's posture wording is limited to SOC 2 Type II audit in progress and designed for FedRAMP High. It claims no Swiss or EU certification, approval or assessment.

What Safeguard does not do

• It does not make you compliant. Scope, reportability and breach risk are your decisions; Safeguard helps you keep the evidence.
• It does not file reports to the federal office, FINMA, the FDPIC or under the CRA.
• It has no FINMA or ISA framework page; that mapping is your work, with Safeguard evidence attached.
• It does not write contracts or legal analysis for FINMA Circular 2018/3 outsourcing, FADP Article 9 or DORA Article 30.
• It does not fix vendor appliances or hosted services; those fixes come from the vendor.
• It does not replace incident response, penetration testing or OT security, including the tests in margin no. 69.
• It does not offer in-country hosting in Switzerland; use on-prem, air-gapped or the local runner.

FAQ

Is the Swiss cyberattack reporting obligation in force?

Yes, since 1 April 2025, with enforcement Articles 74g and 74h since 1 October 2025. Report within 24 hours of discovery; complete within 14 days.

Who has to report cyberattacks in Switzerland?

Those listed in Article 74b ISA, including energy, water, transport, telecoms, hospitals, banks, insurers, Swiss cloud and data centre providers, public authorities, and some hardware and software makers. Article 12 CSV exempts some smaller entities.

What is the fine for not reporting a cyberattack in Switzerland?

Up to CHF 100,000 under Article 74h ISA, only for wilfully ignoring a final order after the office has set a deadline.

Does the Swiss vulnerability disclosure deadline apply to software vendors?

Yes. Under Article 73b(3) ISA and Article 6 CSV the office normally sets 90 days, can shorten or extend it, and can publish afterwards.

When did FINMA Circular 2023/1 fully apply?

In force from 1 January 2024; after the transitions in margin no. 113, fully since 1 January 2026.

How fast must a Swiss bank report a cyberattack to FINMA?

A preliminary notice within 24 hours, a platform report within 72 hours and a root cause analysis later (margin no. 68), in parallel with the ISA report.

Does the EU Cyber Resilience Act apply to Swiss companies?

Only for products made available on the EU market: reporting since 11 September 2026, full requirements including an SBOM from 11 December 2027.

Does Switzerland have an AI law?

Not a horizontal one. The Federal Council plans to ratify the Council of Europe AI Convention; today the FADP, FINMA Guidance 08/2024 and, for EU business, the EU AI Act apply.

Who are the Swiss regulators for cybersecurity and data protection?

The Federal Office for Cybersecurity (BACS, NCSC in English) for ISA reporting and disclosure, FINMA for financial institutions, and the FDPIC for the FADP.

Every Swiss regime above comes back to one question: when a vulnerable component is named in a notice from the federal office, FINMA or a customer, how fast can you find it and fix it. The block below sets out how Safeguard closes the gap between a disclosure and a fixed build, including when upstream has not shipped a fix yet.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to "fix the lodash CVE in this repo". It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow is how a Swiss product team works through a vulnerability notice from the federal office inside its 90-day window, with a person approving each change.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. This is the option for banks and public bodies that weigh FINMA's margin no. 79 or their own residency rules and will not let source code leave their network.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. For teams building the AI inventory FINMA Guidance 08/2024 expects, it shows what scoped agent access looks like in practice.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Information Security Act (ISG, SR 128), consolidated German text in force 1 October 2025 (fedlex)
• Cybersecurity Ordinance (CSV, SR 128.51), German text in force 1 April 2025 (fedlex)
• Federal Act on Data Protection (FADP, SR 235.1), English text (fedlex)
• Data Protection Ordinance (DPO, SR 235.11), English text (fedlex)
• Federal Office for Cybersecurity: legal basis for the reporting obligation
• Federal Office for Cybersecurity: obligation to report cyberattacks comes into force on 1 April
• admin.ch: six months of the reporting obligation for cyberattacks on critical infrastructures
• Federal Office for Cybersecurity: cyberattack on Radix
• FINMA Circular 2023/1 Operational risks and resilience: banks (PDF)
• FINMA Guidance 08/2024 Governance and risk management when using artificial intelligence (PDF)
• FINMA: cyber risks and outsourcing (2024)
• FDPIC: current data protection legislation is directly applicable to AI
• FDPIC concludes investigations into Xplain, fedpol and FOCBS (admin.ch)
• fedpol: hacker attack on Xplain, impact on fedpol and measures taken
• Federal Council: AI regulation, Federal Council to ratify Council of Europe Convention
• European Commission: Cyber Resilience Act
• European Commission: AI Act regulatory framework and timeline
• Safeguard docs: Switzerland revFADP
• Safeguard docs: EU Cyber Resilience Act
• Safeguard docs: Local Runner
• Safeguard docs: Policies and Gates
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: AI-BOM Discovery
• Safeguard docs: Trust Center
• Safeguard docs: Air-Gapped Deployment

Related reading: the Swiss pension fund supplier ransomware case, CRA Article 14 vulnerability reporting, the ENISA single reporting platform, NIS2 supply chain evidence and DORA third-party ICT risk.

To try the flows above, download Safeguard and read the Safeguard documentation.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.