8 Detailed Pen Test Example Scenarios for 2026

Beyond the Scan: Real-World Pen Test Examples

Penetration testing reports often land with a thud. They're packed with scanner output, generic risk text, and screenshots that prove very little to the client who has to fix the problem. If you're a solo tester, freelancer, or part of a small consultancy, you've probably felt that gap between good technical work and a report that drives remediation forward.

A useful pen test example doesn't stop at naming a vulnerability. It shows the setting, the attack path, the proof, the business impact, and the fix. It also shows how to document all of that clearly enough that an engineering lead, security manager, and compliance contact can all act on it without a follow-up meeting for every finding.

That's the standard worth aiming for in 2026. Not longer reports. Better ones.

The eight scenarios below treat each pen test example like a mini case study. Some are drawn from published real-world engagements. Others reflect common engagement patterns practitioners see repeatedly across internal networks, web applications, mobile apps, cloud estates, and human-layer testing. In every case, the reporting angle matters as much as the exploit chain. A missed detail in the write-up can make a valid finding hard to reproduce, hard to prioritise, or easy to argue away.

1. Network Penetration Testing

A strong network pen test example usually starts with something mundane: exposed services, weak segmentation, stale credentials, or management interfaces that nobody meant to leave reachable. That's why network testing is still foundational. It gives you the quickest view of whether perimeter controls, internal trust boundaries, and operational hygiene match the client's assumptions.

One published data point is worth keeping in mind. In simulated attacks, pentesters breached 96% of networks with an average penetration time of 5 days and 4 hours, often through credential brute force, according to the statistics compiled at ZeroThreat's penetration testing statistics roundup. That tracks with what many practitioners see in real engagements. Networks rarely fall because of a single exotic bug. They fall because several ordinary weaknesses line up.

A realistic case pattern

A common scenario looks like this: external reconnaissance identifies a VPN gateway, mail portal, and a handful of internet-facing services. Initial scans may only show minor hygiene issues. Actual progress starts when password spraying, reused credentials, or an exposed admin path provide low-level access, followed by lateral movement through weak internal segmentation.

The reporting mistake is to dump every open port and every medium-severity issue into the main narrative. That buries the actual attack chain.

Use the report to show sequence:

• Entry point: Which exposed service or credential issue enabled foothold.
• Expansion path: Which trust relationship or firewall rule allowed pivoting.
• Privilege path: Which local admin rights, service accounts, or shares increased access.
• Business impact: Which sensitive systems became reachable as a result.

For teams that handle this work frequently, network penetration testing guidance from Vulnsy is useful as a structuring reference because network findings tend to repeat even when environments differ.

Practical rule: Report the path, not just the parts. Clients fix attack chains faster than they fix disconnected findings.

A good network report also benefits from visual evidence. Include route maps, firewall screenshots where permitted, proof of host reachability after pivoting, and concise notes on what you deliberately didn't test because of scope limits. That last point matters in shared hosting, third-party links, and multi-tenant office environments.

2. Web Application Penetration Testing

The best web application pen test example is rarely “scanner found SQL injection”. Modern web assessments often become business logic investigations. The app appears clean under automated checks, then manual testing finds the significant flaw.

A published UK banking case shows that clearly. In a 2022 test by Pentestica for a major UK retail bank, pre-test scanning with tools such as Nessus and Burp Suite surfaced only low-severity issues, but manual black-box testing uncovered a race condition in transaction authorisation and an IDOR issue in account-linking endpoints. Testers manipulated API requests with timestamp offsets under 100ms and simulated a £250,000 unauthorised transfer without triggering fraud detection, as described in Pentestica's case studies.

What this kind of finding teaches

This is the sort of pen test example clients remember because it changes how they think about risk. The scanner wasn't wrong. It just wasn't testing the question that mattered: can a user abuse application workflow to move money improperly?

That has reporting implications:

• Include the exact request flow: Show the endpoint sequence, not just the vulnerable parameter.
• Document the user role used in testing: Business logic flaws often depend on ordinary permissions.
• Describe the timing condition plainly: If race conditions matter, write out the window and execution method.
• Separate root cause from symptom: “IDOR” is the symptom. Missing object-level authorisation is the root cause.

If you're standardising web app reporting, Vulnsy's web application pentest checklist is a practical reference for making sure evidence, PoC steps, and remediation fields stay consistent across assessments.

A weak report for this issue would say “Broken access control may allow unauthorised account actions.” A useful report shows the JSON payload changes, the affected endpoint, the expected server-side control, and the safest remediation path. In the same published case, remediation included input validation, rate limiting, and least-privilege API tokens, followed by a re-test confirming no exploitable path remained.

Manual testing earns its keep when the application behaves correctly in technical terms but incorrectly in business terms.

3. Social Engineering and Phishing Assessments

Social engineering assessments fail when teams treat them like marketing campaigns with a scoreboard. A click rate by itself doesn't tell the client what failed. Was it email security, identity verification, call handling, badge checks, or escalation procedure? The report needs to answer that.

One NHS-focused red team case illustrates the point. In a 2023 exercise against an Epic-based patient management system, testers combined vishing with technical follow-on activity. The social engineering stage succeeded against 85% of 20 staff and produced 3 valid Active Directory credentials, which then enabled lateral movement and privilege escalation, according to the case details published at Petronella Technology Group's real-world penetration testing examples.

Reporting the human layer properly

That example matters because the human action wasn't the end of the story. It was the bridge into technical compromise. That's how social engineering findings should be written up.

A practical structure works well:

• Pretext used: IT support callback, password reset, supplier query, executive request.
• Target behaviour: Credential disclosure, MFA approval, software execution, badge bypass.
• Observed control gap: Weak caller verification, unclear escalation path, over-trusting internal language.
• Downstream impact: Domain access, mailbox access, VPN entry, physical presence.

If you run these engagements regularly, social engineering pentest reporting ideas from Vulnsy can help keep HR, security, and leadership audiences aligned without writing separate narratives from scratch.

The common trade-off here is realism versus safety. More realistic pretexts produce more useful results, but you need hard boundaries around who can be targeted, what can be requested, and when an attempt must stop. That should be documented before the first email or phone call goes out, then reflected again in the final report so nobody mistakes agreed simulation for uncontrolled tester behaviour.

A phishing result only becomes useful when you connect the employee action to the control that should have caught it next.

4. Mobile Application Penetration Testing

Mobile app testing exposes a reporting problem that desktop and web teams often underestimate. The finding usually spans the app binary, local device storage, transport security, and backend API behaviour. If you document only one layer, the client can patch the symptom and leave the underlying issue in place.

A practical mobile pen test example is an app that stores tokens or user identifiers insecurely on-device, while the backend accepts those artefacts with too much trust. On Android, that might surface during local file review, intercepted traffic analysis, or reverse engineering of the APK. On iOS, it might show up in keychain handling, plist contents, or trust validation logic.

What works in mobile assessments

Test on both an emulator and a physical device. Emulators are faster for repeatable checks, but real devices reveal operational controls, certificate pinning behaviour, biometric flows, and environmental assumptions that don't always hold under emulation.

Your report should tie together four evidence types:

• Static evidence: Decompiled code snippets, hardcoded secrets, unsafe storage paths.
• Dynamic evidence: Intercepted requests, modified responses, runtime instrumentation results.
• Authorisation evidence: What a normal user can access after tampering.
• Device context: Rooted or jailbroken assumptions, OS version, app build version.

The reporting trap is overloading the client with reverse engineering detail they can't use. Include enough to prove the issue and support developer reproduction, but keep low-level analysis in an appendix if it distracts from the remediation path.

If your engagement touches mobile attack surfaces from unconventional devices or workflows, Digital Footprint Check's article on hacking with an iPhone is a useful example of how mobile tooling can shape testing perspective, even when the target isn't strictly a consumer app.

A good remediation section for mobile findings almost always includes both client-side and server-side changes. Secure local storage helps. Proper token scoping, backend validation, and API-side authorisation matter more.

5. Cloud Infrastructure and Configuration Testing

Cloud pen tests look technical on the surface, but most of the risk comes from governance failures. Excessive IAM permissions, forgotten public storage, overly broad security groups, and inherited defaults are usually more dangerous than any one exposed VM.

This category rewards precise scoping. Before testing starts, establish whether the client wants a tenant configuration review, exploit validation, identity path testing, Kubernetes coverage, serverless review, or some mix. “Test our AWS” isn't a scope. It's a budget leak.

A common cloud case pattern

A realistic engagement might begin with read-only review of IAM policies and public exposure checks, then move into abuse validation. A storage bucket may be public by mistake. An instance role may allow lateral discovery. A CI/CD token in a repository may expose deployment control. Individually, each looks administrative. Together, they form an attack path.

What works in reporting is grouping findings by blast radius instead of by service name. Clients care less that the issue lives in S3, Azure RBAC, or GCP IAM than they do that it enables data exposure, privilege escalation, or workload takeover.

Use short remediation language:

• Reduce identity scope: Remove wildcard actions and broad trust relationships.
• Tighten network paths: Limit inbound management exposure and peer reachability.
• Protect secrets: Rotate credentials found in code, pipelines, or instance metadata paths.
• Improve auditability: Ensure logging and alerting support detection of abuse, not just configuration change.

For cloud work, screenshots still help, but they shouldn't carry the report. Pair them with policy excerpts, command output, and a short explanation of why the misconfiguration is exploitable in the client's environment. A screenshot of a public bucket isn't enough. Show what an unauthenticated user could list or retrieve, and note whether the exposure is direct, inherited, or conditional.

6. Wireless Network Penetration Testing

Wireless assessments often reveal a mismatch between what the client thinks is physically reachable and what is. Office walls, car parks, shared buildings, and guest networks all complicate the picture. A secure wireless design on paper can still expose the environment to anyone with time, proximity, and a directional antenna.

A solid wireless pen test example might involve a guest SSID that's isolated from the main estate in theory but still allows access to internal services through DNS leakage, weak segmentation, or an overlooked management interface. Another common pattern is a corporate SSID protected by strong encryption but undermined by poor onboarding practices, shared credentials, or trust in rogue access points.

Evidence that matters

Wireless reports improve when they include field context. Signal presence from outside the building, accessible SSIDs in shared premises, captive portal behaviour, and AP naming conventions all influence risk.

Useful evidence includes:

• Coverage observations: Where the network was reachable from.
• Authentication details: WPA2/WPA3 mode, enterprise setup, onboarding process.
• Rogue AP exposure: Whether users could be induced to connect elsewhere.
• Post-connect validation: What internal resources were reachable after association.

Clients often ask, “Can someone crack the Wi-Fi?” The better question is, “What could an unauthorised person reach after connecting, or after impersonating a trusted network?”

Trade-offs matter here. Aggressive testing in shared spaces can create legal and operational risk. Get written approval for channels, locations, testing windows, and whether deauthentication or impersonation techniques are allowed. Then make those same boundaries visible in the report. Wireless findings become contentious when the client can't tell what was tested safely versus what was intentionally excluded.

7. Physical Security and Badge Testing

Physical security findings can be the most politically sensitive in a report because they involve staff behaviour, guard performance, facilities process, and sometimes executive assumptions. If you write them carelessly, the report turns into blame. If you write them well, it becomes a control-improvement document.

A useful physical pen test example isn't “tester entered office by tailgating”. It's more specific. The tester entered through a staff entrance during a busy period, passed through because visual badge checks were inconsistent, reached a restricted corridor without challenge, and then accessed an area that should have required secondary verification.

How to report without turning it into theatre

Keep physical findings factual and time-bound. Include timestamps, entry points, observed controls, bypass method, and what assets became exposed once access was gained. If the engagement involved cloned badges, unattended desks, unsecured comms rooms, or visible credentials, document each one as a separate control failure rather than as one dramatic story.

That separation helps remediation:

• Entry control failure: Tailgating, poor challenge process, weak reception workflow.
• Internal zoning failure: Sensitive areas lacked secondary barriers or checks.
• Asset protection failure: Cabinets, consoles, or paperwork exposed useful information.
• Monitoring failure: Logs existed but no one reviewed them, or review happened too late.

The worst way to write up physical testing is to lean on theatrics. The best way is to show how one lapse allowed the next. Facilities teams can then address process, training, and hardware separately.

Because these reports often include floor plans, photos, and access details, limit distribution carefully. Clients usually need an executive summary for leadership and a restricted technical appendix for security and facilities staff. Putting all of that in one unrestricted PDF creates a new problem while you're trying to solve the original one.

8. Third-Party and Supply Chain Risk Assessment

Third-party testing is where many reports become vague. They fall back on questionnaire summaries, certification checklists, or a few broad observations about “vendor risk posture”. That's not enough when the third party has network access, processes regulated data, or sits in a critical workflow.

A strong supply chain pen test example links vendor weakness to client exposure. Maybe a service provider has remote administrative access with weak segmentation. Maybe an integration partner handles sensitive records through an API with poor token hygiene. Maybe a payment-adjacent supplier stores or transmits data in ways that create contractual or compliance risk for the client.

Turning vendor findings into action

The key reporting choice is to distinguish between verified exposure and unanswered assurance questions. If you've tested an integration path and confirmed insecure behaviour, say so plainly. If the vendor refused evidence or access, mark that as residual risk, not as a proved compromise.

Structure helps here:

• Relationship context: What the vendor connects to, stores, or administers.
• Control gap: Missing MFA, poor access review, unsupported systems, weak data handling.
• Client-side consequence: Indirect access to internal systems, sensitive data exposure, service disruption risk.
• Ownership of remediation: Vendor, client, or shared responsibility.

One UK-specific reporting gap is worth noting. General guidance often misses local compliance framing, yet the UK government's 2025 Cyber Security Breaches Survey reported that 43% of UK businesses experienced breaches and only 22% conducted regular pen tests aligned with sector-specific requirements, as summarised in this discussion of penetration testing gaps and examples. For freelance testers and small consultancies, that means supply chain reports often need a clearer compliance mapping layer than generic templates provide.

Don't pad this section with abstract risk language. If a vendor has access to a production tenant, say what that access can do. If evidence is missing, say what can't be verified and what the client should require contractually before renewal.

8-Point Penetration Testing Comparison

Assessment Type	Implementation Complexity	Resource Requirements	Expected Outcomes	Ideal Use Cases	Key Advantages
Network Penetration Testing	Moderate–High (broad network scope, lateral movement)	Experienced testers, scanners, controlled network access	Identification of network vulnerabilities, exploit paths, remediation priorities	Enterprises with complex on-prem or hybrid networks	Validates real network controls; prioritises fixes
Web Application Penetration Testing	High (app logic, APIs, diverse tech stacks)	App security experts, proxies, test/staging environments	OWASP-class vulnerabilities, PoC exploits, compliance evidence	SaaS, e‑commerce, customer-facing web apps	Protects revenue systems; demonstrates compliance
Social Engineering & Phishing Assessments	Moderate (ethical/legal coordination)	Red teamers, phishing platforms, executive/legal approval	Human risk metrics (click rates), training needs, credential exposure	Organisations needing awareness measurement and training	Quantifies human vulnerability; informs training ROI
Mobile Application Penetration Testing	High (reverse engineering, OS-specific issues)	Specialized mobile tools, real devices, app binaries	API flaws, insecure storage, hardcoded secrets, PoCs	Mobile-first apps, banking, healthcare mobile apps	Finds mobile-specific and API-linked vulnerabilities
Cloud Infrastructure & Configuration Testing	Moderate–High (multi-cloud configs, IAM complexity)	Cloud specialists, account access, IaC and console evidence	Misconfigurations, excessive permissions, exposed storage	Organisations using AWS/Azure/GCP or IaC pipelines	Quickly identifies common cloud misconfigs; IaC alignment
Wireless Network Penetration Testing	Moderate (onsite RF & physical factors)	Wireless adapters, antennas, legal/scope approval	Rogue APs, weak encryption, coverage and IoT risks	Offices, retail sites, facilities with wireless IoT	Reveals physical wireless and perimeter weaknesses
Physical Security & Badge Testing	Moderate–High (sensitive, tightly scoped)	Physical testers, photo/log evidence, executive approval	Evidence of unauthorized access, policy and process gaps	Data centers, server rooms, facilities with sensitive assets	Produces tangible, executive-impacting evidence of gaps
Third-Party & Supply Chain Risk Assessment	Moderate (coordination with vendors)	Questionnaires, audits, vendor cooperation, evidence files	Vendor risk ratings, compliance gaps, remediation plans	Organisations with many vendors or regulatory requirements	Reduces supply-chain breach risk; informs procurement decisions

From Findings to Fixes: The Reporting Advantage

These pen test example scenarios have one thing in common. The technical work only creates value when the report makes the issue understandable, reproducible, and fixable.

That sounds obvious, but a lot of reports still fail at one of those three jobs. Some are understandable but too shallow to reproduce. Others are technically complete but too cluttered for a security manager or engineering lead to prioritise quickly. The best reports sit in the middle. They preserve the proof, trim the noise, and explain the control failure in language the client can act on.

That's especially important in mixed audiences. A web developer wants the request pair, parameter tampering details, and likely root cause in the code or access model. A security manager wants the exploitation path, affected assets, and remediation owner. A compliance contact wants evidence that testing happened, findings were rated consistently, and retesting can be shown later. One report has to serve all three without becoming unreadable.

In practice, that means a few habits matter more than most testers think. Write attack chains in sequence. Separate root cause from observed symptom. Keep proof-of-concept steps tight enough that another practitioner could validate them. Show what was in scope, what was excluded, and where assumptions affected the result. Use appendices for deep technical artefacts rather than forcing every reader through them.

It also helps to treat reporting as part of the engagement, not as admin work at the end. Notes taken during testing are better than reconstructed memory. Screenshots tied to specific exploit steps are better than image dumps. Reusable finding language is better than rewriting the same remediation text from scratch and introducing inconsistencies. If you want a non-security parallel on clarity and reproducibility, these effective issue report writing tips reinforce the same principle from another discipline.

For small teams and independent testers, tooling can remove a lot of friction here. Vulnsy is one relevant option because it's designed around penetration testing reporting workflows: reusable findings, evidence attachments, brandable templates, collaboration, and DOCX output. The advantage isn't that it writes the finding for you. The advantage is that it reduces formatting drag so you can spend more time making the finding accurate and useful.

A report shouldn't just prove that you found something. It should make the next step obvious. That's where good penetration testing turns into measurable security improvement.

---

If you want to spend less time rebuilding report structure for every engagement, Vulnsy is worth a look. It gives pentesters and security teams a way to organise findings, attach evidence, standardise write-ups, and deliver consistent client-ready reports without the usual Word-document overhead.