On paper, everything is in order: the guidelines have been written, the NIS2 gap analysis is done and every task has been ticked off in green. But does anyone know what happens when a vulnerability is found in a critical system? Information security is only truly managed once documents turn into everyday practice.
The topic was discussed in a Granite webinar by Jukka Mäkitalo, GRC Consultant, and Kasper Kälviäinen, Customer Success Lead, who heads Granite’s customer team. This article brings together the key lessons from the webinar: what an effective information security management system (ISMS) requires, what role documentation plays, and what managing information security looks like in practice in Granite’s risk management system.
Ticking off standards is not management
Mäkitalo often comes across the same misconception: a certificate and a pile of documents are taken to be the management system. In reality, standards and regulations such as ISO 27001, NIS2 or the CRA merely set requirements for the management system. If a standard requires incidents to be handled, a process description is not enough. The organisation must also act according to the process, and this must be verifiable afterwards.
“Requirements are the starting point for management, but on their own they do not yet produce results.” – Jukka Mäkitalo
A typical example comes from NIS2 projects. The gap analysis task list reads: ensure there is a handling process and a reporting channel for incidents. The organisation sets up a security@ address, records it in a document and ticks off the task. Management is told that NIS2 has been taken care of. Nobody asks whether the reports are ever handled or whether they lead to any follow-up action. The same pattern easily repeats with other requirements, and the purpose of the law or requirement, improving information security, is never achieved.
What does an effective information security management system look like?
An effective management system can be recognised by decisions that show up in what people actually do. Risks have owners, incidents are handled and fixes are seen through to completion.
According to Mäkitalo, an organisation must be able to answer six questions:
- What are we protecting? Systems, processes and services, and how they depend on one another.
- What threatens them? Is the service exposed to the open internet? Is the supplier based abroad?
- How are the risks managed? Often through the very controls of ISO 27001 or NIS2, which makes the requirements framework a risk management tool in itself. Beyond these, there are many risk-specific measures that the frameworks do not directly address, and the organisation has to resolve them on its own.
- Who is responsible? Every risk and every action has a named owner.
- Do the safeguards work? Are incidents and vulnerabilities detected, and are they fixed? What do audits and tests reveal?
- How do we demonstrate the situation? Evidence of the work done, a report available at any time, and an up-to-date picture for management.
When processes run in a system designed for the purpose, the person responsible does not have to dig out the guidelines every time. They can see at a glance what is open, what is critical and what is overdue. The system then supports putting the management system into practice.
A management system built solely on documents, gap analyses and tasks ticked off once does not deliver what it should. “If nothing has been done about the risks, it means you don’t really have a functioning management system,” says Jukka Mäkitalo.
What does information security documentation do in practice?
Documentation sets out how the organisation has promised to operate. It makes ways of working visible and gives auditors something to compare against. What a document cannot tell you is whether those promises are kept. “Documentation is essential, but management only happens through action,” says Jukka Mäkitalo.
According to Mäkitalo, an auditor wants to know three things:
- What has been agreed? Policies, processes and guidelines.
- Is that how things are done? For example, have incidents been handled within the deadline?
- Does it work? Did the risk decrease once the action was taken?
Ideally, every change is logged automatically in the management system, which makes the work done easy to demonstrate. The auditor can then also see clearly what has been left undone. If an incident has sat unhandled for months, the auditor will notice, and the reason can be worked out together. “In the auditor’s eyes, nothing has happened that hasn’t been recorded,” says Kasper Kälviäinen.
Kälviäinen points out that recording things should not be done for the auditor’s sake. Writing a practice down often brings its weaknesses to light. He compares it to an expert who only truly understands their subject once they can explain it to others.
Managing information security in Granite’s GRC system
The idea behind Granite’s GRC system is simple: all the pieces of information security sit in one place and are linked to each other. From a system in the asset register, you can see its related risks; from a risk, you can see the ISO 27001 and NIS2 requirements that control it, along with open tasks and actions already completed.
In practice, this means:
- Requirements reduce risk. Once the organisation has decided to implement the ISO 27001 controls, they appear under the risk and lower the risk level. The requirements framework is not a separate checklist but part of risk management.
- Responsibility lies where the knowledge is. System owners take care of their own risks and tasks. The security team does not need to, and should not, own everything, but it monitors that information security is being delivered.
- Everyday work builds into a management view. The risk picture of the entire organisation comes together automatically as a report, without a separate round of data collection.
According to Kälviäinen, the same model can also be extended to other areas of risk management. Information security then becomes part of overall security rather than an island of its own.
Example: securing a digital customer service
In the webinar, Mäkitalo presented a fictional organisation’s digital customer service, through which customers and staff handle enquiries and contracts. The service is critical to the organisation, and in the example Mäkitalo acted as its owner.
- The asset is recorded. The customer service is listed in Granite’s asset register, together with its description and dependencies. This also meets the NIS2 requirement to know your operating environment and its critical systems.
- Risks are linked to the asset. The service’s risks are visible from within it: staff fail to follow guidelines, the software has a vulnerability, a server fails. One of the risks is an attack on the cloud service the organisation uses.
- Controls are linked to the risk. Under the cloud service risk, you can see the ISO 27001 control on information security for cloud services, as well as the NIS2 requirements that affect the risk. Because the organisation already implements them, they reduce the risk without any separate action, but their implementation must also be verified for the customer service.
- A gap becomes a task. If the existing measures are not enough, a task is created for the risk, with an assignee and a deadline. The aim is to reduce the likelihood or the impact of the risk. A task can also be assigned directly to the system.
- Impacts are assessed. The business impact analysis shows what an outage of the service would mean and how quickly the situation would become intolerable. The service in the example sits at the second-highest level on the scale, meaning critical. When there are hundreds of systems, only a shared model makes the assessments comparable and shows which functions are the organisation’s top priorities to protect.
- Disruptions are prepared for. A business continuity plan, “Information system disruption”, is attached to the customer service. It sets out when the plan is activated, who is responsible and what is done. When a disruption occurs, the course of action is already defined and the organisation can quickly adapt its operations. Tests of the plan are also recorded, so the auditor can be shown when the plan was exercised and whether any findings were made.
- Management sees the whole picture. When every system owner works the same way, the reporting view brings together the organisation’s functions and information security risks in order of criticality. Management can see, for example, the 20 biggest risks and the critical systems, and make investment decisions on that basis.
According to Mäkitalo, a purely document-based information security management system does not properly answer any of these points. It usually only describes how things were planned. When the management system is brought into an information system and actively maintained, it can instead show how things are actually done.
Without a shared tool, it remains a mystery how information from a system owner’s daily work ever reaches top management.
How to get started with information security risk management
There is no need to take everything on at once. Mäkitalo suggests starting with, for example, two tools: information security risk management and incident reporting. Every organisation needs them, and they are the most important in day-to-day work. As operations mature, you can add an asset register, for instance, and link risks directly to systems.
Kälviäinen sums it up: start with whatever delivers the most value first, and build out the whole gradually. It is worth remembering, however, that obligations such as those under NIS2 may already require much broader information security management. The operating environment, for example, must then be identified, and information security risk management alone will not meet the requirement.
Checklist for risk management professional
- Test what is actually happening. Pick one item marked as complete in your gap analysis. Can you show that it has been acted on over the past three months?
- Give every risk an owner. Push responsibility out to system owners rather than piling everything on the security team.
- Link requirements to risks. Show which risk each ISO 27001 or NIS2 requirement reduces.
- Record unfinished work too. A visible problem can be prioritised; a hidden one cannot.
- Assess systems against the same criteria. Impacts, recovery times and criticality in a single model.
- Test continuity plans and record the tests. An untested plan will not convince auditors or other stakeholders.
- Update documents to match practice. Once a new way of working proves itself, bring it into your policies and guidelines.
- Let management’s situational picture grow out of everyday work. A report compiled separately is already out of date by the time it is finished.