Building a supplier inventory for NIS2, step by step

Guide sub-steps 6-1-1 through 6-1-4 describe what goes into the inventory: mandatory fields, tier criteria, risk profile contents, governance requirements. What they do not describe: how to find suppliers missing from the GDPR RoPA, how a classification session works in practice, which risk profile fields are hard to fill and where to find the information, and what distinguishes a formal approval from a file named "Inventory_final_v3.xlsx". That is what this article covers.

Result: fully classified supplier inventory v1.0 – Tier-1 risk profiles complete, management-approved, inventory owner named, update system active.

Step 1 – Building the Complete Supplier List

The guide rightly identifies the GDPR Record of Processing Activities (RoPA) as the starting point – every processor listed there is in NIS2 scope. The problem: the RoPA only captures suppliers in an Article 28 GDPR processor role. Three categories are systematically absent.

• SaaS providers without a processor role: Monitoring platforms, security scanners, CI/CD services – no Article 28 relationship, but potentially direct system access or business-critical dependency.
• IaaS providers as sub-processors: AWS, Azure, or GCP often appear in the RoPA only as a sub-processor of a processor, not as a standalone entry. NIS2 assesses actual dependency: if your regulated service runs on AWS, AWS is a Tier-1 candidate regardless of who appears as contracting party in the RoPA.
• Software vendors with auto-update mechanisms: No GDPR relationship, but de facto privileged system access – an update process with system rights is an independent attack path (→ A-31).

To close these gaps systematically, you need three search routines in addition to the RoPA export.

Search Routine 1 – Cost Centre Scan

Export all IT-related line items from the accounting system for the past 12 months, plus credit card statements for all IT cost centres. You are looking for recurring payments to software and cloud vendors. What matters is not the merchant name (e.g. "AWS Marketplace") but the underlying service – one line item can contain several SaaS products.

Typical findings: monitoring-as-a-service, penetration testing platforms, developer tools, department-level SaaS subscriptions that bypassed the IT procurement process.

Search Routine 2 – Firewall Outbound / DNS Log

A 30-day snapshot of outbound connections shows which external services your systems communicate with regularly. No packet capture analysis required: a DNS query log or firewall policy report with a unique-destination list is sufficient.

What you are looking for: recurring connections to domains not in the RoPA – particularly update servers (pattern: update.[vendor].com, cdn.[vendor].com), telemetry endpoints of installed software, and API endpoints from SaaS integrations. Most common finding from this routine: software vendors with auto-update that appear in no other source list.

Search Routine 3 – Structured Interviews

The cost centre scan finds what is paid for. The interview finds what is used without being formally procured.

• IT and DevOps: "Which external services do you use for deployment, monitoring, testing, backup?" Common findings: GitHub Actions runners on external servers, external log aggregators, cloud backup services.
• Business departments (HR, Finance, Marketing): "Which tools do you use that you did not raise an IT ticket for?" Common findings: HR software with personnel records, marketing automation platforms with CRM integration.
• Procurement: "Which software licences or service contracts do not run through the IT cost centre?" Common findings: industry-specific software maintenance contracts, outsourcing contracts with implicit system access.

Keep a brief record: two sentences per conversation – date, person, key points. The interview is part of the inventory build and therefore auditable.

Output Step 1: complete raw list of all suppliers with data source ("RoPA", "Cost centre scan", "Firewall log", "Interview [department]"). The source column is not cosmetic – it documents that scope was systematically established.

Step 2 – Tier Classification: How the Decision Actually Works

The tier criteria are clear: Tier 1 for direct privileged access or high-sensitivity data, Tier 2 for indirect dependencies, Tier 3 for no meaningful exposure. What the guide does not describe: how a classification session runs in practice, which questions in which order move decisions forward, and how to handle edge cases and disagreement.

Who Must Be in the Session

• ISB/CISO: chairs the session and makes the formal decision when there is disagreement.
• IT Manager: knows system access paths, network architecture, and technical dependencies.
• Business unit lead (for SaaS applications): knows what business data actually lives in the system. Without this input, data criticality for SaaS suppliers cannot be reliably assessed – and Tier 1 vs. Tier 2 for data-access suppliers becomes guesswork.

The Three Decision Questions in the Right Order

For each supplier – in this order:

1. System access – type and depth? (administrative / read-only / API / physical / no direct access)
2. Data access – does it involve assets rated "high" or "very high" in the protection requirements analysis from Step 2-2?
3. Operational dependency – what happens if this supplier is completely unavailable for 72 hours?

The third question is the most underestimated. A cloud IaaS provider without privileged direct access is still Tier 1 if your regulated service runs exclusively on that infrastructure and no short-term failover exists. Access type alone is not a sufficient classification criterion.

The Justification Line – Concrete Examples

Every classification decision needs a one-line justification in the inventory. Without it, the inventory is not auditable – the result is recorded, but the reasoning is invisible.

Not auditable:

• "Tier 2 – not a critical supplier"
• "Tier 1 – important cloud provider"

Auditable:

• Tier 2: "Access exclusively via support ticket system, no direct system access, processed data rated normal in protection requirements analysis v2.1, outage has no operational impact within 72h"
• Tier 1: "Production database on AWS RDS eu-central-1, no failover site available within 72h, outage would directly interrupt Service X (rated high)"
• Tier 1: "SaaS HR system holds personnel records for all employees (rated high), no direct system access, but high-sensitivity data access and operational dependency for payroll processing"

Document Disagreement – Not Suppress It

If ISB and IT Manager disagree on a supplier: the ISB makes the formal decision, and the dissent is documented in one sentence. An undocumented shadow consensus is harder to defend in a BSI supervisory proceeding than a documented decision that overrides a minority position.

Output Step 2: fully classified supplier list – every row with a justification line and the date of the classification session.

Step 3 – Tier-1 Risk Profiles: Where to Find the Information

The risk profile is not a full assessment – that follows in Step 6-2 (→ B-14). It is a structured snapshot: what is already known about this supplier before the questionnaire process begins? The three fields where inventories consistently fall short are certifications, incident history, and sub-processors.

Security Certifications: The Scope Statement Trap

"Has ISO 27001" is not an auditable entry. The verification sequence:

1. Retrieve the certificate from the certification body's official database – not the supplier's PDF. DAkkS (dakks.de) lists all accredited German bodies; international bodies can be verified via the IAF database (iaf.nu). The official database also shows whether a certificate has been withdrawn.
2. Read the scope statement: does it cover the services the supplier provides to you? A certificate with scope "IT operations at data centre Site A" does not cover a SaaS platform delivered from Site B.
3. Record the expiry date and the date of the last surveillance audit. ISO 27001 certificates run for three years, with annual surveillance audits. A certificate without a recent surveillance record is a snapshot up to two years old.

BSI C5 Type II is equivalent to ISO 27001 for IaaS/PaaS providers. SOC 2 Type II – not Type I, which is a point-in-time snapshot – is equivalent for international SaaS providers when not older than 12 months.

No valid certificate or scope mismatch: enter "No valid certificate covering services provided – open item for Step 6-2". Do not leave blank.

Known Incidents: What "No Known Incidents" Must Mean

A blank field is not an auditable statement – it is unclear whether the question was asked at all. Search three sources systematically:

• BSI-CERT warning archive: bsi.bund.de/cert – search by supplier name and product names.
• ENISA Threat Landscape Reports: for incidents involving major providers with EU relevance.
• Supplier status page (annual archive): For SaaS and IaaS providers, the most direct source. Most providers maintain a public incident log with a historical archive.

What the inventory entry must say: "No known incidents; checked: BSI-CERT warning archive, ENISA Threat Landscape 2022–2024, [Supplier] status page annual archive; search conducted [DD.MM.YYYY]." That is an auditable result. "No incidents known" without source references is not.

Sub-Processors: When You Do Not Know Them

For processors in the RoPA: Article 28 GDPR obliges the processor to disclose their sub-contractors. Use this obligation – submit a request and file the received list as an inventory annex.

For non-processor suppliers: enter "Sub-processors not known; disclosure request planned for Step 6-2 questionnaire." No blank field. A blank field means the question was not asked – a different finding than "unknown, being followed up."

SPOF Assessment: One Question, Binary Answer

Is a functional replacement available within 72 hours if this supplier is completely unavailable? Yes / No / Unclear. For "No" or "Unclear": mark as SPOF in the inventory. The detailed analysis follows in Step 6-2 and in A-33 – only the marking is needed here, not the full concentration risk assessment.

Output Step 3: all Tier-1 risk profiles complete, or with documented open items for Step 6-2.

Step 4 – Approval and Governance: What Concretely Counts

The guide requires formal approval by management or CISO, versioning, a named inventory owner, and an update process. What it does not describe: what "formal approval" specifically means – and what does not qualify.

The Two Valid Approval Modes

• Option A – Signature on the cover sheet: Management or CISO signs the inventory cover sheet. The document carries the approval directly – no searching through email archives.
• Option B – Minutes reference: The cover sheet records the date, meeting name, agenda item, and resolution of the session in which the inventory was approved. The minutes are filed as an annex. Both elements must be present.

Not sufficient: an email saying "looks good"; verbal approval; approval conveyed only by the filename. The cover sheet must contain at minimum: document title, version number (v1.0), creation date, inventory owner (name and role), and the approval record.

Inventory Owner: What the Assignment Means

Name and role on the cover sheet – not "IT department", not "ISB role". The owner initiates event-triggered updates, is responsible for the annual review, and reports the update status to management. If the person is not named, the process cannot be managed at the next trigger.

Operationalising the Update Triggers

The five event-triggered update conditions (→ A-31) remain dead text unless embedded in a running system. Three options:

• ITSM integration: Every new supplier contract as a change request; the change form includes a mandatory field "Inventory update required". If yes: automatic task to the inventory owner. Most robust option because the trigger is created where the work originates.
• Recurring calendar entry: Annual review as a recurring appointment for the inventory owner – with a direct document link. Without a link, no calendar reminder reliably leads to opening the right file.
• Procurement gate: Procurement notifies the inventory owner by email template on every new supplier contract. Five mandatory fields: supplier name, service description, system access (yes/no), contract duration, contract reference. Simplest option when no ITSM is in place.

Output Step 4: inventory v1.0 with cover sheet, approval documented, inventory owner named, update system active.

What You Have After These Steps

After these four steps you have:

1. Complete, classified supplier list (Tier 1/2/3) with a justification line and data source for every entry
2. Tier-1 risk profiles with documented certification status (scope verified), incident history (sources documented), and SPOF assessment
3. Management-approved supplier inventory v1.0 with cover sheet, named inventory owner, and active update system
4. BSI-auditable compliance artefact for Section 30(2) No. 4 BSIG – complete basis for Steps 6-2 and 6-3

Next: B-14 (Setting up supplier assessments – questionnaire and risk rating for your Tier-1 suppliers) · A-33 (Supply chain concentration risk – deepening the SPOF flags from this inventory)