Patching Is Not Enough: Building a Vulnerability Management Programme That Holds Up to FINMA and ISA Scrutiny

Since mid-March, three separate critical zero-days have struck security management infrastructure used by Swiss enterprises: CVE-2026-20131 in Cisco Secure Firewall Management Center, exploited by Interlock ransomware for 36 days before a patch existed; CVE-2026-21643 in Fortinet FortiClient EMS, exploited beginning 24 March; and CVE-2026-35616 in the same product, exploited from 31 March. In each case, the vendor's emergency response was commendable — hotfixes and advisories were published within days of public disclosure. The question is not whether Cisco and Fortinet responded adequately. The question is whether the organisations running these products had the programme infrastructure to detect the threat, assess their exposure, and respond within a timeframe that reduced their actual risk.

In most Swiss organisations, the answer is: not reliably. Patching happens. Vulnerability management — as a structured, risk-driven, audit-ready programme — is less common than it should be, particularly outside the financial sector's largest institutions. This article is about the difference between the two, and about what FINMA Circular 2023/1 and the Swiss Information Security Act's reporting obligations now require of organisations operating in regulated environments.

The Difference Between Patching and Vulnerability Management

Patching is a technical activity: identify a software update, test it, deploy it. It is reactive by nature — it begins when a vendor publishes a fix. Vulnerability management is a programme: a continuous cycle of asset discovery, vulnerability identification, risk-based prioritisation, remediation tracking, exception management, and metrics reporting. It operates on all known vulnerabilities, including those for which no patch exists. It incorporates threat intelligence to distinguish between theoretical vulnerabilities and actively exploited ones. It produces documented evidence of how the organisation responds to risk, which is precisely what regulators request during audits and supervisory reviews.

The gap between patching and vulnerability management becomes most visible in zero-day scenarios, where no patch is available. An organisation with a mature vulnerability management programme can still respond meaningfully to a zero-day: it knows which assets are affected, it can implement mitigating controls while awaiting a patch, it can increase monitoring on affected systems, and it can make a documented risk acceptance decision with defined review criteria. An organisation that treats patching as its complete vulnerability response has no structured mechanism for any of this.

What FINMA Circular 2023/1 Actually Requires

FINMA Circular 2023/1 on operational risks and resilience, which superseded the previous Circular 2008/21, establishes ICT risk management requirements for supervised financial institutions including banks, insurance companies, securities firms, and financial market infrastructures. The circular does not use the phrase "vulnerability management programme" as a defined term, but its requirements collectively define one.

Section 2 of the circular requires institutions to implement a risk management process for ICT risks that covers identification, assessment, treatment, monitoring, and review. Identification includes systematic identification of vulnerabilities in ICT systems — which requires asset inventory, vulnerability scanning, and external threat intelligence feeds. Assessment requires evaluating vulnerabilities against the likelihood and potential impact of exploitation. Treatment requires defined remediation timelines based on risk classification, with tracked progress. Monitoring requires ongoing detection of new vulnerabilities. Review requires periodic reassessment of the overall risk posture.

The circular also requires institutions to conduct regular vulnerability assessments and penetration tests of critical systems, and to address identified findings within defined timeframes. Critically, FINMA expects findings from these exercises to be traceable through to closure — meaning documented ticket management, escalation paths, and evidence of remediation. During FINMA supervisory examinations, examiners routinely request vulnerability scan reports, penetration test findings, and remediation tracking data going back 12 to 24 months.

The ISA Reporting Obligation Changes the Calculus

The Swiss Information Security Act's mandatory incident reporting requirement — in force for critical infrastructure operators since 1 April 2025 — creates a direct operational dependency on vulnerability management capability. The 24-hour notification window begins when the organisation discovers the incident, not when the vendor publishes a patch. An organisation that learns of an active zero-day exploitation from public sources, has no SBOM or asset inventory to assess whether its infrastructure is affected, and cannot determine within 24 hours whether a reportable incident has occurred is in a materially worse regulatory position than one that can make that determination quickly.

The ISA's incident reporting framework also incentivises early detection. An organisation that detects indicators of compromise on a FortiClient EMS server on day three of an exploitation campaign — because it has log monitoring, anomaly detection, and EDR telemetry on management infrastructure — is in a very different position from one that discovers the compromise weeks later through a ransomware note. The former has a credible incident response narrative. The latter has a crisis.

The 14-day detailed follow-up report required under the ISA must include a description of how the incident occurred, the systems affected, the measures taken, and the impact assessment. An organisation with a mature vulnerability management programme can produce this documentation from existing records. One that lacks the programme infrastructure will struggle to reconstruct a coherent timeline under time pressure.

Building the Programme: Seven Core Components

1. Asset inventory with criticality classification. You cannot manage vulnerabilities in assets you do not know you have. The foundation of any vulnerability management programme is a current, accurate inventory of all IT, OT, and cloud assets, tagged with business criticality, data classification, and regulatory sensitivity. This inventory must be maintained continuously — not as a point-in-time snapshot produced for audits. For Swiss financial institutions, the FINMA-required mapping of critical services provides a natural starting point for criticality classification.

2. Continuous vulnerability scanning. Scheduled vulnerability scans of the asset inventory, with frequency calibrated to asset criticality. Internet-facing systems and critical infrastructure components should be scanned at minimum weekly. Internal systems should be scanned monthly at minimum. Scan results must be retained, trended over time, and reviewed by a named owner who is accountable for remediation progress. Many Swiss organisations run scans but do not review the output systematically — the scan exists for compliance theatre rather than operational use.

3. Threat intelligence integration. Raw CVSS scores are a starting point, not a prioritisation framework. A CVSS 9.8 vulnerability in software your organisation does not run is less urgent than a CVSS 7.5 vulnerability in software that is actively being exploited against your sector. Effective vulnerability management integrates threat intelligence feeds — CISA KEV, vendor security advisories, NCSC alerts, sector-specific ISACs — to identify vulnerabilities that are actively weaponised and therefore require accelerated response regardless of base CVSS score. The Fortinet EMS zero-days this week would have been identified as top-priority items by any programme with this integration in place, before CISA published its KEV entry.

4. Risk-based remediation SLAs. Define remediation timeframes by risk tier, and enforce them. A defensible tiering for Swiss financial institutions: Critical (CVSS ≥ 9.0 or actively exploited): remediation or mitigating control within 24–48 hours. High (CVSS 7.0–8.9): remediation within 7 days. Medium (CVSS 4.0–6.9): remediation within 30 days. Low: remediation within 90 days or documented risk acceptance. These SLAs must be formally approved by management and tracked with escalation paths for overdue items.

5. Exception management with documented risk acceptance. Not every vulnerability can be patched immediately. Legacy systems, operational continuity constraints, vendor dependencies, and testing requirements all create legitimate reasons why remediation may extend beyond the standard SLA. These situations require a formal exception process: documented justification, defined compensating controls, named risk owner, expiry date, and board or senior management sign-off for exceptions on critical systems. An exception that is properly documented is a managed risk. One that exists because no one tracked it is a control failure.

6. Management reporting and KPIs. Vulnerability management data must feed into management reporting at a level that enables informed risk decisions. Useful KPIs include: mean time to remediation by risk tier, percentage of critical vulnerabilities remediated within SLA, age distribution of open vulnerabilities, and vulnerability density by system type. Boards and audit committees of Swiss financial institutions are increasingly asking for this data. CISOs who cannot provide it are not managing the risk — they are simply hoping it does not materialise.

7. Integration with incident response. Vulnerability management and incident response are not separate programmes — they are connected at multiple points. An active exploitation of a known vulnerability is both a vulnerability management failure and an incident response trigger. The programmes must share asset inventory data, threat intelligence, and communication channels so that when a zero-day surfaces, the transition from vulnerability assessment to incident response mode is immediate and coordinated, not dependent on ad-hoc coordination between siloed teams.

The Zero-Day Problem and Compensating Controls

A well-structured vulnerability management programme does not prevent zero-days. No programme can. What it does is ensure that when a zero-day occurs in software your organisation runs, you can detect it faster, limit its impact through compensating controls, and respond more effectively than organisations that are reacting without programme infrastructure.

For the Fortinet EMS scenario documented in this week's featured article, an organisation with a mature programme would have had: a current inventory confirming which version of FortiClient EMS is running and on which network segment; network access controls already in place restricting management interface access to named jump hosts; monitoring alerts configured for anomalous authentication patterns and unexpected administrative actions on the EMS server; and a defined escalation path that kicked in within hours of the Defused Cyber advisory being published. None of this requires predicting the specific CVE. All of it requires the programme infrastructure that treats security management infrastructure as a high-criticality asset deserving of active, continuous attention.

The organisations that were most exposed during the five-day window between initial exploitation and Fortinet's hotfix were those without these compensating controls — because they had not built the programme that would have put those controls in place as a matter of standard practice, independent of any specific threat.

Starting Where You Are

Not every Swiss organisation can build a mature vulnerability management programme overnight. Resource constraints, legacy infrastructure, and competing priorities are real. The pragmatic approach is to sequence improvement based on risk rather than trying to address everything at once. Start with internet-facing systems and security management infrastructure — the asset categories that are most commonly targeted and where exploitation has the highest potential blast radius. Build the asset inventory, deploy continuous scanning, integrate CISA KEV and NCSC alerts as minimum threat intelligence feeds, and define remediation SLAs for critical and high findings. Document everything. That foundation will serve an organisation better during the next zero-day than a sophisticated toolset with no governance around it.