Penetration testing that proves what an attacker can reach

A scan lists what might be wrong. A penetration test proves what an attacker can actually reach, by chaining findings together the way a real intrusion does. Our engineers hold OSCP, CRTE, GPEN and CISSP, with OSCE and OSEP at senior level. Testing typically starts within a week and a half of engagement, and a mid-size test runs three to five weeks from signature to report.

100% manualEight surfacesOSCP-certifiedPCI-DSS, HIPAA, SOC 2Retest available

Request a free consultation Book a call

Penetration test — findingsApplied IAM

ScopeInternal + ADMethodManualDeliveredWeek 4

Domain admin via unquoted service pathExploited
Kerberoastable account, weak keyExploited
Local admin reused on 41 hostsVerified
Password spray reached 3 accountsVerified
SMB signing not enforcedVerified

Every finding reached by hand and reproduced. No scanner output is included, so there is nothing here for your team to triage away.

Scan vs test

Where the scan stops and the testers start

Anyone can run a scanner and forward the PDF. The difference is what happens after it.

What an automated scan returnsLists

A list of what might be wrong, produced by a tool and handed over unranked.

Known CVEs and missing patches
Open ports and exposed services
Weak TLS and configuration flags
A long list, unranked by real risk

What our testers proveProves

What an attacker can actually reach, chained together the way a real intrusion does.

Chained exploits that reach live data
Business-logic flaws no tool detects
Privilege escalation and lateral movement
Ranked findings with working evidence

Every finding is re-verified before it reaches your report, so there are no false positives to chase down. Most real intrusions run through stolen credentials and standing privilege, which is the path we follow first — because it is the same path we close every day in our PAM implementation work.

Eight surfaces

Penetration testing services by surface

Eight testing disciplines, staffed today. Scope one, or combine several into a single engagement.

External penetration testing

Your internet-facing systems tested from an attacker's view of the perimeter. That means the exposed services, the subdomain somebody stood up for a project two years ago, and the admin interface that was never meant to be reachable from outside. Most engagements start here, because it is what an attacker sees first and it is usually where the fastest wins are. If you only ever run one test, run this one.

Internal penetration testing

An assumed-breach scenario. If an attacker is already inside — through a phished credential, a compromised vendor, or an insider who turns — what can they actually reach? This is where privileged access decides the answer, and it is where a test most often turns up admin and service accounts nobody knew existed. The findings here are usually the uncomfortable ones, because they are about how the estate is built rather than what is exposed.

Network penetration testing

Your internal and external network infrastructure attacked with the techniques a real adversary uses: from the open internet and from inside the perimeter. Segmentation gets tested rather than assumed, which matters if you are relying on it to keep a regulated environment out of scope. Firewall rules, routing and trust relationships between segments are where the interesting findings sit.

Web application penetration testing

Business logic, authentication and injection flaws found by hand and proven with evidence. Authentication and authorization flaws are the most common serious finding and the most commonly missed by tools, because a scanner cannot tell that one user should not be able to load another user's record by changing a number in the URL. We test authenticated, across every role your application has, not just as an anonymous visitor.

API penetration testing

Authentication, authorization, rate limits and data exposure across your APIs, tested by engineers who build software rather than only scan it. The classic finding is authorization between endpoints: one API that checks who you are properly, and another beside it that does not. APIs also tend to return more data than the interface displays, which is invisible from the front end and obvious from the wire.

Mobile app penetration testing

Custom iOS and Android applications tested for the storage, transport and platform flaws specific to mobile. That includes what the app leaves behind on the device: cached credentials, tokens in local storage, logs that should not exist. We test the app and the backend it talks to, because an app is only as secure as the API behind it and the two are almost always assessed separately.

Wireless penetration testing

Weaknesses in your wireless networks found before they expose data beyond the physical perimeter. Guest network isolation, rogue access points, and the segregation between corporate and guest traffic. This matters most where the physical perimeter is porous: a retail floor, a hospital, a campus, or any building where the car park is within range of the access points.

IoT and SCADA penetration testing

Embedded devices and industrial control systems tested with the techniques operational environments demand and the caution they require. Nothing runs against live process control without explicit written agreement and, where it exists, a test environment. The findings here are usually about access paths between the corporate network and the operational one. Relevant across identity security for energy and utilities.

Beyond a test

Red teaming and social engineering

Red team assessment

A red team assessment is not a bigger penetration test. A penetration test asks what is exploitable. A red team assessment asks whether your defenders would notice. It runs without warning to the security team, with an objective — reach the crown jewels — and with reconnaissance, exploitation, lateral movement and exfiltration all in scope while your team detects and responds. It is the truest measure of how a security program performs under pressure, and it is worth doing only once the basics are in place. Running one against an estate that has never had a penetration test tells you what you already know.

Social engineering testing

Phishing and manipulation campaigns that test people rather than systems, plus breach-and-attack simulation that exercises your controls continuously. The tactics we use are the ones taught in the training we run, so the test and the fix come from the same team. See security awareness training.

By framework

Compliance-driven testing

Most testing has a deadline attached. We scope and report against the framework you are measured on, so the finding closes the first time.

PCI-DSS

PCI penetration testing

PCI-DSS requires penetration testing at least annually and after any significant change, covering both the cardholder data environment and the segmentation that keeps it separate. Segmentation testing is the part most often missed, and it is the expensive one to miss: if the segmentation fails, the scope of your whole assessment widens to everything it was supposed to exclude. We test both and report in the structure a QSA expects. Common across identity security for retail and identity security for finance.

HIPAA

HIPAA penetration testing

HIPAA does not name penetration testing outright. It requires a risk analysis, and testing is how most organizations evidence it. We scope to the systems holding ePHI, report in the language an OCR reviewer expects, and pair it with the encryption validation that usually comes with it. See identity security for healthcare.

SOC 2

SOC 2 penetration testing

The test your auditor expects to see inside your observation window, mapped to the Trust Services Criteria and timed so that remediation and retest both land before the window closes. Timing is the thing people get wrong: a test run a week before the window ends leaves no room to fix what it finds. Pairs with a SOC 2 readiness assessment.

Timeline

Signed to report in three to five weeks

Six stages, on a timeline we commit to up front. All times are business days.

Business days, agreed before we start

signedweek 1week 2week 3week 4week 5

Kickoff and scopingScope, rules of engagement and timing confirmed

1–3 days

AuthorizationSigned authorization, access and test accounts. No test starts without it.

2–5 days

Active testingManual, expert-driven exploitation

3–10 days, or 2–4 weeks for larger scopes

ValidationEvery finding re-verified before it reaches the report

1–3 days

ReportDelivered one to two weeks after testing ends

3–5 days

DebriefA readout call for leadership and engineers

30–60 minutes

The deliverable

What you get at the end

A 25 to 50 page report written for two audiences. An executive summary leadership can read without a translator, and technical findings your engineers can act on: severity-rated, with reproduction steps, screenshot evidence and specific remediation guidance for every finding. Then a debrief call within a week of delivery, so the report gets read rather than filed.

Retesting, and second opinions. Findings are not closed until they are proven closed. We retest remediated findings as a follow-up engagement, often packaged with the original test at a lower cost than commissioning it separately.

Some clients come to us only to retest another firm's engagement, because a report full of green checkmarks is only reassuring if the testing behind it was real. If your last test felt too easy, that is worth a second look.

One report, two readersApplied IAM

For leadershipWhat it means and what it costs

For your engineersWhat to change, and how to prove it worked

1. Reach the host as svc_backup2. Escalate via the unquoted service path3. Confirm: whoami → NT AUTHORITY\SYSTEM

25–50 pages. The summary is written so it can be read on its own, and the findings are written so nobody has to take our word for it.

Why Applied IAM

Why teams choose us for penetration testing

100% manual testing. The scan is the starting point, not the deliverable. Our testers combine its output with OSINT and manual reconnaissance, then attempt real exploitation. No tool-only PDF with a logo on top.
Certified offensive engineers. OSCP, CRTE, GPEN and CISSP, with OSCE and OSEP at senior level — hands-on delivery certifications rather than checkbox ones.
Testing starts in about 1.5 weeks. Most firms quote two to four weeks before testing even begins. That matters when an auditor has given you a date.
We help you fix what we find. Testing that ends at a PDF leaves you holding the risk. Our delivery teams remediate findings with you, from access control to hardening.
We attack the identity path because we defend it. Stolen credentials and standing privilege are how most real intrusions run. That is our core practice, not a module in someone else's methodology.
Compliance-mapped reporting. Findings mapped to HIPAA, SOC 2, PCI-DSS and NIST, so reports close audit items instead of raising new questions.

FAQs

Common questions about penetration testing

It depends on scope. The biggest drivers are the number of systems and applications in scope, whether testing is credentialed across several user roles, and how much compliance-driven depth a framework like PCI-DSS or HIPAA requires. We scope precisely before quoting, so you pay for the testing you need rather than a package.

Active testing runs three to ten business days for a single application or network segment, and two to four weeks for larger scopes. End to end, from signed authorization to a delivered report, a mid-size engagement is typically three to five weeks. Testing usually begins within about a week and a half of engagement.

A scan is automated: a tool lists known weaknesses. A penetration test is a certified engineer attempting to exploit them, chaining findings together and proving what is genuinely reachable. Frameworks like PCI-DSS and SOC 2 generally expect a manual test, not just a scan, and an auditor can usually tell the difference from the report.

At least annually, and after any significant change: a new application, a major migration, or a merger. Most frameworks require annual testing plus a retest after remediation. Many clients pair an annual full test with a smaller retest a few months later.

Testing runs under written rules of engagement agreed before we start: exclusions, blackout windows, and a technical contact reachable during testing hours. Destructive techniques are never used against production without explicit sign-off, and anything we consider risky gets raised before it is attempted rather than explained afterwards.

A penetration test asks what is exploitable, with your team aware it is happening. A red team assessment asks whether your defenders would notice, without warning them. Most organizations should run the first several times before the second is worth the money.

Yes. PCI-DSS, HIPAA, SOC 2 and NIST each expect testing scoped and reported differently. We agree which framework you are being held to before scoping, because it changes what falls inside the boundary and what the report has to show.

See what an attacker would find

Tell us your scope and the framework you are testing against. A free consultation gets you a precise quote and a start date, typically within a week and a half.