You ship software
Web apps and APIs change every sprint. A penetration test tells you which of those changes opened a path an attacker can actually use, with steps to reproduce it.
Penetration testing services
Penetration testing services
Penetration testing is an authorized, simulated attack on your applications, APIs and network that finds exploitable weaknesses before a real attacker does, then proves each fix holds with a re-test.
CloudKey runs scoped, manual penetration tests across web applications, APIs, and external and internal networks. Every engagement opens with a signed Rules of Engagement and closes with reproducible, prioritized findings and a re-test of every fix.
- RoE-gated
- External plus internal scope
- Manual, not just a scan
- Re-test included
High
Aggregate risk
- Account takeover via chained auth bypass (app.example.com) Critical
- Broken object-level authorization on /api/v1/orders Critical
- SQL injection in legacy search endpoint High
- Exposed admin panel on internet-facing host High
Each finding ships with reproduction steps, evidence and a re-test. Illustration only.
Scope, by the numbers
What an engagement covers
Overview
Manual testing that proves what is actually exploitable
Most security tools tell you what might be wrong. A penetration test tells you what an attacker can actually do with it. CloudKey penetration testing services put an experienced tester against your systems under controlled, written authorization, with one goal: find the paths a real attacker would take, prove the impact, and hand your team the steps to close them.
Automated scanners have their place, and we use them to cover breadth. But scanners cannot chain three medium issues into a full account takeover, reason about your business logic, or tell a false positive from a genuine risk. People do that. Every CloudKey engagement is led by manual testing, with the scanner output treated as a starting point, not the report.
We test web applications, APIs, and external and internal networks, scoped to the risk you care about and the mandate you are working against. You get prioritized findings with reproduction steps, an executive summary your board can read, and a re-test that confirms the fixes held.
Who it is for
When do you need penetration testing services?
Three situations bring teams to us. Most arrive with more than one.
You run a network
External perimeter and internal segments both carry risk. External and internal penetration testing shows what an outsider reaches from the internet and what an intruder reaches once inside.
An auditor is asking
SOC 2, PCI DSS, ISO 27001 and NIS2 all expect evidence of testing. We deliver a report your auditor can read, mapped to the control that required it.
Scope
What can CloudKey penetration testing services cover?
Pick the scope that matches your risk. We test it manually, not with an automated scanner alone. The panels are stylized illustrations of the kind of findings each scope surfaces.
Web application penetration testing
Authentication, access control, business logic, injection and the OWASP Top 10, tested by hand against your real application, not a generic checklist.
- OWASP Top 10
- Authentication and access control
- Business logic flaws
- Broken access control on /admin High
- Stored XSS in profile bio field High
- Business logic: coupon stacking abuse Medium
- Verbose error leaks stack trace Low
Illustration for example.com, not a live scan.
API penetration testing
REST and GraphQL endpoints checked for broken object-level authorization, excessive data exposure and rate-limit gaps, the failures that scanners routinely miss.
- REST and GraphQL
- Broken object-level authorization
- Excessive data exposure
- GET /api/v1/users/{id} BOLA - High
- GET /api/v1/orders Excessive data - High
- POST /api/v1/login No rate limit - Medium
- GET /api/v1/health Pass
Illustration of endpoint findings for example.com.
External network penetration testing
The view an attacker has of your internet-facing assets. Exposed services, weak configurations and edge vulnerabilities, ranked by what is actually reachable.
- Perimeter and edge services
- Internet-facing exposure
- Reachable, ranked findings
- 203.0.113.10:443 https (TLS 1.0 enabled) High
- 203.0.113.10:22 ssh (password auth) Medium
- 203.0.113.24:3389 rdp (exposed to internet) High
- 203.0.113.24:80 http (redirects to https) Pass
Sample hosts for example.com. Illustration only.
Internal network penetration testing
What an intruder reaches after a foothold. Lateral movement, privilege escalation and segmentation gaps inside your environment.
- Lateral movement
- Privilege escalation
- Segmentation gaps
- 10.0.2.15 workstation (initial foothold) Entry
- 10.0.2.40 file server (reused local admin) Lateral - High
- 10.0.1.5 domain controller (kerberoast) Escalation - Critical
- user VLAN to server VLAN No segmentation - High
Illustration of an attack path for example.com.
Methodology
Tested against recognized methodologies
We structure engagements around the standards your auditors and engineers already trust, so the work is repeatable and the report is defensible. Testers hold OSCP and CEH; team leads pursue CREST CRT and OSWE as engagements demand.
OWASP WSTG
Web and API testing follows the OWASP Web Security Testing Guide and covers the OWASP Top 10 and API Security Top 10, the baseline most auditors expect to see referenced.
PTES and OSSTMM
Engagement structure follows the Penetration Testing Execution Standard, from pre-engagement scoping through exploitation and reporting, so nothing is improvised.
NIST SP 800-115
Technical testing aligns to the NIST technical guide to information security testing, the reference many compliance frameworks point back to.
Tester credentials
Lead testers hold OSCP (Offensive Security Certified Professional) and CEH (Certified Ethical Hacker). Engagement leads work toward CREST CRT and OSWE for web-app depth, so your report is defensible in front of auditors who ask who held the keyboard.
How it works
How does a penetration test work?
Scroll through: each phase takes over as you go.
Stage 01
Scope and Rules of Engagement
We agree the targets, time windows, emergency contacts and disclosure terms, then put them in a Rules of Engagement document you sign.
- Scope agreed signed
- Time windows defined
- Emergency contacts named
Illustrative.
Stage 02
Reconnaissance
We map the attack surface in scope, the assets, entry points and technologies, so the testing that follows is targeted, not noisy.
- app.example.tld web
- api.example.tld API
- vpn.example.tld perimeter
Illustrative.
Stage 03
Exploitation
We attempt real, controlled exploitation of the weaknesses we find, confirming impact rather than reporting theoretical risk.
- $ attempt auth-bypass confirmed
- $ access gained evidence captured
- $ impact proven logged
Illustration, not a real target.
Stage 04
Reporting
You get prioritized findings with reproduction steps and evidence, an executive summary, and a technical detail section your engineers can act on.
- Auth bypass · edge Critical
- IDOR · API High
- Missing headers Low
Illustrative.
Stage 05
Re-test
Once you have fixed the findings, we re-test them and issue an attestation confirming what is closed. The re-test is included.
- Auth bypass Closed
- IDOR Closed
- Attestation issued
Illustrative.
Going further
Red teaming and breach-and-attack-simulation
When a standard penetration test is not enough, we run objective-based offensive engagements that test detection and response, not just the controls.
Red team assessment
An objective-based, stealth-aware engagement that emulates a real adversary against agreed goals, such as reaching a sensitive dataset, to test whether your team detects and responds. Scoped and authorized like every CloudKey engagement.
Breach and attack simulation
Repeatable simulation of known attacker techniques mapped to MITRE ATT&CK, so you can measure detection coverage over time rather than at a single point.
We do not test until the Rules of Engagement is signed
Reconnaissance and exploitation only begin after written authorization. The Rules of Engagement defines scope, time windows, emergency contacts and how findings are disclosed. No exceptions.
- Scope and targets agreed in writing
- Time windows and emergency contacts named
- Disclosure terms set before any active test
The life of a finding
From exploitable to closed, proven at each step
Every finding follows the same path, traceable end to end.
-
Found
Auth bypass · edge-gw
Exploited under authorization, impact proven.
-
Reported
Finding + reproduction
Steps, evidence and priority handed to your team.
-
Re-tested
Closed · attestation
Fix re-tested, closure attested.
What you get
Your penetration testing report, and proof the fixes held
Findings you can act on, evidence an auditor accepts, and a re-test that closes the loop.
Prioritized findings
Each issue ranked by real exploitability and business impact, not just a raw severity score, so your team fixes the few that matter first.
Reproduction and evidence
Every finding carries the steps to reproduce it and the evidence we captured. An engineer opens it and confirms it. No folklore.
Executive and technical report
A summary your board reads and a technical section your engineers work from, in one document.
Re-test attestation
After remediation we re-test and attest what is closed, the artifact your auditor and your customers want to see.
Compliance
Penetration testing for SOC 2, PCI DSS, ISO 27001 and NIS2
Most engagements are triggered by a mandate. We map the report to the control that required it.
SOC 2
Independent penetration testing evidence for your SOC 2 audit, scoped to the systems in your trust boundary.
PCI DSS
External and internal penetration testing aligned to PCI DSS requirement 11, with the segmentation checks the standard expects.
ISO 27001
Testing evidence that supports your ISO 27001 control set and informs the risk treatment plan.
NIS2
Testing that supports the risk-management and resilience expectations EU organizations face under NIS2.
FAQ
Penetration testing, answered
Penetration testing is an authorized, simulated attack on your applications, APIs or network. A tester tries to exploit real weaknesses the way an attacker would, then reports what worked, how to reproduce it, and how to fix it.
A vulnerability scan is automated and lists potential issues. A penetration test is manual: a human confirms which issues are actually exploitable, chains them together, and proves business impact. Scanning finds candidates; testing proves which ones matter.
Cost depends on scope: the number of applications, APIs and network ranges, and whether testing is external, internal or both. We scope each engagement and quote a fixed price before any work begins, so there are no surprises.
A focused web application or external network test typically runs one to two weeks of testing, plus scoping beforehand and reporting afterward. Larger or combined scopes take longer. We confirm the timeline in the Rules of Engagement.
Black box means no prior knowledge, like an external attacker. Grey box means limited access, such as a low-privilege account. White box means full access to code and credentials. Grey box usually gives the best coverage for the time.
External testing assesses what an attacker reaches from the internet against your perimeter. Internal testing assesses what an intruder reaches after gaining a foothold inside your network. Many engagements include both.
SOC 2 does not name penetration testing as a line item, but auditors routinely expect testing evidence to support the security criteria. A penetration test report scoped to your trust boundary is the usual way to provide it.
Yes. CloudKey does not begin reconnaissance or exploitation until you sign a Rules of Engagement document that defines scope, time windows, emergency contacts and disclosure. Testing without written authorization is never appropriate.
Next step
Scope your penetration test
Tell us what you run and what an auditor or customer is asking for. We come back with a scope, a timeline and a fixed quote, then nothing active starts until you sign.