What NEN 7510 teaches us

For organisations with sensitive data or business-critical processes, a software partner is not just an ordinary supplier. Software affects the daily operations of employees and customers—and sometimes even people’s safety or health. System failures, incorrect information, or a data breach are therefore more than just technical incidents.

In the healthcare sector, that responsibility is particularly evident. NEN 7510 requires organisations to demonstrate that they handle information security with due care. The standard is specific to healthcare, but the underlying principles are relevant more broadly: identifying risks, controlling access, ensuring data reliability, and continuously improving.

That is why a certificate alone is not enough. The more important question is how a software partner applies those principles every day. Can you entrust sensitive data, critical processes, and the continuity of your organisation to that party?

The recent audit and the transition to the current NEN 7510 standard make this clear. Not as a scorecard, but as a glimpse into how trust in software is built and maintained.

Security, privacy, and compliance are daily responsibilities. Anyone who works with sensitive information wants to know who has access, how that access is controlled, what is logged, and what happens when a vulnerability is discovered. In the healthcare sector, this involves health data, but the same questions apply to financial information, personal data, trade secrets, and critical operational data.

NEN 7510 focuses on confidentiality, integrity, and availability. In practice, this means that only authorized individuals are granted access, that data remains reliable, and that information is available when the process requires it.

The true value is realized only when these principles are integrated into daily work. Consider strong authentication, appropriate access rights, logging, data minimization, encryption, and clear agreements on where sensitive data may and may not be used.

A concrete example is Engineer Awareness. Developers learn to recognize personal health data and keep it out of logs, tickets, and other non-production environments. That may seem like a small thing, but it prevents exactly the kind of risk that arises when sensitive information inadvertently circulates throughout an organisation. The lesson extends beyond the healthcare sector. Good security isn’t just about tools or policies—it’s about professionals who understand the risks their daily decisions can create.

Continuity begins before the first outage. Organisations aren’t looking for software that only works properly at delivery. They must be able to trust that management, knowledge, security, and recovery will also be well-organised down the line.

This is precisely where an audit reveals the difference between a certificate and a living management system. Findings aren’t the most important part of an audit; the way an organisation addresses them is. Identifying deviations, understanding the cause, taking corrective actions, and then verifying whether they work—that is continuous improvement in practice.

This is essential for custom software. Its lifespan is determined by architecture, documentation, testability, maintainability, and ownership. Building new functionality without safeguarding that foundation may yield speed, but it increases technical debt in the long run.

This requires clear management agreements. SLAs clarify responsibilities and escalation procedures. Backups are only valuable if recovery is also tested. Monitoring, vulnerability management, and penetration testing help identify problems before they impact operations.

Business continuity is therefore not a separate management issue. It begins during design and development and continues for as long as the software is critical to the organisation.

Innovating Without Losing Control: Organisations must continue to innovate. AI can accelerate processes, make knowledge more accessible, and support employees. At the same time, new questions arise regarding data, accountability, explainability, margins of error, and dependence on suppliers.

The relevant question, therefore, is not whether a software partner uses AI. What matters more is whether new technology can be applied responsibly when the consequences of errors are significant.

AI governance and risk classification help define, for each application, what data is used, what the application’s purpose is, how much human oversight remains necessary, and what security measures are appropriate. This creates room to experiment without every experiment having immediate access to sensitive data or critical processes.

That is the strength of a mature security foundation. Innovation is not organised in isolation from risks but within the same framework of responsibilities, controls, and evaluation.

The maturity of a software partner is evident not only from certifications, but above all from daily practice. You see it in access controls that are consistently enforced, in engineers who recognize sensitive data and prevent it from ending up in logs or tickets, and in backups whose recoverability is demonstrably tested. You also see it in audit findings that aren’t ignored but are carefully investigated and systematically resolved.

Trust isn’t built simply because nothing is ever found. It arises when risks are made visible, taken seriously, and addressed in a targeted manner. That is why a good assessment begins with the question: Can I trust this? The answer must be evident from demonstrable security, privacy-conscious software development, and people who understand the risks they are managing.

Next comes the question: Will it continue to work for years to come? That requires continuity in management, reliable recovery procedures, maintainable software, and concrete follow-up on findings. Finally, you want to know: does it actually help us move forward? A good software partner enables innovation and applies new technology responsibly, without the organisation losing control over its data and processes.