"Is it safe?" It's one of the first questions business owners ask about custom software, and one of the hardest to answer in a single sentence. Security isn't a checkbox you tick at the end. It's a set of decisions baked into the software from the first week — and if those decisions are wrong, no amount of patching afterwards fully fixes them.
You don't need to become a security engineer. But you do need to know enough to ask the right questions and recognise when the answers are weak. Here's what matters, in plain language.
Security is a baseline, not a feature
The most expensive misunderstanding in software is treating security as something you add later, like a feature. It isn't. It's the foundation everything else sits on. A well-built application is secure by default; a poorly built one leaks data no matter how many features you bolt on.
The good news: the fundamentals are well understood. Most breaches don't come from sophisticated attackers — they come from skipping basics. The industry-standard reference is the OWASP Top 10, a list of the most common ways web applications get compromised. A competent developer builds against it without being asked.
The basics every business application needs
You can hold your developer to these five, regardless of what you're building:
- Authentication done properly — Passwords hashed (never stored in plain text), and multi-factor authentication available for anything sensitive. If a developer can tell you a user's password, walk away.
- Access control on every action — A logged-in user should only reach their own data. The most common real-world breach isn't hacking — it's user A being able to load user B's records by changing a number in the URL.
- Input validation — Never trust what comes from the browser. Unvalidated input is how injection attacks and broken data get in. This is the difference between code that "works in the demo" and code that survives the real world.
- Encryption in transit and at rest — HTTPS everywhere (not just the login page), and sensitive data encrypted in the database. This is standard, not a premium add-on.
- Up-to-date dependencies — Most applications are 80% third-party libraries. Outdated ones carry known, published vulnerabilities. This overlaps directly with technical debt: neglected dependencies are a security problem, not just a maintenance one.
GDPR: what actually applies to your software
If your software touches personal data — names, emails, customer records, employee data, anything that identifies a person — the GDPR (in Dutch: AVG) applies. Enforcement in the Netherlands runs through the Autoriteit Persoonsgegevens, and the headline number is real: fines up to €20 million or 4% of global annual turnover, whichever is higher.
You don't need a legal degree, but your software needs to respect a few principles by design:
- Data minimisation — Only collect what you actually use. Every extra field you store is extra liability if it leaks.
- A lawful basis for processing — Consent, contract, legal obligation. Know why you hold each piece of data.
- The right to access and deletion — Users can ask for their data or ask you to erase it. Your system should make that possible without a developer manually editing the database.
- Breach notification — A serious data breach must be reported to the Autoriteit Persoonsgegevens within 72 hours. That's only realistic if your software has proper logging and monitoring in place beforehand.
- Processing agreements — Every external service that touches your data (hosting, email, analytics, AI) is a processor you need an agreement with.
Where your data lives matters
This is the GDPR question most people forget to ask: where is my data physically stored, and who else can reach it? Modern applications lean on cloud providers and third-party services, and each one is a place your data goes.
For EU businesses, hosting in an EU region (most providers offer one) keeps things simple. The moment data flows to a provider outside the EU, you need to check the legal basis for that transfer. This is especially relevant for AI features — sending customer data to an external AI model means that data leaves your system, and you need to know where it lands and whether your processing agreement covers it.
A practical rule: before adding any external service, ask "what data does it see, and where does that data live?" If nobody can answer, that's a finding, not a detail.
What getting it wrong actually costs
Security and compliance feel like cost centres until something goes wrong. Then the math changes fast:
- Regulatory fines — The AP has issued penalties in the hundreds of thousands to millions of euros for inadequate data protection. Even a "small" enforcement action dwarfs the cost of building things right.
- Breach response — Investigation, notification, remediation and legal costs add up quickly, even for a mid-sized incident. The build savings you made by cutting corners disappear in the first week of a breach.
- Reputational damage — The hardest cost to quantify and the slowest to recover. B2B customers don't forget which supplier leaked their data.
Against that, the cost of doing it properly is modest: secure development is mostly a matter of competence and discipline, not extra budget. A dedicated security review or penetration test for a sensitive application typically runs €3,000–€10,000 — cheap insurance for software that handles money or personal data.
A checklist for the non-technical owner
You can assess a developer's security posture without writing code. Ask these:
- How are passwords stored, and is multi-factor authentication available?
- How do you make sure one user can't access another user's data?
- Where is our data hosted, and is it in the EU?
- Which external services touch our data, and do we have processing agreements?
- How would we detect and report a breach within 72 hours?
- How do you keep dependencies up to date after launch?
You're not looking for perfect jargon. You're looking for someone who has clearly thought about this before you asked. Vague or dismissive answers ("don't worry, it's secure") are the red flag.
What good looks like in a build
In a well-run project, security shows up early and stays throughout:
- In discovery — Data sensitivity and compliance requirements get mapped during the discovery phase, not discovered after launch.
- During development — Least-privilege access, validated input and encrypted secrets as default habits, not afterthoughts.
- Before go-live — Logging and monitoring in place so you can actually see what's happening, plus a security review for anything handling sensitive data.
- After launch — Regular dependency updates and patches. Security isn't a one-time state; it's maintenance.
This is also a reason the who-builds-it decision matters: a single overstretched developer is more likely to cut security corners under deadline pressure than a team with code review built into the process.
Want a second opinion on your software's security?
If you're commissioning new software, I can help you set the right security and GDPR requirements from the start. If you already have an application and aren't sure how exposed you are, a focused review gives you a clear, jargon-free picture of what's solid and what needs attention — alongside a realistic sense of what fixing it costs. No scare tactics, just an honest assessment. Get in touch.