grcskills
Menu

Subprocessor register update

Use this skill when the company acts as a processor for its customers and someone asks "update our subprocessor list", "are we missing subprocessors", "we added a new tool, do we need to tell customers", "check the public subprocessor page", "where is customer data processed" or "draft the subprocessor change notice". Finds which suppliers actually receive customer personal data, compares them with the published list, records purpose, data, locations and transfer basis for each, works out the customer notice duties from the signed agreements, and writes an updated register, a change list and a draft notice for review.

Vendors and third partiesGDPRISO 27701

Use this every quarter, and before any new tool that touches customer data goes live. You get four files in a new folder, ./subprocessor-register-update/: a draft of the list of outside companies that handle your customers' personal data, as a spreadsheet you can open in Excel (subprocessor-register.csv); a short change log of what was added, removed or moved since the last version (changes.md); a draft notice to customers about the changes, for the privacy lead to approve and send (customer-notice-draft.md); and the facts still to confirm, per owner (open-questions.md). This skill drafts for a human to review and sign; this skill never marks a control effective. The data protection officer or privacy lead approves the list and any notice.

Inputs to gather

Read the current published subprocessor list and any internal version, the supplier list or tiering, the single sign-on application list, accounts payable for the last twelve months, the architecture and data flow diagrams, the standard data processing agreement and its notice clause, and a list of customer agreements with non-standard subprocessor terms. Ask the reader, in one message: which products and environments are in scope, whether any affiliate companies process customer data, and who approves new tools.

Step 1: decide who is a subprocessor

A subprocessor here is a supplier that processes personal data the company handles on behalf of its customers. Keep two lists apart: suppliers processing customer personal data (the published list) and suppliers processing only the company's own data, such as payroll or the employee directory (internal records, not published). Include affiliates, support and ticketing tools that receive customer messages, email delivery, hosting, logging and error tracking that capture user data, and AI model providers behind product features.

Step 2: find the drift

Compare the published list with reality, source by source: new single sign-on applications, new payees, code-level services (software libraries that send data to an external endpoint, such as analytics or error reporting), and product features released since the last update. For each candidate, check the data flow: does customer personal data reach it, in which field, and under which configuration? A tool that receives only aggregated or pseudonymised data may still be a subprocessor; record the reasoning either way.

Step 3: complete each entry

For each subprocessor record: legal entity, service, purpose, categories of personal data, processing locations including where support staff can access the data, the transfer mechanism if data leaves the European Economic Area (GDPR Art. 44 to 46 cover transfers; record which basis is relied on, such as an adequacy decision or standard contractual clauses), whether a data processing agreement with matching terms is signed with that supplier (GDPR Art. 28 covers passing obligations down the chain), and the business owner role. Leave a field marked "to confirm" rather than guessing a location or mechanism, with an owner and a date; an entry should not go live with an unconfirmed location or mechanism. Note whether each subprocessor publishes its own subprocessor list, and flag the major ones (hosting, AI providers) for a look one link further down.

Step 4: work out the notice duties

GDPR Art. 28 lets a processor engage another processor only with the controller's prior specific or general written authorisation, with notice of changes under a general one. Read the standard agreement for the notice period and objection mechanism, then the list of customers with non-standard terms: some need prior approval, some a longer notice period, some notice by a named channel. For each change, list which customers need what and by when relative to go-live. Flag any addition already live before its notice or objection window ran: that is a breach of the agreement; put it first in the open questions for the privacy lead, not just as a register entry. Draft one notice for the standard terms in the customer notice draft (customer-notice-draft.md): what changes, purpose, data, location, and how to object. The privacy lead approves it and a named person sends it through the channel each agreement names; the agent sends nothing. For interpretation beyond this, run a framework lookup or ask counsel.

Step 5: write the outputs

The register spreadsheet (subprocessor-register.csv): the complete list with all fields and the source of each; the privacy lead approves it and the list owner publishes it. The change log (changes.md): additions, removals and changed locations or purposes since the last version; for each removal, the return or deletion evidence the agreement's exit clause calls for, or "to confirm". Cross-check the published list against the processor record of processing and the supplier list, and list mismatched rows. The open questions (open-questions.md): unconfirmed fields per owner.

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

What good looks like

  • The list matches the data flows. Every entry has a purpose and data categories a customer's privacy team would understand.
  • The common mistake is a list that has not changed while the tool count grew. The tell: error tracking, support chat and AI providers missing, while office software that never sees customer data is listed.
  • Locations include where data can be accessed from, not only where the servers are.
  • Notice duties are worked out per customer before go-live, not after a customer spots the new name.
  • Removals are recorded too, so the list does not only grow.

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-subprocessor-register-update

Rules

  • MUST check every customer agreement with non-standard terms before proposing a notice.
  • MUST record the data flow reasoning for every supplier added to or left off the list.
  • MUST write outputs only inside ./subprocessor-register-update/ and ask before overwriting.
  • NEVER publish the list or send a notice to customers; the privacy lead approves and sends.
  • NEVER guess a processing location or transfer mechanism; mark it "to confirm".
  • NEVER include customer names in the public register draft; keep them in the internal notice table.