How to Build an ICT Third-Party Risk Register for NIS2 Compliance
NIS2 Article 21 requires organisations to assess supply chain risk, including cloud provider dependencies. Here is a practical guide to building the register, with a concrete template and worked examples.
NIS2 (Directive 2022/2555) requires organisations in essential and important sectors to implement cybersecurity risk management measures that specifically address “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers” (Article 21(2)(d)).
This means you need a documented understanding of your ICT third-party dependencies, the risks they introduce, and the measures you have in place to manage those risks. Most organisations call this an ICT third-party risk register.
This post walks through how to build one, with a practical template and worked examples for the most common dependencies European organisations face.
What NIS2 Actually Requires
Article 21 of NIS2 lists 10 categories of cybersecurity risk management measures. Supply chain security is one of them. The Directive does not prescribe a specific format for the register, but the intent is clear: supervisory authorities will expect to see documented evidence that you have:
- Identified your critical ICT third-party providers. Not just the obvious ones (Microsoft, Google, AWS) but every service in the chain.
- Assessed the risks each provider introduces. Including concentration risk, jurisdictional risk, and operational continuity risk.
- Implemented proportionate measures. Contractual safeguards, diversification, contingency planning, or migration.
- Established monitoring and review processes. The register is not a one-time exercise. It must be kept current.
Recital 85 of NIS2 adds context: member states should encourage entities to “incorporate supply chain risk management measures into their contracts” and to “take into account the overall quality and resilience of products and services, the cybersecurity measures embedded in them, and the cybersecurity practices of their suppliers and service providers.”
The Register Structure
An effective ICT third-party risk register captures the following for each provider:
Provider Information
| Field | Description |
|---|---|
| Provider name | Legal entity name |
| Service description | What the provider does for your organisation |
| Contract reference | Internal contract/PO reference |
| Contract renewal date | When the agreement renews or expires |
| Provider jurisdiction | Country of the provider’s legal headquarters |
| Data processing locations | Where data is actually stored and processed |
| Sub-processors | Known sub-processors and their jurisdictions |
Dependency Assessment
| Field | Description |
|---|---|
| Business functions supported | Which departments and workflows depend on this provider |
| Data categories processed | Personal data, financial data, health data, IP, operational data |
| Criticality level | Critical, High, Medium, Low |
| Concentration risk | Is this provider a single point of failure? Do multiple critical functions depend on it? |
| Replaceability | Easy, Medium, Hard, Currently Not Replaceable |
| Estimated migration timeline | How long it would take to switch if needed |
Risk Assessment
| Field | Description |
|---|---|
| Jurisdictional risk | Is the provider subject to non-EU laws (CLOUD Act, FISA, etc.) that could compel data disclosure or service restriction? |
| Operational risk | What happens if the service becomes unavailable for 24 hours, 72 hours, or permanently? |
| Data protection risk | Does the provider’s data handling create GDPR compliance risks? |
| Lock-in risk | How difficult is it to exit the relationship? (Contractual, technical, operational barriers) |
| Supply chain depth risk | Does the provider itself depend on sub-processors that introduce additional risk? |
Measures and Controls
| Field | Description |
|---|---|
| Contractual safeguards | SLAs, data processing agreements, exit clauses, audit rights |
| Technical measures | Encryption, access controls, backup, monitoring |
| Organisational measures | Incident response procedures, escalation paths, regular reviews |
| Exit strategy | Documented plan for transitioning away from the provider |
| Residual risk | Risk remaining after all measures are applied |
| Risk owner | Named person accountable for monitoring this provider |
| Last reviewed | Date of most recent review |
Worked Example: Microsoft 365
Here is how a completed register entry looks for a typical Microsoft 365 deployment:
Provider Information
| Field | Value |
|---|---|
| Provider name | Microsoft Ireland Operations Limited (contracting entity for EU customers) |
| Service description | Email (Exchange Online), file storage (SharePoint/OneDrive), identity (Entra ID), collaboration (Teams), device management (Intune) |
| Contract renewal date | 1 March 2027 |
| Provider jurisdiction | United States (Microsoft Corporation, Redmond, WA). EU contracting entity is Microsoft Ireland Operations Limited. |
| Data processing locations | EU (Netherlands, Ireland). Microsoft’s EU Data Boundary commitment applies. |
| Sub-processors | Microsoft lists sub-processors at microsoft.com/licensing. Includes Azure data centre operators, support contractors, and third-party security vendors. |
Dependency Assessment
| Field | Value |
|---|---|
| Business functions supported | All departments. Email, file storage, identity/SSO, internal communication, calendar, device management. |
| Data categories processed | Personal data (employee and client), financial data (invoices, contracts), operational data (project files, internal communications) |
| Criticality level | Critical. Loss of Microsoft 365 would halt all operations. |
| Concentration risk | Very High. Identity, email, files, communication, and device management all depend on a single provider. |
| Replaceability | Hard. Identity layer (Entra ID) is deeply embedded. Email is replaceable. Files are replaceable with metadata loss. Teams is hard to replace without loss of history. |
| Estimated migration timeline | 6 to 12 months for a complete exit (identity migration is the bottleneck) |
Risk Assessment
| Field | Value |
|---|---|
| Jurisdictional risk | High. Microsoft is a US-headquartered company subject to the CLOUD Act (18 U.S.C. §2713). US law enforcement can compel disclosure of data regardless of storage location. Microsoft’s EU Data Boundary addresses data residency but not jurisdictional control. |
| Operational risk | Critical. A 24-hour outage would prevent all employee email, file access, calendar access, and SSO-connected application access. A permanent loss would require months of recovery. |
| Data protection risk | Medium-High. Transfer Impact Assessment (per EDPB Recommendations 01/2020) identifies CLOUD Act exposure as a residual risk not fully mitigated by SCCs or the EU-US Data Privacy Framework. |
| Lock-in risk | High. Multi-year enterprise agreement. Bundled pricing discourages partial exit. Identity and integration dependencies create significant switching costs. |
| Supply chain depth risk | Medium. Microsoft’s own supply chain (Azure infrastructure, certificate authorities, DNS, CDN) introduces additional dependencies not directly visible to the customer. |
Measures and Controls
| Field | Value |
|---|---|
| Contractual safeguards | Microsoft Products and Services Data Protection Addendum. SLA: 99.9% uptime for core services. Data processing agreement in place. |
| Technical measures | MFA enabled for all users. Conditional access policies configured. Regular backup of mailboxes via third-party tool (Veeam for M365). SharePoint backed up weekly. |
| Organisational measures | IT reviews Microsoft service health dashboard daily. Incident response procedure documents Microsoft outage scenarios. |
| Exit strategy | Not yet documented. (This is the gap NIS2 requires you to close.) |
| Residual risk | High. Concentration risk and jurisdictional risk remain after all current measures. No documented exit strategy. |
| Risk owner | CTO / IT Manager |
| Last reviewed | [current date] |
Worked Example: Cloudflare (DNS and CDN)
Provider Information
| Field | Value |
|---|---|
| Provider name | Cloudflare, Inc. |
| Service description | DNS hosting, CDN, DDoS protection for company website |
| Provider jurisdiction | United States (San Francisco, CA) |
| Data processing locations | Global edge network. EU traffic typically served from EU nodes, but request metadata may be processed in the US. |
Dependency Assessment
| Field | Value |
|---|---|
| Business functions supported | Website availability, email delivery (MX records), API endpoints |
| Criticality level | High. DNS failure makes website, email, and all internet-facing services unreachable. |
| Concentration risk | Medium. DNS is a single point of failure, but migration is fast. |
| Replaceability | Easy. DNS migration to a European provider (Hetzner, deSEC, Gcore) takes hours with proper TTL management. |
| Estimated migration timeline | 4 to 24 hours |
Risk Assessment
| Field | Value |
|---|---|
| Jurisdictional risk | Medium. Cloudflare is US-headquartered. DNS query data is metadata, not content, but it reveals which domains your organisation queries. |
| Operational risk | High for availability, low for data. Cloudflare outage makes services unreachable. No sensitive data is stored in Cloudflare. |
Measures and Controls
| Field | Value |
|---|---|
| Exit strategy | Documented. Zone file exported and stored locally. European DNS provider (Hetzner DNS) pre-configured as backup. Migration tested quarterly. TTL set to 300 seconds for fast propagation. |
| Residual risk | Low. Exit strategy is documented, tested, and executable within hours. |
Common Providers to Include
For a typical European organisation with 10 to 50 employees, the register should cover at minimum:
Critical / High:
- Primary productivity suite (Microsoft 365, Google Workspace)
- Identity provider (Azure AD, Google, Okta)
- Cloud hosting (AWS, Azure, GCP, Hetzner, OVHcloud)
- Email service (if separate from productivity suite)
- CRM (Salesforce, HubSpot, Pipedrive)
Medium:
- DNS provider (Cloudflare, Route 53, Hetzner DNS)
- Code repository (GitHub, GitLab, Bitbucket)
- Communication tools (Slack, Teams, Zoom)
- Project management (Jira, Asana, Monday.com, Linear)
- Payment processor (Stripe, Mollie, Adyen)
Lower but should be documented:
- Marketing tools (Mailchimp, HubSpot Marketing, ActiveCampaign)
- Analytics (Google Analytics, Plausible, Matomo)
- Design tools (Figma, Canva)
- HR/payroll (Personio, BambooHR)
- Accounting (Xero, QuickBooks, Exact)
Building the Register: Practical Steps
Step 1: Inventory. List every SaaS tool, cloud service, and third-party integration your organisation uses. Sources: browser bookmarks, SSO dashboard, finance records (what are you paying for?), IT admin consoles, and employee surveys (“what tools do you use daily?”).
Step 2: Classify. Assign a criticality level to each provider based on: what business functions depend on it, how many employees use it, and what happens if it disappears.
Step 3: Assess risks. For each provider, document jurisdictional risk, operational risk, data protection risk, and lock-in risk. Be specific. “High risk” without explanation is not useful to a supervisory authority.
Step 4: Document measures. For each risk, document what you are doing about it. Contractual safeguards, technical controls, and exit strategies. Where measures are missing, document that too, with a timeline for addressing the gap.
Step 5: Assign ownership. Each provider should have a named risk owner who is responsible for monitoring changes and triggering reviews.
Step 6: Schedule reviews. Review the register at least annually, and after any significant change: new provider onboarded, provider acquisition, regulatory change, or security incident.
What Supervisory Authorities Will Look For
NIS2 gives member state supervisory authorities the power to conduct audits, issue binding instructions, and impose fines. While enforcement is still ramping up across member states, the direction is clear.
A supervisory authority reviewing your NIS2 compliance will likely ask:
- Do you have a documented register of ICT third-party providers? Yes or no.
- Does it cover your critical and high-risk providers? Or only the obvious ones?
- Have you assessed concentration risk? Specifically, the risk of depending on a single provider for multiple critical functions.
- Do you have exit strategies for critical providers? Not aspirational plans, but documented, tested procedures.
- When was the register last reviewed? A register from 2024 that has not been updated is not compliant.
- Who is accountable? Named risk owners, not “the IT department.”
The organisations that will fare best are the ones that built the register before the supervisory authority asked for it. The ones that will fare worst are the ones that scramble to create one during an audit.
Getting Started
If you do not have a register today, start with your three most critical providers. Complete the full assessment for each one. That exercise alone will reveal gaps in your understanding of your own dependencies and give you a template for extending the register to the rest of your stack.
The register is a living document. It does not need to be perfect on day one. It needs to exist, it needs to be honest about where the gaps are, and it needs to improve over time.
Sovereign Shift delivers a complete ICT dependency register as part of every audit: every provider mapped, every risk scored, every alternative documented. See pricing and scope →