Service
Cloud & application security
Architecture, configuration, and identity reviews
Service
Authorized penetration testing for applications, APIs, and networks
Our testers try to find and safely exploit weaknesses in the systems you choose, under written authorization, and give you a clear report of what they found and how to fix it.
What we deliver
Authorized penetration testing for web applications, APIs, and external or internal networks.
- Pricing
- Published starting price
Who it's for
A good fit for
- SaaS and e-commerce companies that need outside testing for customer or partner security reviews
- Teams launching a new application, major feature, or API that want it tested before release
- Organizations that need testing as part of a compliance program such as PCI DSS or SOC 2
- IT leaders who want to know what an attacker could reach from the internet or from inside the network
Not the right fit for
- Teams that only need an automated vulnerability scan
- Anyone who can't authorize testing of the target systems, such as third-party systems without the owner's permission
- Organizations looking for red-team, social-engineering, or physical intrusion exercises
Problems it addresses
- Customers or partners are asking for a recent third-party penetration test report.
- A new application or API is about to launch and hasn't been tested by anyone outside the team that built it.
- Automated scans produce long lists of findings but don't show which ones are actually exploitable.
- No one knows what an attacker could reach after getting past the perimeter.
- Earlier findings were fixed, but no one has confirmed that the fixes work.
Scope
Included
- Manual testing shaped by the target, with automated tools supporting tester judgment rather than replacing it
- Authentication, authorization, session handling, input handling, and business-logic testing for applications and APIs
- Testing with the user roles you provide, including checks for access across roles and across customer accounts
- Network discovery, service enumeration, and exploitation of confirmed weaknesses within the agreed rules
- Safe proof of concept for significant findings, stopping at the agreed limits
- Notice of critical findings during testing, through the contacts named in the rules of engagement
- Retesting of fixed findings, as set out in your proposal
Not included
- Denial-of-service, load, or stress testing
- Social engineering, phishing campaigns, and physical intrusion
- Systems or third-party services you aren't authorized to include
- Fixing the vulnerabilities found; your team or vendors remediate, and we advise
- Continuous or automated scanning services
Testing types
Web application testing
Testing a web application the way its users experience it: sign-in, authorization between roles and accounts, session management, input handling, and business logic. Scope depends on the number of roles, key workflows, and integrations.
- Price
- Web Application or API Penetration Test: from $12,000; typical $12,000–$30,000
API testing
Testing APIs directly, including object- and function-level authorization, authentication, rate limiting, data exposure, and how the API handles unexpected input. Documentation or request collections help us reach every endpoint.
- Price
- Web Application or API Penetration Test: from $12,000; typical $12,000–$30,000
External network testing
Testing your internet-facing footprint (hosts, exposed services, VPNs, and remote-access portals) to find what an outside attacker could discover and exploit.
- Price
- External Network Penetration Test: from $6,000; typical $6,000–$12,000
Internal network testing
Testing from an assumed-breach position inside your network, such as a virtual machine or device you deploy for us, to show how far an attacker could move and whether they could reach directory services, file shares, or sensitive systems.
- Price
- Internal Network Penetration Test: from $9,000; typical $9,000–$20,000
Deliverables
- Executive summary that describes overall risk in plain language for leadership and customers
- Technical report with each finding's severity, affected assets, reproduction steps, and evidence
- Remediation guidance specific to your technology
- Retest results showing which findings are resolved
- Findings debrief with your engineering team
How the engagement runs
Every engagement begins with a written scope and proposal.
Scope
We confirm targets, testing types, user roles, environments, and constraints, and record them in a written scope.
Authorize and prepare
Your team completes the authorization paperwork, confirms points of contact, and sets up test accounts and access.
Test
Testers work within the agreed windows, keep you informed of progress, and pause if a stop condition is reached.
Report
You receive the executive summary and technical report, followed by a debrief with the people who'll fix the findings.
Retest
After you remediate, we retest the affected findings and update the report.
Standards and methods
- OWASP Web Security Testing Guide (WSTG) as a reference for web application test coverage
- OWASP API Security Top 10:2023 for risks specific to APIs
- NIST SP 800-115 for test planning, execution, and reporting practices
- Common Vulnerability Scoring System (CVSS) for technical severity, adjusted for business context
Testing frequency, in brief
How often you need a penetration test depends on which rules apply to you, and only some of them set a frequency.
- PCI DSS v4.0.1 requires internal and external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change (Requirements 11.4.2 and 11.4.3). The tester can be a qualified internal resource or a qualified third party with organizational independence, and doesn't need to be a PCI SSC-listed assessor or scanning vendor. If segmentation is used to reduce scope, it's tested at least once every 12 months and after changes, or every six months for service providers (11.4.5 and 11.4.6).
- SOC 2 sets no testing frequency. The points of focus for monitoring activities (CC4.1) in the Trust Services Criteria list penetration testing and vulnerability scans among the kinds of evaluations management can use.
- The HIPAA Security Rule in force doesn't name penetration testing. HHS's January 2025 proposal would require it at least once every 12 months, but as of 2026-09-27 the proposal hasn't been finalized or withdrawn.
Sources: PCI SSC document library: PCI DSS v4.0.1 (Requirements 11.3 and 11.4); AICPA & CIMA: 2017 Trust Services Criteria (With Revised Points of Focus – 2022); Federal Register: HIPAA Security Rule To Strengthen the Cybersecurity of ePHI (proposed rule, January 6, 2025)
Read the full guide: Penetration testing types and how often to test
Where vulnerability scanning fits
A vulnerability scan and a penetration test answer different questions. A vulnerability assessment is a systematic examination of a system to determine the adequacy of security measures and identify security deficiencies, and scanning tools do most of that work across many systems at once. A penetration test is security testing in which evaluators mimic real-world attacks to find ways to circumvent the security features of an application, system, or network (NIST SP 800-115's definition).
PCI DSS keeps them separate. Internal and external vulnerability scans run at least once every three months, with external scans performed by a PCI SSC Approved Scanning Vendor (Requirement 11.3). Penetration testing is its own requirement (11.4). The two work together: scans for breadth and frequency, and penetration tests for depth, exploitability, and the business-logic flaws that scanners can't judge.
Sources: NIST CSRC glossary: vulnerability assessment; NIST CSRC glossary: penetration testing; PCI SSC document library: PCI DSS v4.0.1 (Requirements 11.3 and 11.4)
Read the full guide: Penetration testing vs vulnerability scanning
Prerequisites and your responsibilities
- Written authorization from someone with authority over every system in scope, plus any permission your hosting or SaaS providers' terms require
- A stable test environment, or approval and a plan for testing in production
- Test accounts for each user role in scope, and API documentation or request collections for API testing
- Technical and emergency contacts who are reachable during testing windows
- Coordination with whoever runs your security tools, so testing isn't blocked or mistaken for an attack
Pricing
Web Application or API Penetration Test
From $12,000
Typical scoped range: $12,000 to $30,000
One-time project
External Network Penetration Test
From $6,000
Typical scoped range: $6,000 to $12,000
One-time project
Internal Network Penetration Test
From $9,000
Typical scoped range: $9,000 to $20,000
One-time project
Non-binding. Final pricing follows a written scope and proposal.
Penetration-test pricing assumes authorized manual testing, an executive summary, a technical report, remediation guidance, and one retest within 60 days unless the proposal says otherwise.
What affects the final price
Pricing depends on environment size, complexity, testing depth, locations, applications, accounts, user roles, compliance objectives, and delivery timeline. Every engagement begins with a written scope and proposal. Taxes, travel, remediation, third-party audit or certification fees, licensing, and emergency work are separate. Readiness services do not include independent certification, attestation, legal advice, or a guarantee of passing.
Testing starts only with written authorization
All penetration testing requires written authorization, a signed scope, rules of engagement, approved targets, testing windows, emergency contacts, and stop conditions.
Guides
- Testing · 10 min readPenetration testing types and how often to testPenetration test types and cadence: web app, API, external and internal network tests, and what PCI DSS, SOC 2, HIPAA and ISO 27001 say about frequency.
- Compliance · 9 min readPCI DSS v4.0.1 explained: versions and 2025 requirementsPCI DSS v4.0.1 explained: how it differs from v4.0, the requirements that took effect March 31, 2025, and what the 2026 request for comments means.
- Testing · 9 min readPenetration testing vs vulnerability scanningVulnerability scanning vs penetration testing: what each finds, how often each runs, where PCI DSS requires ASV scans, and how the two work together.
- Testing · 5 min readHow to scope a penetration test you can act onHow to scope a penetration test you can act on: the question to answer, written authorization, targets and exclusions, rules of engagement and retest.
- Compliance · 9 min readProposed HIPAA Security Rule changes: status and impactThe proposed HIPAA Security Rule update explained: its current status, what HHS proposed in January 2025, what applies today, and how to plan sensibly.
- Compliance · 10 min readPCI DSS 6.4.3 and 11.6.1: payment page script securityPCI DSS requirements 6.4.3 and 11.6.1 in plain terms: payment page script inventory, authorization and integrity, tamper detection, and SAQ A eligibility.
Frequently asked questions
How is this different from a vulnerability scan?
A scan uses automated tools to list known weaknesses, and it often flags issues that can't actually be exploited. Penetration testing adds a person who confirms which weaknesses are real, chains them together the way an attacker would, and tests things scanners can't judge, such as whether one customer can see another customer's data.
Can you test in production?
Yes, when you approve it in the rules of engagement. We agree on testing windows, avoid destructive techniques, and name contacts who can stop testing whenever they need to. If you have a staging environment that closely matches production, testing there first is often the safer choice.
Will the report satisfy our customer or auditor?
The report is written with that audience in mind, with an executive summary kept separate from the technical detail. Whether it meets a specific requirement depends on what that customer, program, or assessor asks for, so share any requirements during scoping and we'll shape the scope around them.
What happens if you find something critical during testing?
We tell the contacts named in your rules of engagement once the finding is confirmed, without waiting for the final report, so your team can decide whether to act right away.
Do you need our source code?
No. Testing is normally done from the outside, the way a user or attacker would see the system. If you'd like a deeper review, sharing architecture notes, API specifications, or selected code can make testing more efficient, and we'll discuss that during scoping.
Talk to a practitioner about penetration testing
Share what’s prompting the work and what you need to decide, and we’ll help you judge whether this service is the right fit.
What happens next
- Tell us about your environment and what's driving the request.
- Talk through goals, constraints, and options with a practitioner.
- Review the proposal and decide whether to go ahead.