Compliance

Penetration testing that finds the things automation misses.

Uzado's red team runs PTES-aligned engagements scoped to your environment, for businesses across North America. External, internal, web app, segmentation. Reports your auditor will accept.

What it is

Penetration testing, defined

A penetration test is a goal-directed, manual security assessment by a skilled tester. It is not a vulnerability scan; it is the work of demonstrating real exploitation paths and the impact at the end of them.

Uzado's engagements follow the Penetration Testing Execution Standard (PTES). The standard organises work into pre-engagement, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation, and reporting. The discipline is what separates a credible report from a list of CVE numbers.

Reports are written for the audience that will read them next: the auditor, the underwriter, the engineering team. Executive summary at the top; findings ranked by severity; evidence per finding; remediation guidance. The retest pass within the engagement window is what makes the report worth more than the test itself.

Test types

Engagements scoped to your environment

External network

Internet-facing infrastructure tested for exposure, weak authentication, and vulnerable services. The first thing most attackers and most auditors look at.

Internal network

Assumed-breach simulation from inside the network perimeter. Lateral movement, privilege escalation, and access to sensitive systems are the test goals.

Web application

OWASP-aligned testing on web apps and APIs. Authentication, authorisation, injection, and business logic flaws.

API

REST and GraphQL endpoint testing. Authentication, broken object-level authorisation, and rate limiting are common findings.

Segmentation (PCI)

Annual segmentation testing required for PCI DSS. Confirms the cardholder data environment is isolated from the rest of the network.

Cloud configuration

AWS, Azure, and GCP configuration review and exploitation paths. IAM, storage exposure, control plane abuse, and lateral movement across cloud accounts.

Social engineering

Phishing, vishing, and physical access tests when scoped. Findings inform awareness programmes and process gaps, not blame.

How we deliver

A five-step engagement model

01
Scoping

Agree targets, in-scope and out-of-scope assets, test windows, communication paths, and rules of engagement.

02
Recon & enumeration

Open-source intelligence and active enumeration to map attack surface before exploitation.

03
Exploitation

Controlled exploitation of identified vulnerabilities, documented for the report and tracked for remediation.

04
Post-exploitation & lateral movement

Where compromise is achieved, demonstrate impact: data access, lateral movement, persistence. Severity is grounded in real outcomes.

05
Reporting & retest

Findings reported with severity, evidence, and remediation guidance. Free retest of remediated findings within the engagement window.

FAQ

Common penetration testing questions

How often should I pen test?+

Once a year and after significant change is the baseline for SMBs. SOC 2 expects annual external testing. PCI DSS Requirement 11.4 requires internal and external testing at least annually and after significant infrastructure or application change. Mature programmes test more frequently against high-risk systems.

Do I need penetration testing for SOC 2?+

SOC 2 does not strictly require penetration testing, but auditors expect to see external testing as part of the overall security posture, particularly when claiming the Security Trust Services Criterion. In practice, most SOC 2 reports for SaaS companies reference an annual penetration test in the controls description.

Do I need penetration testing for PCI DSS?+

Yes. PCI DSS Requirement 11.4 mandates internal and external penetration testing at least annually and after significant change. Segmentation testing is also required at least annually for service providers and every two years for merchants. Uzado covers all three.

What's the difference between black-box, grey-box, and white-box testing?+

Black-box testing assumes no prior knowledge of the target. Grey-box testing provides limited information (credentials, basic architecture) to focus the engagement. White-box testing includes source code access and full architecture documentation. Grey-box is the most common engagement model because it produces the most realistic findings within a defined budget.

What's included in the report?+

Executive summary for leadership, severity-ranked findings with evidence, technical detail for the engineering team, and a remediation roadmap. The report is written so an auditor or insurance underwriter can read it without translation. Raw scan output is delivered separately on request.

Do you do retests?+

Yes. A retest of remediated findings is included within a defined window after the initial engagement. Retesting is what turns a report into evidence that risks were actually closed.

How do you scope a cloud penetration test?+

Cloud testing is scoped against your AWS, Azure, or GCP environment specifically: in-scope accounts, identity perimeter, in-scope storage and compute, and the test boundary against shared cloud-provider infrastructure. Provider notification (where required by AWS, Azure, GCP terms) is handled by Uzado.

Need a real test, not a scan?

Talk to Uzado. We will scope the engagement, run it, and deliver a report your auditor and your engineers will both use.