GDPR in web applications: how we build compliant systems
GDPR is not just a privacy policy in the footer. It is how the application collects, stores, shares and deletes data. In Laravel this can be designed from day one — cheaper than fixing it after an audit.
Many companies “handle GDPR” with a PDF in the footer. That is not enough when the app holds customer records, order history, documents, or medical and HR data. The regulation requires protection to be built into the system (privacy by design), not bolted on at the end.
What GDPR means in software practice
- Minimisation — collect only what you really need for a stated purpose.
- Legal basis — consent, contract or legitimate interest must be clear and demonstrable.
- Purpose limitation — contact-form data is not later used for other marketing without consent.
- Access and erasure — a user can get a copy of their data and ask for deletion.
- Security — encryption in transit, access control, backups, breach reporting.
How this looks in a Laravel application
Consents and a processing record
Marketing consents and terms are stored with date, version text and source (form, panel, import). A single “I accept everything” checkbox is not enough. Processing consent, newsletter and profiling are separate — if profiling is needed at all.
Roles instead of one password for everything
Office staff should not see payroll. Accounting does not need the full chat history with a client. Laravel roles and policies limit access to specific resources. That is one of the most effective ways to reduce the impact of a leak — an attacker with a low-privilege account does not take the whole database.
Right to erasure and anonymisation
“Delete account” must not leave a name, email and phone number in five tables. We design the path: what is deleted, what is anonymised (to keep invoices required by law), what remains in backups and for how long. That has to be decided before the database grows to hundreds of thousands of rows.
Logs, but not too many
An audit log (“who changed the customer address”) is necessary. Logging full national ID numbers or password contents is not. Passwords never go to logs. Sensitive data in logs is masked or not stored at all.
What you cannot cheaply bolt on later
Disk encryption and an SSL certificate can be added at any time. It is much harder to add a coherent consent model, retention, on-demand export, role separation and an audit trail. That is why in new Laravel applications we plan these on analysis — before the first database table exists.
We build systems for industries where data is especially sensitive: healthcare, law firms, HR, insurance. If you need a GDPR-ready app or a review of an existing panel, contact us. We will tell you what is a real risk and what is just cosmetic wording in the policy.
Describe your project