Integration Scope and Data Boundary Audit (Onboarding)

Integration Scope and Data Boundary Audit (Onboarding)

1. 01

   Inventory every system that will exchange data before a single connector is authorized

   List CRM, ERP, billing, support desk, ad platforms, and any spreadsheet acting as a de facto database. Name the system of record for each object type so two tools never claim authority over the same field.

2. 02

   Classify each data flow by direction and sensitivity tier

   Tag flows as one-way push, one-way pull, or bidirectional, then mark any flow carrying PII, payment data, or client-confidential pipeline figures. Bidirectional flows on sensitive objects get a named human owner before build starts.

3. 03

   Confirm where client data lands in the vendor's model and training pipeline

   Forrester's September 2026 position that private AI deployments outperform shared public models for B2B marketing makes this a client-facing question, not an internal one. Document the answer per account and keep it in the onboarding file.

4. 04

   Set the autonomy ceiling for each workflow before it goes live

   Classify every planned automation as read-only, draft-for-review, or write-without-review. Anything touching client-facing communications or CRM records starts at draft-for-review, per the risk framework in n8n's September 2026 agent architecture guidance.

5. 05

   Map credential custody and rotation for every connected account

   Record which API keys live in the platform vault, who can read them, and the rotation interval. The May 2026 RubyGems incident, where autonomous agents uploaded hundreds of malicious packages and forced a four-day signup shutdown, is the reference case for why agent-held credentials need scoped permissions.

6. 06

   Write the rollback path for each integration before build, not after

   Define what happens when a sync fails mid-run: which records get quarantined, who is paged, and how the client is notified. A rollback plan written during onboarding costs an hour; one improvised during an incident costs the retainer.

7. 07

   Get written client sign-off on the scope document and the boundary list

   The sign-off names the systems in scope, the data classes permitted, and the flows explicitly excluded. This document is the reference point when a client later asks for a connector that was never in the original statement of work.