A custom application is usually commissioned to solve a business problem: faster order handling, a customer portal, a tool that connects three older systems. Security tends to arrive late, as a test before launch or a checklist item in the contract. By then, the most expensive decisions have already been made. How data is stored, how users are identified and how components talk to each other are architecture choices, and changing them afterwards can mean rebuilding large parts of the system.

This article sets out what a German business should expect to be built into a custom application from the start, how to ask for it, and where legal obligations shape the technical requirements.

Security is a set of design decisions, not a feature

It helps to drop the idea that security is a module added at the end. In practice it is a collection of decisions made throughout the project: what data the application needs to hold, who may see it, how it moves between systems, what happens when something fails and how problems are detected and fixed.

A sensible starting point is a short threat discussion before development begins. Who might want to misuse this application, and how? A customer portal exposed to the internet faces different risks from an internal planning tool. An application that holds payment details, health information or employee records carries different consequences if compromised than one that displays product catalogues. Writing down the most plausible threats, even informally, gives the team something concrete to design against and gives you a basis for judging the result.

Identity, authentication and access control

Most serious breaches involve someone getting in who should not have, or someone inside seeing more than they should. Several features address this directly.

Strong authentication. Passwords alone are a weak foundation. Multi-factor authentication should be available, and required for administrative accounts and for any access to sensitive data. Where your company already uses a central identity provider, the application should connect to it through single sign-on rather than keeping its own separate user list. That makes it easier to remove access when someone leaves.

Role-based access. Users should see and change only what their role needs. A sales assistant does not need payroll data, and a warehouse operator does not need to edit customer pricing. Design roles around real job functions, and apply the principle of least privilege: start with minimal access and add what is demonstrably required.

Session handling. Sessions should expire after reasonable inactivity, tokens should be protected against theft and reuse, and sensitive actions, such as changing bank details, should prompt re-confirmation.

Access control must be enforced on the server side. Hiding a button in the interface is not protection, because a determined user can call the underlying function directly.

Protecting data in storage and in transit

Data should be encrypted when it travels between systems and when it is stored, particularly for personal information and credentials. Connections between the application, its database and any external services should use current, well-established encryption protocols, with certificates managed properly.

Passwords should never be stored in readable form. They should be hashed with a method designed for the purpose, not a general-purpose hash. Keys and secrets, such as database credentials and API tokens, should be kept in a dedicated secrets store and not written into source code or configuration files that end up in repositories.

Equally valuable is collecting less. Data an application never stores cannot be stolen. Question each field: is it necessary, and for how long? Retention rules and automated deletion reduce both risk and compliance burden.

Secure handling of input

A large share of application-level attacks rely on the system trusting data it should not. Every input, from form fields to file uploads to data arriving from other systems, should be validated and treated as untrusted. Database queries should use parameterised statements to prevent injection, and output shown to users should be properly encoded to stop malicious scripts from running in their browsers. File uploads need type and size limits and scanning, and should never be executed or served from locations that allow code to run.

These practices are well documented, and a competent development team should treat them as routine. A useful question to put to any supplier is which established guidance they follow, such as the OWASP recommendations for web applications, and how they check that it has been applied.

Logging, monitoring and incident readiness

Even well-built applications are sometimes attacked successfully, and the difference between a contained incident and a serious one is often how quickly it is noticed. The application should record security-relevant events: logins and failed attempts, changes to permissions, access to sensitive records, administrative actions. Logs need to be protected from tampering, kept for a sensible period and reviewed or monitored, with alerts for unusual patterns such as repeated failed logins or large data exports.

Logs themselves can become a liability if they capture passwords or full personal records, so decide deliberately what they contain.

Prepare for the bad day as well. Know who will be told, how the application can be isolated, how backups are restored and how quickly. Backups should be encrypted, stored separately from the live system and tested by actually restoring them, since an untested backup is only a hope.

Third-party components and the software supply chain

Custom applications rarely consist only of custom code. They rely on open-source libraries, frameworks and external services, and vulnerabilities in these are a frequent route in. Maintain an inventory of the components used and their versions, and have a process for applying security updates promptly. Automated dependency scanning in the build process helps flag known issues. Treat external services with the same care: check what data they receive, how they authenticate and what happens to your application if they fail.

Companies that commission custom development often look for a partner in software entwicklung who can explain how these practices are applied in their projects, and who documents the components and decisions so your own team can maintain the system later.

German and European requirements

The GDPR requires appropriate technical and organisational measures to protect personal data, and expects data protection by design and by default. For custom applications this translates into the features above: access control, encryption, minimal data collection, logging and the ability to support data subject rights such as access and deletion. A data protection impact assessment may be required where processing carries high risk, and your data protection officer should be involved early.

Depending on your sector and size, additional obligations may apply, for example under the NIS2 framework as implemented in Germany or sector-specific rules in finance and healthcare. Whether these apply to a given company depends on its activities and scale, so confirm with your legal adviser rather than assuming. Contracts should specify who is responsible for what, including security updates, incident notification and the handling of data processed on your behalf.

Verifying what you are getting

Promises in a proposal are not evidence. Ask how security is tested during development, whether code is reviewed by a second person, and whether automated analysis is part of the build. For applications exposed to the internet or handling sensitive data, an independent penetration test before launch, and periodically afterwards, gives an outside view of weaknesses. Agree in the contract how findings will be prioritised and fixed, and by when.

Where face-to-face workshops help to agree requirements, some companies prefer regional providers, such as those offering software entwicklung berlin in the capital or software entwicklung hamburg in the north. Location is a convenience, and demonstrable security practice should count for more.

Conclusion

A secure custom application is the result of decisions made early: who can sign in and what they may do, how data is stored and protected, how inputs are treated, what is logged and how components are kept up to date. None of these is exotic, but each costs more to retrofit than to include from the first design.

A practical next step is to write a one-page security requirements list for your next project before asking for quotes. Cover authentication, access roles, data classification, logging, backup and testing expectations, and ask each supplier to respond to it point by point. The quality of their answers will tell you a good deal about how seriously they take the subject.