Your cloud provider fell victim to ransomware. Your ERP vendor had a data breach. The printer company had a backdoor in their firmware. In each of these scenarios - your supplier’s problem becomes your problem. And that’s exactly why NIS2 requires organizations to formally manage supply chain security.
Quick Navigation
- What does NIS2 say about supply chain?
- Why is this a challenge for organizations?
- How to conduct a vendor audit?
- Vendor categorization by risk
- Security questionnaires - how to do them right
- Vendor Scorecard - assessment and monitoring
- Security clauses in contracts
What does NIS2 say about supply chain?
Article 21(4) of the NIS2 Directive
The NIS2 Directive requires essential and important entities to implement cybersecurity risk management measures, including:
“Supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.”
This is not a suggestion - it’s a legal requirement, with penalties of up to EUR 10 million or 2% of annual turnover for non-compliance.
What does this mean in practice?
You must:
- Identify all ICT (Information and Communication Technology) suppliers
- Assess the risk associated with each vendor
- Have procedures for selecting and monitoring vendors
- Require specific security standards from suppliers
- Be able to demonstrate this to auditors/regulators
It’s not enough to:
- Have a vendor list in Excel without risk assessment
- Send a questionnaire once and forget about it
- Include a clause saying “vendor ensures security” without specifics
📚 Read the complete guide: SOC: Security Operations Center - czym jest, jak działa, jak wybrać
Why is this a challenge for organizations?
The scale problem
An average company has 100-300 ICT vendors:
- Cloud (AWS, Azure, Google Cloud)
- SaaS (Salesforce, HubSpot, Slack, Zoom)
- ERP/CRM (SAP, Microsoft Dynamics)
- Infrastructure (Dell, HP, Cisco)
- Software (Adobe, Microsoft, specialized)
- Services (printers, telephony, internet)
- IT subcontractors (software house, helpdesk)
Auditing each one separately takes hundreds of work hours that the IT team doesn’t have.
The competency problem
Sending a security questionnaire is one thing. But:
- How do you verify if the answers are truthful?
- How do you assess if a vendor’s ISO 27001 certificate is “good”?
- How do you compare vendor A’s risk vs vendor B’s?
- What do you do when a vendor refuses to respond?
The silo problem
- Procurement signs contracts without consulting IT
- IT doesn’t know about all SaaS used by the business (Shadow IT)
- Security has no visibility into vendor contracts
- Legal doesn’t understand the technical security aspects
How to conduct a vendor audit?
Step 1: ICT vendor inventory
Information sources:
- Procurement department - list of contracts and invoices
- Finance department - payments to IT vendors
- IT - systems, licenses, integrations
- Security - list of VPN connections, API keys
- Network scan - what external services are being used
What we collect for each vendor:
- Name and contact details
- Type of service/product
- What data they process (personal, business, critical?)
- Do they have access to our network?
- Who owns the relationship (business owner)
- Contract start and expiration dates
Step 2: Categorization by risk
You can’t treat a cloud provider the same as a pen supplier. Categorization allows you to focus resources where the risk is greatest.
| Category | Criteria | Examples |
|---|---|---|
| Critical | Access to critical data, single point of failure, no alternative | Cloud provider, ERP, core banking |
| High | Access to sensitive data, significant impact on operations | CRM, email, HR system |
| Medium | Limited access, replaceable | Collaboration tools, monitoring |
| Low | No data access, minimal impact | Printers, telephony, office supplies |
Step 3: Assessment by category
For Critical vendors:
- Full security questionnaire (100+ questions)
- Interview with vendor representative
- Certificate verification (ISO 27001, SOC 2)
- OSINT - checking incident history
- Review of security clauses in the contract
- On-site audit (optional for the largest)
For High vendors:
- Extended questionnaire (50-80 questions)
- Certificate verification
- OSINT
For Medium vendors:
- Simplified questionnaire (30 questions)
- Basic verification
For Low vendors:
- Minimal or no verification
- Standard contract clauses
Vendor categorization by risk
Vendor risk matrix
We use two dimensions for categorization:
Dimension 1: Impact
- What data does the vendor process?
- How critical is the service to operations?
- Is there an alternative/backup?
Dimension 2: Likelihood
- What is the vendor’s security maturity?
- Has the vendor had incidents in the past?
- How large is the attack surface?
IMPACT
Low Medium High
┌─────────┬─────────┬─────────┐
High │ Medium │ High │ Critical│
├─────────┼─────────┼─────────┤
LIKEL. │ Low │ Medium │ High │
Medium ├─────────┼─────────┼─────────┤
Low │ Low │ Low │ Medium │
└─────────┴─────────┴─────────┘Example categorization
| Vendor | Service | Data | Impact | Likelihood | Category |
|---|---|---|---|---|---|
| AWS | Cloud infrastructure | All | Critical | Low (SOC 2) | High |
| Software house X | App development | Code + test data | High | Medium | High |
| Printer company | MFP printers | Scanned documents | Medium | High | Medium |
| ISP | Internet connection | N/A | Medium | Low | Low |
Security questionnaires - how to do them right
Structure of a good questionnaire
Section 1: General information
- Certificates and audits (ISO 27001, SOC 2, PCI DSS)
- Insurance policies (cyber insurance)
- Incident history
Section 2: Governance
- Do they have a CISO / person responsible for security?
- Do they have security policies?
- How often are they updated?
Section 3: Technical security
- MFA for system access
- Data encryption (at rest, in transit)
- Backup and disaster recovery
- Patch management
- Monitoring and logging
Section 4: Physical security
- Data center location
- Physical access control
- Redundancy
Section 5: Incident management
- Do they have an incident response plan?
- SLA for incident notification
- How do they handle breaches?
Section 6: Compliance
- GDPR - are they a processor/controller?
- Data location (EU/US)
- Subprocessors
Verifying responses
Don’t trust - verify:
OSINT (Open Source Intelligence):
- Search for vendor + “breach” / “hack” / “leak”
- Check Have I Been Pwned for the domain
- Review forums and social media
Certificate verification:
- Request a copy of the ISO 27001 certificate (not just a statement)
- Check the certification scope (it doesn’t always cover what you’re buying)
- Verify in the certification body’s registry
Follow-up interview:
- For critical/high vendors - schedule a call
- Ask deeper questions
- Assess maturity (do they know what they’re talking about?)
Vendor Scorecard - assessment and monitoring
Scoring model
Each vendor receives a score on a 1-5 scale (or A-E) based on:
| Area | Weight | Questions |
|---|---|---|
| Governance | 20% | Policies, CISO, training |
| Technical security | 30% | MFA, encryption, patching |
| Incident management | 20% | IR plan, SLA, communication |
| Compliance | 15% | Certificates, GDPR, audits |
| History | 15% | Incidents, reputation |
Acceptance thresholds
| Score | Rating | Action |
|---|---|---|
| 4.0 - 5.0 | Excellent | Accept, review every 24 months |
| 3.0 - 3.9 | Good | Accept, review every 12 months |
| 2.0 - 2.9 | Acceptable | Conditional acceptance, improvement plan, review every 6 months |
| 1.0 - 1.9 | Poor | Reject or exit strategy |
| < 1.0 | Critical | Immediate action (termination or escalation) |
Continuous monitoring
Assessment is not a one-time project:
Ongoing:
- Incident alerts (Google Alerts, threat intelligence)
- Certificate change monitoring
- Feedback from internal users
Quarterly:
- Critical vendor review
- Scorecard update for vendors with improvement plans
Annually:
- Full re-assessment of all High and Critical vendors
- Categorization update (new services, business changes)
- Board report
Security clauses in contracts
Minimum contractual requirements
Every ICT vendor contract should include:
1. Security requirements:
- Compliance with specific standards (ISO 27001, CIS Controls)
- Data encryption
- Access control and MFA
- Backup and disaster recovery
2. Right to audit:
- Ability to conduct security audits
- Access to SOC 2 / ISO 27001 reports
- Right to ask questions and request evidence
3. Incident management:
- SLA for incident notification (e.g., 24h)
- Cooperation in case of incident
- Post-incident report
4. Subcontractors:
- List of subprocessors
- Notification of changes
- Same requirements for subcontractors
5. Termination:
- Data return or destruction
- Transition period
- Confirmation of data deletion
Example clause
“The Supplier commits to: (a) maintaining ISO 27001 certification for services covered by the Agreement throughout its duration; (b) notifying the Client of any security incident concerning Client data within 24 hours of detection; (c) allowing the Client to conduct a security audit once a year upon prior agreement of the date.”
Summary
Supply chain audit is not a one-time project - it’s a continuous process. NIS2 requires:
- Inventory - you know who your ICT vendors are
- Categorization - you know which ones are critical
- Assessment - you know each one’s security level
- Monitoring - you track changes and incidents
- Documentation - you can demonstrate this to auditors
Organizations that don’t have resources to run this process internally can consider outsourcing to specialized partners offering Vendor Risk Management services.
Need support with supply chain auditing? We take over the entire process - from inventory to scorecard. Contact us to discuss details.
Related Terms
Learn key terms related to this article in our cybersecurity glossary:
- CSPM (Cloud Security Posture Management) — CSPM (Cloud Security Posture Management) is a category of cloud security tools…
- Security Operations Center (SOC) — Security Operations Center (SOC) is a central location where a team of security…
- SOC as a Service — SOC as a Service (Security Operations Center as a Service), also known as…
- Cybersecurity Incident Management — Cybersecurity incident management is the process of identifying, analyzing,…
- Cybersecurity — Cybersecurity is a collection of techniques, processes, and practices used to…
Learn More
Explore related articles in our knowledge base:
- SZBI and the KSC NIS2 supply chain: How should the CISO build and implement procedures and manage supplier risk?
- NIS2 national implementation: how the directive is changing cybersecurity law across Europe
- Security Audit for Startups: A Practical Checklist for Small Businesses
- What Are the Main NIS2 Directive Requirements? Comprehensive Guide for Regulated Entities
- A modern approach to monitoring IT environments - a guide
Explore Our Services
Need cybersecurity support? Check out:
- NIS2 Compliance - NIS2 directive compliance
- NIS2 Readiness Check - NIS2 readiness assessment
- Security Audits - comprehensive security assessment
Related topics
See also:
