What Is Penetration Testing? A Plain Guide (With Mobile App Focus) (2026)
Ten days or 249 days. In one five-year dataset of penetration tests, that is the gap between the top 10% and the bottom 10% of organisations at closing high-risk findings. A penetration test is an authorised, simulated attack on a system you own or operate. It uses the tools and techniques a real attacker would, to find out which weaknesses can actually be exploited. The report is only the start of the value, and in that dataset the difference between organisations opens up after the report arrives. This guide covers what a penetration test is, how an engagement runs, why a mobile app changes the scope, and what to settle before you sign anything.
Penetration testing statistics: what the data shows
The most detailed independent figures on penetration testing come from Cyentia Institute's analysis of pentest telemetry from Cobalt, published as the State of Pentesting Report 2026. Cobalt hosts its own edition at resource.cobalt.io. Every figure below comes from that report.
High-risk finding half-life, top decile: 10 days for the top-performing organisations, measured over five years of Cobalt pentests to 2026. Evidence type: independent analysis of vendor-collected engagement data.
High-risk finding half-life, bottom decile: 249 days for the bottom 10% of organisations on the same measure, which Cyentia describes as "about eight extra months of exposure."
High-risk resolution rate: 86% for "the typical organization" across the same five years.
Resolution rate, all findings: 52% across all findings in the dataset. The denominator differs from the 86% above, so the two are not one rate.
Share of findings rated high risk, all pentests: 12% across the dataset to 2026.
Share of findings rated high risk, AI and LLM pentests: 32%, which Cyentia describes as nearly 2.7 times the all-pentest rate.
Executives versus practitioners on SLA performance: 57% versus 15%, from a 2026 double-blind survey of 450 validated security leaders and practitioners, run alongside the Cobalt dataset.
Programme maturity and speed: organisations running a programmatic security process were 4.5 times more likely to resolve critical findings within three days than compliance-driven or ad hoc teams, by Cyentia's classification.
Dataset scope: more than 16,500 Cobalt pentests on nearly 3,000 organisations over five years, plus the 450-person survey.
Limitation: Cobalt sells penetration tests and owns this data, and Cyentia analysed it. It describes Cobalt's customers, not the market. No cross-provider benchmark with disclosed sampling was found, and the public pages do not publish full measurement definitions.
Cyentia's own summary is the line to keep: "Leaders and laggards start with about the same share of high-risk issues, so the gap opens up after the pentest report lands." Most organisations find a similar share of serious issues. What separates strong programmes is how quickly and completely they fix them. When you budget for a penetration test, budget for the remediation that follows it.
Get the Mobile Testing Playbook Used by 800+ QA Teams
Discover 50+ battle-tested strategies to catch critical bugs before production and ship 5-star apps faster.
What a penetration test is
The US National Institute of Standards and Technology defines penetration testing in its CSRC glossary as security testing "in which evaluators mimic real-world attacks in an attempt to identify ways to circumvent the security features of an application, system, or network." The same entry, drawing on NIST SP 800-95, gives an application-focused definition: testers "target individual binary components or the application as a whole to determine whether intra or intercomponent vulnerabilities can be exploited to compromise the application, its data, or its environment resources." NIST adds that most tests look for combinations of vulnerabilities that together grant more access than any single one.
The UK National Cyber Security Centre frames the purpose more narrowly. Its penetration testing guidance says a pentest "should be viewed as a method for gaining assurance in your organisation's vulnerability assessment and management processes, not as a primary method for identifying vulnerabilities." A pentest checks whether your defences hold against a skilled attacker. It is not how you discover most of what is wrong.
Tenable, which sells security tooling, draws the same line between an ongoing assessment and a test in its penetration testing overview: a vulnerability assessment is continuous, while pen tests give a "point-in-time picture."
How an engagement runs, phase by phase
Firms do not share one mandated sequence. IBM's explainer on penetration testing describes a common process that sets scope before any testing begins, then runs five steps:
Reconnaissance. The team gathers information on the target. For an app, that can include source code, alongside open-source intelligence.
Target discovery and development. The team turns what it learned into candidate weaknesses, for example through port scanning or probing how security features react to suspicious traffic.
Exploitation. The team begins the actual attack. The mix depends on the target, earlier findings and the agreed scope.
Escalation. After gaining a foothold, testers try to move around and reach more of the system. IBM calls this "vulnerability chaining."
Cleanup and reporting. The team removes any back doors or altered configurations it created, then writes the report.
IBM says the process "usually follows the same overall steps" whichever methodology is used, and names OWASP's guidelines, the Penetration Testing Execution Standard and NIST SP 800-115 as options. Read the five steps as IBM's description of common practice, not an industry rule.
For mobile apps, the OWASP Mobile Application Security Testing Guide (MASTG) uses its own structure: preparation, intelligence gathering, mapping the application, exploitation and reporting. Preparation is the phase to read closely. MASTG defines it as scoping the test, identifying applicable security controls, your testing goals and your sensitive data. It explicitly includes "all synchronization with the client as well as legally protecting the tester (who is often a third party)."
MASTG also gives reporting a shape: an executive summary, scope and context, methods, and sources of information. Ask any vendor for a sample report and look for those headings.
Why mobile apps are a different target
A mobile app is a product you distribute, not a service you host. The tester works against an app installed on devices you do not control. That fact shapes the engagement, and it is why MASTG's preparation phase spends time on client coordination and the tester's legal protection.
The second difference is the number of surfaces. MASTG treats static analysis, dynamic analysis and penetration testing as distinct kinds of work, and OWASP maintains a separate chapter on network communication. Mobile traffic is part of mobile testing, but not all of it.
That leads to a scoping question you should answer deliberately. A test that observes only the traffic your app sends and receives does not read the app artefact. A test confined to the installed app does not exercise the backend APIs it calls. Many mobile engagements therefore scope both the app and the services behind it. If your next question is how to test the API side routinely, Quash's guide to API testing for mobile teams covers it.
The third difference is the vulnerability classes. The OWASP Mobile Top 10 (2024) classifies mobile risks. It does not measure how often they occur. Several of its named classes concern the shipped app rather than its traffic, including insecure data storage, insufficient binary protection, improper credential usage and inadequate supply chain security. A scope that leaves out the app artefact is unlikely to address those directly. No published data gives their frequency in real mobile pentests.
Black-box, white-box and grey-box: choose scope to match your objective
Tests are commonly described by how much the tester knows in advance. MASTG defines three approaches:
Black-box testing is conducted without the tester having any information about the app. OWASP calls it "zero-knowledge testing," and its purpose is to let the tester behave like a real attacker.
White-box testing gives the tester full knowledge, which may include source code, documentation and diagrams. OWASP says this "allows much faster testing than black-box testing."
Grey-box testing falls between the two. Usually the tester receives credentials, and the rest is left to discover. OWASP calls it the most common kind of testing in the security industry. That is OWASP's characterisation, not a measured prevalence. For the QA-side view of the same idea, see Quash's gray box testing guide for mobile apps.
OWASP advises requesting source code so testing time is used efficiently, and says a white-box test is the way to go if the app has not been tested before. It adds a practical reason: Android decompilation is straightforward, but obfuscated code takes time to untangle. White-box is not a universal rule, though. A first test of an untested app and a test of the production build you ship to customers ask different questions, so pick the box that matches yours.
NCSC uses different words for the same split: transparent or open-box, and opaque or closed-box. If you meet either vocabulary, they map onto the same distinction.
OWASP also states the limit of automation plainly: automatic tools "will only find what they have been programmed to find," so human analysis may be needed to augment their results. A scanner runs in minutes while a manual tester works for hours or days. The difference is depth of analysis.
What a penetration test will not tell you
NCSC is direct about what a pentest cannot establish, and most introductions skip it.
It is scoped and time-bound. A test describes the scope and conditions it was given, at the time it ran. Findings are not proof that no other known issue existed, and any change to your system or the threat landscape changes the risk.
Long gaps between tests happen. NCSC notes it is "not uncommon for a year or more to elapse between penetration tests," so vulnerabilities could go unnoticed for long periods if testing is your only validation. This is a qualitative observation, not a measured average.
It audits a process; it does not replace one. NCSC compares a pentest to a financial audit. The audit checks the books at a point in time and does not run the business.
It is not the right tool for every question. NCSC says checking whether defined security controls are functioning is not a valuable use of penetration testing resources. It also says testing can usefully apply to systems and applications developed in-house, and that a planned pentest does not excuse dropping security tests from your normal regime. Use a pentest for adversarial questions and keep routine testing running beside it.
Quash (our product) does not focus on security testing, so routine functional and regression coverage from a tool like Quash sits alongside a pentest, not in place of one. The broader picture is in Quash's mobile app security testing guide.
Authorisation and scope: what to settle before testing starts
Authorisation comes first. MASTG warns that "attacking a system without written authorization is illegal in many parts of the world." Get written permission from someone with the authority to grant it before any engagement.
In the United States, the Department of Justice's charging policy under the Computer Fraud and Abuse Act describes how federal prosecutors approach computer-crime cases. It is prosecutorial policy, not a safe harbour, and it says nothing about law elsewhere.
Hosting providers set their own rules. Microsoft publishes penetration testing rules for Azure. If your app runs on a cloud platform, that platform's rules belong in your scope document.
Before you sign, your scope document should answer these:
What is in scope? Name the app binary, the backend APIs it calls, the cloud services behind them, and any third-party components you are responsible for.
Which box? State whether the tester gets source code, credentials or nothing, and which build, test or production, is in scope.
When? Agree the test window and who on your side can stop the test.
What does the report contain? Ask for the MASTG sections: executive summary, scope and context, methods, and sources of information.
Who fixes what, and by when? The Cobalt data suggests this is where outcomes diverge, so decide it before the report lands.
What is not published about cost and duration
No published, method-sampled benchmark of penetration testing price or duration, by scope or region, was found. Vendor pricing pages and blog estimates exist, but each is a company describing its own rate card, with no disclosed sample or method.
What the standards do show is what shapes an engagement: scope breadth, the box colour, and whether the scope covers the app artefact, the backend or both. Ask every vendor to price those factors separately so you can compare like with like. No measured rule for how often to test was found either; NCSC's observation about year-long gaps is qualitative.
How these figures were sourced
The statistics here come from one dataset: Cyentia Institute's analysis of Cobalt's penetration-test records, paired with a practitioner survey, both from the 2026 State of Pentesting Report. The public pages do not disclose exact start and end dates, exclusions or full measurement definitions; those sit in the full report.
Three kinds of figure were left out on purpose:
Market-size forecasts for penetration testing. The syndicated estimates found disclose no sample or method.
Vendor pricing estimates. Each is a seller describing its own offering, without a sample.
Breach-cost figures. They measure the cost of breaches at organisations that had one. They do not show what a pentest costs or what risk reduction it buys.
Quash has no first-party data on penetration testing, pentest findings or mobile-versus-network coverage. Three gaps remain in the public record, each with what would settle it:
Finding and remediation rates across providers. A multi-provider or provider-neutral dataset with disclosed sampling would show whether the Cobalt pattern holds beyond one customer base.
Mobile findings by asset type. A study reporting mobile-scope findings separately for the app binary, the operating system, the API and backend, and the cloud would show where mobile issues concentrate.
Price and duration by scope and region. A survey with a stated sampling frame and sample would give you a benchmark instead of a rate card.
Conclusion
Before you commission a penetration test, decide what question it must answer. If the question is whether a skilled attacker can exploit your app or its backend, scope the test to match: name the app build, the APIs and the box colour, and get written authorisation covering all of them. If the question is whether your controls work day to day, a pentest is the wrong instrument and routine security testing will serve you better.
Then plan for the part the data points to. Before the report arrives, agree how findings will be triaged, who owns each fix and what counts as closed. That decision is yours, and it is the one that separates the 10-day organisations from the 249-day ones.
Continue reading
More articles from the Quash editorial desk.
