NIS2 Art. 21 · NIST SSDF · OWASP ASVS

NIS2 Software Security Assessment

Structured software security assessment for NIS2-relevant environments

The assessment builds on our security code review and extends it with a defined control catalog, evidence requirements and documented pass/fail criteria. You get traceable evidence of how your software addresses relevant NIS2 security requirements.

Request a NIS2 assessmentView the security code review

A software assessment can neither establish nor confirm the NIS2 compliance of your company as a whole.

Who is it for?

The assessment is an optional add-on. You only need it if you require structured evidence. Otherwise, a security code review is enough.

NIS2-relevant companies

Your company falls under NIS2 itself and you want to demonstrate the security of software you develop in a traceable way.

Software suppliers

You supply software to NIS2-relevant companies and are being asked for security evidence.

Supply chain documentation

You need to document dependencies, build process and vulnerability handling for your software.

Structured security evidence

You need more than a findings list: defined controls, evidence and a traceable result.

Procurement & vendor assessments

Your customers set concrete software security requirements in tenders or supplier assessments.

How the assessment differs from a security code review

The technical security review remains the core. The assessment adds structure and verifiability without reinventing anything: the controls are derived from NIS2 Art. 21, Implementing Regulation (EU) 2024/2690 and the ENISA guidance, and are mapped to open standards such as NIST SSDF, OWASP ASVS and CWE.

Defined controls

We assess against a fixed control catalog rather than only against an individually agreed scope.

Evidence requirements

Each control defines which evidence is expected, such as configurations, pipeline definitions or process documents.

Documented test steps

Every test step is described, making it traceable for third parties as well.

Pass/fail criteria

Clear criteria for when a control counts as met, instead of a mere assessment.

Supply chain & vulnerability management

Beyond the code, we look at dependencies, the build process and how vulnerabilities are handled across the lifecycle.

NIS2 mapping

Results are mapped to relevant requirements from NIS2 Art. 21 in a documented way, as a traceability aid rather than proof that a legal obligation is met.

What is assessed? The 10 domains

NIS2 Art. 21 addresses, among other things, supply chain security, security in the acquisition, development and maintenance of network and information systems, and vulnerability handling. Our control catalog maps the relevant software security aspects into ten domains.

  1. 01

    Governance & Risk

    Responsibilities, security requirements and risk assessment for the software.

  2. 02

    Architecture & Threat Modeling

    Security architecture, trust boundaries and documented threat analysis.

  3. 03

    Secure Software Development

    Secure development practices, code reviews and coding guidelines.

  4. 04

    Authentication & Authorization

    Login, sessions, roles and permission checks.

  5. 05

    Cryptography & Data Protection

    Encryption, key management and protection of sensitive data, including archives, backups and exports.

  6. 06

    Software Supply Chain

    Dependencies, SBOM and provenance of third-party components.

  7. 07

    CI/CD & Build Security

    Integrity of pipeline, build and artifacts.

  8. 08

    Vulnerability Management

    Detection, assessment and remediation of vulnerabilities.

  9. 09

    Logging, Monitoring & Incident Handling

    Security-relevant logging, monitoring and incident readiness.

  10. 10

    Security Testing

    Automated and manual security testing in the development process.

The full control catalog comprises 71 controls, each referencing the matching practice from the NIST Secure Software Development Framework (SSDF). We walk you through it in the initial meeting.

How the assessment works

Built on the security code review, extended with evidence and documentation.

  1. 01

    Scope & context

    We define application, version, components and the requirements relevant to you.

  2. 02

    Security code review

    Technical review of the source code as the foundation of the assessment.

  3. 03

    Evidence review

    We review evidence on processes, pipeline, dependencies and vulnerability management.

  4. 04

    Assessment report

    Status per control (PASS, FAIL, N/A or NOT TESTED), findings, remediation, NIS2 mapping and overall result.

  5. 05

    Retest

    After remediation, we verify open controls and update the result.

What you get

A documented result you can use internally and with your customers.

Control assessment

A status for each control (PASS, FAIL, N/A or NOT TESTED) with rationale and referenced evidence. N/A always comes with a technical justification.

Findings & remediation

Technical findings from the security code review with severity and concrete recommendations.

NIS2 mapping

Documentation of which controls contribute to which requirements from NIS2 Art. 21.

Assessment statement

A result summary following the standard's template, with assessment ID, assessed version, overall result, and issue and expiry dates.

What the result means and what it doesn't

Clear statements instead of compliance promises.

What does PASS mean?

PASS requires zero open Critical or High findings, all applicable mandatory controls passed, and no material limitation that prevents a reliable conclusion. PASS WITH OBSERVATIONS is possible when all mandatory controls pass and only Medium, Low or Observation findings with documented treatment remain. In all other cases the result is FAIL. It applies only to the documented assessment boundary of product, version and commit.

Statements you can make

  • That your software has undergone a software security assessment by vensas, with result and date.
  • Always naming the assessed product and version, or linking to the public verification record.
  • No wording that implies government approval, statutory certification, accreditation or blanket NIS2 compliance.

What the assessment is not

  • Not a certification and not an audit by an authority
  • Not a confirmation of your company's overall NIS2 compliance
  • Not a substitute for organizational measures such as risk management or reporting processes
  • Not a permanent statement: the result refers to a version and a point in time

Frequently asked questions

No. The result is a documented assessment based on established standards such as NIS2 Art. 21, Implementing Regulation (EU) 2024/2690, the ENISA guidance, NIST SSDF and OWASP ASVS, not a certification by an authority or an accredited body.
NIS2 applies to companies, not to individual software products. The assessment shows how your software addresses relevant security requirements from NIS2 Art. 21 and is therefore one building block of your evidence. It can neither establish nor confirm your company's NIS2 compliance.
No, the security code review is part of the assessment. If we have already reviewed your code, we build on that.
Besides read access to the repository, typically pipeline definitions, information on dependencies (for example an SBOM), descriptions of your development and vulnerability processes and relevant configurations. We clarify exactly what's needed during scoping.
Every result has an issue and an expiry date and applies only to the assessed version. Material security-relevant changes, such as to the architecture or authentication, or a newly discovered Critical or High vulnerability can invalidate it earlier. Where a mark is issued, a public verification record is intended to show its current status (valid, suspended, withdrawn or expired).

Do you need structured security evidence?

Let's clarify whether the NIS2 assessment makes sense for you or whether a security code review is already enough.

Request a NIS2 assessment

You don't need formal evidence? Go to code review & security code review