Frequently asked questions

A penetration test is a hands-on security assessment where experienced testers attack your application the way a real attacker would - looking for ways to reach data or functionality they should not be able to reach. It is not a scan. Automated tools find known patterns; the findings that matter in a real application are usually logic and authorization flaws that no scanner can recognise, because nothing is malformed - the request is perfectly valid, it simply should not have been answered.

Web applications, REST APIs and mobile applications (iOS and Android) - including the backend services behind them. That is the whole of what we do; we are specialists rather than a general security firm.

It depends on the size of the application and the number of roles and workflows involved, but a typical engagement runs from a few days to a few weeks. We scope it with you first so you get a fixed timeline rather than an open-ended one, and we will tell you honestly if the scope you have in mind is too small to be meaningful.

A description of the application and what matters most about it, an environment to test against (staging that mirrors production is ideal), and credentials for each user role. Roles matter more than anything else: most serious findings come from what one role can do to another's data, so testing with a single account hides exactly the issues you most want found.

We prefer to test against a staging environment for that reason. Where production testing is necessary, we agree the boundaries with you in advance - what is in scope, what techniques are excluded, and a contact who can reach us immediately. Destructive testing is never done without explicit written agreement.

A report written for the people who have to fix the problem. Every finding includes what it is, how to reproduce it step by step, the real business impact, and a concrete remediation - not a scanner description and a CVSS number. We also walk your team through it, and we are happy to defend any finding to the developers who wrote the code.

By what an attacker can actually achieve in your application, not by a generic score. A theoretically 'medium' issue that exposes another customer's data is treated as what it is. We would rather tell you that a finding is not exploitable than pad a report - and we will say so plainly when that is the case.

Yes. A finding is not closed until it has been verified as fixed, and retesting of reported findings is part of the engagement rather than an upsell. It is also the point at which many teams discover a fix was incomplete.

Experienced application security specialists - the same people throughout the engagement. You are not handed to a junior after the kick-off call. Our team has included researchers who built tools the industry still uses and who went on to found security companies.

Yes. We will explain findings to the development team, review proposed fixes, and answer questions while remediation is underway. Having spent years teaching developers how attackers break applications, we know where reports usually lose their reader - so ours are written to be acted on.

It is driven by scope: the size of the application, how many user roles and workflows exist, whether APIs and mobile clients are included, and how deep you want us to go. We scope properly before quoting so the number you get is the number you pay. Talk to us and we will give you an honest estimate, including whether you need a test at all right now.

Yes - our testing and reporting are regularly used to satisfy customer security reviews, regulatory expectations and certification requirements. Tell us which framework or customer questionnaire you are answering and we will make sure the report addresses it.

Confidentially, under NDA, as standard. Findings, evidence and reports are treated as sensitive material - they are effectively a map of how to attack you. We are happy to sign your agreement rather than insist on ours.

Both, as accelerators - never as a substitute for a human. We use our own platform, CybeRapid, to take the repetitive work out of an engagement so that more of our testers' time goes on the parts that need judgement: attack strategy, business context and deciding what actually matters to you. The testing is human-led, enhanced by proprietary technology.

Get in touch with a short description of the application and what worries you about it. We will come back with scoping questions, a clear proposal, and a realistic timeline - and if we are not the right fit, we will say so.