Data security in a custom application - what you need to know before deployment

Data security in a custom application comes down to three things: where the data sits, who has access to it and how it is protected in case of a leak. Unlike off-the-shelf SaaS products, in a custom system you have full control over this - but that also means these decisions have to be made deliberately before deployment. Below is what to ask about.

Data location and hosting

The first question: where the data physically sits. With personal data, storing it in the EU simplifies RODO (GDPR) compliance. In a custom application you choose the region yourself - this is an advantage over closed platforms, where the location is sometimes imposed on you. → Why Next.js + Supabase

Roles and access

The most common gap is not a sophisticated attack, but access that is too broad - everyone sees everything. A well-designed system gives each role only what it needs. This is especially important for medical, financial or HR data. → Compliance system for clinics

RODO in practice

RODO compliance does not "happen on its own" - it results from design: minimizing the data collected, encryption, access control, clear rules for storage and deletion. It is worth establishing this at the specification stage, not after deployment. → 5 mistakes when ordering an application

Security layers: authorization, roles, encryption

Data security is not a single switch - it is several layers that work together. If one fails, the others still limit the damage. It is worth understanding what each of them is responsible for.

The first layer is authentication - confirming that the user is who they claim to be. This is password login, ideally reinforced with a second factor (a code from an app, a hardware key). The second layer is authorization - the decision about what a given user can do after logging in. This is where roles and permissions come in.

A practical model is task-based roles: administrator, accounting, sales, employee. Each role gets the minimal scope that allows them to do their work - and nothing more. The principle is called "least privilege" and it is one of the cheapest ways to limit risk. An employee who has no access to HR data cannot accidentally export it or fall victim to phishing that extracts that data.

The third layer is encryption, that is, securing the data itself in case the earlier layers fail. More on it below. These three levels - who gets in, what they can do and how the data is protected - form the framework that is worth establishing at the specification stage. → Custom application - a guide

Data encryption and backups

Encryption works on two fronts. Encryption in transit (TLS/HTTPS) protects data on its way between the user's browser and the server - it is a standard that should not be missing from any application today. Encryption at rest secures data stored on the database disk and in backups. If someone gains physical access to the medium or steals the backup file, without the keys they will see only an unreadable string of characters.

Particularly sensitive data deserves separate treatment - passwords should never be stored in plain text, but as irreversible hashes with a salt. Card numbers, identity documents or medical data are often additionally encrypted at the level of individual fields.

Backups are the second half of the same story. A backup protects not against a break-in, but against loss - a disk failure, human error, a ransomware attack or a plain "I deleted the wrong record". A good backup has three traits: it is automatic (it does not depend on whether someone remembered), it has retention (several copies back, so you can roll back to the state before the problem) and it is regularly tested through a trial restore. A copy that has never been restored is only a hope, not a safeguard. → Application maintenance after deployment

RODO in practice: sensitive data, EU hosting, retention

RODO is sometimes treated as a formality to tick off, but in practice it translates into concrete technical decisions. The first is data minimization - collect only what is really needed for the process to work. Every additional field with personal data is a liability, not an asset.

The second decision is hosting location. Storing data on servers in the EU simplifies compliance, because it eliminates questions about transferring data outside the European Economic Area. In a custom application you choose the region yourself - this is an advantage over off-the-shelf platforms, where data is sometimes scattered around the world without your control.

The third is retention, that is, clear rules for how long data is stored and when it disappears. RODO requires that data not be kept "forever, just in case it comes in handy". In practice this means a mechanism for automatic deletion or anonymization after a defined period, and the ability to fulfill the right to be forgotten - when someone requests deletion, the system must be able to do it.

The fourth is accountability - the ability to demonstrate that you are doing all this deliberately. Here we come back to logs and access policies. RODO does not reward good intentions, it expects you to be able to document who had access to personal data and when. → 5 mistakes when ordering an application

Audit, logging and monitoring

Security does not end on deployment day - the daily question "is nothing bad happening" comes into force. It is answered by a layer that is easy to forget: logs, monitoring and periodic audit.

Access logs record who did what and when in the system - logged in, downloaded a report, changed a record, deleted data. This is the basis of diagnostics ("why did this record disappear?") and RODO accountability. It is important that the logs themselves be protected and non-editable - a log that can be quietly wiped loses its evidentiary value.

Monitoring watches the application's behavior in real time: unusual login patterns, a sudden spike in the number of requests, access attempts from outside the allowed addresses, server errors. Well-configured monitoring signals a problem before a user notices it - or before a leak spreads.

Audit is a periodic, deliberate review: are the permissions still current (does a former employee still have an account?), are the libraries updated, are backups running and can they be restored. An application that is not looked after gradually slides toward vulnerabilities - not because someone broke it, but because the world around it changed. That is why security is worth treating as part of maintenance, not a one-off project. → Why Next.js + Supabase

What to check before you start

• In which region the data sits.
• Whether there are roles and permissions.
• Whether sensitive data is encrypted.
• Who has access and when (logs).
• What the backup and recovery look like.

FAQ

Where is my application's data stored? With a custom application you have control over data location - it can be kept on servers in a chosen region (e.g. the EU), which often matters for personal data and RODO (GDPR) requirements.

Is a custom application compliant with RODO? It can be, if it is designed with RODO in mind: data minimization, access control, encryption and clear retention rules. Compliance comes from design, it does not happen on its own.

How do I restrict access to sensitive data? Through roles and permissions - each user sees only what they need. This is the basic data protection mechanism in a multi-user system.

How often should backups be made? It depends on how much data you can afford to lose. For most companies a daily automatic backup with a retention of several to a dozen or so copies is sufficient, but with heavy writes it is worth considering more frequent, incremental copies. It is also crucial to regularly test recovery - a backup that has never been restored is only an assumption.

What is the difference between encryption at rest and encryption in transit? Encryption in transit (TLS/HTTPS) protects data while it is transmitted between the browser and the server. Encryption at rest secures data stored on the database disk and in backups. Full protection requires both - data is exposed both in motion and where it is stored.

Why does an application need logs and monitoring if I have a backup? A backup lets you restore data after a failure, but it will not tell you what happened or who did what. Access logs and monitoring detect unusual behavior, make error diagnostics easier and are required for RODO accountability - these are two different tools with different purposes.

---