How security testing is done

Scoping defines the exact coverage of the test: which applications, APIs, systems, and features are included. Another important decision is the depth of testing — whether a vulnerability scan is sufficient or if penetration testing is required. The next chapter of this guide explains these differences in more detail.

It is also important to understand the security threats or risks already identified for the target system. If these are not known, a good starting point may be a threat modeling exercise.

1. Scoping meeting

In the scoping meeting, the target system is introduced to the testing team in its business context. The main goal is to estimate the effort required, which depends on the size and complexity of the target and the testing methods used.

For web or mobile applications, demonstrating the user interface is often enough to provide an effort estimate. The simplest way to arrange this is through a Teams meeting. Another option is to provide credentials to a demo environment, but these are not always available.

For external or internal networks, the effort estimate is based on the number of servers, domains, and/or IP addresses in scope.

Once the target is clear, the team ensures that the chosen testing method supports the business objectives. These objectives may include regulatory reporting, risk assessments, or vulnerability management.

From the client side, the scoping meeting should include both business stakeholders and technical experts. For external network testing, typical participants include the CISO, CIO, and IT Manager. For applications, this should include the product manager, lead developer, and an infrastructure representative. If the application runs in a partner’s environment, the partner should also be informed about the upcoming test..

2. Testiympäristön valmistelu

Testing in production is not recommended, although in some cases it may be unavoidable. The preferred option is a production-like environment (test or staging) to ensure that findings are still relevant for production.

If the test environment is inside the client’s internal network, firewall rules or a VPN connection may be needed. If the test or staging environment is accessible from the internet, no special access is required.

Test accounts are required for the application to check visibility restrictions across organizational and user levels. They also enable test cases that simulate the perspective of a dishonest end user.

Before testing begins, it is recommended to take a backup — especially if testing in production or if test data would be difficult to recreate.

3. Testing and reporting

Testing is carried out by experts using both automated and manual security tools and methods. Findings are verified by attempting to exploit them. This removes false positives and provides a more accurate impact assessment for confirmed issues.

The duration of testing depends on the scope and complexity of the target. A typical project for a web application lasts one to two weeks. Testing network environments usually takes two to four weeks.

The result of testing is a report describing the scope of work, the findings and their associated risks, and recommendations for remediation. The results are reviewed with the client in a follow-up meeting to ensure that the severity of findings and the required corrective actions are fully understood.