01
Preparation
We confirm the scope, authorisation and testing conditions, and check access to the environment, accounts and documentation.
Application pentesting
Application penetration testing
We check whether accounts can be taken over, another user’s data accessed or important application rules bypassed. We test web applications and APIs within an agreed scope and explain the findings so your team can plan the fixes.
Trusted by
Companies and institutions that need stable IT.
Application security in practice
A customer portal, employee dashboard and partner API may expose the same data in different ways. Testing covers agreed functions and user roles, not just the sign-in page. It helps assess security before launch, after changes or when evaluating a supplier.
What we assess
We select scenarios based on the system’s functions, the data it processes and how people use it.
Accounts and permissions
We check whether users can view or change another person’s, company’s or role’s data. We also assess access to administrative functions.Authentication and sessions
We test the agreed sign-in, password reset and additional authentication mechanisms, along with session management and termination.APIs and data handling
We assess API access control, input and file handling, information disclosure and request limits.Business processes
We examine application-specific scenarios such as payments, orders, limits and approvals for ways to bypass the agreed rules.Information available to the testing team
We agree the model with you. More information changes what can be examined, but does not itself guarantee that every issue will be found.
Without accounts or documentation — black-box
We assess the application from an outsider’s perspective, using information available within the agreed scope.With accounts and some documentation — grey-box
We compare functions and data available to different user roles and can use the API documentation you provide.With source-code access — white-box
The agreed scope can include code, architecture and configuration. We specify which components are subject to review before work starts.What your team receives
The report relates to a specific application version and scope. It is not a guarantee that no vulnerabilities remain or a certificate of organisational compliance.
Reproducible findings
Affected functions and roles, conditions, requests and responses, or other evidence needed to reproduce a confirmed issue.Risk assessment and recommendations
Technical assessment, the impact on data and processes, and recommended priorities. We discuss the recommendations with the team responsible for the application.Summary and next steps
The key findings for management, testing limitations and areas for remediation and possible follow-up testing.Baseline — 10 years of recurring penetration tests
For 10 years, we have regularly tested the security of the Baseline platform, which supports business processes and document workflows. We test customer-facing modules and the administration panel, combining automated testing with detailed manual verification. After fixes are implemented, we carry out retests to verify their effectiveness. Our work supports Baseline in maintaining platform security and successfully passing audits conducted by TÜV NORD Polska.ISO 27001 · TÜV NORD Polska
Virtline’s information security management system is certified by TÜV NORD Polska. The published certificate specifies its scope and validity.
View Virtline’s certificateHow an application test works
We combine tool-assisted testing with manual analysis of application functions, permissions and workflows.
02
Testing
We carry out the agreed scenarios, analyse results and verify vulnerabilities in a controlled manner. Significant limitations are recorded in the report.
03
Discussing findings
We deliver the report and explain the findings to technical teams and decision-makers. We agree remediation priorities.
04
Checking changes
Where agreed, we retest specified vulnerabilities after remediation and document their current status and any retest limitations.
Practical scope
What we agree before testing
We need authorisation to test and clear boundaries. Different environments and roles may require separate scenarios.
We identify addresses, the system version, in-scope APIs and dependencies on other providers. We agree which activities are permitted in production.
We define test roles and data preparation. Accounts and documentation are shared through an agreed secure channel.
We discuss the processes whose compromise would cause the most harm, such as customer data access or payment approval.
We define permitted techniques, limits, dates, contact people and stopping conditions.
Testing methodology and references
OWASP ASVS defines application security verification requirements, while WSTG describes testing scenarios. We agree the scope and reference versions for the application and its APIs, taking account of data, user roles and risks discussed with the client. The legal sources below add context; they do not replace testing guidance or mean that a pentest proves full compliance.
Source
Regulation (EU) 2016/679 — GDPR
The official General Data Protection Regulation text in EUR-Lex.
Open sourceSource
Directive (EU) 2022/2555 — NIS2
The official text of the NIS2 Directive in EUR-Lex.
Open sourceSource
ISO — ISO/IEC 27001:2022
The official standard page for information security management system requirements.
Open sourceQuestions about penetration testing
Does the test include APIs?
+
Yes, if they are included in the scope. We agree the interfaces, functions, roles and data to assess. API documentation and test accounts help cover scenarios that are not visible through the browser alone.
Do you need test accounts and source code?
+
Not always. We can agree a test without accounts, a test using different user roles, or a scope that includes code and documentation. The model depends on the objective. Providing code does not automatically mean the entire application will be reviewed.
Can you test a live application?
+
Production testing can be agreed, but risk cannot be eliminated completely. We define permitted activities, hours, restrictions and stopping conditions. Higher-risk scenarios require separate arrangements or a test environment.
Will you check the application again after fixes?
+
We can retest specified vulnerabilities. Scope, timing and cost are agreed in the proposal or separately before work starts. Rechecking individual fixes does not replace a full test of a new application version.
Let us discuss testing your application
Describe the application, its main functions, user roles and API scope. Tell us whether a test environment is available and when you need the results. We will agree a secure way to transfer access details and confidential documentation separately.
Discuss an application test