Cybersecurity in custom software: what we build in from the first sprint

Are you having software developed that handles customer data, financial information or medical records? Then you don’t want to find out just before go-live that its security falls short.

Security added afterwards is difficult and expensive. By then, decisions about access rights, storage and integrations are woven deep into the code. That is why we build security in from the first sprint, in the design and in the development.

Agreements first, then code

Before a single line of code is written, we make a few agreements with you. They may look administrative, but they shape much of what we decide technically afterwards.

The first question is which data the application processes and who needs access to it. Names and addresses call for different protection than financial or medical data, so we map out which information the application needs and for whom. If we process personal data on your behalf, we sign a data processing agreement and make arrangements in line with the GDPR.

Next comes location. Where is the data stored, who can reach that environment, and does anything go to services outside Europe? For hosting and external services, we look at the storage location, at transfers outside the European Economic Area and at the security agreements with those suppliers.

And then ownership. Code, content and data are yours and stay yours. We develop with mainstream technology and keep an eye on the licences of third-party components, so you are never tied to a single supplier.

The basics in every application

Which measures an application needs depends on what is at stake. An internal tool calls for something different from a platform with medical records or payments. These six are the ones we look at in every application from the start.

The same six measures, taken further as more is at stake.

Roles and permissions. Every user sees and does only what their own work requires: someone in customer service has no need to change financial data. Hiding a button or a screen is not enough for that. Behind the scenes, the application checks again on every action whether that person is allowed to perform it. Design the roles properly from the start, and you won’t have to rework permissions across the whole application later. It is no coincidence that access control failures top the OWASP Top 10 of 2025 once again, the international list of the most serious security risks in web applications.

A second login step. A strong password helps, but not once it has been stolen or leaked. With multi-factor authentication (MFA), users also confirm their login through an app on their phone or a physical security key. That matters most for sensitive data and for accounts with broad permissions.

Encryption. Data intercepted in transit, or storage that someone reaches without authorisation, should yield nothing readable. That is why we encrypt in two places: in transit, over secure connections such as HTTPS, and where needed at rest, from databases and files to backups. Passwords are not stored at all. We keep only a calculated fingerprint (a hash), which lets you check a password but never recover it.

Recording who did what. In sensitive processes you want to be able to see who changed a record, altered permissions or approved a payment, and when. An audit log records exactly that. It helps when investigating an incident and with internal control. The log itself is protected too, and it holds no more sensitive information than necessary.

Testing for weak spots. A mistake in the code can also give someone access they have no right to. So we check everything users enter, to make sure nobody can send commands to the database through an input field (an SQL injection), and we handle the keys the application uses to reach other systems with care. On top of that, every application relies on dozens of software components made by others. A vulnerability found in one of them affects the whole application. Automated checks for known vulnerabilities, code reviews and targeted security tests find weak spots early. For higher-risk applications, an independent penetration test can be worthwhile: an outside party that deliberately tries to get in.

Backups you can restore. Good security makes an incident less likely, not impossible. Human error, an outage or ransomware can still strike. So we agree which data is backed up, how those backups are protected against being read or deleted, and how quickly the application must be running again. A backup only counts once you have tried restoring it.

How secure an application stays in practice also depends on the way of working around it: tests, monitoring and small releases. You can read more about that in the DevOps practices your software partner should have in order.

Integrations and AI only get what they need

Every integration with another system is a door to your data. That is why we prefer to build integrations in a separate layer, apart from the core of the application. This lets you control, per integration, who gets in and which data goes out. An external service has no need to see a full customer record when a few details will do. The keys integrations use to log in are stored securely and can be replaced whenever needed.

Through the integration layer, a scheduling service receives only name, address and appointment time. The rest of the record stays inside.

The same principle applies to AI. In an AI implementation, your data stays within your own environment. For each question, only what is needed is passed on, and every answer points back to the source it is based on. Together we agree in advance what a good answer must meet, so quality becomes measurable. AI suggests, the specialist decides: an AI answer never simply changes sensitive data or makes final decisions.

Security is not finished at go-live

An application that is well secured today may not be a year from now. New vulnerabilities are found, staff change roles and integrations change. The pace is picking up as well: according to the Cyber Security Assessment Netherlands 2026 (in Dutch), attackers now use AI at every stage of an attack.

Sources: Verizon Data Breach Investigations Report 2026 and NCSC (in Dutch).

We maintain the servers we manage every week and monitor them every day, and critical updates go through straight away. How that works when the pressure is on, you can read in our piece on the PHP2Shell vulnerability.

What else is needed differs per client. An internal dashboard calls for something different from a customer portal that users rely on day and night. Either way, agree in advance who acts when an incident occurs. If your organisation falls under the Dutch Cybersecurity Act, the Dutch implementation of NIS2, a risk analysis and appropriate measures have also been a legal requirement since 15 August 2026.

Is a custom application on your roadmap? In the Discovery sprint, we spend four weeks exploring whether the idea is functionally and technically feasible, including the choices around architecture and security. You get a clickable prototype, a budget and an honest go/no-go recommendation.