How do you govern information security with risk management?

How strategic, tactical and operational risk management together form one continuous system of steering, from boardroom to shop floor

Risk management is not a separate activity alongside information security; it is the mechanism that steers it. It translates the question "what could go wrong" into "what do we do about it, what do we accept, and who decides". Yet in many organisations, risk management gets stuck in an annual form-filling exercise: a register that closes again for a year once the audit is over. That is almost always because the three steering levels are not connected. This article explains how strategic, tactical and operational risk management relate to each other, and how you connect the whole to the other processes in your organisation.

In short

• Risk management steers information security at three levels: strategic sets the boundaries, tactical assesses and treats, operational executes and detects.
• The cycle follows ISO 31000 and ISO 27005: context, identification, analysis and evaluation together form the risk assessment, followed by treatment and continuous monitoring.
• The four treatment options are reduce, avoid, transfer and accept; acceptance above the tolerance is a board decision.
• Boundaries flow down and risk information flows up; without those routes the register ages into paper.
• The risk management process coincides with the four phases of the Kantyra model: detect, assess, resolve and demonstrate.

The three levels do not differ in method but in the question asked, the time horizon and the ownership. Strategic is about how much risk the organisation is willing to run. Tactical is about systematically assessing and treating risks. Operational is about day-to-day control and detection. The levels are connected through a continuous cycle: boundaries flow down and risk information flows up.

Strategic level: how much risk are we willing to run?

At the strategic level, with the board and executive management, everything revolves around one question: how much risk are we willing and permitted to run, given our objectives and our legal obligations? The time horizon here is one to four years, meaning that decisions at this level look one to four years ahead and are recalibrated annually.

The core products are the risk appetite and the risk tolerance. The risk appetite is a qualitative statement per domain, for example: "we accept virtually no risk around customers' personal data, but are prepared to take moderate risk in innovative pilot projects". The tolerance makes that measurable: above which residual risk score is board-level acceptance mandatory? Without these boundaries, every risk analysis is rudderless, because the analyst then implicitly decides what is acceptable.

Governance also belongs here. The risk owner always sits in the line, never with the CISO. The second line (the CISO function, the central privacy officer and the risk function) reviews and advises, and the third line (internal audit) provides independent assurance. The data protection officer stands beside them as an independent internal supervisor: advising, yes, but not working in the line. Under the Cyber Security Act (Cbw), the Dutch implementation of the European NIS2 directive, none of this is optional any more: the board carries an explicit duty of care, must demonstrably approve the risk management measures and supervise their implementation, and is required to be trained. Risk acceptance above the tolerance has thereby become a board decision, with personal liability as the ultimate consequence.

The strategic level periodically receives an aggregated risk picture, usually quarterly: the top risks, the trend, the status of treatment plans and the formally accepted residual risks. The Cbw sets the bar higher than a fixed reporting moment: the board does not merely approve the measures, it also supervises their implementation and must actively keep itself informed about risks, measures and incidents. A serious incident, or a residual risk that exceeds the tolerance, does not wait for the quarterly report but reaches the board directly. The board steers through policy, budget and priorities.

Tactical level: which risks do we run and how do we treat them?

At the tactical level, with the CISO, the information security officers and the process and system owners, the risk management process itself is designed and executed. The time horizon runs from three to eighteen months.

The cycle essentially follows ISO 27005 and consists of four steps. The first step is context and scope: which process or system are you assessing, which dependencies play a role, and which CIA classification applies? The classification for confidentiality, integrity and availability forms the bridge between business interest and security requirement, and determines the depth of the analysis. The second step is risk identification and analysis: which threats can cause which impact through which vulnerabilities? You rate this against a fixed probability and impact matrix, so that scores remain comparable across the organisation.

The third step is risk treatment, with the four classic options. You can reduce a risk with controls, avoid it by stopping the activity or arranging it differently, transfer it through insurance or contractual arrangements with a supplier, or formally accept it when it falls within the tolerance and the risk owner signs. The fourth step is recording it all in the risk register, with an owner, a residual risk score, a treatment plan and a review date for every risk.

In Kantyra, that register is the heart of the platform. Every risk has an owner, a handler, a category, a gross and a residual score and a review date, and you link it to the assets, controls, suppliers and incidents it belongs to. The matrix is configurable from 3×3 to 5×5, with your own scale labels, and if you wish the platform requires a justification with every score. You record the risk tolerance as a setting: risks whose residual score exceeds that limit are flagged by the platform, in the register and on the dashboard, until a formal acceptance is in place. That acceptance runs through the exception register, which enforces the four-eyes principle: the requester cannot approve their own risk acceptance, every acceptance has an end date, and the platform guards that expiry date with a task as the review approaches.

If you work with ISO 27001, the selection of controls is recorded in the Statement of Applicability: which controls from Annex A do you apply, which not, and why. That document is the hinge between the risk analysis and the management system. In Kantyra you link risks and controls to those same Annex A controls, so that the statement rests on your risk analysis rather than beside it, and you export it as a PDF for the auditor. A risk analysis itself also goes through a review round under the four-eyes principle: the author submits it and someone else approves it or sends it back with comments.

The tactical level also guards methodological consistency: one matrix, one register, one acceptance procedure. Without that consistency, risks cannot be added up across departments and you cannot give the board a reliable picture.

Operational level: does it work, and what do we see happening?

At the operational level, with administrators, the security team and team leads, the focus is on execution and detection, in a rhythm from daily to monthly. The controls from the treatment plans are implemented and maintained here: patching, access management, logging, backups, hardening. At the same time, this level provides the senses of risk management: vulnerability management, incident registration, monitoring and risk indicators such as patch backlog, the number of accounts without MFA and the willingness to report phishing.

The feedback route upwards is crucial. An operational finding, such as a critical vulnerability that cannot be patched within the agreed period or a series of similar incidents, is not a loose report but a signal that a risk score in the register may no longer be correct. Operational escalates to tactical when a control structurally fails or proves infeasible. Tactical escalates to strategic when the residual risk exceeds the tolerance. Without those routes, the risk register ages into a paper reality, and that is in practice the most common way risk management fails.

In Kantyra, that feedback route is built in, so it does not depend on good intentions. You link an incident to the risk that materialised, and for a high or critical incident the platform automatically creates a task to reassess that risk. Controls have their own effectiveness test with a planned date; when that date approaches or the outcome is inadequate, it appears in the task list by itself. This is how the shop floor keeps the register current without a separate reporting circuit.

The connecting cycle

The three levels together form a continuous improvement cycle. Strategic sets the boundaries, tactical analyses and treats, operational executes and measures, and the reporting line upwards feeds the adjustments, after which the board recalibrates the boundaries. A healthy rhythm looks like this: continuous detection at the operational level, quarterly updates of the register and tactical reporting, and an annual recalibration (and after major changes) of the risk analyses and the risk appetite through the management review.

For that management review, Kantyra bundles the picture in a management report that provides a current overview at any moment: the top risks and risk levels, progress on the Statement of Applicability, the incident trend of the past twelve months and the open and overdue tasks.

Where does risk management sit in the Kantyra model?

The classic process model from ISO 31000 and ISO 27005 draws risk management as a layered cycle. At its core sits the risk assessment: establishing the context, identifying risks, analysing them and evaluating them. Around it follow risk treatment and continuous monitoring and review, and along the entire cycle runs one axis that connects everything: risk communication and information about risk.

Put that process model next to the Kantyra model and you see the same cycle with different labels. The risk assessment, from context to evaluation, is the assess phase. Risk treatment, with the four treatment options and the controls that follow from them, is the resolve phase. Monitoring and review, fed by incidents, vulnerabilities and indicators, is the detect phase. And the communication axis, continuously informing board, regulator and auditor, is the demonstrate phase.

There is one essential difference, and it lies in the starting point. The ISO model starts at the top, with the context: it reasons from the analysis towards practice. The Kantyra model starts at the bottom, with detection: it reasons from practice towards the analysis. That is a deliberate choice, because the most common defect in risk management is not a missing analysis, but an analysis that is no longer fed by what actually happens. Risk management therefore does not sit in one phase of the Kantyra model; it is the cycle of the model, applied to risks.

Connecting to other processes

Risk management stands or falls with its connections to the processes around it. A useful design principle: every process should either feed the risk register or execute treatment from it. As soon as a process does neither, it has come loose from risk steering.

The information security management system

Risk management is the engine of the ISMS, not an adjacent process. ISO 27001:2022 requires in clause 6 that you design the risk assessment and risk treatment, with the treatment plan and the Statement of Applicability (which connects risks to controls) as mandatory outcomes, and in clause 8 that you also carry out that assessment periodically and after major changes. The management review in clause 9 is the formal moment at which the risk picture receives board-level follow-up.

Incident management

Incidents are materialised risks. Every significant incident should lead to the question: was this risk in the register, was the probability estimate right, and did the controls work? Conversely, risk scores determine the priorities and escalation thresholds in incident handling. Under the Cbw, the legal reporting duty is added, with an early warning within 24 hours, a notification within 72 hours and a final report within one month, and that places demands on the operational detection and triage chain. In Kantyra you mark such an incident as reportable: the register calculates the deadlines from the moment of occurrence and signals when a deadline passes without the corresponding step being recorded.

Change management

Every significant change should go through a risk assessment before it is approved. This is where "security by design" becomes practical: a change that affects the CIA classification or the threat profile leads to an additional risk analysis of the differences, rather than a completely new analysis.

Business continuity and crisis management

The business impact analysis (BIA) and the risk analysis are sister instruments. The BIA determines what the organisation can at most do without, expressed in recovery times and maximum data loss. The risk analysis determines how likely a disruption is. Availability risks from the register feed the continuity plans, and exercises return findings to the register. In Kantyra, both analyses sit as templates in the same assessments module and share the same risk register, in which continuity risks have their own category.

Supplier and supply chain management

Outsourcing moves a risk, but does not remove it. Procurement and contract management are therefore execution channels of risk treatment: classification-dependent requirements in tenders, data processing agreements, exit arrangements and a periodic review of critical suppliers. The Cbw explicitly places supply chain security with the organisation itself, so supplier risks belong as full entries in the register, and not in a separate list at procurement. In Kantyra you therefore link suppliers directly to the risks in the register, and every supplier gets a periodic review that automatically returns as a task.

Privacy and the GDPR

The DPIA is methodologically a risk analysis from the perspective of the data subject rather than the organisation. Arranged well, the DPIA and the information security risk analysis share the same intake, classification and register structure, with the central privacy officer as the second-line role alongside the CISO and the data protection officer as independent reviewer. In Kantyra both sit as templates in the same assessments module, with the same review round. Data breaches follow the same incident process, with their own notification route to the Dutch Data Protection Authority; in the incident register you record whether an incident was a data breach and whether it was reported to the regulator.

Compliance and audit

Compliance translates legal and contractual requirements, such as the Cbw, the GDPR and where applicable DORA, into mandatory controls and minimum risk boundaries. Audit independently verifies that the risk process works as described. Audit findings are a structural source of input for the register; in Kantyra they have their own findings register with follow-up.

Asset management

Without a current overview of systems, data and owners, you analyse risks on an incomplete playing field. In practice this is the most underestimated dependency: the quality of your risk picture is never better than the quality of your administration of assets and processing activities. In Kantyra you therefore give every asset an owner, a data classification and a CIA score, and link it to the risks that rest on it.

Awareness and HR

People are a dominant factor in virtually every risk analysis. Awareness programmes are therefore a fully-fledged risk treatment measure, provided you measure them at the right level: completion rates only prove that the training was taken, not that behaviour changes. Research into measuring and reporting security awareness shows that the willingness to report is the best predictor of risk reduction, with click rates as a supplementary but murky measure. HR processes such as onboarding, offboarding and screening are also operational controls that follow directly from the register.

Frequently asked questions about risk management

What is the difference between risk appetite and risk tolerance? The risk appetite is the board's qualitative statement about how much risk the organisation is willing to run per domain. The risk tolerance makes that measurable: the limit above which a residual risk may only continue to exist with formal board-level acceptance.

What are the four treatment options for a risk? You can reduce a risk with controls, avoid it by stopping the activity or arranging it differently, transfer it through insurance or a supplier, or formally accept it when it falls within the tolerance and the risk owner signs.

How often should you update a risk analysis? A healthy rhythm is continuous detection at the operational level, quarterly updates and reporting of the register, and an annual recalibration (and after major changes) of the analyses and the risk appetite through the management review.

What is the difference between a risk analysis, a BIA and a DPIA? The risk analysis assesses what could go wrong with the organisation's information provision. The BIA determines what the organisation can at most do without during a disruption, expressed in recovery times. The DPIA assesses the same kind of questions, but from the perspective of the person whose personal data is processed. Methodologically they are sister instruments that can share one register structure.

Is a risk matrix actually reliable? A matrix has known limitations, but remains the most workable instrument for making risks comparable across the organisation, provided you use one fixed scale and justify the scores. We take a closer look at what the research says in a separate article.

In closing

When you organise risk management along these three levels, with working escalation and reporting routes between them and clear interfaces to the surrounding processes, it changes from an annual obligation into the steering mechanism of your information security. The register then stops being a filing exhibit for the auditor and becomes the living document on which board, CISO and operations share the same reality. And that is precisely what the Cbw asks of organisations: demonstrable, board-supported risk steering that runs all the way to the shop floor.

Getting started with risk management in Kantyra

Would you rather not manage your risk register in loose files, but in one environment where risks, controls, incidents and the Statement of Applicability are connected? In Kantyra the register calculates the scores automatically, the platform guards reviews and acceptances, and the management report delivers the board-level picture for the management review. Request a demo and discover how the cycle from detect to demonstrate works in practice.

Kantyra is a Dutch ISMS and GRC platform that lets organisations manage their information security, risk management and continuity demonstrably, in line with ISO 27001, ISO 22301 and the Dutch Cyber Security Act.