Most supplier registers stop at the suppliers you pay, so when a hosting provider, sub-processor or support subcontractor two steps down the chain is breached or fails, nobody can say quickly which services and data are affected. A fourth-party register records those indirect suppliers as attributes of each direct supplier relationship, scores them for criticality and aggregation, and sets triggers for review. This template gives you a register standard with numbered sections, a field list you can paste into a spreadsheet or TPRM tool, a scoring method, and monitoring triggers. It is for TPRM leads, privacy teams, procurement and resilience managers. For the reasoning behind fourth-party risk, read the Fourth-Party and Nth-Party Risk Guide first; this page does not repeat it.
How to use this template
- Bracketed timings, durations and thresholds are NHI Mgmt Group recommendations; adjust them to your risk appetite, policies and contracts.
- Replace the placeholders: text in square brackets, such as [Organisation] and [TPRM Lead], is yours to fill in.
- Start narrow: populate the register only for direct suppliers that support critical services or hold your personal data, confidential data or credentials. Extend later.
- Keep it inside the supplier register: each fourth-party row links to the direct supplier (tier 1) that uses it. Do not build a separate, unlinked list.
- Use the field list as columns: section 4 gives field names, definitions and allowed values. Mandatory fields are marked.
- Regulated firms: EU financial entities under DORA should align field names and ranks with the register of information templates in Commission Implementing Regulation (EU) 2024/2956. See the DORA ICT Third-Party Risk and Register of Information Guide.
1. Purpose
1.1 This standard sets out how [Organisation] identifies, records, scores and monitors fourth parties and further subcontractors (nth parties) that support services provided by its direct suppliers.
1.2 The register exists to answer four questions within [4 hours] of an external event: which direct suppliers use the affected fourth party; which of our services depend on them; what data or credentials it may hold; and who owns the response.
1.3 It supports [Organisation]'s obligations on sub-processors under UK GDPR and EU GDPR Article 28, and, where applicable, the subcontractor entries in the DORA register of information.
2. Scope
2.1 In scope are fourth and nth parties that:
- (a) process personal data on behalf of a processor of [Organisation] (sub-processors);
- (b) effectively underpin a service supporting a critical or important function of [Organisation], meaning their disruption would impair the security or continuity of that service;
- (c) hold or can use credentials, tokens, keys or network access that reach [Organisation]'s environment or data;
- (d) provide hosting, identity, DNS, content delivery, payment, managed security or support desk services to a tier 1 supplier in scope.
2.2 Out of scope: suppliers of a direct supplier that have no access to [Organisation]'s data, credentials or service delivery, for example a supplier's office cleaning contractor.
2.3 Software components inside purchased products are handled through the SBOM process, not this register. See the SBOM Guide.
3. Roles and responsibilities
| Role | Responsibility |
|---|---|
| [TPRM Lead] | Owns the register and this standard; runs the annual review; reports concentration findings |
| Supplier relationship owner | Obtains fourth-party disclosures from the tier 1 supplier at onboarding, renewal and on change notices |
| [Data Protection Officer] | Reviews sub-processor changes and objections; confirms transfer mechanisms |
| Security architecture | Records credentials and access paths held in the chain; validates external discovery findings |
| Business continuity | Uses concentration results in scenario tests and recovery planning |
| [Risk Committee] | Approves risk acceptance for high-aggregation fourth parties |
4. Register fields
4.1 Each row records one fourth or nth party in relation to one tier 1 supplier and one service. The same fourth party appears in several rows when several suppliers use it; that duplication is what makes aggregation visible.
| Field | Definition and allowed values | Mandatory |
|---|---|---|
| Row ID | Unique identifier, for example FP-0001 | Yes |
| Fourth party legal name | Registered legal name, not brand | Yes |
| Identifier | LEI or company registration number where known (DORA asks for an LEI or EUID for relevant subcontractors) | Where available |
| Registered address and contact | Address and a contact point. The EDPB says controllers should have name, address and contact person for all processors and sub-processors readily available | Yes for sub-processors |
| Tier 1 supplier | Link to the direct supplier record | Yes |
| Rank | Position in the chain: 2 for a supplier's direct subcontractor, 3 for the next level, and so on (the DORA templates rank the direct provider as 1) | Yes |
| Engaged by | The provider that passed the service on (for rank 3 and above) | Yes for rank 3+ |
| Service supported | Our service or business process that depends on it | Yes |
| Function provided | Hosting, identity, data processing, support desk, development, payment, managed security, communications, other | Yes |
| Critical or important function | Yes or No | Yes |
| Data held | None, personal, special category, confidential, payment, credentials | Yes |
| Credentials and access | OAuth tokens, API keys, service accounts, VPN or remote access, none | Yes |
| Processing and storage locations | Countries | Yes |
| Transfer mechanism | Adequacy, standard contractual clauses, IDTA, other, not applicable | For personal data outside UK/EEA |
| Source of information | Sub-processor list, assurance report, questionnaire, contract notice, external discovery, own tenant data | Yes |
| Assurance coverage | Included in tier 1 assurance report, carved out, separately certified, none known | Yes |
| Substitutability | Easy, difficult, not substitutable, unknown (as stated by the tier 1 supplier) | Critical rows |
| Criticality score, aggregation count, priority | Calculated per section 5 | Yes |
| Contract controls in tier 1 agreement | Prior authorisation, change notice, right to object, flow-down, incident notice covering subcontractors | Yes |
| Date verified and next review | Dates | Yes |
| Status | Active, proposed, objected, exited | Yes |
Example rows
| Row | Fourth party | Tier 1 | Rank | Function | Data and access | Source |
|---|---|---|---|---|---|---|
| FP-0001 | [Cloud Host A] | [Payroll SaaS] | 2 | Hosting | Personal data | Sub-processor list |
| FP-0002 | [Cloud Host A] | [CRM SaaS] | 2 | Hosting | Personal data, OAuth tokens | Assurance report (carved out) |
| FP-0003 | [Support Partner B] | [CRM SaaS] | 2 | Support desk | Admin access to our tenant | Questionnaire |
| FP-0004 | [Data Centre C] | [Support Partner B] | 3 | Hosting | Ticket data | Contract notice |
5. Criticality and concentration scoring
5.1 Score each row for criticality from 1 to 3 on each factor and use the highest factor as the row score:
| Factor | 1 (low) | 2 (medium) | 3 (high) |
|---|---|---|---|
| Service impact | No critical service | Supports an important but tolerant service | Supports a critical or important function |
| Data | None or public | Internal or limited personal data | Special category, payment, large-volume personal or confidential data |
| Access | None | Read-only or scoped tokens | Write or administrative access, broad tokens, network access |
| Substitutability | Easy | Difficult | Not substitutable or unknown |
5.2 Aggregation count: for each distinct fourth party, count the tier 1 suppliers in scope that depend on it, and separately count the critical services. Record both against every row for that fourth party.
5.3 Priority: P1 where criticality is 3 and aggregation is [3] or more suppliers, or any fourth party behind [2] or more critical services; P2 where criticality is 3 or aggregation is [3] or more; P3 otherwise. Thresholds in brackets are NHI Mgmt Group starting values; tune them to your supplier base.
5.4 P1 fourth parties are reported to the [Risk Committee] with a concentration statement, feed business continuity scenarios, and require either documented risk acceptance or a mitigation, such as a tested alternative, contractual resilience commitment or exit plan. See the Cloud Concentration Risk and Exit Strategy Guide and the Third-Party Risk Management Guide.
6. Collecting the data
6.1 Relationship owners collect fourth-party information at onboarding, at renewal and whenever a tier 1 supplier gives notice of a change. Use at least two sources for every P1 fourth party.
- Sub-processor lists: request the current list and subscribe to change notices. Under Article 28 the processor needs prior written authorisation (specific or general) and, under general authorisation, must tell you about intended changes and give you the chance to object.
- Assurance reports: record each subservice organisation named in a SOC 2 or similar report and whether its controls were included or carved out. See the SOC 2 Guide.
- Questionnaire: add these to the security questionnaire: hosting provider and regions; identity provider for staff access to customer data; outsourced support or development teams and their access to customer environments; where customer tokens and secrets are stored; managed security providers.
- Own tenant data: export connected apps and OAuth grants from your SaaS platforms and record the publisher and any hosting provider it discloses.
- External discovery: DNS, mail and certificate records show hosting, email and CDN providers. Treat findings as unconfirmed until the supplier confirms them.
6.2 DORA-regulated entities: the implementing regulation requires information on all subcontractors that effectively underpin ICT services supporting critical or important functions, linked to the provider that passed on the service. Article 29(2) of DORA also asks firms to weigh whether long or complex subcontracting chains could limit their ability to monitor the contracted functions.
7. Monitoring and triggers
7.1 Review cadence: P1 rows every [6 months], P2 rows annually, P3 rows at tier 1 renewal.
7.2 Event triggers. Any of the following starts a review within [5 working days], or within [4 hours] for an incident:
| Trigger | Action | Owner |
|---|---|---|
| Sub-processor change notice | Assess, record as proposed, object within the contractual window if unacceptable | [Data Protection Officer] |
| Public incident or outage at a fourth party | Query the register for every row, contact affected tier 1 suppliers, start the third-party incident process | [TPRM Lead] |
| Fourth party acquired or changes jurisdiction | Re-score, check transfer mechanism | Relationship owner |
| Assurance report carve-out found for a P1 row | Request separate evidence or compensating controls | Relationship owner |
| Aggregation count crosses the P1 threshold | Concentration statement to [Risk Committee] | [TPRM Lead] |
7.3 Incident queries must be answerable from the register alone: filter by fourth party name to list tier 1 suppliers, services, data and credentials, then revoke or rotate credentials held in the chain where exposure is possible. See the Third-Party Incident Response Playbook.
8. Exceptions, review and approval
8.1 Where a tier 1 supplier will not disclose fourth parties behind a critical service, record the row as "not disclosed", score substitutability and access as 3, and escalate for risk acceptance.
8.2 The [TPRM Lead] reviews this standard annually and after any significant fourth-party incident. Approved by [Risk Committee] on [date]. Version [1.0].
Implementation guidance
- Pick the first 20 suppliers: those behind critical services or holding the most sensitive data and credentials.
- Load what you already have: sub-processor lists and assurance reports usually cover most hosting fourth parties in the first pass.
- Run the aggregation query: group rows by fourth party. The first result often shows two or three hosting and identity providers behind most critical suppliers.
- Close contract gaps at renewal: add change notice, right to object, flow-down and subcontractor incident notice where missing. See the DORA Article 30 Contract Provisions Guide for a regulated example; DORA Article 30(2)(a) requires contracts to state whether subcontracting of services supporting critical or important functions is permitted and on what conditions.
- Exercise it: run a tabletop where a P1 fourth party fails and time how long the register takes to answer the four questions in 1.2.
Metrics
- Share of critical tier 1 suppliers with fourth parties recorded and verified in the last 12 months.
- Number of P1 fourth parties and the share with accepted risk or a tested mitigation.
- Time to answer the four incident questions in the last exercise or real event.
- Sub-processor change notices reviewed within the contractual window.
Framework mapping
| Register element | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| Suppliers known and prioritised | GV.SC-04 | SR-3 |
| Supplier risk understood and monitored | GV.SC-07 | SR-6, SA-9 |
| Contract requirements reach the chain | GV.SC-05 | SR-5 |
| Ongoing monitoring | GV.SC-07 | CA-7 |
Standards and references
- EUR-Lex: Commission Implementing Regulation (EU) 2024/2956, register of information templates
- EUR-Lex: Regulation (EU) 2022/2554, Digital Operational Resilience Act
- ICO: What needs to be included in the contract
- EDPB: Opinion 22/2024 on obligations following from reliance on processors and sub-processors
- Hunton Andrews Kurth: EDPB adopts opinion on processors
- NCSC: Supply chain security principles
This template is provided for guidance and must be adapted to your organisation. It summarises regulatory requirements and is not legal advice. Related NHI Mgmt Group resources: Fourth-Party and Nth-Party Risk Guide · Third-Party Risk Management Guide · DORA ICT Third-Party Risk and Register of Information Guide · Third-Party Risk Management Maturity Model