Two Approved Target-List Versions Swapped Client Approval Records: Hold and Reauthorize Both

A target list belongs to a client approval only when its exact version, scope and exclusions, along with release conditions match the approval record. If List A points to Client B's approval and List B points to Client A's approval, both lists have a broken authorization trail.

Put both lists on hold. Stop new prospect releases; connection requests; follow-ups and exports; and changes that depend on either approval. A corrected pointer fixes the current record. It does not establish what was authorized when prior releases occurred.

The job is to rebuild evidence, not to guess intent. Treat the approval record, list version, release manifest, and activity history as separate records that must agree.

Which approval belongs to each target list?

Start with the version that was actually submitted for approval, not the current editable list. Record the list ID, version ID, content hash, client ID, approver ID, approval timestamp, approved scope and exclusions, along with conditions and release status.

Then record the observed binding from the system at the time the swap was found. The accepted binding and observed binding may differ because of an import, copy, reassignment, or manual edit. Do not collapse those fields into one value.

NIST describes configuration management as managing and monitoring system configurations to minimize organizational risk while supporting intended business functionality. That is useful here as a control principle: preserve the version and binding that existed, then make the correction traceable. NIST SP 800-128, updated October 10, 2019.

Which prospects and touches were released under the wrong approval?

Build the release population from the earliest possible point of the mismatch through the time both lists were held. Include every prospect added, exported, assigned, queued, contacted, replied to, or moved to a later touch during that window.

Use release manifests where they exist. If they do not, reconstruct the sequence from immutable activity records, list membership history, outbound queues, and operator actions. Keep unknowns marked as unknown instead of assigning a prospect to an approval based on timing alone.

For each released prospect, record the list version, client actually intended, approval attached at release, touch type, timestamp, status, and whether a further touch is pending. The resulting ledger lets the client decide whether each released record is within scope or out of scope, with any remaining record needing more review.

Log management guidance from NIST covers establishing and maintaining effective log-management processes. Microsoft also describes audit records as visibility into activities across an organization and supports searching records by activity and user, plus date range. NIST SP 800-92, September 2006 and Microsoft Purview audit overview, updated May 18, 2026 support retaining a reviewable activity trail.

Can either list remain active after the binding is corrected?

Do not assume so. A corrected binding proves that the records now point to the intended approval. It does not prove that the approver accepts the list version, prospect population, exclusions, conditions, or released touches after the incident.

Ask each client approver to review the corrected ledger and make a clear decision for the exact list version. The decision should say whether the list may resume or the scope changed, plus whether any prospects must be removed and how already released touches should be handled.

If the approver changes scope or exclusions, create a new list version and a new approval record. Do not overwrite the old approval to make the history look clean. FDA guidance on data integrity states that data should be reliable and accurate and that organizations should use meaningful, effective strategies to manage data-integrity risk. FDA data integrity guidance, December 13, 2018.

• Keep both lists inactive until the correct approver gives a written reauthorization or rejection.
• Create a new version if any scope, exclusion, condition, or prospect population changes.
• Preserve the original approval and observed swap, along with release history, correction, and reauthorization decision.

How do you prove the swap cannot happen again?

Run a negative-swap test after the correction. Attempt to bind List A to List B's approval and List B to List A's approval in a controlled test. The system should reject the mismatch or require a new, explicit authorization path.

Require the release process to compare the target-list version and hash with the client and approver IDs, along with scope, exclusions, and conditions recorded in the approval. A client name match alone is not enough.

Protected-branch guidance from GitHub gives a related control pattern: rules can require reviews and status checks before changes are merged. For list release, use the same basic idea as a recommendation: require and preserve the approval check before release, blocking a release that does not match the approved version. GitHub Docs: protected branches.