Penetration testing as a service

The pentest that keeps running after the report ships.

Security engineers lead the testing of your web apps, APIs, mobile apps, cloud, networks, identity, AI applications and code. An always-on testing engine built by our team extends the coverage between tests, and engineers verify every finding. Fixes get retested at no charge.

Request a quote See a test, start to finish

For teams preparing evidence for SOC 2, ISO 27001, PCI DSS, HIPAA or a customer security review.

portal.example/acme-sample/findings Illustrative sample data

Engagement Findings 5 Assets 12 Retests 2 Reports

Filters Verified only Open Awaiting retest

Verified4

In review1

Awaiting retest1

Fixed1

High

GP-0001Broken object-level authorization on invoice endpoint

Verified

Med

GP-0002No rate limiting on password reset

Awaiting retest

Med

GP-0003Stack traces returned on malformed JSON

In review

Low

GP-0004Session cookie missing SameSite attribute

Verified

Med

GP-0005Reflected XSS in search parameter

Retest passed

Illustrative Mock-up with invented sample data, drawn in HTML. Not a real client, not a real finding.

01 / Approach

Engineers lead and verify. An always-on engine extends the coverage.

Annual pentests describe the system as it was on one week in the spring. Greyprobe tests the system as it is, and engineers decide what counts as a finding.

Engineers lead the testing

Engineers scope and plan each test, then find vulnerabilities by hand: business-logic flaws, broken authorization and chained attacks. They exploit what they find, judge severity in your context and write the fix guidance.

An always-on engine extends the coverage

Our always-on testing engine, built by our team, maps your attack surface, runs continuous checks between tests, catches regressions and drafts evidence, so engineers can focus on the hard problems. Engineers verify its findings before they reach you.

You track it live

Findings appear in the portal as they are verified, with the verifying engineer named, evidence, severity rationale and remediation guidance. Mark one fixed and request a retest from the same page.

Engineers

Lead the testing

Scoping and planning
Manually finding vulnerabilities: business-logic flaws, broken authorization, chained attacks
Exploiting them and judging severity in your context
Writing fix guidance and answering developer questions
Running retests

Always-on testing engine

Built by our team; extends the coverage

Attack-surface mapping
Continuous checks between tests
Regression catching
Drafting evidence so engineers focus on hard problems

02 / Scope

What gets tested

Scope is set per engagement and agreed in writing before anything runs. Typical areas:

Web applications

Engineers test login and session handling, tenant and role authorization, business-logic abuse and injection.

APIs (REST, GraphQL)

Engineers test object- and function-level access control, mass assignment, input handling, rate-limit abuse and token lifecycle.

Mobile apps (iOS, Android)

Engineers test the app on each platform, how it stores data and handles sessions, and the backend it talks to.

Cloud environments (AWS, Azure, GCP configuration and identity)

Engineers review in-scope account configuration, storage exposure, and IAM roles and permissions for privilege escalation paths.

Internal and external network infrastructure

Engineers test internet-facing hosts and exposed services, then check internal segmentation and lateral movement paths.

Active Directory and identity

Engineers test AD for credential attacks, over-privileged accounts, misconfigured delegation and paths to domain admin.

AI and LLM applications (prompt injection, data leakage)

Engineers test prompts for injection and jailbreaks, and check whether the model can be made to leak data or misuse connected tools.

Red team engagements

Engineers chain findings across systems in an agreed, goal-based scenario to show how far an attacker could get.

Source code review

Engineers read in-scope code by hand for auth flaws, injection, insecure crypto use and hardcoded secrets.

03 / Sample finding

A finding you can hand to an engineer.

This is an illustrative excerpt with fictional details and redactions, showing the structure of a verified finding. It is not from a real engagement.

GP-0001 · SAMPLE EXCERPTCLIENT:

Broken object-level authorization on invoice endpoint

HighCWE-639OWASP API1✓ Verified by engineer

Summary

Any authenticated user can read invoices belonging to other accounts by changing the identifier in the path. The server checks that the caller is logged in, but not that the invoice belongs to the caller's organization.

Evidence

# authenticated as user B (org       )
GET /v2/invoices/         HTTP/1.1
Host: api.        
Authorization: Bearer             

HTTP/1.1 200 OK
{"org_id":"      ","total":   ,"bill_to":"          "}

Impact

Cross-tenant disclosure of billing records. Identifiers were , so enumeration is practical without prior knowledge of valid values.

Remediation

Scope the invoice lookup to the caller's organization in the data-access layer, return 404 for non-matching records, and add an automated authorization test for this route.

Reproducible

Request, response and the exact account setup, so the developer can see it fail before changing anything.

Reasoned severity

Severity comes with a short explanation of exploitability and impact, so triage is a conversation about facts.

A concrete fix

Remediation names the layer to change and the test to add, not just a link to a generic guide.

04 / Timeline

From kickoff to free retest

The shape of a typical engagement. Calendar dates are set with you at scoping.

Step 1
Kickoff
Call with your engineering lead. Confirm assets, environments, test accounts and who to page if something looks wrong.
Step 2
Rules of engagement
Scope, testing windows, rate limits and out-of-bounds systems agreed in writing before traffic starts.
Step 3
Engineer-led testing
Engineers scope and plan the test, then manually look for business-logic flaws, broken authorization and chained attacks. The always-on testing engine maps the surface and runs continuous checks alongside.
Step 4
Exploitation and severity
Engineers exploit what they find and judge severity in your context. Findings appear in the portal with evidence, reproduced by hand. Critical issues are flagged to you directly, not held for the report.
Step 5
Fix
Your team works from the portal. Developer questions go to the engineer who found the issue.
Step 6
Free retest
Request a retest per finding. We re-run the original exploit path and record pass or fail with evidence.

Retests: one round within 90 days on single-application tests; unlimited retests of fixed findings on continuous plans, with deep-test retests within 90 days of the report. Notification channel for critical findings: [CONFIRM].

05 / Compliance

Evidence for the frameworks your buyers ask about

A penetration test report is commonly requested during these audits and reviews. What satisfies a control is your auditor's decision.

Framework	Where a pentest usually comes up
SOC 2	Auditors commonly ask for recent penetration test results as support for vulnerability-management and monitoring criteria (for example CC7.1). Not a stated requirement of the Trust Services Criteria.
ISO 27001	Often cited for technical vulnerability management and security testing controls in Annex A (A.8.8, A.8.29 in the 2022 edition).
PCI DSS	Requirement 11.4 covers penetration testing of the cardholder data environment and its segmentation. Qualifying scope and tester requirements are set by the standard and your assessor.
HIPAA	The Security Rule requires periodic technical evaluation and risk analysis. Penetration testing is a common way to support both, not a named requirement.
Customer security reviews	Enterprise questionnaires often ask for a recent third-party pentest summary and proof that findings were fixed. The retest record covers the second part.

Greyprobe is not an auditor or certification body, and a penetration test alone does not make you compliant. Confirm report requirements with your auditor before you scope.

06 / Clients

An established practice, working with real teams

Our testers have delivered security and compliance work since 2020. A few of the teams we work with:

Hivel
Noyce
QuickIntel

Names and logos shown with permission. [TODO: logo files for Hivel, Noyce and QuickIntel pending]

07 / FAQ

Questions we expect

What is PTaaS?

Penetration testing as a service: testing delivered through a platform, with findings available as they are verified, instead of a single engagement that ends in a PDF.

Is everything automated?

No. Engineers lead the testing: they scope and plan it, manually find and exploit vulnerabilities, judge severity, write fix guidance and run retests. Our always-on testing engine, built by our team, extends the coverage with attack-surface mapping, continuous checks between tests, regression catching and evidence drafting, and engineers verify its findings before delivery. Every report names the engineer who verified it.

What do you test?

Web applications, APIs (REST, GraphQL), mobile apps (iOS, Android), cloud environments (AWS, Azure, GCP configuration and identity), internal and external network infrastructure, Active Directory and identity, AI and LLM applications, red team engagements and source code review. Exact scope is agreed in writing before testing starts.

Who are the testers?

A team of 15 security testers across Canada, the United States and India. Certifications held across the team include OSCP and CEH, and our practice is CREST-aligned. Engineers lead the testing, from scoping and manual exploitation to fix guidance and retests. Subcontractors may support some engagements.

Will this satisfy my auditor?

Pentest reports are commonly used as evidence, but acceptance is the auditor's call. Send us your requirements at scoping and we will tell you plainly whether our report format fits.

How do retests work?

After you fix a finding, request a retest in the portal. We re-run the original exploit path and record the result. Single-application tests include one retest round of that report's findings within 90 days. Continuous plans include unlimited retests of fixed findings, and retests of the two annual deep tests are covered within 90 days of the report.

Can testing affect production?

Testing windows, rate limits and safe-testing rules are agreed in writing before any traffic is sent. [CONFIRM: production vs. staging policy]

Where is my data stored?

[PLACEHOLDER: hosting regions and data-handling details to be confirmed before launch.] This page makes no data-residency commitment.

How much does it cost?

Scope drives effort, so we quote per engagement. A single-application test typically starts from USD 3,500. Continuous plans typically start from USD 12,000 per year, covering one application and its API (additional applications are priced separately), and include always-on testing (an always-on testing engine, built by our team, with engineers verifying findings before delivery), two deep human-led penetration tests per year, and unlimited retests. Extras, such as additional scopes, red team work or source code review, are priced separately. Use the form below and we will reply with questions and a scoped quote.

Which regions do you serve?

Teams worldwide, starting with the United States, then India and Canada.