Application Security Testing

Application security testing for NIS2, DORA and CRA

We test web apps, mobile apps and APIs the way an attacker would, then help your team fix what we find. Every report ranks the findings by risk, and is evidence of the regular security testing that NIS2, DORA and the Cyber Resilience Act expect.

Start a project
See our work

Organisations we've built for

  • MeQrez General Hospital
  • Space Science and Geospatial Institute
  • Ahadu Bank

Best for

When a security test is the right move

If one of these is on your desk, a test and a clear report are usually the next step.

NIS2 supplier checks

A client under NIS2 asks how your software is tested for security, and there's nothing on paper.

A penetration test and a report you can show them, with each finding and its fix tracked.

Banks and DORA

Under DORA, banks must test the systems behind critical or important functions every year, and their suppliers are asked to help.

Tests by testers who didn't build the system, with a report your auditors can follow.

Products under the CRA

Your product is sold in the EU, and the Cyber Resilience Act asks for regular security tests and vulnerability handling.

Regular tests, a software bill of materials, and help setting up how vulnerabilities are reported and fixed.

Before a big launch

A new app or a major release is about to go live, and nobody has looked at it as an attacker would.

A test before launch, the fixes checked again, and any open risks written down.

What you get

What our security testing covers

Tests focused on the applications your business and your clients depend on.

Web application tests

Penetration tests of web applications, guided by the OWASP Web Security Testing Guide.

Mobile app tests

iOS and Android apps tested on the device and against the APIs behind them.

API tests

Sign-in, access control and data exposure tested on the APIs your apps and partners use.

Secure development

Secure code reviews, dependency and secret scanning, and security checks in your pipeline.

Every test includes

Scope and rules of engagement in writing

A report ranking every finding by risk

Clear steps to fix each finding

A retest once the fixes are in

How we deliver

From the scope to fixes you can show

Three steps, with the rules agreed in writing before any test starts.

01

Scope

We agree what's tested, when, with which accounts and what's out of bounds, signed before the first test.

02

Test

Our testers work through the scope by hand and with tools, and tell you straight away if they find a critical issue.

03

Report and retest

A technical report for your engineers and a summary for management, with every finding ranked. Once the fixes are in, we test them again.

How we work

Security and data

How we test safely

A security test touches your systems and your data. The rules for that are agreed before it starts.

Rules in writing.

Scope, timing and limits agreed and signed first, so nothing is tested that you haven't approved.

Findings kept confidential.

Test accounts instead of real users where possible, results shared only through secure channels, and test data deleted at the end.

Independent testers.

The testers are separate from the engineers who build software, including software we built for you.

How we protect your data

Compliance support

Help with the evidence your assessors ask for

We help you prepare for ISO/IEC 27001, PCI DSS and SWIFT CSP assessments. The certificate or attestation itself comes from your certification body or assessor.

Gap check.

Your current security controls compared with the standard, with the gaps ranked by risk and effort.

Evidence.

Test reports, records and policy drafts your assessor will ask for, prepared with your team.

What the rules mean for your software.

Which tests and processes NIS2, DORA or the CRA point to for your software, as engineering guidance alongside your legal advisers.

Sectors and technologies

Where we've built, and what we test against

Sectors

Our engineering team has built and secured systems for banks, hospitals and a national geospatial institute, led by people with banking, IT audit and national cyber security backgrounds.

Healthcare

Financial services

Logistics & mobility

Public sector & geospatial

Methods

Open, widely used methods, so your engineers and auditors can follow every finding.

OWASP WSTG

OWASP Top 10

OWASP MASVS

OWASP ASVS

Web

iOS

Android

APIs

FAQ

Questions about application security testing

Vulnerability assessments, penetration tests, source code reviews and a written report with every finding rated by severity and a recommended fix for each.

A scan is automated and finds known issues quickly. A penetration test adds people who think like attackers: they chain small weaknesses together and test the business logic a scanner can't understand. Most applications need both, at different intervals.

At least once a year and after major changes is common practice. DORA requires yearly tests of the systems behind critical or important functions, and the Cyber Resilience Act asks for regular tests over a product's life. We help you set a schedule that fits your releases.

No. Threat-led penetration testing under DORA Article 26 is a separate, larger exercise for the financial entities their authority identifies, run by testers who meet Article 27. We support the regular tests of Articles 24 and 25, such as vulnerability assessments, source code reviews and penetration tests.

Yes, with testers who weren't involved in building it. If your regulator or auditor needs a tester from outside FlightLabs, we tell you before the test, so the report counts for what you need it for.

We agree the scope, the targets and the time window in writing before we start, and test a staging copy where we can. Anything that could affect production is agreed with you first.

Manufacturers have had to report actively exploited vulnerabilities and severe incidents since 11 September 2026. The security requirements, including regular tests and vulnerability handling, apply from 11 December 2027 to products placed on the EU market.

No. Certification comes from an accredited certification body, and PCI DSS assessments from a qualified assessor. We help you prepare: the gap check, the tests and the evidence they'll ask for.

Vulnerability assessments, penetration tests, source code reviews and a written report with every finding rated by severity and a recommended fix for each.

A scan is automated and finds known issues quickly. A penetration test adds people who think like attackers: they chain small weaknesses together and test the business logic a scanner can't understand. Most applications need both, at different intervals.

At least once a year and after major changes is common practice. DORA requires yearly tests of the systems behind critical or important functions, and the Cyber Resilience Act asks for regular tests over a product's life. We help you set a schedule that fits your releases.

No. Threat-led penetration testing under DORA Article 26 is a separate, larger exercise for the financial entities their authority identifies, run by testers who meet Article 27. We support the regular tests of Articles 24 and 25, such as vulnerability assessments, source code reviews and penetration tests.

Yes, with testers who weren't involved in building it. If your regulator or auditor needs a tester from outside FlightLabs, we tell you before the test, so the report counts for what you need it for.

We agree the scope, the targets and the time window in writing before we start, and test a staging copy where we can. Anything that could affect production is agreed with you first.

Manufacturers have had to report actively exploited vulnerabilities and severe incidents since 11 September 2026. The security requirements, including regular tests and vulnerability handling, apply from 11 December 2027 to products placed on the EU market.

No. Certification comes from an accredited certification body, and PCI DSS assessments from a qualified assessor. We help you prepare: the gap check, the tests and the evidence they'll ask for.

Vulnerability assessments, penetration tests, source code reviews and a written report with every finding rated by severity and a recommended fix for each.

A scan is automated and finds known issues quickly. A penetration test adds people who think like attackers: they chain small weaknesses together and test the business logic a scanner can't understand. Most applications need both, at different intervals.

At least once a year and after major changes is common practice. DORA requires yearly tests of the systems behind critical or important functions, and the Cyber Resilience Act asks for regular tests over a product's life. We help you set a schedule that fits your releases.

No. Threat-led penetration testing under DORA Article 26 is a separate, larger exercise for the financial entities their authority identifies, run by testers who meet Article 27. We support the regular tests of Articles 24 and 25, such as vulnerability assessments, source code reviews and penetration tests.

Yes, with testers who weren't involved in building it. If your regulator or auditor needs a tester from outside FlightLabs, we tell you before the test, so the report counts for what you need it for.

We agree the scope, the targets and the time window in writing before we start, and test a staging copy where we can. Anything that could affect production is agreed with you first.

Manufacturers have had to report actively exploited vulnerabilities and severe incidents since 11 September 2026. The security requirements, including regular tests and vulnerability handling, apply from 11 December 2027 to products placed on the EU market.

No. Certification comes from an accredited certification body, and PCI DSS assessments from a qualified assessor. We help you prepare: the gap check, the tests and the evidence they'll ask for.

Related services

Often combined with

Quality & security

QA & Test Automation

Functional and automated tests, so security fixes don't break anything else.

Rescue & run

Codebase Recovery & Stabilisation

When a test finds deeper problems in the code, we stabilise and fix the code itself.

Rescue & run

DevOps & Managed Support

Patches and dependency updates on a schedule, so known vulnerabilities get fixed.

Have a project in mind?

We reply within one working day.

FlightLabs is a Berlin-based software engineering company that builds, tests, secures and runs production software and AI for European companies, with its engineering team in Addis Ababa, 1–2 hours from Central European Time.

hello@flightlabs.ioBerlin, GermanyEngineering team: Addis Ababa, Ethiopia
LinkedIn (opens in a new tab)

In partnership with eTech S.C.