grcskills
Menu

ICT third-party register

Use this skill when a financial entity in scope of DORA needs to build or refresh its register of ICT third-party arrangements, and someone asks "build our register of information", "list our ICT providers for the regulator", "which providers support critical or important functions", "refresh the DORA register", "map our ICT contracts to functions" or "where is our provider concentration". Builds the population of ICT arrangements including intra-group ones, maps each to the functions it supports, collects the fields a supervisor will ask about, flags concentration, missing exit plans and contract gaps, and writes a working register with open questions for function owners.

Vendors and third partiesDORA

Use this when the register is first built, at each periodic refresh, and whenever an ICT contract is signed, changed or ended. You get four files in a new folder, ./ict-third-party-register/: a spreadsheet you can open in Excel listing every ICT contract with its provider, the business functions it supports, data locations, subcontractors and exit plan, and where each fact came from (register.csv); a list of missing fields, missing exit plans and contracts for legal review (gaps.md); a one-page view of the providers that several critical functions depend on (concentration.md); and one block of questions per function owner (questions-for-owners.md). This skill drafts for a human to review and sign; this skill never marks a control effective. The working register is not the regulatory submission; the entity's own team prepares and files that.

Inputs to gather

Read the contract repository, the supplier list or tiering, the accounts payable export, the list of the entity's business functions with any existing criticality assessment, the group structure, any existing outsourcing register, and the ICT asset inventory. Ask the reader, in one message: which legal entities of the group are in scope, which functions the entity has already classed as critical or important, who owns each function, and when the next submission to the competent authority is due.

Step 1: build the population of ICT arrangements

DORA Art. 28(3) asks financial entities to keep a register of information on all contractual arrangements for ICT services, to report on new arrangements to the competent authority at least yearly, and to hand over the full register on request. DORA has applied since 17 January 2025, so this is a standing deliverable: a stale register is a finding in itself. Read "ICT service" widely: cloud and hosting, software and software as a service, data and market data feeds, managed security and network services, support and maintenance, and services from other companies in the same group. Intra-group providers and click-through online terms are the arrangements most often missed. One row per contractual arrangement, not per supplier: a provider with three contracts is three rows linked to one provider.

Step 2: map arrangements to functions

For each arrangement, list the business functions it supports. Propose, with one line of reasoning, whether each function is critical or important, using the entity's own assessment where it exists. The classification is the entity's decision; the agent proposes and flags disagreements with an existing assessment. Where a provider supports a critical or important function, trace the chain of subcontractors that effectively underpin the service, as far as the contract and the provider's documents show. Where the contract is silent on whether and under which conditions the service may be subcontracted, that silence is a contract gap for legal review (Art. 30(2)(a)), not just an unknown.

Step 3: collect the fields

For each arrangement collect: the contract reference, start, end and notice terms; the provider's legal entity and identifier (a legal entity identifier where one exists); the service type; the functions supported; data involved and storage and processing locations; the subcontractors in the chain; how easily the service could be substituted; whether an exit plan exists and was tested; the date of the last risk assessment. The exact template, field list and codes come from the implementing technical standards and change over time; run a framework lookup for the current version rather than assuming the columns.

Step 4: run quality checks

  • Concentration: several critical or important functions resting on one provider, or one provider's subcontractor. Write the concentration page (concentration.md) with each case and the functions at stake. It is an input to the entity's own concentration risk assessment (Art. 29), which weighs substitutability, several arrangements with the same or closely connected providers, and subcontracting in third countries before a contract for a critical or important function is signed.
  • Exit: arrangements supporting critical or important functions without a documented, tested and periodically reviewed exit strategy (Art. 28(8)). Other arrangements need only a short exit note; do not list them as exit gaps.
  • Contract terms: DORA Art. 30 lists key contractual provisions for ICT arrangements; mark contracts the legal team should check against it, without concluding on compliance.
  • Data quality: missing identifiers, unknown locations, provider names that do not match legal entities, rows that are suppliers rather than arrangements.

Step 5: write the outputs

register.csv: the working register with the source of each field. gaps.md: missing fields, missing exit plans and contracts for legal review, each with an owner role. questions-for-owners.md: one block per function owner with the arrangements to confirm. Set a refresh trigger in the notes: any new, changed or ended ICT contract triggers a re-run, and the register owner applies the change within the cycle the entity defines. Where the entity has an ICT third-party risk strategy and policy (Art. 28(2)), draft the line for its owner that names the register owner role, the cadence and how contract changes reach them.

If the output folder exists, ask before overwriting and offer a new subfolder instead.

What good looks like

  • The population includes intra-group services and online terms, not only negotiated procurement contracts.
  • Every critical or important function traces to the arrangements that support it, and back.
  • The common mistake is marking everything critical, or nothing. The tell: no reasoning column, and a criticality split that does not match the entity's own business impact analysis.
  • Identifiers and locations are either sourced or marked missing; nothing is filled in from memory.
  • Concentration is visible on one page, so the management body can discuss it.

Framework lookups

If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-ict-third-party-register

Rules

  • MUST record one row per contractual arrangement and the source of every field.
  • MUST mark unknown identifiers, locations and subcontractors as missing rather than inferring them.
  • MUST write outputs only inside ./ict-third-party-register/ and ask before overwriting.
  • NEVER submit the register to a competent authority or send it to a provider.
  • NEVER decide on the entity's behalf that a function is critical or important; propose and flag.
  • NEVER put personal contact details of provider staff into the register; use roles.