Client Onboarding Compliance SOP

Version 1.0 - Effective 2026-07-08 - Change log

Template document: review by a qualified data-protection lawyer or DPO before commercial reliance. Not legal advice.

This is the standard operating procedure Amaigo follows for every Whistle client onboarding. It is published so that a prospective client's DPO can see exactly how an engagement is set up to meet Article 28 of the EU GDPR and UK GDPR, and it is the same document our team works from internally. Every step below is mirrored by a generated, client-specific onboarding pack, so the compliance record is produced by the same process that configures the deployment.

The onboarding pack

Each client deployment generates a pack of five documents, pre-filled from the deployment configuration:

• Client DPA (dpa-client.md): the DPA with deployment-specific annexes pre-filled, ready for signature
• Onboarding compliance checklist (onboarding-checklist.md): the working checklist for steps 1 to 5 below
• Consent wording (consent-wording.md): the exact consent statements visitors see, plus the recommended paragraph for the client's privacy notice
• Go-live checklist (go-live-checklist.md): pre-flight checks, smoke tests and sign-off
• DPIA starter (dpia-starter.md): a pre-filled starter based on the DPIA template

The pack is regenerated whenever the configuration changes, so it always reflects the live deployment.

Procedure

1. Order signed

The client signs the order or agreement. The Terms incorporate the DPA, the Acceptable Use Policy, the SLA and the AI Transparency Notice, so the Article 28 terms apply from day one rather than waiting on a separately negotiated contract.

2. Configuration scaffolded

We scaffold the client configuration (npm run new-tenant), which creates the deployment config and generates the initial onboarding pack. At this stage most compliance fields are deliberately empty and the pack flags them as unresolved.

3. Compliance fields completed and pack regenerated

We complete the configuration with the client and regenerate the pack (npm run regen-pack). The compliance fields, each of which appears in the pack's checklist:

• privacyPolicyUrl: the client's privacy policy, live and covering the widget. The consent statements link to it, so it is a hard prerequisite.
• consentPolicyVersion: set to the current version of the Consent Notice, so each recorded consent is tied to the wording in force.
• retentionDays: agreed with the client (default 365 days). For sensitive intake we recommend 90 to 180 days for non-engaged prospects; see the Retention Policy.
• storeTranscript: decision recorded (default off; if enabled, transcripts carry the same or shorter retention as the lead).
• allowedOrigins: locked to the client's own domain(s) so the widget serves only from their site.
• leadAlertEmail: set to a monitored address; it also serves as the contact for privacy and sub-processor notices.

4. Client-side duties confirmed

The client, as controller, confirms in the checklist that:

• its privacy notice has been updated with the paragraph supplied in consent-wording.md;
• its lawful bases have been confirmed (including an Article 9 condition where special-category data is likely);
• where enquiries may include special-category data (health, legal matters), a DPIA is completed, using the pre-filled dpia-starter.md if the client has no format of its own.

5. DPA executed

The pack's dpa-client.md is the executed instrument: the standard DPA with the deployment-specific details (retention, transcript setting, consent version, authorised origins, notification address, active sub-processors) pre-filled from the live configuration. Both parties sign; the countersigned copy is filed. This gives the client an Article 28(3) contract whose annexes match the actual deployment, not generic boilerplate.

6. Consent-flow smoke test

Before go-live, on a staging page or pre-announcement production page, we verify per the go-live checklist:

• the widget loads and the assistant introduces itself as an AI assistant;
• the consent statements render with a working privacy-policy link (not a dead link);
• skipping the early-contact card stores nothing personal;
• the marketing opt-in is unticked by default;
• the consent timestamp and policy version are recorded against a test lead;
• qualification test scenarios pass and the lead alert arrives with a de-identified summary;
• the test lead is erased after verification.

7. Go-live sign-off

Client sign-off is recorded (date and by whom) on the go-live checklist. The configuration is committed, the pack regenerated one final time, and the complete pack filed as the onboarding compliance record for the engagement.

8. Ongoing obligations

After go-live, the standing compliance operations continue:

• Sub-processor changes: 30 days' advance notice to the registered client contact, per the sub-processor change procedure and the sub-processor list.
• Transfer risk: the transfer risk assessment is reviewed annually and on trigger events.
• Retention: the automated purge runs on a schedule against the agreed retentionDays; erasure requests are handled per the DSAR procedure.
• Incidents: handled per the breach procedure.

Records

For every engagement the following artifacts are retained as the compliance record:

Together these evidence documented instructions, the Article 28(3) contract, controller-side transparency, tested consent capture and enforced retention: the record set a client DPO or supervisory authority would ask for.

This document is a GDPR-aligned template and must be reviewed by a qualified data-protection lawyer or DPO before commercial reliance. It is not legal advice.