Agree on the retention decision before selecting records
Age alone is not a complete deletion rule. Identify the purpose of the submissions, whether an active customer matter depends on them and which business or legal requirements apply. Ask the responsible owner to approve a written scope and exceptions. This guide supplies a technical planning method, not a universal retention period or legal deadline.
Separate routine cleanup from an individual’s verified request and from incident-related evidence. These can require different authorization, identity checks and handling. If there is an unresolved dispute, investigation or preservation requirement, get the appropriate decision before removing potentially relevant material. Do not assume a convenient database filter settles that question.
Record the system, environment, date boundary, record type and exclusions in a way another person can review. Counts and references can often describe the scope without a full export of the messages. Avoid creating an uncontrolled download simply to make deletion feel reversible; that creates a fresh copy needing its own justification and protection.
Build a copy-by-copy plan with an accountable owner
Follow the enquiry route through the form application, notifications, CRM, attachments, staff exports and diagnostic stores. Each destination may have a different administrator and lifecycle. A single checkbox labelled “delete submissions” may cover only one of them.
Use this worksheet to distinguish a proposed action from a verified result. Populate it for the real workflow before removal, including destinations where the outcome is still unknown. Keep recovery and archive decisions explicit rather than silently treating old copies as outside the process.
| Copy or system | Decision before action | Evidence after authorized action |
|---|---|---|
| Form entry store | Exact eligible records, exclusions and owner approval | Scoped count and agreed lookup no longer returning the selected records |
| Uploaded attachments | Whether files are shared or independently referenced | Selected file handling and continued operation of unaffected records |
| Email and CRM | Responsible owner and applicable lifecycle rule | Separate confirmation of the approved action or stated exception |
| Staff export | Known locations, users and justified remaining use | Owner confirmation without claiming unknown copies were erased |
| Logs or support records | Diagnostic and preservation requirements | Documented coverage, restrictions and retention behavior |
| Backups or archives | Recovery, preservation and restore-handling decision | Recorded limitation and process to address restored data |
Understand what the WordPress eraser actually covers
WordPress documents a personal-data erasure tool that gathers data from WordPress and participating plugins. Its documentation explicitly excludes backups and archive files. A form plugin, remote CRM or other component may therefore need a separate supported procedure; do not assume every entry is included because the website runs WordPress.
The documented erasure process is permanent once carried out. Confirm the actual product version, plugin support, user identification method and owner authorization before using it. This article does not provide a bulk SQL command or instruct you to force requests through the interface. Use the supported process appropriate to the records and request.
Also distinguish removing an erasure-request record from removing the underlying personal data. Interface status alone is not a complete copy inventory. Check the affected component’s behavior and record any information intentionally retained or excluded, with the responsible owner’s decision.
Validate the scope using synthetic data before a wider change
Where supported, rehearse the workflow in an isolated, appropriately protected environment using invented submissions and attachments. Check that the filter selects exactly the intended examples and leaves excluded examples alone. A staging environment containing production data still needs protection; the word “staging” does not make disclosure acceptable.
Before a live authorized action, confirm ownership, dependencies, recovery approach and the acceptance record. A backup can help operational recovery without making deletion harmless or automatically compliant. If old data is restored later, the agreed process must address the previous deletion decision again.
After the action, use the agreed lookups, counts and functional checks. Confirm that the form still accepts an authorized synthetic test through the expected route and that unrelated records remain available to the right people. Coordinate notifications so verification does not send unwanted messages or create real business transactions.
Do not confuse a clean dashboard with complete deletion
A form list can be empty while historical notifications remain in a mailbox or a downloaded spreadsheet remains on a laptop. State the boundary of every result: which application, records and date range were checked, by whom, and what was outside that check. Avoid issuing a blanket statement about copies nobody has located or inspected.
If an unexpected destination is discovered, update the data map and refer it to its owner. Do not use the cleanup as a reason to delete evidence of a possible disclosure. Restrict further unnecessary copying while the responsible people establish what exists and what obligations apply.
Prevent the same backlog from returning
Ask whether every field and copy is necessary. A shorter form, a minimal notification and a clear export process may reduce future cleanup work more effectively than repeated manual purges. Give each destination a retention owner, review trigger and supported method, with exceptions visible to the people responsible.
CyberFixCrew is an Israeli cybersecurity company serving worldwide businesses. Our practical Israeli website and digital-infrastructure knowledge connects WordPress maintenance, integrations, access and recovery planning. Describe the form system, intended scope and known destinations first; do not send the submissions themselves. Any deletion requires the actual owner’s decisions and a specifically agreed operational scope.
A useful handover contains the approved selection, systems covered, evidence of the scoped outcome, exceptions and restore-handling responsibilities. Keep that record appropriately limited and protected. The objective is a maintainable lifecycle with clear boundaries, not a promise that one cleanup button erases every historical trace.
