What are the key factors to consider when developing a web application with high compliance requirements

Key factors in compliance for web application development

When developing web applications with high compliance requirements, design choices must be linked from the outset to the requirements applicable to data processing. This article focuses on applications subject to the GDPR and that, where relevant, must also take account of additional sector-specific regimes such as DORA or NIS2.

• Link data processing to explicit processing purposes and retention periods to ensure privacy by design.
• Ensure central and auditable authorisation and logging to guarantee auditability.
• Incorporate security measures structurally into the development process rather than limiting them to final testing.
• Establish testing and governance early, including how controls and release decisions are substantiated.

Why compliance changes the design of web applications

Compliance does not change a web application only when the first version is complete, but at the moment decisions about data and rights are established. An application that processes personal data already faces questions in the data model that are difficult to separate later: which data remains, how long it remains and what happens when data must be deleted or anonymised? When database relationships are designed solely to preserve consistency permanently, strict foreign key constraints can prevent the cleanup of expired personal data. Deleting data then affects not only one table, but also the application logic that depends on those relationships.

This makes compliance a design principle: from the outset, the structure must provide room to manage data throughout its entire lifecycle. A final review can determine that an application insufficiently accounts for retention, but it does not automatically resolve dependencies that have by then been embedded in data structures, processes and screens. For scope decision-making, this means retention is not a separate operational topic. It is a characteristic of the chosen data structure.

The same applies to access rights. If authorisation logic ends up in different places, for example partly in controllers and partly in frontend views, there is no unambiguous picture of who may perform which action. This distribution makes it difficult to demonstrably track access rights. A change in a view can then affect a right that is interpreted differently elsewhere. For an organisation that must be able to substantiate access, there is a significant difference between rights that have evolved as separate local decisions and rights applied from a single formal layer.

The design question is therefore broader than: does the functionality work? The boundaries around access and data must also be recognisable in the architecture. This does not necessarily limit room for customisation; it makes clear which customisation choices have consequences for demonstrability and management. In Laravel software development, for example, this boundary can already be considered when functional processes and authorisations are translated into the application structure. The later assessment then concerns a setup designed for this purpose, rather than fixes around an already constrained data model or fragmented permissions model.

Core factors for compliance in web application development

The core factors gain value only when they are translated into testable design and release decisions. Therefore, document for each data flow what purpose it serves, which data is required, how long it remains and what processing follows afterwards. This makes clear whether the data model, integrations and operational processes actually align with the intended retention policy.

For access, not only the chosen authorisation technology matters, but also whether rights, exceptions and changes can be traced from a single auditable model. Logging is part of this: recorded events must align with the actions the organisation may later need to investigate, such as viewing, modifying or deleting data.

Security then requires an appropriate technical foundation that is not separate from the development process. Rather than treating a single standard as a checklist item, security requirements must be linked to the risks, the applicable obligations and the application's architecture. This allows subjects such as authentication, cryptography and vulnerabilities to be assessed in relation to the processing performed by the application.

Finally, agreed evidence is needed before a release: which requirements have been tested, which findings remain open and who assesses the outcome? This shifts governance from a document created afterwards to a fixed part of the process.

Common mistakes that cause compliance rebuilds

Compliance rebuilds in web applications often arise because fundamental security and compliance requirements are addressed late in the development process. A common mistake is to add security and compliance only as a final step, while data structures, user flows and integrations have already been established. As a result, security measures must be retrofitted to existing assumptions, which can lead to conflicts with the required setup and sometimes even to a reassessment of the entire data and process model.

The core of the problem lies in the order of decision-making. When architectural choices are made solely on the basis of functionality and only later tested against compliance requirements, tension arises between what has already been built and what must be demonstrable. The question is then no longer only how to add a control, but whether the existing structure supports that control at all.

Risks also arise in access management when a local permissions model is chosen in application code, for example through Laravel policies. Although this offers flexibility in the user interface, it does not automatically provide the same central governance as facilities for multi-factor authentication and direct session management through enterprise identity providers (OIDC or SAML). A local solution should therefore not simply be treated as equivalent to a central facility; the differences affect manageability and compliance demonstrability.

These problems often begin with incomplete scoping. Functions are then described without explicitly establishing the conditions under which identity, sessions and data structures must operate. Once the data model and access model are deeply integrated into the application, necessary adjustments become considerably more complex and costly than if these requirements had been included from the architecture phase.

Practical application of compliance requirements in web applications

In practice, meeting compliance requirements for web applications requires authorisation and access management to be organised centrally and audibly. Instead of generic super-service accounts for machine-to-machine API integrations, access rights must be limited for each integration to what is strictly necessary. This prevents a single account from receiving unrestricted access and makes it possible to reconstruct afterwards which automated party performed which action. Although additional identification methods or logging can partially support attribution, the risk remains that a shared account complicates forensic traceability. It is therefore advisable to use unique credentials and a defined authorisation profile for each integration.

Retention policy also requires a practical translation into the application. Retention periods must be enforced, with a process for deleting or anonymising data once the period has expired. When this remains fully dependent on manual actions, the likelihood of inconsistency increases. By implementing retention policy as part of the application architecture, it remains clear how data management aligns with the established periods.

A useful distinction can be made between proof of concept and production. In the first phase, validation can take place using test data and minimal administrative overhead. In the later hardening and integration phase, formal controls, such as DPIAs and verification steps, are added. This prevents temporary exceptions or unrestricted accounts from the development phase from inadvertently ending up in the production environment.

Key lessons for compliance in web applications

The common thread is that compliance is not determined by a standalone check at the end, but by the relationship between scope, architecture, access management and the substantiation of releases. A web application is more manageable when all these choices can later be explained and assessed. Two lessons make this relationship concrete:

• Make the development chain auditable. A traceable Secure Software Development Lifecycle can include automated SAST scans, dependency vulnerability scanning (SCA) and formal peer reviews before deployment in the CI/CD pipeline. The value lies in the demonstrable relationship: findings from code and dependencies are not handled separately from releases, while peer review forms part of the step before software is deployed. This does not provide a legal statement on overall compliance, but it does make clear how vulnerabilities and changes are handled within software development. For a client, these are concrete topics to have described in advance: which controls take place, where outcomes are recorded and at what point a deployment is assessed.
• Limit the scope to what is justifiably necessary. Data minimisation also requires methodological honesty from a software partner. Sometimes the best technical and organisational choice is not to include a risky functionality or planned data collection. This assessment prevents additional data or features from becoming an assumed part of the scope while increasing compliance and security risks. It requires a discussion in which accepting “do not proceed” as an outcome remains possible, rather than technically implementing every request. If a function has no justifiable place in the data or process design, including it can later increase both the management burden and the risk surrounding releases.