EN
RO
A client asking us for a customer or order management application almost always asks, at some point: "who's responsible if this data leaks?". The right answer isn't a document signed after launch — it's a series of technical decisions made during the architecture phase. GDPR compliance for a custom web application is built into the database schema, the authentication flows, and how deletions are handled — it isn't added at the end through a privacy policy published on the website.
The difference from a site built on a generic platform is that, in a custom application, the development team controls every table, every form field, and every log entry — which also means the responsibility to design these elements correctly from the first line of code. This guide walks through the concrete technical requirements HappyWeb treats as the minimum standard for any Laravel project that processes personal data.
What GDPR Means, in Technical Terms, for a Custom Application
Regulation (EU) 2016/679 (GDPR) sets rules for any system that collects, stores, or processes data about identifiable individuals — names, emails, IP addresses, order history. For a development team, four principles from the regulation have direct consequences for the code:
- Data minimization — the application collects only the fields strictly necessary for the function it performs, not everything that "might be useful someday".
- Purpose limitation — data collected through a contact form isn't repurposed for marketing without a lawful basis.
- Security of processing — passwords, payment data, and sensitive information are protected technically (encryption, hashing, access control), not just through a contractual promise.
- Data subject rights — a user can request access, rectification, deletion, or export of their own data, and the application has to be able to respond in practice, not just in theory.
Privacy by Design: Why Architecture Matters More Than the Privacy Policy
Article 25 of GDPR introduces the principle of privacy by design: data protection has to be built into the system from the design phase, not added later as a separate module. In practice, this means decisions made in a project's first week — which fields go into the database schema, who has access to which table, what happens when an account gets deleted — determine how easy (or difficult) it will be to comply with the regulation two years later, once the application already holds thousands of records.
A well-written privacy policy is still necessary, but it doesn't compensate for an architecture that technically can't delete a user's data or locate where copies of it are stored. The gap between "compliant on paper" and "compliant in practice" shows up exactly at this point.
What to Implement Technically From the First Version of the Application
The list below is the minimum standard HappyWeb applies to the architecture of any custom Laravel application that processes personal data, regardless of industry:
- Hashing for passwords, never stored in plain text — Laravel's standard hashing functions (bcrypt/Argon2) should be used by default for any authentication field, with no "temporary" exceptions.
- Encryption for sensitive fields — national ID numbers, medical data, payment details, or other special categories of data get encrypted at the database level, using the framework's encryption mechanism, not stored as plain text.
- Role-based access control — every internal user (employee, admin, operator) sees only the data relevant to their role, not the entire customer base by default.
- Access log for sensitive data — a history of who viewed or modified a record containing personal data, useful both for internal audits and for investigating a potential incident.
- Minimal forms — every field added to a registration or checkout form should be justified by an actual application function, not collected "just in case it's useful".
- End-to-end encrypted connections — an active SSL/TLS certificate on all environments (production, staging), not just the main domain.
Data Subject Rights and How You Build Them Into the Application
GDPR grants users concrete rights over their own data. A well-designed custom application treats each right as an actual system function, not a manual process handled over email:
| GDPR Right | What It Means for the User | How It's Implemented Technically |
|---|---|---|
| Right of access | Can see what data the application holds about them | "My data" section in the account, or an internal export process on request |
| Right to rectification | Can correct wrong or incomplete data | Editable profile forms, with validation on save |
| Right to erasure (right to be forgotten) | Can request account and associated data deletion | Hard-delete flow for personal data, separate from the legal archiving of accounting records |
| Right to portability | Can receive their data in a reusable format | Structured export (e.g. JSON/CSV) of the account's core data |
| Right to object | Can refuse a specific processing activity (e.g. marketing) | Granular consent settings, separated by processing purpose |
Storing and Deleting Data: Soft Delete vs Permanent Deletion
Many Laravel applications default to "soft delete" — the record stays in the database, just marked as deleted, so it can be restored. This mechanism is operationally useful, but it conflicts directly with the right to erasure if it isn't handled carefully: a soft-deleted record still physically exists in the database, so the data hasn't actually been deleted.
The practical solution isn't removing soft delete everywhere — it's clearly separating two categories of data at the architecture level:
- Data that can stay soft-deleted — operational records without direct personal character (products, categories, orders anonymized after the legal archiving period).
- Personal data subject to the right to erasure — user account, address, phone number — for which the application needs a separate process for permanent deletion or irreversible anonymization, triggered on request from the data subject or at the end of the defined retention period.
The retention period needs to be defined explicitly for each data category (e.g. billing data kept per tax obligations, marketing data deleted after a set period of inactivity), not left undefined "indefinitely".
Common Risks and How to Avoid Them
- Risk: application logs that store sensitive data in plain text. Mitigation: explicitly exclude password fields, tokens, or personal data from error logs and debug messages.
- Risk: third-party integrations (email marketing, analytics, payments) without a clear basis for the data transfer. Mitigation: list every third-party processor that receives personal data and verify it has its own GDPR safeguards (a data processing agreement).
- Risk: no plan for notifying a security breach within 72 hours, the deadline set by GDPR Article 33. Mitigation: a documented internal process — who gets notified, what data gets checked, how impact gets assessed — prepared before it's needed.
- Risk: unencrypted backups kept indefinitely. Mitigation: encrypt backups and align their retention policy with the production data's retention policy, instead of keeping them forever "just to be safe".
Practical Plan: How to Bring GDPR Into a Custom Project's Roadmap
- Design phase — data mapping: identify every field that holds personal data and classify it (basic data, sensitive data, billing data) before writing the first migration.
- Development phase — technical implementation: hashing, encryption, access control, and audit logging built alongside the core functionality, not added later as an "improvement".
- Launch phase — user rights flows: access, rectification, deletion, and export functional and tested before go-live, not promised for a future release.
- Operations phase — periodic review: check every 6-12 months whether retention periods, third-party integrations, and logs still match the application's actual practices.
Quick checklist before launching an application that processes personal data:
- Are passwords and sensitive data encrypted/hashed, not stored in plain text?
- Can a user actually request access, rectification, and deletion of their data from the application?
- Does personal data have an explicitly defined retention period, separate from operational data?
- Is there a documented process for notifying a security breach within 72 hours?
- Are all third-party processors receiving personal data listed and covered contractually?
Frequently Asked Questions About GDPR in Custom Web Applications
Does GDPR apply to an internal application used only by employees?
Yes, if the application processes personal data — including data about the company's own employees or B2B clients. The fact that it isn't public-facing doesn't exempt it from the regulation.
How much does it cost, roughly, to implement GDPR requirements in a custom application?
It depends on the volume of personal data handled and how many flows (access, deletion, export) need to be built. Implemented from the architecture phase, the cost is marginal relative to the total development budget; added later on top of an already-built system, the effort increases significantly.
Is a privacy policy enough if the application lacks these technical functions?
No. A privacy policy describes what happens to the data, but it doesn't replace the application's actual technical ability to respond to an access or deletion request.
What happens to data kept in backups after a deletion request?
It needs to be handled through a backup retention policy aligned with the standard rotation period (for example, older backups get overwritten automatically within a defined interval), not kept separately indefinitely.
Who is legally responsible — the application developer or the company operating it?
The company operating the application is generally the data controller under GDPR and carries the legal responsibility; the developer, as a processor, has the obligation to build the technical means that enable compliance. For the exact legal classification of a specific case, consulting a data protection specialist is recommended.
Conclusion: GDPR Compliance Is an Architecture Decision, Not a Final Document
A custom web application offers the advantage of building data protection directly into the system's structure — encryption, access control, real flows for user rights — instead of depending on the generic settings of a third-party platform. The cost of this implementation is significantly lower when the decisions are made during the design phase, compared to retrofitting an architecture already in production.
See our portfolio of custom projects: HappyWeb Portfolio.
Want an application built correctly from the start, including from a data protection standpoint?
HappyWeb builds GDPR requirements directly into the architecture of the Laravel applications we develop. Contact us to discuss your project.
Related Articles
- Ongoing Web Application Maintenance: Why a Finished Site Still Needs It
- Migrating WordPress to Custom Laravel: SEO and Security Risks
- HappyWeb Personal Data Processing Policy
Image generated with AI, used for illustrative purposes.
Write a comment