SZBI and the KSC NIS2 supply chain: How should the CISO build and implement procedures and manage supplier risk?

The implementation of KSC/NIS2 has its “showy” moments. Management listens intently when you talk about risks and sanctions. The CTO looks forward to the architecture upgrade and SIEM implementation. But the real long-term success – or failure – of a KSC/NIS2 implementation lies elsewhere. It lies in the painstaking, glare-free and absolutely critical work: the procedural challenge. We’re talking about building a complete Information Security Management System (ISMS) and operationalizing something that for many companies is a complete novelty – supply chain risk management (SCRM).

As a CISO, you know that technology without procedures is useless. The best 24/7 SOC system won’t help if the incident response procedure is unclear and the business continuity plan is non-existent. The regulator, coming in for an inspection, will first ask for just the “paperwork” – policies, procedures, risk registers and evidence of their implementation. This is your compliance backbone. This article is a practical guide on how to build and maintain it, focusing on the two most difficult elements: CMS and SCRM.

What is an Information Security Management System (ISMS) in the context of KSC/NIS2?

Information Security Management System (ISMS) is a concept that many managers mistakenly equate with a “policy folder” or an ISO 27001 certificate hanging on the wall. In the context of KSC/NIS2, an ISMS is something much deeper. It is the central nervous system of risk management in an organization. It is a formal set of policies, procedures, processes and standards that collectively define how an organization approaches the protection of its information.

The KSC/NIS2 requirement to have an ISMS means that a company must move away from “intuitive” and reactive security management. It must implement structured, repeatable and measurable processes. The ISMS is based on the Deming cycle (Plan-Do-Check-Act) – you must plan your safeguards (based on risk analysis ), implement them, regularly check their effectiveness (through audits and monitoring ) and continuously improve them.

Having a CMS is not an option, it’s a hard legal requirement. For CISOs, it is an essential tool for the job. It is within an ISMS that you formalize processes such as incident management, access control or business continuity. In practice, a KSC/NIS2 implementation is the implementation or major upgrade of an existing ISMS to cover all the new stringent requirements.

Many organizations choose ISO 27001 as the foundation of their ISMS because it is a globally recognized standard that provides a ready-made structure and set of controls. Implementing an ISMS that complies with this standard is the best way to document to the regulator that the company has approached security in a systematic and professional manner.

Why are ready-made policy and procedure templates a trap?

The first temptation facing any CISO under time pressure is to buy a “ready-made KSC/NIS2 documentation package” or download ISO 27001 templates from the Internet. This is a shortcut that almost always leads to failure. The problem with templates is that they are generic. Meanwhile, KSC/NIS2 does not require the implementation of generic safeguards. It requires the implementation of measures “appropriate and proportionate” to the individually assessed risks.

A template security policy that does not take into account the specifics of your business is worthless. A manufacturing company with an extensive OT network has different risks, and an e-commerce company that is 100% cloud-based has different risks. An incident management procedure copied from a template will not reflect your real-world organizational structure, the technologies you have (e.g., SIEM/SOC ) or the established communication channels.

An auditor or regulator will immediately pick up that the documentation is “dead” – that it is a set of theoretical wishes that do not translate into operational reality. Such a CMS will not pass any serious scrutiny. Documentation must be “tailor-made.” It must result directly from your company’s risk analysis and describe the processes that you have actually implemented and that your team understands and can execute.

That’s why GRC partners like nFlo don’t sell templates. They conduct workshops, analyze processes and develop documentation together with the client so that it is a true reflection of the organization and an effective management tool, not just a “launching pad” for an audit.

What key documents (policies, procedures) are absolutely mandatory?

While the entire ISMS must be “tailor-made,” the KSC/NIS2 Act and best practices (like ISO 27001) point to a set of fundamental documents that must be in every organization. As a CISO, you must treat this list as your minimum.

First, the framework documents. At the top is the Information Security Policy. This is the overarching document, approved by the board, that defines the organization’s goals, direction and commitment to security. Next to it must be the Risk Analysis Policy, which defines your methodology (e.g., in accordance with ISO 27005 ) – how you identify assets, how you estimate risk and what your risk appetite is.

Second, the key policies and operating procedures that the law places special emphasis on. The absolute “must-haves” are:

• Incident Management Procedure: The heart of the response system, crucial to the 24-hour requirement.
• Business Continuity Plan (BCP) and Disaster Recovery Plans (DRP): Responding to the requirement to maintain continuity of service delivery.
• Supply Chain Security Policy (SCRM): Formal policies for ICT supplier security.
• Access Control Policy: Who, when, and what they can access.
• Cyber Security and Training Policy: How you educate employees on security.

On top of that, there are a number of other important documents, such as asset management policies, cryptographic policies, human resources security policies and vulnerability management procedures. Each of these documents must not only be written, but also formally approved by the board, communicated to employees and implemented.

How to implement and test a Business Continuity Plan (BCP) in practice?

Having a Business Continuity Plan is one of the most critical requirements of KSC/NIS2. Simply writing a document and hiding it in a drawer is an easy way to incur penalties in the event of an incident. The value of the BCP lies in its testing. As a CISO, you must operationalize this process.

The first step is to conduct (or update) a Business Impact Analysis (BIA). You need to define the critical processes and services together with the business owners, and then determine two key metrics for them: RTO (Recovery Time Objective – how fast does the service need to return?) and RPO (Recovery Point Objective – how much data can we lose?). This is the foundation of BCP.

The second step is to develop recovery plans (DRPs) for the IT/OT systems that support these critical processes. The plan must be specific: who makes the decisions? What are the procedures for restoring from backups? Where is the backup location? What are the phone numbers for key people and suppliers?

The third, and most important, step is testing. KSC/NIS2 explicitly requires testing of contingency plans. You need to schedule and regularly conduct tests. You start with table-top exercises, where you simulate a crisis (e.g., “we lost the main server room, what do we do step by step?”) among managers and specialists “in the dry”. Then you move on to technical testing – real attempts to restore systems from backup, preferably in an isolated environment. Only in this way will you build a real ability to survive the crisis and have hard proof for the regulator.

How to operationalize incident management procedures to work in tandem with the SOC?

The Incident Management Procedure is the second pillar of resilience. It is absolutely critical to meeting the 24-hour reporting requirement. If your company uses a third-party SOC, this procedure becomes an operational contract between your team and the SOC analysts.

The procedure must not be vague. It must be a precise “playbook. “ It must clearly define:

1. Detection and Classification: What events are considered an incident? What are the priority levels (P1-P4)? Who (the SOC analyst or your administrator) does the initial classification?
2. Escalation: This is the heart of the process. When a SOC analyst detects a P1 incident (e.g., ransomware) at 3:00 a.m., what should he do? Who exactly should he call? What are the first, second and third numbers on the list? Who has the authority to wake you up as a CISO or even a board member?
3. Response and Containment: Who has the authorization to take action? Does the SOC analyst have the authority to isolate an infected workstation from the network himself? Who makes the decision to cut off an entire network segment or critical server?
4. Reporting: Who in your organization is responsible for preparing and sending a formal report to the CSIRT within 24 hours? This must be a clearly identified person (or role), supported by the legal and technical team.

Like the BCP, this procedure must be tested. Regular exercises simulating an incident, conducted in conjunction with the SOC team, are essential to check that communication channels are working, that people know their roles and that decisions are being made quickly enough.

What exactly does “supply chain risk management” (SCRM) mean under the Act?

This is one of the biggest and most difficult revolutions that KSC/NIS2 introduces. Until now, purchasing departments have chosen IT vendors based mainly on price, functionality and SLAs. The new regulations make it clear: the organization is responsible for the security used by its ICT vendors. Your responsibility no longer ends with your firewall.

Supply Chain Risk Management means that you need to proactively assess, monitor and manage the risks that external partners bring to your business. This includes any vendor that has access to your data, systems or network – from your cloud provider (AWS, Azure), to the company that develops software for you, to your ISP, to your local printer maintenance company if it has remote access.

In practice, KSC/NIS2 requires you to implement a complete SCRM process that includes identifying critical suppliers, assessing their security levels (through audits and questionnaires), and then enforcing specific security requirements through appropriate provisions in contracts. This is no longer a “good practice,” but a hard legal obligation that you will be held accountable for.

How do you start the process of auditing ICT vendors without severing business relationships?

Many CISOs are wary of this step. The vision of sending a 100-page security questionnaire to a long-time business partner seems like the beginning of a conflict. The key is to take a risk-based, partnership approach. You don’t have to audit every office paper supplier.

The first step is to inventory and categorize suppliers. You need to create a register of all ICT suppliers and categorize them into risk categories (e.g. Critical, Important, Low Risk). A critical supplier is one that has administrative access to your systems or stores your sensitive data. They are the ones you focus 90% of your efforts on.

The second step is communication and partnership. Don’t start by sending an audit. Start with a conversation. Make agreements with your key suppliers and explain to them that KSC/NIS2 applies to both of you – you as the key entity and them as the ICT service provider. Show that the goal is not to “squeeze” them, but to jointly secure the supply chain so that you both can continue to do business under the new legal regime.

Only then do you proceed to a formal evaluation. For low-risk suppliers, a self-assessment (questionnaire) may suffice. For critical suppliers, you will need hard evidence: their certifications (ISO, SOC 2), the results of their penetration tests, and in extreme cases, the right to conduct your own technical audit.

What technical and contractual requirements should be placed on key suppliers?

Your SCRM policy must translate into specific provisions in contracts. As CISO, you must work closely with legal and procurement to implement standard security clauses into all new and renewal contracts with ICT vendors.

These clauses are your security enforcement mechanism. At a minimum, they must include:

• Obligation to use specific measures: e.g., requiring provider administrators to use MFA, encrypting data, regularly patching vulnerabilities.
• Right to audit: A key provision giving you the right to verify supplier compliance (through questionnaires, inspections or technical audits).
• Incident reporting obligation: The provider must be contractually obligated to immediately inform you of any security incident that involves your data or services.
• “Downstream” management: Require your supplier to apply the same safety standards to its sub-suppliers.
• Contractual penalties and liability: Clearly define financial consequences for non-compliance with security requirements that lead to an incident.

Having such provisions in your contracts is hard evidence to the regulator that you are actively managing supply chain risk.

What is the “active” support in SCRM that nFlo is talking about?

Building and implementing an SCRM program is a gigantic resource burden for CISOs. Many companies simply don’t have the internal expertise or time to effectively audit their suppliers. “Active Support in SCRM,” which nFlo offers as part of its CORE Package, is the answer to this problem.

“Active” means that nFlo will not only help you develop policies and questionnaires (which is the standard for GRC consulting ). It means that nFlo experts will conduct audits on your behalf. Instead of sending your supplier a questionnaire whose answers you can’t verify, you send an nFlo technical auditor there.

This support is crucial in two areas. First, in procedural audits – a GRC expert from nFlo verifies the supplier’s documentation (do they have a CMS, BCP, etc.). Second, in technical audits – nFlo’s pentesters can (with approval) perform technical verification of the supplier’s security, giving you a real, not just paper, picture of its security. For you as a CISO, this is a huge time saver and reassurance that the assessment is conducted professionally.

How is the CISO supposed to prove to the board and regulators that the SMS actually works?

You’ve written policies, implemented procedures, audited suppliers. Now how do you prove that this system is not just “security theater,” but realistically works? KSC/NIS2, like ISO standards, is based on evidence. Your job is to collect and present this evidence.

First, the documentation must be “living.” You must show the version history of the documents, evidence of annual review and updating. You must show formal board approvals.

Second, you need to show “records” (records), that is, evidence that processes are being performed. This is not an incident management policy, but an incident log and incident handling reports. It’s not a Business Continuity Plan, but BCP test reports signed by participants. It’s not a SCRM policy, but completed questionnaires and supplier audit reports.

Third, you need to show metrics and results. These are reports from phishing tests showing a decrease in “click-through rates” , reports from vulnerability scanners showing a reduction in time to patch , or reports from the SOC showing response times to alerts. This is the hard data that shows management the return on investment in security and the regulator the due diligence.

Is a GRC partner necessary to build an effective CMS?

In theory, a CISO with a large and mature team could try to build an entire ISMS and SCRM program by himself. In practice, for 99% of organizations, this is extremely difficult, time-consuming and fraught with the risk of errors. Engaging a specialized partner in the GRC (Governance, Risk, Compliance) area is a strategic decision with tangible benefits.

First, experience and methodology. A GRC partner such as nFlo has already implemented a CMS in dozens of organizations. It has ready-made but flexible methodologies, proven processes, and understands how to interpret the Act’s requirements translated into different industries (e.g., manufacturing with OT or finance with DORA ). You don’t waste time “reinventing the wheel.”

Second, resources and “detachment from the day-to-day. “ Your team is busy putting out fires and maintaining systems. A GRC partner provides a dedicated team with the sole purpose of proving your ISMS implementation project on time. It acts as the PMO (Project Management Office) for your compliance program.

Third, authority and independence. A report and recommendation from an external, reputable partner has much more clout with the board. It’s easier for you to justify a budget for key controls (like SIEM/SOC ) when the recommendation comes from an independent audit, not just your internal request. A GRC partner is your strategic ally in the business conversation.

Procedural vs. Technical Challenge: CISO Accountability Table.

Successful implementation of KSC/NIS2 requires the CISO to balance activities in both areas. The following table synthesizes the key tasks.