Legal playbook · AI Employee: Lex

Subprocessor List Management

Subprocessor list current within 24h of change

Install this playbookBack to marketplace
The problem

Subprocessor lists are a compliance obligation nobody wants to own. DPAs commit us to publishing a current list of subprocessors handling customer data and to notifying customers of additions or changes. In practice: the published list lags reality by 3-6 months, additions happen without customer notice, and one customer's routine audit finds the discrepancy. Trust page shows 47 subprocessors; procurement has 89 vendors with data-processing agreements.

At a glance
Trigger
Cron + form
Approvals
Legal + privacy approval
What it does
Writes to your systems
Systems
Ironclad · Website CMS
How it feels in production

An hour-by-hour walkthrough.

Every night, Lex reconciles the subprocessor picture from three sources: (1) the published list on the trust page, (2) procurement's vendor list filtered to "processes customer data," and (3) production system inventory (what third-party services actually receive customer data via API integrations). Discrepancy detection: - New: vendor in procurement + data-processing flagged, but not on trust page. Trigger: add to trust page + notify customers per DPA notice period (usually 30 days). - Removed: vendor on trust page but no active contract + not receiving data. Trigger: remove from trust page + notify customers of removal. - Changed: same vendor, but new subprocessor of that subprocessor (fourth-party). Trigger: review whether disclosure is required per your DPA language. For each discrepancy, Lex drafts the action: - Trust page update (Git PR to the published-list source) - Customer notification (email + in-app to customers with notification-required tier) - DPA amendment (rare, only if adding a subprocessor in a new jurisdiction requiring SCC updates) Legal reviews the batch weekly, approves, and the trust page updates, notifications fire, and the audit trail records every change. Compliance auditors see a subprocessor list that matches reality, updated with the required notice, and every notification captured with delivery confirmation.
How it works

Step by step.

  1. 01

    Nightly reconciliation across sources

    Trust page published list + procurement vendor list (data-processing flagged) + production integration inventory. Normalise vendor identities across sources ("Segment" = "Segment.io, Inc." = the segment.com API endpoint).

    Trust page · Procurement · Production inventory · Vendor registry
  2. 02

    Detect + classify discrepancies

    New (add), removed (delete), changed (fourth-party addition). Each has different obligation: new + removed require customer notice + trust page update; changed depends on DPA language.

    Reconciliation engine · DPA obligation matrix
  3. 03

    Draft actions with customer-notice planning

    Trust page update (Git PR or CMS update). Customer notification with the required lead time before the change (30 days typical). DPA-tier-specific notifications: some customers require signed acknowledgement, others just informational.

    Git · CMS · Email · Customer notification tier
  4. 04

    Weekly legal review + batch approval

    Weekly review of the batch: adds, removes, changes with the drafted actions. Legal approves or edits. On approval, changes fire in sequence with the notification lead time respected.

    Web UI · Slack · Approval flow
  5. 05

    Notify + verify + audit

    Customer notifications fire per tier + region. Delivery confirmations tracked. Trust page updates go live at the effective date. Audit record with every notification + acknowledgement for regulatory response.

    Email · In-app · Trust page · Audit log
Systems and wiring

What you connect to make this run.

Trust page · CMS · Static site

read+write

Published subprocessor list. Updates via CMS or Git PR to a source of truth file. Change events time-stamped so customer notice periods can be honoured (announce the change; effective 30 days later).

Coupa · Ramp · Airbase · Vendor management

read

Vendor list filtered to data-processing-flagged contracts. Vendors added, removed, or reclassified feed the reconciliation.

API integration inventory · Cloud posture

read

Production integration monitoring: which external services are we actually calling with customer data. Catches shadow subprocessors that procurement missed.

Email · Customer notification platform

read+write

Customer notifications with acknowledgement tracking. Notification tier per customer contract (some require signed ack; some informational). Delivery confirmation retained for audit.

What changes

Before and after, honestly.

Trust-page lag from actual subprocessor list
Before
3-6 months
After
Under 7 days
% of subprocessor changes with proper customer notice
Before
20-40%
After
98%+
Audit findings on subprocessor disclosure
Before
2-8 per year
After
Zero
Legal hours per month on subprocessor management
Before
15-30 hours
After
1-3 hours (weekly batch review)
Related

Playbooks that pair with this one.

Legal

DPA Handling

DPA language dictates notification obligations; consulted per subprocessor change.

Security

Vendor Security Review

New subprocessors require security review before DPA sign-off; joint intake.

Legal

Privacy Review for New Features

New features adding subprocessors trigger this list update as part of launch approval.

Frequently asked

Answers about this playbook.

What if a subprocessor is added mid-notification-window?

Change effective date deferred to end of notification window. If urgent business need to onboard immediately, customer notice fires with the shorter timeline + apology; some customers may formally object per DPA.

How does it handle customer objections to a new subprocessor?

Objection intake. Customer's objection routes to legal + the business owner. Options: contract termination for-cause (rare), agreed workaround (segregate customer's data from that subprocessor), or accept objection is unactionable per contract terms.

What about subprocessors we're removing (going off contract)?

Removal notification + data-return / deletion verification with the subprocessor. Audit record of the removal + the data disposition (returned to us, deleted, escrowed).

Can we differentiate subprocessor lists by product line?

Yes — product-specific subprocessor lists common when the SaaS has multiple product surfaces with different data flows. Customer sees the list relevant to the products they subscribe to.

How does this coordinate with SOC 2 / ISO 27001 subprocessor reviews?

Same list; different consumer. Compliance audits reference the same trust-page list + supporting DPA evidence. Consistency across compliance frameworks + customer-facing disclosures.

See it run on your data.

Free plan, no credit card. Connect the systems this playbook needs and run it against a past event first.

Book a demoMore Legal playbooks