Client offboarding evidence pack for outbound operations

Produce a single, auditable evidence pack that proves offboarding work was performed, what was exported, what was deleted or retained, and where responsibility transfers. This template lists concrete evidence items, the decision boundaries for each item, and a compact diagnostic table you can complete and store with the client record. Use the pack to close exits defensibly and to speed future audits.

What this evidence pack covers and its decision boundary

This pack documents outputs and proofs from agency outbound offboarding: account exports, mailbox and service deletions or transfers, credential rotations, campaign data exports, reporting handover, and client acceptance. Decision boundary: do not use this pack to justify legal retention beyond client instructions or jurisdictional law; it records operational proofs only. Evidence limits: this pack relies on system exports, logs, screenshots, and signed acceptance; it does not replace formal legal or regulatory records (retain those separately). Practical sequence: gather exports first, then produce deletion proofs, then create a final acceptance record and archive the pack.

Required export and proof artifacts (what to collect)

Collect specific artifact types so an auditor can reconstruct what happened: account export files (CSV/JSON), campaign history exports with timestamps, domain/DNS change logs, provider admin activity logs, and user credential rotation records. Each artifact must include the export timestamp, the exporting account (email/ID), and a checksum or file size to detect tampering. Decision boundary: if a provider does not allow direct export of a type, capture provider support tickets or screenshots showing the limitation and the agreed alternative export format. Evidence limits: some providers purge activity logs after a retention window; if logs are not available, capture contemporaneous screenshots and a signed statement from the operator. Practical sequence: prioritize exports with short retention windows (mailboxes, analytics) first, then gather longer-lived records (contracts, invoices).

Deletion, disabling, and retention evidence (how to prove removal)

For each deleted or disabled object (mailbox, app client, API key), collect: an admin action audit log entry, a screenshot of the deletion confirmation including timestamp and admin ID, and the follow-up verification (attempted sign-in failure with recorded error message). Include retention rationale and owner for any data kept (customer request, legal hold). Decision boundary: never rely solely on verbal confirmation; require a recorded system action or provider ticket. Evidence limits: some provider UIs obscure timestamps—capture surrounding log lines or support case IDs to link actions to time. Practical sequence: disable credentials immediately after exporting data, then perform deletions, and finally verify by attempting access or checking status endpoints. Record who performed each step and the exact command or UI path used.

Acceptance, signoff, and transfer of responsibility

A defensible offboard requires explicit client acceptance. Include a signed (electronic signature acceptable) acceptance form listing exported files, deletion proofs, and retained items with reasons. Record acceptance date and the person authorized to accept on the client side. Decision boundary: silence is not acceptance—define a reasonable response window (commonly 7–14 calendar days) after delivering the evidence pack; if no acceptance, follow contract escalation terms. Evidence limits: electronic acceptance should include message headers or audit logs proving the signer’s identity if disputes arise. Practical sequence: deliver the pack with a clear acceptance form, mark the start of the acceptance window, and record any client questions and the responses as part of the pack.

Packaging, storage, and chain-of-custody instructions

Store the evidence pack as a single archive (e.g., passworded ZIP) with a manifest file listing contents, checksums, and the preparer’s identity. Record where the archive is stored (S3 bucket/path, internal drive location) and access controls and retention schedule tied to the client contract. Decision boundary: do not store sensitive exports in shared, uncontrolled locations; use restricted access and record every accessor. Evidence limits: cloud object metadata can change—preserve checksums and an exported metadata snapshot at the time of archiving. Practical sequence: assemble artifacts, create the manifest and checksums, upload the archive to the chosen storage, then record access policy and retention timeline in the manifest.

Practical checklist

• Export all campaign data and mailboxes with timestamps and checksums.
• Capture admin audit logs or provider support tickets for each deletion or transfer.
• Rotate or revoke API keys and credentials, and document the exact commands or UI steps.
• Produce a manifest listing files, checksums, and preparer identity and include it in the archive.
• Deliver the evidence pack to the client with a clear acceptance form and defined response window.
• Store the archive in a restricted location and record the storage path and retention policy.
• Record all access to the archive and any subsequent modifications to the manifest.
• If a provider prevents export, attach support correspondence showing the limitation and agreed alternative.

Where RepMail fits

Use this evidence pack as a checklist and stored artifact alongside outbound activity records. It helps outbound teams prove what exports and deletions were performed and when, and it supports defensible client handover by providing a repeatable format for packaging and storing proofs. Do not treat this guide as a vendor-specific feature list—adapt stored fields to match the mailbox providers and campaign systems you used.

Continue with A/B Testing Cold Email With Small Samples for the next step in the workflow.

Related RepMail guides

• Client consent and evidence register for outbound approvals
• Agency permission matrix for client, contractor, and vendor roles

Sources