What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Does $user->delete() delete a user’s data for GDPR? Not necessarily. In Laravel, what the call does depends on the model, and even a permanent deletion of its database row does not establish that every relevant copy of a person’s data has been erased. A right-to-erasure request requires a decision about whether the right applies, action across the data and recipients in scope, and verification of the result.
What does Laravel’s delete() actually do?
First check the model. Laravel’s current 13.x Eloquent documentation says that when a model uses the SoftDeletes trait, delete() sets its deleted_at timestamp rather than removing the row. Ordinary Eloquent queries exclude that row, but it remains in the table; it can be retrieved with withTrashed() and restored. Laravel puts it plainly: “When models are soft deleted, they are not actually removed from the database.”
As an Amazon Associate I earn from qualifying purchases.
For a soft-deleted model, forceDelete() permanently removes that model’s row. That is a different operation, but its scope is still the row it targets—not automatically every copy, related record, or disclosure elsewhere in the system.
| Operation or approach | What it establishes | Important limitation |
|---|---|---|
delete() on a model using SoftDeletes |
Marks the row as deleted; ordinary queries omit it, and it can be restored. | The row remains stored. Laravel 13.x Eloquent documentation. |
forceDelete() on a soft-deleted model |
Permanently removes that model’s row. | Does not by itself address other stores, linked records, or recipients. Laravel 13.x Eloquent documentation. |
| Query-based mass delete | Deletes matching records without retrieving each model. | Does not dispatch each model’s deleting and deleted events, so per-model cleanup that relies on those events may not run. Laravel 13.x Eloquent documentation. |
Laravel’s Prunable feature provides a pruning() hook for handling additional resources associated with a model. It is an implementation facility, not a request-decision or privacy workflow: the application still needs to know what it stores and where the data has gone.
#1 Best Overall
Why is a hard-deleted row not the same as erasure?
A database row is not necessarily a complete inventory of personal data. Depending on the system, relevant information may also exist in related tables, uploaded files, logs, search indexes, analytics systems, backups, or services operated by other organizations. The right scope depends on the actual data flows and the applicable decision, so an application should not assume that deleting the user table’s row reaches every copy.
There may also be service records distinct from a profile. In examples discussed by the European Data Protection Board (EDPB) in its February 2026 Coordinated Enforcement Framework report, profile information and service records were handled separately, with anonymization considered as one possible way to retain some service information. These examples do not establish that any particular record is anonymous, or that anonymization is sufficient in every case. A retained record must not leave the person identifiable or linkable in a way that defeats the intended outcome, and its continued use must be permitted under the applicable rules.
The same distinction applies to a button labeled “delete account.” The EDPB report describes an app action that removed the app from the device while the person’s data remained in the controller’s database. A user-interface label is not evidence of what the backend did; verify the resulting data state.
Does GDPR require every record to be destroyed?
GDPR Article 17 provides a right to obtain erasure without undue delay when one of its specified conditions applies, and it also sets out circumstances in which the right does not apply. A request therefore calls for an applicability decision, not an unconditional instruction to destroy every record. The framework cannot decide whether the request qualifies, whether an exception applies, or what data and recipients fall within scope. The EDPB’s data subject rights guidance emphasizes that controllers must facilitate the exercise of those rights.
If information is lawfully retained, document the applicable reason and limit its use accordingly. Do not describe the request as fully completed while relevant copies remain available for use. The legal analysis depends on the circumstances and jurisdiction; Article 17 is the starting point for an EU GDPR discussion, not a substitute for assessing the rules that apply to a particular controller and request.
What happens to backups and data held by processors?
Backups
For UK guidance, the Information Commissioner’s Office (ICO) says that a valid erasure request with no applicable exemption should cover backup systems as well as live systems. If immediate overwriting is not practical, the ICO’s guidance is to put backup data “beyond use,” prevent it from being used for another purpose, and let it expire under an established retention schedule. The ICO says organizations should explain to the individual what happens to data in backups.
“Beyond use” is not the same as claiming that the backup has been overwritten. The organization needs controls consistent with its circumstances and retention schedule, and should account for the possibility of restoration or access. This is UK regulator guidance; it should not be presented as a universal rule for every jurisdiction. The ICO notes that some of its guidance is under review following UK legislative changes, so organizations applying it should check the current guidance.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Recipients and processors
Where personal data has been disclosed to other organizations, ICO guidance says recipients should generally be informed of erasure, subject to impossibility or disproportionate effort. For processors, the ICO’s contract guidance describes the controller’s choice to have data returned or deleted at contract end. Delayed deletion from backups or archives may be acceptable with appropriate safeguards and an appropriate retention period. The controller needs to coordinate the required action rather than treating its own database operation as completion.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How should an application handle an erasure request?
Use a tracked workflow that separates the legal decision from the code operation. The following is an engineering checklist, not a substitute for deciding which law applies to a particular request.
Quick Recap
- Receive and track the request. Provide a clear route for requests and record enough information to identify the request and follow its status. Communicate the decision and timing under the rules that apply. The EDPB’s data subject rights guidance addresses facilitating rights; the ICO publishes UK process guidance.
- Determine the person, scope, and outcome. Identify the data subject and relevant records, then assess the applicable grounds, exceptions, and retention duties. Record whether erasure applies and what information, if any, may lawfully remain.
- Map the data and its flows. Identify profile and service data, related records, files, operational systems, recipients, processors, and backups. Decide how each in-scope location will be handled; do not assume that all records are in the user model or that an anonymization label alone resolves the question.
- Select and execute the Laravel operation. Inspect the model for
SoftDeletesand choose an operation consistent with the decision. Check whether the cleanup path uses instance operations or query-based mass deletion, and make sure required cleanup does not depend on events that the chosen path will not dispatch. - Coordinate downstream work and verify it. Arrange actions with recipients and processors, apply the documented backup controls where needed, and check the outcome in the relevant systems. Verify backend effects rather than relying on the account screen or button label.
- Close the request with an accurate record. Keep the decision, completion evidence, any applicable limitation or exception, and the explanation given to the requester. Describe backup expiry or other delayed handling accurately rather than claiming immediate removal where it has not occurred.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
