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