Risk-based cyber security management: why fewer checklists mean more security

Most security programmes consist of two types of activity: visible ones like writing policies, planning awareness campaigns or renewing certificates, and effective ones. The overlap is smaller than it should be. An ISMS handbook that runs to 140 pages and documents every ISO control with painstaking precision says nothing about whether that one legacy application with the unencrypted customer data store is actually protected. That is the difference between compliance-driven and risk-based security management, and the reason this distinction is increasingly becoming a decisive success factor for Swiss SMEs and large enterprises alike.

This article explains what a risk-based approach means in practice, why it reduces overhead rather than creating it, and how to make the real pressure points of your organisation visible, without having to hang yet another certificate on the wall.

1 · The problem with "we do everything"

A typical picture in many organisations: IT security has built up a stack of measures over the years, a firewall ruleset, patch management, endpoint protection, a SIEM, regular pen tests. All spread across multiple teams, documented in different tools, reviewed in different audits. On paper it looks impressive. But ask: "What are our five biggest cyber risks, and what are we doing about them?", and you will usually be met with a long silence, or a list of controls, not risks.

The distinction is central. Listing controls describes what is being done. Naming risks describes what you are actually protecting against. A security programme oriented primarily towards control compliance produces four well-known side effects:

• Overhead without protection gains. Mandatory awareness training for all staff is cheap to procure and easy to report, but offers only marginal protection against modern attackers, while the application in the DMZ with the unpatched Java framework sits untouched for years.
• False security through coverage. An ISO certificate confirms that an ISMS is functioning, not that the actually exposed systems are adequately protected. Many certified organisations have still been successfully attacked because the vulnerability was out of scope or lost in a generic "medium risk" classification.
• Paralysis through equal weighting. When all 74 Annex A controls under ISO 27001 are treated as equally important, there is no capacity to deeply address the three to five truly critical areas.
• Decoupling from the business. Security is seen as a "compliance matter", not a business topic. Management signs off budgets because an auditor demands it, not because they understand why this specific risk is threatening for this organisation.

Risk-based security management reverses this logic. The starting point is not the control but the risk. And not every risk is treated the same.

2 · What risk-based really means

The term "risk-based" is used loosely, from consulting firms selling a new approach to tools that simply relabel classic compliance matrices. A simple heuristic separates marketing from method:

A security programme is risk-based when every significant investment decision, every measure, every prioritisation can be traced back to a concrete risk assessment, and when that assessment is reviewed regularly.

In practice, a risk-based approach consists of four interlocking elements:

First: a current risk register. Not an Excel list refreshed once a year for the audit, but a living record in which risks are identified, assessed and assigned to an owner. Each risk has at least a gross value (how large would it be without protection), a residual value (how large is it with the measures in place) and a status.

Second: a clear link from risk to protected asset to process. A risk does not float in a vacuum. It strikes a concrete asset, a database server, an application, a business process. Anyone unable to establish this link cannot estimate the impact of an incident and, in an emergency, cannot prioritise what needs to be restored first.

Third: measures with proof of effectiveness. Every control is assigned to one or more risks. Anyone who asks what a particular measure achieves gets an answer in the form of a gross-to-residual reduction. Measures that cannot be assigned to any significant risk are critically questioned, and often removed or consolidated.

Fourth: periodic re-assessment. The threat landscape, business processes and technology base change constantly. A risk-based programme defines how often which risks are reassessed, and who triggers it. A new third-party connection, a new ERP module, a changed regulatory requirement: all are triggers for an update.

3 · Identifying the crown jewels

Every organisation has one area where a successful attack would be truly existential, and three dozen other areas where an incident would be unpleasant but manageable. The first task of a risk-based programme is to be able to name that difference.

In security literature, these are called an organisation's crown jewels: those data sets, systems or processes whose compromise or failure would fundamentally damage the business. The crown jewels are not identical to "all personal data" or "all systems with internet access". An industrial company with 30 years of development know-how has different crown jewels than an accountancy firm with client dossiers or a hospital with patient records.

The identification runs along a simple question that can be answered in a short workshop with management: What would fundamentally damage our organisation in twelve months if it were irrevocably compromised or deleted today? The answers are usually surprisingly concrete:

• The source code of the flagship product and the associated build pipelines
• The customer database with contract terms, payment details and history
• The central ERP, without which neither orders come in nor invoices go out
• The M365 tenant with all e-mail communications and OneDrive data of the leadership team
• The CAD files of patent-relevant designs

A typical SME should not name more than five to seven crown jewels, anyone producing a longer list either has a very special business structure or has not yet made the distinction from all other assets. The value of this exercise lies precisely in the focus it creates.

Once the crown jewels are named, security work is re-sorted: which controls protect these specific assets? Which measures would deliver the greatest reduction there? What monitoring exists there, and what is missing? Many organisations discover during this phase that the most expensive security investments were made at the least critical points, while the crown jewels are surprisingly thinly protected.

4 · Pressure points instead of checklists

A pressure point is a place where a single incident simultaneously affects multiple critical processes. In the classic compliance view, pressure points appear as one control among many. In the risk-based view, they are what attention must primarily focus on.

Typical pressure points in Swiss organisations:

• Active Directory / Entra ID. A compromised domain admin account typically means the end of every isolated line of defence. Yet the security programme often treats identity as one control among many, rather than the central switchboard it actually is.
• The backup system. Ransomware attacks in recent years have shown that the difference between "restorable in 4 hours" and "we pay the ransom" almost always lies in the backup concept, not in the antivirus product. Yet backup is a side topic in many ISMS.
• The central collaboration platform. M365, Google Workspace or equivalent variants are the de-facto working environment for many firms. A compromise there is practically a compromise of the entire organisation, yet configuration security is rarely at the level this risk situation demands.
• The one key supplier without a fallback concept. The cloud ERP from a single vendor, the only banking interface, the sole payment provider: where no alternative exists, a single point of failure arises that is invisible in any firewall rule.
• The legacy application with privileged access. Almost every grown organisation has at least one old application running on an unmaintained stack but with access to business-critical data. As long as it "somehow works", it is left alone, until it is exploited as an attack vector.

Identifying such pressure points is not a checklist task, but an analysis task. It requires someone who has understood both the business processes and the technical dependencies, and an organisation willing to hear uncomfortable answers. A good connectivity view that represents risks, processes, assets and suppliers as an interconnected graph accelerates this analysis enormously. You can then see at a glance which nodes carry the most connections, those are the pressure points.

5 · Prioritisation through the gross-residual gap

The methodologically most elegant way to prioritise investments is to look at the gross-residual gap: the distance between the risk without protection measures and the risk with the currently implemented measures. Where this gap is small, the controls are already working. Where it is large, action is needed.

A simple example. Consider three risks on a 5×5 scale (1 = very low, 25 = catastrophic):

• Risk A: Phishing attack on regular employees. Gross 12, Residual 6. Gap = 6.
• Risk B: Ransomware encryption of the customer database. Gross 20, Residual 16. Gap = 4.
• Risk C: Compromise of a domain admin account via an unpatched RDP vulnerability. Gross 22, Residual 18. Gap = 4.

The compliance view would mark Risk A as "well covered" (residual at 6) and move on. The risk-based view asks: why are the residuals of B and C so high? And more importantly: where does the next investment pay off most?

Investing further resources in anti-phishing might push Risk A's residual from 6 to 4. A gain of 2 points. Investing instead in hardening privileged access could bring Risk C's residual from 18 down to 10. A gain of 8 points, on a risk that is existential in an emergency.

Those who consistently view investment decisions this way arrive at a different security roadmap than those who work through checklists. And management suddenly understands why the budget flows where it flows, because the argument is not "ISO requires it" but "this is how we reduce our biggest residual risk".

6 · Less overhead, more impact

The argument that a risk-based programme is more demanding than a compliance-driven one does not hold up in practice. The opposite is true: the effort shifts, but it decreases overall, and the impact grows.

Where effort is saved:

• No more pseudo-controls. Measures that address no measurable risk are dropped in the annual review. This reduces the maintenance, reporting and audit burden for the entire rest of the year.
• Focused awareness programme. Instead of procuring generic mandatory training for all 700 employees, a specific programme runs for the 40 people with privileged access, and a shorter baseline training for everyone else. Same effect, fraction of the cost.
• Reduced vendor sprawl. Those who have named the real risks can buy three security products that genuinely address those risks, instead of twelve products with overlapping functions, none of which ever delivers its full benefit.
• Leaner audits. An auditor who finds a functioning risk register and clear gross-to-residual assessments works through the review faster than one who has to wade through 140 pages of policy documentation without context.

Where effort is added:

• Initial identification and assessment of risks. This is not trivial and requires the involvement of business units. Typical effort for a mid-sized company: two to four workshops over six to eight weeks, plus ongoing maintenance by a part-time role.
• Ongoing effectiveness assessment. Instead of "control is implemented: yes/no", the assessment considers how well a control works. This requires slightly more analytical effort per measure.
• Communication with management. The risk language needs to be introduced, which pays off quickly, because decisions can be made more transparently and faster.

On balance: total effort decreases, and the more clearly so the longer the programme runs. The investment at the start is the identification of risks and crown jewels; thereafter the model amortises itself every year.

7 · A practical starting point

Anyone who wants to start a risk-based security programme having previously worked in a mostly compliance-oriented way does not need to change everything at once. A staged entry works well:

Step 1: Crown jewels workshop. Half a day with management, ideally moderated by someone who does not need to provide technical detail themselves. The goal is a list of five to seven crown jewels with a clear explanation of why each is critical.

Step 2: Set up a risk inventory. For each crown jewel, the three to five most important threats are identified and assessed with gross and residual values. This produces the first version of the risk register, not comprehensive, but meaningful.

Step 3: Pressure point analysis. Which shared infrastructure components (identity, backup, central platforms) are used simultaneously by multiple crown jewels? These components are treated separately and prioritised.

Step 4: Measure mapping. Existing controls are assigned to the identified risks. What cannot be assigned to any risk is questioned. What does not sufficiently reduce any risk gets new or supplementary measures.

Step 5: Quarterly review. The risk register is discussed with management on a quarterly basis, briefly, focused, with clear decision points. New initiatives (new application, new supplier, new regulation) are reviewed for their risk profile before being implemented.

A Swiss SME typically completes this phase in three to six months with internal capacity and occasional external support. The result is a security programme that no longer tries to do everything equally well, but does the few truly important areas really well, and keeps the rest at an appropriate baseline level.

Outlook

Risk-based cyber security management is not a new framework and not a product. It is a mindset: first understand what is at stake, then decide what to do. This mindset has practical consequences, it reduces overhead, increases impact, makes security investments comprehensible to management and puts the organisation in a position where it responds to incidents not in surprise but in preparation.

Anyone who starts today with a compliance-driven programme and adds a risk-based lens does not need to abandon existing investments. On the contrary: much of what already exists can be integrated into the new model, the results will simply become more visible and better justified. The real pressure points of the organisation are addressed, the irrelevant controls fall away, and what emerges is a programme that costs less, achieves more and presents itself externally, to auditors, customers and regulators, far more robustly than any collection of certificates.

The path there begins with a simple question every organisation should ask itself honestly: What would really damage us in twelve months, and are we doing enough to prevent exactly that?