What matters is not only whether individual controls are met, but whether the capabilities relevant to secure operations work under realistic conditions.
Anyone implementing the ICT minimum standard maps requirements, implements measures and appoints owners. With every completed measure, however, a further question arises: has operation actually become more secure and robust as a result?
A fulfilled requirement is important progress. Whether it results in resilient cyber security, however, only becomes clear in its interplay with other controls, the people responsible and operational processes. This interplay must also work under time pressure, when staff are absent or when several disruptions occur at the same time.
The view of individual controls must therefore be complemented by a view of operational capabilities: identifying and treating vulnerabilities, managing security incidents and restoring critical services. Such a capability covers the entire sequence from trigger to intended outcome, including the people, systems and external partners involved.
Strengthening the whole chain, not just individual links
Security can be understood as a chain. Individual links may be technically excellent. If clear rules, reliable handovers or unambiguous responsibilities are missing elsewhere, the chain nevertheless remains vulnerable. Its resilience is decided by its weakest link.
In practice, this means that further refining an already strong control is not always the most effective next step. The bigger lever often lies in an unspectacular weakness in the process. Technically mature monitoring, for example, is of limited help if alerts are not assessed in time or escalation leads nowhere.
Rather than just working through the next individual measure, it is therefore worth regularly looking at the capability as a whole: what works reliably? Where does the process stall? Where is more effort already being spent than is reasonable in relation to the risk? The following three examples show how different priorities can emerge from this perspective.
Vulnerability management: From finding to effective treatment
An installed update is a measure. The capability to manage vulnerabilities, however, starts earlier: critical components and their dependencies must be known. Vendor advisories, results from vulnerability scans and relevant system changes must reach the people responsible. Only then can it be assessed which systems are affected, what impact is to be expected and which treatment makes sense, taking into account operations, maintenance windows and OT requirements.
A reliable asset inventory provides the basis for this. It links systems to their criticality, the people responsible and operational dependencies. This makes it possible, for example, to assess whether a vulnerability could affect grid operations. On this basis, IT, OT and external service partners must agree on a coordinated treatment.
This also includes handling exceptions: what happens if no patch is available or it cannot be applied at short notice? Who decides on compensating measures? Who accepts a remaining risk for a limited time, and when will it be reassessed? The work does not end with the closed ticket. It must be traceable whether the vulnerability was fixed, its impact limited or the remaining risk accepted with justification.
Security incidents: From alert to coordinated response
In security incident management, too, technical detection is only part of the capability. Additional data sources and alerts are of little help if the process between detection, decision and response does not work.
A concrete scenario makes these handovers visible: a critical configuration is changed unexpectedly. Which signal triggers the handling? Who assesses it, and within what time frame? Who may decide, together with operations, on isolation, shutdown or continued operation? Do deputies and escalation also work outside office hours, insofar as operations require it?
If the weakness lies in these handovers, a clarified on-call service, an unambiguous decision-making authority or a tested escalation path can achieve more than another log source. Budget and attention should be directed where they actually improve the ability to respond.
Recovery: From backup to an operational service
A successful backup alone does not restore operations. What matters is whether a required service is available again within the time operations require. For this, people, documentation, communication channels, technical prerequisites and external partners have to work together.
Recovery plans should therefore be tested against concrete recovery objectives. Who triggers and approves the recovery? Which systems and services have priority? Which dependencies determine the sequence? Which fallback procedures apply if central means of communication fail? If the test reveals a gap, it needs an owner, a deadline for fixing it and a renewed test. Only then does the insight strengthen the capability.
Conclusion: Keeping the whole security chain in view
The three examples show that the ICT minimum standard, with its framework and controls, remains an important foundation. Looking at overarching capabilities does not replace it. It connects the individual controls with the operational outcome they are meant to enable together.
To avoid getting stuck in the treadmill of individual measures, it is necessary to step back from the details regularly. Which capability is decisive for secure operations? Where is its weakest link? What counts is not only the lowest maturity level, but which weakness could have the greatest impact in the specific operation.
The maturity levels of the ICT minimum standard form the basis for assessing individual controls. In addition, it is advisable to define verifiable criteria for each level for integration into the overall capability: are the necessary responsibilities and handovers aligned? Are they reliably practised in everyday work? Is the interplay reviewed and improved? Such criteria make the operational assessment more concrete without replacing the existing level definitions.
A high maturity level should therefore not be justified solely by the quality of a tool, a document or an isolated work step. Before rating, it should be checked whether the interfaces essential to the control have actually been implemented as well. Remaining gaps in the interplay must stay visible, even if individual controls are already well developed.
Priorities can be derived from this overall picture: which improvement strengthens the capability in question most effectively? This allows limited human and financial resources to be used where they make a traceable operational contribution. Implementation remains concrete, with owners, deadlines and a check whether the measure actually fixes the identified weakness.
The yardstick is therefore not the longest possible list of completed measures. What matters is whether the next improvement strengthens the weakest link and makes the entire capability more resilient in operation.
fortControl: Developing security in a balanced way
fortControl is a Swiss platform for information security and risk management. It brings together requirements, risks and measures and makes it easier to develop security capabilities in a balanced way: addressing weaknesses specifically, setting priorities and keeping the interplay in view.