A penetration test (pen test) checks whether a specific system has vulnerabilities that can be exploited in practice under the conditions defined for the test, and what their impact could be. With your written authorisation, we define the boundaries of the test and its safety rules, combine automated reconnaissance with manual testing and document evidence that helps your team remediate the risk.
The aim of a pen test is not to produce the longest possible list of vulnerabilities. It is to test a specific attack surface within a limited time and scope, validate significant findings and show what impact they can have. We choose the type of test and the starting point to suit the system and the risk you want to test.
We test authentication, session management and access control, business logic, input handling, object-level and function-level authorisation in APIs, server configuration and other attack vectors that matter for the application in question. We do not stop at what an automated scanner reports.
Depending on the scope, we test public-facing or internal services, configuration, known vulnerabilities, authentication and privilege risks, and other paths that can lead to unauthorised access or allow an attacker to escalate the privileges initially gained.
How much information and access we start with can vary from test to test. Testing from the perspective of an external attacker answers one question. Test accounts, documentation or other information you provide allow deeper testing of authorisation, business logic and features that are not public-facing. We choose the approach based on the objective of the test, rather than assuming that less information always means a better test.
Before active testing begins, we set out in writing the objectives and boundaries of the test, permitted and prohibited actions, testing windows, the sources the testing will come from, points of contact, incident escalation and stop conditions. When a production system is tested, the level of risk has to be chosen deliberately. A pen test is not free of consequences, so we agree riskier methods separately or exclude them.
We define the objectives of the test, which systems, accounts and other assets are in or out of scope, the permitted methods, testing windows, points of contact, escalation and stop conditions. The necessary authorisation is formally in place before testing starts.
We combine reconnaissance and automated tools with manual testing. We validate significant findings only as far as is needed to prove the impact, and only within the agreed rules. The evidence is documented in a reproducible form that developers can use.
You get the findings with technical evidence, an explanation of the impact, a risk priority and recommendations for remediation. When we rate a finding, we consider not only its technical severity but also how exploitable and reachable it is and how important the affected asset is in your environment.
Once the fixes are in place, we retest the agreed findings and document their status. A retest confirms the state of a specific finding at that point in time; it is not a new full-scope pen test and does not confirm that the system has no other vulnerabilities.
Find out where your weak points are
Send us a few details about the system and what you want to test. We will reply within one working day and clarify the information we need to scope the test and prepare a proposal.
Automated scanning is useful for identifying the attack surface and known issues, but on its own it does not show everything in an application's business logic, its authorisation flaws, or the way several seemingly minor weaknesses link up into a single attack chain. In a pen test, the scanner's findings are only one of the inputs. We check them manually, look for additional attack paths and document the impact we can demonstrate in practice.
A pen test is an assessment of a system over a specific period of time; it does not guarantee that the system has no vulnerabilities once the test is over. It makes sense to consider one before a major release, after significant changes to the architecture or infrastructure, after a major incident, or periodically, in line with the system's risk and your organisation's security programme.
In a black box test, the tester starts with no inside information, like an outside attacker. In a grey box test they have partial information, such as a user account, and in a white box test documentation or source code is available as well. The more information there is, the more of the system can be covered in the same time, so we choose the approach based on the goal of the test. To test what an attacker could do once already inside, an assumed breach test is the better fit.