During a recent audit at a client in the energy sector, we came across an Excel spreadsheet titled “IT Vendor List.” It contained 47 entries, and next to 31 of them in the “security status” column, the word “OK” had been entered manually by someone who had long since left the company. When I asked what “OK” meant — silence. Nobody knew when anyone had last verified it. Nobody knew whether the vendors had ever received a security questionnaire at all. And nobody knew that three entries on that list were companies that had ceased to exist more than a year ago.
This is not an exceptional case. It is the norm in Polish organisations that are only now — under pressure from NIS2 and the amendment to the Act on the National Cybersecurity System — beginning to take the topic of ICT supply chains seriously. The client asked me directly: “Przemek, where do we start?” This article is the answer — not only for him, but for every CISO, compliance manager, and IT manager facing the same challenge.
Why has supply chain security become a regulatory priority?
For years the cybersecurity industry focused on protecting its own infrastructure — firewalls, intrusion detection systems, encryption of data at rest and in transit. Attackers adapted to this reality. Instead of storming the well-fortified walls of an organisation, they began entering through vendors — entities that the victim trusts and that have legitimate, often privileged access to its systems, data, and infrastructure. This attack vector proved incomparably more effective.
European regulators responded in advance to the growing trend. The NIS2 Directive, adopted in October 2022 and applicable under national implementations from October 2024, for the first time in the history of EU law imposes specific obligations on essential and important entities with regard to supply chain security management. These are not soft recommendations — they are hard legal requirements with penalties reaching 10 million euros or 2% of annual global turnover.
The scale of the problem that regulators sought to address is well documented. According to the ENISA “Threat Landscape for Supply Chain Attacks” report from 2021, in 66% of the analysed supply chain attacks, attackers focused on vendor code as the entry vector. That figure is not declining. In 2023, software supply chain attacks increased by 241% year on year according to Sonatype analyses. The European legislator drew a straightforward conclusion from this data: if you want to protect critical infrastructure, you must protect not only yourself, but the entire ecosystem that sustains it.
An organisation’s security is now synonymous with the security of its weakest vendor. NIS2 requires you to measure, document, and improve this.
The regulatory motivation has another dimension that is rarely discussed: a geopolitical one. The NIS2 Directive and the related CRA (Cyber Resilience Act) are the EU’s response to the risk associated with European critical infrastructure’s dependence on vendors from outside the Union — particularly in the context of hardware and software from countries with a different risk profile. Article 22 of NIS2 concerning coordinated security risk assessments of ICT supply chains at the EU level is a direct expression of this strategic concern.
📚 Read the complete guide: NIS2: Kompletny przewodnik po dyrektywie NIS2 - obowiązki, kary, terminy
What requirements does NIS2 and the KSC amendment impose on ICT vendors?
Article 21 of the NIS2 Directive obliges essential and important entities to implement cybersecurity risk management measures, explicitly covering “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” This wording is key — it refers to relationships with direct suppliers, but simultaneously implies the need to understand and manage fourth-party risk (the vendors of vendors).
Poland’s implementation of NIS2 — the amendment to the Act on the National Cybersecurity System (KSC) — goes one step further and makes requirements more specific. The draft Article 8a of the KSC Act includes obligations to develop and implement a supply chain security policy, to regularly assess the risk posed by providers of ICT services, ICT products, and managed services, and to introduce mechanisms for verifying that vendors meet minimum security requirements. Importantly, the KSC amendment provides for the possibility of supervisory authorities issuing decisions to exclude specific vendors from the market if they pose an unacceptable risk to national security.
In practice, this means that every essential or important entity must be able to answer several specific questions that an auditor or supervisory authority will ask. Have you inventoried all your ICT vendors? Have you assessed the risk associated with each of them? Do you have documented vendor selection criteria from a security perspective? Do your vendor contracts contain security clauses, audit rights, and requirements for incident notification? Do you monitor vendor security on a continuous basis?
Simply having an ISO 27001 certificate at your vendor does not fulfil NIS2 requirements. You must document your own risk assessment, your own contractual requirements, and your own monitoring.
It is also worth knowing that NIS2 refers to ENISA guidelines on ICT supply chain risk assessment and to the standards of the European Union Agency for Cybersecurity. ENISA published dedicated guidelines in 2023 — “Good Practices for Supply Chain Cybersecurity” — which effectively become an interpretive guide for supervisory authorities during inspections. Organisations unfamiliar with these guidelines may be unpleasantly surprised by the scope of the regulator’s expectations.
The most important mindset shift that NIS2 enforces is the transition from a one-off “check the vendor when signing the contract” approach to a continuous, integrated Third-Party Risk Management (TPRM) process. This is not a project with a completion date — it is a permanent element of an organisation’s operating model.
How to conduct a vendor risk assessment — a practical framework?
During client audits I always start with the same question: “Show me your list of critical ICT vendors.” The answer says a great deal about an organisation’s maturity. If the list exists, is up to date, and includes a risk assessment — we are in a good position. If someone has to run to the procurement department for a printout of last year’s invoices — we have real work to do.
A practical vendor risk assessment framework consists of four stages that must be executed sequentially.
Stage 1: Inventory and classification. Compile a complete list of ICT vendors from all sources: procurement, invoices, contract registers, IT Asset Management, network scanning for external connections, and the GDPR data processing register. For each vendor determine: the type of product or service provided, what data it processes (especially personal and business-critical data), whether it has access to your network or systems, what level of integration it has with your infrastructure, and who internally owns that business relationship.
Stage 2: Categorisation by risk. You do not assess all vendors the same way — that would be a waste of resources. The key is to assign vendors to risk categories based on two dimensions: impact (what happens if the vendor fails or is compromised?) and likelihood (how mature is the vendor’s security, and how large is its attack surface?). A typical division uses four categories: Critical, High, Medium, Low. Critical vendors are those on whom the continuity of key services depends or who process the most sensitive data.
Stage 3: Assessment proportionate to category. The scope of the assessment must be proportionate to the classified risk. A Critical vendor requires a full security questionnaire, certificate verification, an interview with a representative, OSINT analysis, and a review of contractual clauses. A Low vendor requires a standard clause in the contract and annual incident monitoring. Applying a uniform approach to all vendors is one of the most common mistakes, leading either to resource overload or to overlooking critical risks.
Stage 4: Scoring and documentation. Assessment results must be translated into a measurable risk indicator (Vendor Risk Score) and documented together with the rationale for the decision to accept, conditionally accept, or reject the vendor. This documentation is your evidence during a supervisory authority audit.
A vendor assessment framework must be a living document — not a one-off project. Every change in the vendor’s scope of services, every incident in the industry, every change of ownership at the vendor should trigger a re-assessment.
One issue organisations frequently overlook is fourth-party risk management. Your hosting provider may be an exemplary entity with ISO 27001 and SOC 2 Type II certification — but if it uses the services of a subcontractor that does not meet those standards, the risk is transferred to you. As part of the assessment of Critical vendors, I always ask: “Who is your critical subcontractor, and how do you verify them?”
What is an SBOM (Software Bill of Materials) and why is it becoming a standard?
A client from the financial sector recently asked me whether they needed to care about which open-source libraries are embedded in their vendor’s ERP system. My answer surprised them: yes, and that is exactly what a Software Bill of Materials is for.
An SBOM is a structured list of all the components that make up a piece of software — libraries, frameworks, modules, dependencies, and their versions. Imagine a list of ingredients on a food product label, but for code. When a new critical vulnerability appears — such as Log4Shell in December 2021 — an organisation that holds SBOMs from its vendors can check within hours which system is at risk. Without an SBOM this takes weeks of manual reviews that still do not guarantee completeness.
The significance of SBOMs is growing rapidly in the regulatory context. The CRA (Cyber Resilience Act), which is being phased in until 2027, places an obligation on manufacturers of software and network-connected devices to make SBOMs available to purchasers. This means that in a few years demanding an SBOM from a software vendor will become a market standard, not an exception.
An SBOM is not a one-off document. Every software update should generate an updated SBOM. It is worth explicitly writing into the requirements for Critical vendors an obligation to deliver a current SBOM with every new release.
In practice, SBOMs exist in several formats. The most popular are SPDX (Software Package Data Exchange), promoted by the Linux Foundation, and CycloneDX, developed by OWASP. Both are machine-readable, enabling automatic analysis and correlation with vulnerability databases such as NVD (National Vulnerability Database) and OSV (Open Source Vulnerabilities). Organisations that implement vulnerability management based on SBOMs are able to reduce the time to identify vulnerable components from weeks to minutes.
For most Polish organisations, SBOM is still an exotic concept. However, as part of an ICT vendor audit it is worth starting with at least two steps: first, include in the security questionnaire a question about whether the vendor is able to provide an SBOM; and second, for Critical software vendors, record in new contracts an obligation to make the SBOM available on request. This is an investment that will pay off at the first serious vulnerability in a popular library.
What questions should a vendor security questionnaire contain?
A good security questionnaire is not a list of 200 questions sent by email asking for a “yes/no” answer. It is a diagnostic instrument that gives you real insight into the vendor’s security level and allows you to compare results between vendors in a structured way.
The questionnaire should be proportionate to the vendor’s risk category and divided into logical sections. Below I present the key areas that must be included in every thorough questionnaire for Critical and High-risk vendors.
Section 1: Governance and security management. Does the organisation have a designated person responsible for information security (a CISO or equivalent function)? Is there a board-approved information security policy? How frequently is it updated? Are regular employee training sessions on cybersecurity conducted, and how is their effectiveness measured? Does the organisation hold ISO 27001 or SOC 2 certification, and what is the scope of that certification?
Section 2: Access and identity management. Is multi-factor authentication (MFA) applied for all access to systems processing customer data? What does the process of granting and revoking access look like (offboarding)? Is the principle of Least Privilege applied? How are privileged accounts managed (Privileged Access Management)?
Section 3: Technical security. What does the vulnerability and update management process look like (patch management)? Within what timeframe are critical vulnerabilities patched? Is encryption of data at rest and in transit applied — which algorithms? What is the network architecture and segmentation? Is security monitoring in place (SIEM/SOC), and what is the incident response time?
Section 4: Incident management. Does the organisation have a documented security incident management procedure? What is the time commitment for notifying customers of an incident affecting their data (SLA)? Are regular tests of the incident response procedure conducted? What security incidents have occurred in the past 24 months?
Section 5: Business continuity and disaster recovery. Is there a documented Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP)? How frequently are they tested? What recovery objectives (RTO, RPO) are defined for the services provided to customers?
Section 6: Vendor’s own supply chain security. Does the organisation apply formal security requirements to its own subcontractors? Who are the critical subcontractors involved in delivering services to our organisation? Are we informed of changes in the subcontractor pool?
When verifying responses, it is not sufficient to trust declarations alone. For Critical vendors, always ask for evidence: copies of certificates (not merely statements), reports from recent audits, results of recent penetration tests (executive summary). Trust, but verify.
For Critical vendors the questionnaire should be supplemented by an in-depth interview with the vendor representative responsible for security. This interview allows you to assess the maturity of the security culture — whether the answers are substantive and considered, or rather curt and defensive. A mature vendor is not afraid of questions about past incidents — on the contrary, it is happy to explain what it learned from them.
How to monitor vendor security on a continuous basis?
An assessment is a starting point, not a finish line. A vendor whose ISO 27001 certificate and questionnaire results are excellent today may fall victim to a serious attack tomorrow, or may change its operating model in ways that increase risk. Continuous monitoring is not only a NIS2 requirement — it is common sense.
Vendor monitoring can be divided into three intensity levels that should be assigned to the vendor’s risk category.
Basic level (Low and Medium vendors): Automated Google alerts for the vendor’s name combined with keywords such as “breach,” “hack,” “data leak.” Monitoring of entries on platforms such as HaveIBeenPwned for the vendor’s domain. A review of publicly available information on incidents every quarter. Annual verification of certificate validity.
Extended level (High vendors): Everything from the basic level, plus an annual repeat of the security questionnaire (abbreviated version). Verification that certificates are still valid and cover the services provided. A review of SOC 2 reports or ISO 27001 audit results provided by the vendor. Monitoring of the vendor’s external attack surface using tools such as SecurityScorecard, BitSight, or UpGuard.
Intensive level (Critical vendors): A full re-assessment annually or after every significant event (a vendor incident, change of ownership, change in scope of services). Continuous monitoring of the external attack surface. Participation in threat intelligence programmes specific to the vendor’s industry. Regular working meetings with the vendor’s security team (quarterly business reviews with a security agenda). Verification of the remediation plans from the previous assessment.
Automated vendor security scoring tools (Security Ratings) such as SecurityScorecard and BitSight assess an organisation’s public digital hygiene: open ports, DNS configurations, data leaks, malware activity. They do not replace an assessment, but they are an excellent early warning signal.
A key element of continuous monitoring is defining the events that trigger an immediate unscheduled re-assessment. These include: any publicly confirmed security incident at the vendor, a change of the vendor’s owner or a merger, information about significant changes in the vendor’s IT structure or subcontractors, and an external scoring tool result that falls below a defined threshold. It is also worth including Critical vendors in the internal incident management process — they should know how to contact you in the event of an incident affecting your data, and you should have a dedicated escalation channel to their security team.
What to do when a vendor does not meet security requirements?
This is the question that makes many security managers squirm with discomfort. What will you do when the ERP vendor on whom the entire company depends does not meet your security requirements? Reject them and shut down the business? Of course not. But that does not mean you are powerless.
The response to a vendor’s low assessment score depends on a combination of two factors: the vendor’s criticality to your business, and the nature and severity of the identified gaps. Below I present a practical approach across four scenarios.
Scenario 1: Low score, low vendor risk level. This is the simplest case. The vendor is not critical to you and can be replaced relatively easily. In this situation you formalise the requirements in the contract, set the vendor a deadline for improvement (typically 3–6 months), and monitor progress. If the requirements are not met within the set deadline, you consider changing the vendor.
Scenario 2: Technical gaps to be remediated, vendor willing to cooperate. This is the most common scenario in practice. The vendor is not perfect, but is aware of the problem and has the will to address it. You formalise the assessment results in a document listing “findings” and required “remediations.” You agree on a remediation plan with specific deadlines and success indicators. You incorporate the remediation plan into the contract or an addendum as a vendor commitment. You monitor progress quarterly.
Scenario 3: Critical gap at a Critical vendor. This situation requires immediate escalation. Example: the network management software vendor does not apply MFA for administrators and had a customer data breach a year ago. If the contract permits — you suspend the vendor’s access to your systems until the issue is remediated. You escalate the matter to board or CISO level on both sides. You launch an internal assessment of whether customer data is at risk. In parallel you analyse options for migrating to an alternative vendor.
Scenario 4: Vendor refuses to respond or cooperate. This is the highest-level warning signal. A vendor that refuses to respond to a security questionnaire or blocks audit rights is either hiding something or simply does not understand the regulatory environment we operate in. In either case this is unacceptable for a Critical or High-risk vendor. You document the refusal, escalate internally, and launch a migration project to an alternative vendor.
Audit rights and the vendor’s obligation to respond to security questions must be written into the contract before a problem arises. Negotiating these clauses after a contract has been signed is many times more difficult.
In this context it is worth speaking about the role of the legal and procurement departments. Supply chain security is not solely the task of the cybersecurity team. It requires close collaboration with lawyers who know how to write security requirements into a contract in enforceable language, and with the procurement department, which understands that a security assessment result is one of the vendor selection criteria — alongside price, quality, and delivery time.
What does a supply chain attack look like — anatomy of the SolarWinds incident and its lessons?
In December 2020 the cybersecurity world held its breath. FireEye — one of the most reputable firms in the industry — announced that it had detected an advanced intruder in its own systems. The investigation quickly revealed the scale of the disaster: the attackers, later identified as the Russian APT29 group (Cozy Bear), had embedded malicious code in the update mechanism of an IT monitoring platform — SolarWinds Orion. The victims? The US Departments of the Treasury, Defence, Homeland Security, and State, Microsoft, Intel, Cisco — and hundreds of other organisations around the world.
The attack mechanism was elegant in its simplicity and insidious in its consequences. The attackers compromised SolarWinds’ development environment and injected a backdoor (known as SUNBURST) into legitimate Orion software updates that were cryptographically signed with a SolarWinds certificate. Organisations downloading the updates — following the good habit of keeping software current — were simultaneously installing an advanced spyware tool. The backdoor communicated with C&C servers via normally-appearing HTTPS traffic, effectively bypassing most traditional network security controls.
The attack went undetected for approximately nine months. During that time the attackers had access to the internal systems of thousands of organisations. The scale of the potential data leak remains difficult to estimate to this day.
The lessons from the SolarWinds incident are fundamental for anyone building a supply chain security management programme.
Lesson 1: A trusted distribution channel is a premium target. Software update mechanisms, open-source libraries, developer tools — each of these channels is a potential supply chain attack vector. An attacker knows that if they compromise a trusted channel, they will bypass most of the organisation’s security controls. This requires verifying not only the end product, but the entire software development process (SDLC — Software Development Lifecycle).
Lesson 2: A cryptographic signature is a necessary but insufficient condition for trust. The SUNBURST files were signed with a legitimate SolarWinds certificate. Verifying a digital signature — while necessary — does not protect against the scenario in which an attacker gains access to the signing key or injects malicious code before the signing stage. SBOMs and behavioural analysis of software are additional layers of protection.
Lesson 3: The principle of least privilege is critical. The scope of the SolarWinds damage was so enormous because many organisations had granted SolarWinds Orion tools excessive privileges within their IT environment — after all, it is a monitoring tool, it needs to “see” everything. Analysing what privileges each vendor tool has within your environment is a mandatory element of the assessment.
Lesson 4: Detection time (dwell time) is critical. Nine months of an undetected attack. No security system is capable of eliminating the possibility of a breach — but you can drastically reduce the time an intruder operates undetected. This requires investment in behavioural monitoring and advanced threat-hunting capabilities, not only in perimeter defences.
Lesson 5: Third-party risk management must be a process, not a checklist. Many organisations affected by SolarWinds had an “approved” vendor in an Excel spreadsheet. But nobody asked the question: “What do we do if this approved vendor is compromised?” Scenarios involving “vendor as attack vector” must be part of business continuity planning and tabletop exercises.
The SolarWinds incident changed the way supply chain security is thought about forever. Every software update, every new library release — is a potential vector. Security must be built into the development process, not only into the end product.
Similar — though less publicised — incidents have also occurred in Europe and Poland. The attack on Kaseya VSA in 2021 affected Polish companies using managed IT services through Kaseya partners. The compromise of the XZ Utils library in 2024 showed that even a fundamental component of the Linux ecosystem can be the target of an advanced supply chain attack. These are not academic incidents — they are real risks for every organisation using any external software.
How to build supply chain resilience — a maturity model?
An organisation’s maturity in ICT supply chain security management can be described using a five-level model that allows both an assessment of the current state and a definition of the direction of development. The maturity model below is based on practical experience from audits and combines elements of NIST SP 800-161 (Supply Chain Risk Management Practices for Federal Information Systems), ENISA guidelines, and the C-SCRM (Cyber Supply Chain Risk Management) framework.
| Level | Name | Characteristics | Key actions |
|---|---|---|---|
| 1 — Initial | Ad hoc | No formal process. Vendors are not systematically inventoried or assessed. Security is addressed reactively, after incidents. | Create an ICT vendor register. Identify 3–5 Critical vendors. Basic security clauses in new contracts. |
| 2 — Repeatable | Managed | A vendor register and basic risk categorisation exist. Security questionnaires are sent to key vendors, but the process is not fully formalised or regular. | Formalise the TPRM process. Standard security questionnaire. Annual re-assessment of Critical vendors. Basic contractual clauses. |
| 3 — Defined | Documented | A formal, documented TPRM process integrated with the procurement process. Security requirements are part of vendor selection criteria. Vendor Risk Score is monitored. | Full integration of TPRM with procurement. Monitoring of the external attack surface. Remediation plan as a standard for non-compliant vendors. Training for the procurement department. |
| 4 — Managed | Measured | The TPRM process is measured using KPI indicators. Continuous monitoring with automation. Security requirements include SBOM. Fourth-party risk is taken into account. Tabletop exercises with supply chain scenarios. | Deploy automated vendor scoring tools. SBOM requirements in contracts with software vendors. Regular tabletop exercises with a “compromised vendor” scenario. |
| 5 — Optimising | Continuously improving | The organisation actively participates in industry information-sharing programmes (ISAC, CERT). Supply chain risk management is integrated into business strategy. Security requirements are verified through penetration tests and red team exercises. | Participation in industry threat intelligence programmes. Security requirements for vendors’ SDLC processes. Regular on-site audits of Critical vendors. Vendor certification programme. |
During audits of clients in Poland, the overwhelming majority of essential and important entities hover around levels 1–2 of this model. NIS2 effectively requires a minimum of level 3 — which means most Polish organisations have significant work ahead of them. The good news is that moving from level 1 to level 3 does not require enormous budget investment — it primarily requires a formal process, appropriate policies, and people’s commitment.
It is also worth emphasising that the maturity model is a tool for communicating with the board. Instead of the abstract “we are not compliant with NIS2,” you can say: “We are at level 2. NIS2 requires level 3. Here is a specific action plan with a budget and timeline.” This is language that C-level executives and the supervisory board understand.
How does nFlo support organisations in ICT vendor auditing?
At nFlo we have completed more than 500 projects for more than 200 clients, a significant portion of which concerned exactly third-party security management and NIS2/KSC compliance. Over the years we have developed an approach that effectively addresses the real challenges faced by organisations — from a lack of internal resources and difficulty verifying vendor responses, to the need to document the entire process for the regulator.
Our support in ICT vendor auditing covers several key areas. First, comprehensive execution of the TPRM process from scratch — from vendor inventory and categorisation, through the design of risk-proportionate questionnaires, to scoring and a results report ready to be presented to a regulator or supervisory authority. Second, verification of vendor self-assessment results — we verify whether vendor declarations are backed by reality, using OSINT tools, external attack surface scoring, and analysis of publicly available information.
Third, support in contractual negotiations — our team prepares template security clauses adapted to Polish law, NIS2 requirements, and the specifics of the relationship with a particular type of vendor. Fourth, implementation of continuous vendor monitoring using automated security scoring tools and incident alerting — so that your team is informed of threats before they turn into a crisis.
Our response time of under 15 minutes and 98% client retention speak for themselves — we build long-term relationships based on trust and real results, not one-off projects. If you are facing the implementation of a TPRM programme or want to check whether your current programme meets NIS2 requirements, we would be happy to talk.
FAQ — Frequently asked questions
Does NIS2 apply to all companies in Poland?
No, NIS2 applies to essential and important entities as defined in the directive and its national implementations. In Poland these will primarily be organisations from the following sectors: energy, transport, banking, financial market infrastructure, healthcare, drinking water, wastewater, digital infrastructure, ICT service management, public administration, and space. In addition the directive may cover providers of digital services above certain size thresholds. If you are not sure whether your organisation falls within the scope of NIS2, a legal consultation or readiness audit will resolve the matter.
How frequently should vendor re-assessments be conducted?
The frequency of re-assessment should be proportionate to the vendor’s risk category. Critical vendors — at least once a year, and additionally after every significant event (a vendor incident, change in scope of services, change of ownership). High-risk vendors — once a year. Medium-risk vendors — every two years. Low-risk vendors — every three years or upon contract renewal. It is important to remember that a vendor’s risk category can change over time — a vendor that was “Low” may become “Critical” after the scope of their services is expanded.
Do external security scoring tools (e.g. SecurityScorecard) replace a questionnaire?
No, these tools are complementary rather than interchangeable. SecurityScorecard, BitSight, and UpGuard assess the vendor’s external, publicly visible attack surface — open ports, DNS configurations, publicly available data breach history, malware activity. They are excellent tools for continuous monitoring and early warning signals. But they will not tell you whether the vendor has an incident response plan, how it manages privileged access, or how it verifies its own subcontractors. A questionnaire and an in-depth interview are indispensable for that.
What to do if a key vendor refuses to complete the security questionnaire?
A refusal by a key vendor to participate in an assessment is a signal of serious risk and must be documented. As a first step it is worth escalating the matter to the level of the business relationship — the refusal often comes from the legal department, which fears liability for declarations, rather than from the security department. In many cases vendors accept alternative forms of verification: providing a SOC 2 Type II report or an ISO 27001 certificate whose scope covers your services. If the vendor still refuses any form of verification and is a Critical vendor for you — you have a problem requiring escalation to the board and the launch of a migration plan.
What do the sanctions for failing to manage supply chain security under NIS2 look like?
The NIS2 Directive provides for sanctions for essential entities of up to 10 million euros or 2% of annual global turnover (whichever is higher). For important entities — up to 7 million euros or 1.4% of annual turnover. Importantly, Article 20 of NIS2 introduces personal liability for management, including the possibility of a temporary ban on holding managerial positions for persons responsible for violations. In the Polish implementation (KSC amendment) sanctions may be additionally supplemented by national administrative penalties.
Sources
- ENISA (2021). Threat Landscape for Supply Chain Attacks. European Union Agency for Cybersecurity. https://www.enisa.europa.eu/publications/threat-landscape-for-supply-chain-attacks
- ENISA (2023). Good Practices for Supply Chain Cybersecurity. European Union Agency for Cybersecurity. https://www.enisa.europa.eu/publications/good-practices-for-supply-chain-cybersecurity
- Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 (NIS2). Official Journal of the European Union, L 333.
- NIST (2022). Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. NIST SP 800-161 Rev. 1. National Institute of Standards and Technology. https://csrc.nist.gov/publications/detail/sp/800-161/rev-1/final
- Sonatype (2023). 9th Annual State of the Software Supply Chain Report. Sonatype Inc.
- CISA, NSA, FBI (2021). Joint Advisory: Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations (SolarWinds). Cybersecurity and Infrastructure Security Agency.
- OWASP (2023). CycloneDX Software Bill of Materials Standard. Open Web Application Security Project. https://cyclonedx.org/specification/overview/
- Linux Foundation (2023). System Package Data Exchange (SPDX) Specification v2.3. https://spdx.dev/specifications/
Related concepts
Explore key terms related to this article in our cybersecurity glossary:
- NIS2 — NIS2 (Network and Information Security Directive 2) is an EU directive imposing cybersecurity requirements on essential and important entities.
- Cybersecurity — Cybersecurity is a set of techniques, processes, and practices for protecting IT systems, networks, and data.
- SOC 2 — SOC 2 is an AICPA audit standard that evaluates controls for security, availability, processing integrity, and confidentiality.
- Encryption — Encryption is the process of converting data into ciphertext that is unreadable without a decryption key.
- SIEM — SIEM (Security Information and Event Management) is a platform for collecting, correlating, and analysing security events in real time.
Learn more
Explore related articles in our knowledge base:
- NIS2 supply chain audit: How to manage ICT vendor risk?
- ISMS and KSC NIS2 supply chain: How should a CISO build and implement procedures and manage vendor risk?
- How to conduct a KSC NIS2 readiness audit? A practical guide for CISOs
- Software supply chain attacks — supply chain security
- IT security audit — a complete guide
Check our services
Do you need cybersecurity support? See:
- NIS2 Compliance — compliance with the NIS2 directive
- NIS2 Readiness Check — NIS2 readiness assessment
- Security audits — comprehensive security posture evaluation
- Vendor risk management — Third-Party Risk Management (TPRM)
Related topics
See also:
- NIS2 for hospitals — implementation and funding
- Security Audit Pricing Calculator
- NIS2 for hospitals — compliance
