What Is Penetration Testing? A Plain-Language Guide (2026)

If you have ever been told to "get a pen test" before closing a deal, passing an audit, or launching a product, you are not alone, and you are probably not sure what you are actually buying. Penetration testing is one of the most commonly requested and most poorly understood services in security. This guide explains it in plain language: what it is, who actually needs one, what happens during an engagement, how long it takes, and the misconceptions that trip up first-time buyers.

What penetration testing actually is

Penetration testing, or "pen testing," is a controlled, authorized attempt by a skilled human tester to break into your systems the same way a real attacker would. The tester probes your web applications, network, or cloud infrastructure for exploitable weaknesses, then documents exactly what they found, how they found it, and how to fix it.

The key word is human-led. A pen test is not the same thing as running a vulnerability scanner and forwarding the results. Automated scanners flag known signatures and misconfigurations, which is useful, but they cannot chain three minor issues together into a working exploit, cannot judge whether a flaw is actually reachable by an attacker, and cannot think creatively about your specific business logic the way a person can. A real pen test involves someone actively trying to compromise your environment and proving it, not just listing theoretical risks.

Who actually needs one

Pen testing shows up for a few distinct reasons, and knowing which one applies to you changes what you should be shopping for.

• Compliance requirements. SOC 2, PCI DSS, and ISO 27001 all expect regular penetration testing as part of the control set. If a customer or auditor is asking for a pen test report, this is almost always why.
• Sales and procurement pressure. Enterprise buyers, especially in the US, increasingly ask smaller vendors for recent pen test evidence during security review, even outside a formal certification.
• Pre-launch due diligence. Before shipping a new product, application, or major feature, testing catches exploitable flaws before customers or attackers do.
• Genuine risk reduction. Some organizations simply want an outside expert's honest read on how exposed they are, independent of any audit or sales requirement.

If none of these apply yet, you may not need a full pen test today. A lighter-weight security assessment might be the more appropriate starting point, and that is a conversation worth having with whoever is doing the testing before you commit to scope.

What actually happens during an engagement

A properly run pen test follows a defined sequence, not an open-ended fishing expedition.

Scoping. You and the testing team agree on what is in bounds: specific applications, IP ranges, cloud accounts, or network segments. This step also sets rules of engagement, such as testing windows and what happens if the tester finds something that looks like an active breach in progress.

Reconnaissance and mapping. The tester maps out what is exposed: subdomains, open ports, exposed APIs, authentication flows, third-party integrations. This is where a tester's judgment starts to matter, since knowing what is worth investigating separates a useful test from a noisy one.

Active testing. The tester attempts real exploitation: authentication bypass, injection flaws, privilege escalation, misconfigured cloud permissions, exposed secrets, and business-logic abuse specific to how your application actually works. This is the phase where human expertise pays off, since experienced testers chain small findings together the way a real attacker would rather than reporting each issue in isolation.

Reporting. You receive a report that lists each finding, its severity, proof it is exploitable (not just theoretical), and clear remediation guidance your engineering team can act on without needing a security background to interpret it.

Retesting. After you fix the findings, a competent provider retests to confirm the fixes actually closed the gap. Skipping this step is one of the most common ways companies end up with a report that says "fixed" on paper but is not fixed in practice.

Realistic timeline

For a single web application or a modest cloud environment, expect roughly one to three weeks of active testing, depending on scope and complexity. Add time on both ends for scoping and for report delivery and retest. If you are working against a hard deadline, such as an auditor's due date or a customer's security review, build in buffer, because scoping delays and remediation cycles are the most common reasons timelines slip, not the testing itself.

If you need the report to satisfy SOC 2 or PCI evidence requirements, confirm with your provider up front that the report format and testing methodology will actually be accepted by your auditor or acquirer. Not every pen test report is written with compliance evidence in mind, and finding that out after the fact costs you a second engagement.

Common misconceptions

"A vulnerability scan is the same thing." It is not. A scan is a useful input, but it is automated pattern matching, not human-led exploitation. Auditors and sophisticated buyers can usually tell the difference, and a scan alone will not satisfy most compliance requirements that specifically call for penetration testing.

"One pen test means we're secure now." A pen test is a snapshot of your security posture at one point in time. New code, new infrastructure, and new integrations introduce new risk. Most frameworks expect annual testing at minimum, and mature organizations test more often around major releases.

"A clean report is the goal." A report with zero findings is not necessarily good news, it is sometimes a sign the test was too shallow. A thorough test on a real system almost always turns up something. The goal is not a spotless report, it is an accurate one, followed by fixes.

"Any tester will do." Skill and experience vary enormously in this field. A tester who has done original security research, found real-world vulnerabilities, or holds recognized credentials brings a different level of insight than someone running the same scanner playbook on every engagement. This matters most for cloud and network testing, where business logic and environment-specific misconfigurations rarely show up in generic checklists.

How traztech approaches it

traztech runs human-led penetration testing across web applications, networks, and cloud environments, led by Jacob Masse, a published security researcher credited with five CVEs, including a CVSS 9.1 finding used to disable a variant of the Mirai botnet. Engagements are delivered with offensive-security partner Lorikeet, and testing is scoped from the outset to double as usable evidence for SOC 2 and PCI audits, so you are not paying for a second engagement later just to satisfy an auditor. You can see how this fits into a broader security program on our security services page, and if you are approaching this because of an upcoming SOC 2 audit specifically, our compliance services page covers how testing fits into the full audit timeline.

Next step

If you are trying to figure out whether you need a full penetration test, a lighter assessment, or something scoped specifically to satisfy an auditor or a customer's security review, the fastest way to get a straight answer is to talk to someone who does this work. Contact traztech to walk through your situation and get a scope and timeline that actually match what you need.

The different kinds of test, and which one you are being asked for

"Pen test" is a category, not a product. When a customer or auditor asks for one, they usually have a specific type in mind, and buying the wrong one is an expensive way to find out. These are the ones that come up.

External network testing looks at everything of yours that is reachable from the internet: exposed services, remote access, mail infrastructure, forgotten hosts left running after a migration. It is the cheapest test and the one most often confused with the others.

Web application testing targets your product itself, working through the login as a real user would. For a SaaS company this is almost always the test that matters, because your product is the thing holding customer data.

API testing overlaps with application testing but deserves naming separately, particularly if you have partner integrations or a mobile client. APIs tend to enforce authorization inconsistently across endpoints, and that inconsistency is invisible from the user interface.

Cloud configuration review examines identity and access policies, storage exposure, network boundaries, and secret handling in AWS, Azure, or GCP. It is not strictly a penetration test, though most providers bundle it, and for cloud-native products it frequently produces the most serious findings.

Internal network testing assumes a foothold already exists and asks how far an attacker gets from there. If you run an office network, a corporate identity directory, or on-premises systems, this is where lateral movement and privilege escalation show up. Companies that are entirely cloud-based often do not need it.

Social engineering covers phishing and pretexting against your staff. Useful, and a different exercise from technical testing, with its own consent and HR considerations that need agreeing in advance.

If you are not sure which one you are being asked for, ask the requester to point at the sentence in their policy or contract. It usually names the scope precisely, and reading it takes five minutes against the days you would spend guessing.

Black box, grey box, and why grey box is normally right

Testing firms describe engagements by how much information the tester starts with. Black box means they begin knowing only what a stranger would know. Grey box means they get accounts, documentation, and an architecture walkthrough. White box adds source code.

Black box testing appeals to buyers because it feels like the most honest simulation. In practice it spends a meaningful share of a fixed budget on reconnaissance that you could have handed over in an email, and the result is a shallower test for the same money. A determined attacker has months. Your tester has days, and the fair comparison is what an attacker finds over a long campaign, not what one can find in a week from a cold start.

Grey box is the default for a reason. You get accounts at multiple privilege levels, the tester gets past discovery quickly, and the days go into exploitation. Choose black box only when the specific question you are answering is "what is visible from outside", which is a reasonable question and a much smaller engagement.

What you need to have ready

Engagements slip at the start far more often than they slip during testing, and the causes are mundane. Before the kickoff call, have the following in place.

Test accounts for each role, created and confirmed working, on email addresses the tester controls. A named technical contact who can answer questions inside a day, because a tester blocked on an unanswered question is a tester burning your budget. Written authorization from someone with the standing to give it, which matters legally and matters again when your cloud provider or hosting partner asks. Agreement on the testing window, including whether out-of-hours testing is permitted. Confirmation of whether test data or real customer data sits in the target environment. And a decision on your firewall and rate limiting, since leaving them fully active means you are largely testing the vendor rather than your own code.

Also tell your team. Support staff receiving strange requests, engineers seeing failed login spikes, and an on-call rotation getting paged all need to know the window and the rule for the window, which should be that alerts get investigated as normal and the tester confirms attribution when asked.

How to read the report when it arrives

The first read is always uncomfortable, and the severity column is where people anchor. Two things are worth knowing before you circulate it internally.

Severity is technical, impact is yours. A rating reflects the characteristics of the flaw. Whether it matters depends on what sits behind the affected component, how many customers it touches, and what regulatory obligation attaches to the data. A medium-rated finding on your authentication flow can outrank a high-rated finding on an internal admin tool nobody outside the company can reach. Read the reproduction steps, not just the label.

Proof matters. Every finding worth acting on should include enough detail for one of your engineers to reproduce it in an hour: the request, the parameter, the response, and what the tester obtained. Findings that consist of a description and a severity, with no demonstration, are usually theoretical, and mixing them in with proven ones without distinguishing them is a sign of a weak report.

The other thing to look for is the presence of a narrative. Good reports include an attack path showing how several individually modest findings combine into something serious. That section is where an experienced tester earns their fee, and it is the part your engineering leadership should read first, because it explains why fixing three medium issues in a particular order is more valuable than fixing the highest-rated one.

What happens after, and what you can hand to a customer

Remediation is your work, not the tester's, and it is where the value is either realized or lost. Assign each finding an owner and a target date, fix in severity order with the attack path in mind, and then get the retest done and documented.

The artifact that follows the retest is more useful than most buyers realize. A retest letter, sometimes called an attestation, states what was tested, what was found, and what has been confirmed fixed. It is short, it contains no exploitation detail, and it is the document you give to customers and prospects. Handing over the full technical report is rarely wise, because it is a working set of instructions for attacking your product, and most sophisticated buyers do not expect it. Offer the letter first and share the full report under NDA only when a reviewer specifically requires it.

Keep the report itself, with the remediation record, for your auditors. The evidence they want is the pairing: the finding, the fix, the date, and the confirmation. A report on its own tells them you tested. A report with a closed remediation trail tells them you have a functioning process, which is the control they are actually assessing when you are working through a compliance program.

Pen testing compared with the things people confuse it with

Vulnerability scanning runs continuously, costs little, and finds known issues. It is the foundation. It is not a substitute, and running it well before a pen test makes the pen test better by clearing the noise.

Red teaming is objective-based and adversarial: given a goal such as reaching customer data, the team uses whatever route works, including phishing and physical access, usually without the defenders knowing. It tests detection and response as much as controls, and it only makes sense once you have a security team capable of detecting something. Buying it before that produces an expensive report saying nobody noticed.

Bug bounty programs pay outside researchers for findings on an ongoing basis. Good breadth, no schedule, no scope guarantee, and no report an auditor will accept as a point-in-time test. They complement testing rather than replacing it, and they demand internal capacity to triage submissions.

Breach and attack simulation tools automate known techniques against your environment continuously. Useful for validating detection coverage. Still automation, and still not a human trying to break your specific business logic.

When you should not buy one from us

Being straight about this saves everyone time.

If nobody has asked, no framework applies to you, and you have not yet shipped to paying customers, spend the money on fixing what you already know is wrong. Enable multi-factor authentication everywhere, remove standing production access, get backups running with a tested restore, and turn on a scanner. That work is cheaper and it removes the findings a test would have charged you to discover.

If you cannot remediate for the next six months because your engineering team is committed elsewhere, wait. A report ages, and a customer who asks for it will also ask what you did about it. An unremediated six-month-old report is a harder conversation than having no report at all.

If the requirement is genuinely a scan, buy a scan. Some contracts and questionnaires ask for evidence of vulnerability management, and companies read that as needing a full test. Check the wording first.

And if you have an internal security engineer with offensive experience, use them for the routine coverage and bring in an outside firm annually for independence, which is what most frameworks require anyway. Paying for both continuously is duplication.

Where an outside test genuinely earns its cost is a product holding customer data, an audit or enterprise buyer asking, and a team able to fix what comes back. If that is you, the useful next move is a scoping conversation rather than a quote, since the scope is what sets both the price and whether the report survives contact with your auditor. We are happy to tell you if the answer is to wait.