Skip to content

How it works

Clear scope. Written permission. Proven findings.

Every engagement follows the same five steps, so you know what will happen before testing begins.

  1. 1ScopeYou describe what to test. Targets, roles and timing are agreed, and you receive a written quote.
  2. 2AuthorizeThe system’s owner signs written authorization and rules of engagement. Testing does not begin without them.
  3. 3TestHands-on testing inside the agreed window. A critical issue is reported as soon as it is confirmed.
  4. 4ReportEvery finding comes with severity, business impact, evidence and a specific fix.
  5. 5RetestOnce you have fixed the issues, they are tested again and the report is updated with the results.

Before testing

What is needed from you.

01

Authorization

Written permission from whoever owns the systems, including hosting providers where their rules require it.

02

Test accounts

Credentials for each role in scope, created for testing and easy to remove.

03

A stable environment

Staging where possible, or production with the rules agreed in advance.

04

A technical contact

Someone who can answer questions and receive urgent findings during the test.

Rules of engagement

How testing is kept safe.

  1. 01

    Only what is in scope

    Targets, accounts and test windows are written down. Anything else stays untouched.

  2. 02

    No disruption by default

    Denial-of-service and destructive actions are excluded unless you agree to them in writing.

  3. 03

    Minimum proof

    Testing stops once an issue is proven. Real user data is not collected beyond what proof requires.

  4. 04

    Confidential by default

    Your name, findings and report are never published without your written permission.

  5. 05

    Clean close

    Test accounts should be removed when the engagement closes, and engagement data is deleted on your request.

Deliverables

What you receive at the end.

  1. 01

    Executive summary

    Overall risk and priorities in plain language, for people who will not read the technical detail.

  2. 02

    Technical findings

    Severity, affected component, business impact, evidence, steps to reproduce and a specific fix for each issue.

  3. 03

    Early notice

    Critical issues are shared as soon as they are confirmed, without waiting for the final report.

  4. 04

    One round of retesting

    After your fixes, each finding is tested again and its status is updated in the report.

  5. 05

    Attestation letter

    A short letter stating what was tested and when, which you can share with customers or auditors.

The report

What a finding looks like.

The report is written for two readers: the people deciding what to fix first, and the developers fixing it.

  • 01Executive summary
  • 02Scope and method
  • 03Findings by severity
  • 04Fix guidance
  • 05Retest results

Illustrative example · Fictional targetHigh

Invoice API returns records from other tenants

Affected
Invoice lookup endpoint, api.example.test
Impact
Any signed-in user can read invoices that belong to other organizations.
Evidence
Requests from two test accounts in separate tenants, with data redacted.
Fix
Check ownership on the server for every invoice lookup, and add a regression test.
Retest
Access denied across tenants. Finding closed.

Questions

Frequently asked.

How much does a pentest cost?

Each engagement is priced after scoping, based on the size of the application, the number of roles and the depth you need. You receive a written quote before anything starts.

How long does it take, and how soon can it start?

Both depend on scope and current availability. The start date and test window are confirmed in writing with your quote.

Who performs the testing?

The person who scopes your engagement performs the testing. The lead tester’s public record is on the About page, with links to the original sources.

Is retesting included?

Yes. One round of retesting is included after you fix the reported issues, and the report is updated with the results.

Can you test production?

Yes, under agreed rules. Staging is preferred where it matches production, and actions that could disrupt service are excluded unless you agree to them in writing.

Will this make us compliant with SOC 2, ISO 27001 or PCI DSS?

A pentest alone does not make you compliant, and ZeroDay Labs is not an auditor. The report and attestation letter can be provided as evidence, and your auditor decides whether they meet the requirement.

Will you sign an NDA?

Yes. An NDA can be signed before you share any details about your systems.

Can you test a system we do not own?

Only with written authorization from its owner. Without it, the engagement cannot go ahead.

Find it before someone else does.

Tell ZeroDay Labs what you need tested. You will get a clear scope and a written quote before any work begins.

Request a pentest