Prospect deletion spans the systems that hold, copy, enrich, send, or back up a record. A broker that reacquires information after deleting it must delete it again on the following cycle.1 Build the workflow to find the record across copies, remove it from each system, and check whether it returns. Treat deletion as a recurring control with a clear trigger, an owner for each copy, and a verification step.
Start with the event that requires removal. Write down what happened, whose record is affected, and what “deleted” must mean before anyone opens a tool.
A person can request that a company delete their personal data.2 When the purpose for collecting information has ended and the information is no longer needed, it should be deleted or securely disposed of.3 Your procedure should account for comprehensive deletion across the record's copies.4
For broker-held records, basic information can be enough for the broker to find and delete the information it holds.5 Ask: “What triggered this deletion, and what systems and copies fall inside the request?” Record the trigger, the person or record to match, and the required scope before moving on.
Start with discovery. Find where the prospect exists before removing anything, because one system can recreate or continue using a record held elsewhere.
List the CRM record, enrichment copy, outreach record, campaign membership, activity history, exports, and backups that your workflow uses. If you keep duplicated databases, document how customer information will be deleted from every copy when a contact opts out of all or specific types of contact.6
Include service providers and contractors in the handoff. A broker that receives a deletion request has 45 days to complete the deletion and must direct its service providers and contractors to do the same.7
For each location, record the action you will take, the person responsible, and the signal that confirms completion. Ask each system owner: “Where does this record live after the main profile is removed?” Put every answer in the deletion runbook.
The same request may require different actions in different tools. Decide the disposition for each copy before you start, then record the decision so a later operator does not improvise.
Choose whether each system needs full removal, partial removal, anonymization, or archival. A retention policy can automatically delete records after a specified period, with the configuration applying to all records or only part of them.8 Automating deletion, anonymization, or archival through systems or a CRM reduces the chance of keeping data beyond the allowed period or losing track of it.9 Secure deletion may involve overwriting or destruction, while anonymization is a separate treatment.10
Systems with recycle bins need an explicit rule for the interim state and the final state. In Pardot, prospects can be placed in the recycle bin manually from an individual record or through a selected group.11 They can then be permanently removed from the database and recycle bin through a separate action.12 Agree when a prospect enters the recycle bin and when it is deleted altogether.13
Before choosing permanent deletion, record what the system will lose. Move a record from review to execution only when the team agrees on the disposition and its effect on history.
Execute the workflow in an order that lets you stop when a system behaves differently from expected. Start with the approved population, apply the action in each mapped location, and keep a completion status for every system.
Remove prospects in phases so you can monitor the data and stop the removal if issues appear.14 For recurring retention work, use the tool's automatic cadence where available. The deletion process can run according to the cadence set by the admin without further manual involvement until the admin changes the retention requirements.15
A broker process may have a scheduled intake requirement. Starting August 1, 2026, data brokers must access DROP at least once every 45 days to begin processing deletion requests.16 If your workflow sends requests through a broker process, track the submission and completion dates separately.
After the first batch, compare the intended population with the completed population. Investigate exceptions before releasing the next batch.
Verification is a separate pass after the delete action has run. Check the record in every mapped location, confirm that the intended action occurred, and look for signs that the person or record can enter the system again.
In Pardot, prospect activity is not tracked while a prospect is in the recycle bin, and a prospect is automatically undeleted if they submit an MCAE form.17 Treat re-entry as a check in the workflow and send the record back through the deletion rule.
If a person removes information from data broker databases, certain online experiences may change.18 Give the requester or internal owner a clear completion status and note any system behavior that needs follow-up.
Close the run when each system has a status, each exception has an owner, and the recurring rule is ready for the next cycle.
What not to do
- Do not treat a duplicated database as outside the deletion scope. Document a way to remove the information from every copy.6
- Do not create an optional backup that preserves the deleted subscriber record without deciding whether that backup belongs in the deletion workflow.19
- Do not leave an automated retention rule unchanged after the retention requirements change. The cadence continues without manual involvement until an admin updates those requirements.15
- Do not delete a large population in one uncontrolled action when a phased removal lets you monitor the data or stop the run.14
- Do not permanently delete a prospect before recording the consequence for its activity history. Permanent deletion makes the record and activity history unretrievable.20 Removing that activity can change asset metrics, so each form completed by the prospect has one fewer submission.21