The NIS2 directive expands the regulatory perimeter substantially. Medium and large organizations (over fifty employees or ten million euros annual revenue) in eighteen sectors are in scope: energy, transport, health, drinking water, digital infrastructure, public administration, space, post, chemicals, food, industry, research, among others.
For those organizations, binding obligations now include: risk analysis, incident-reporting duty (initial report within twenty-four hours), business-continuity planning, supply-chain assurance. Supply-chain assurance is the clause that directly touches external suppliers: as a customer, you must be able to demonstrate that your software partner meets the requirements.
Practical consequence for contracts: documentation obligations, audit rights, and incident-response commitments must be specific, not generic.
ISO 27001 remains the most widely recognized certification standard for information security management systems across Europe and beyond. Vendor-due-diligence processes in financial services, healthcare, and public sector almost uniformly ask whether the supplier holds ISO 27001 certification or maintains an equivalent ISMS.
For a software supplier, this means:
Certification is not the only path, but any uncertified supplier engaged by an ISO-27001-certified customer will face the same scrutiny through contractual equivalence proofs.
A defensible development process contains at minimum the following elements:
Threat modeling at project start. A structured analysis of possible attack vectors against the application. STRIDE or PASTA are common methods. The output is a prioritized list of security requirements that enter the backlog.
Secure coding guidelines. Binding rules for development, language- and framework-specific. For web applications: input validation, secure session handling, correct use of cryptographic primitives, OWASP Top Ten coverage.
Static Application Security Testing (SAST) in the pipeline. Automated source-code analysis on every commit. Tools like Semgrep, SonarQube, or specialized language linters identify known insecure-code patterns.
Dynamic Application Security Testing (DAST). Runtime tests against a test environment. Tools like OWASP ZAP or Burp Suite scan the running application for vulnerabilities.
Software Composition Analysis (SCA). Analysis of open-source dependencies for known vulnerabilities. Dependabot, Snyk, or Trivy cover standard demand.
Penetration test before go-live. An independent examiner (external, not the development team) tests the application against current attack patterns. For critical applications, repeated annually.
None of these elements is expensive on individual setup. All of them together are the difference between "we pay attention to security" and a defensible security architecture.
Generic security clauses are worthless. Specific clauses cost little at negotiation and a great deal in incident response — in the inverse proportion.
Examples of effective formulations:
These clauses are enforceable. Generic "the contractor ensures appropriate security" provisions are not, when a dispute arises.
A penetration test is not an overall security proof. It tests specifically against a defined attack vector within a defined window. Typical web-application coverage:
For most B2B web applications, a grey-box test over five to ten working days is the most economical entry. The report lists findings with criticality rating (often CVSS) and remediation recommendations.
Important: a pen test finds vulnerabilities; it does not fix them. Remediation is part of the development budget — plan ten to twenty percent additional effort for remediation after a first productive pen test.
Standard practice: SAST and SCA in every pipeline. Threat modeling at project start as a mandatory task. Secure coding guidelines based on OWASP ASVS Level 2 for typical applications, Level 3 for security-critical products. External pen test before each major release — via partners with CREST or OSCP certification.
Contractually: specific security clauses as an annex to the work contract, incident-response window of twenty-four hours, documentation obligation for architecture and critical design decisions. Security engagements sit inside our cybersecurity portfolio and operate in lockstep with DevOps and cloud infrastructure.
If your organization falls under NIS2 or is preparing for certification, a structured assessment of your current software commissions saves time. Which suppliers have which security clauses on file? Book a complimentary online scoping session — we examine current state before the regulator asks. The parallel piece on GDPR-aligned product development covers the data-protection layer, which interlocks closely with Article 32 and BSI-equivalent standards.
Not mandatorily. Certified contracting organizations substantially reduce your own compliance effort. If you carry ISO 27001 or TISAX, critical suppliers should carry equivalent certification or demonstrate an equivalent ISMS.
Directly only in special cases (operators of critical infrastructure are in scope regardless of size). Indirectly often yes — as a supplier to an NIS2-bound customer, you may be asked to demonstrate evidence through the supply chain.
For critical applications, annually or after material changes. For lower-criticality applications, every two years. After a major architecture change, always — even when the prior test is recent.
Market pricing varies by scope and examiner qualification. Concrete quotes follow scope alignment (affected components, test depth, test days). Under five working days of testing effort, depth is typically inadequate for critical applications.
Yes, and you should. Tools like Dependabot (free with GitHub), Trivy, or SonarCloud cover baseline demand. The more important investment is less the tool than the process of triaging and remediating findings promptly.