How we work
What happens from the first email to the retest, and the work we turn down.
How a test runs
Scope
Targets, roles, environments and test windows, set out in a written proposal.
Prepare
Written authorisation, a test account for each role, and a named contact on your side.
Test
Mostly manual. We report serious findings to your contact as we find them.
Report
The written report, a walkthrough with your engineers, then a retest if it's in scope. See a fictional sample.
Scoping
We start by email or on a short call: what you want tested or certified, why now, and any deadline. For a test we then ask for a list of in-scope hosts, applications and roles, and ideally a demo account.
The proposal states the scope, the testing dates, who will do the work, what you receive and the price. It also lists anything left out of scope. We'll sign an NDA before you share anything sensitive.
Testing methodology
We follow published methods so your auditors and customers can see what was covered:
- OWASP Web Security Testing Guide and ASVS for web applications and APIs
- OWASP MASVS and MASTG for iOS and Android
- PTES and NIST SP 800-115 for network and infrastructure tests
- CIS Benchmarks and each provider's security guidance for cloud reviews
- IEC 62443 and NIST SP 800-82 for OT environments
Scanners give us coverage on the first day. The rest is manual testing, which is where we find broken access control between tenants, logic flaws in payment and approval flows, and minor issues that chain together.
Production testing is agreed in advance. We avoid destructive payloads, keep request rates within limits you set, and pause testing and contact you if something looks unstable.
What the report contains
- A leadership summary: overall risk, the issues that matter most, and what to fix first
- Scope, dates, testers, method and any limits on coverage
- Each finding with its CVSS v4.0 base score and a separate severity rating that reflects your business context, affected components, evidence, reproduction steps and a specific fix
- A list of what we tested and found sound, which auditors often ask for
- If retesting is in scope, an updated status for each finding and a retest letter you can share externally
Independence
Some work would mean checking our own work, and some decisions belong to an assessor. Where that applies, we'll say so and suggest who to approach instead.
- We don't issue ISO certificates, SOC 2 reports or PCI DSS reports on compliance. Accredited certification bodies, licensed CPA firms and QSAs do that.
- We don't give an independent opinion, such as an internal audit or a penetration test, on controls we designed or implemented for you. If you need both, we'll suggest another firm for that part.
Scan or penetration test?
The two are often confused, and questionnaires sometimes ask for one when they mean the other.
| Vulnerability scan | Penetration test | |
|---|---|---|
| Purpose | Find known weaknesses across many systems | Show whether weaknesses can be exploited, and what an attacker could reach |
| How | Automated tools, with results reviewed by a person | Mostly manual testing, using tools for coverage |
| Output | A list of issues ranked by severity | Findings with evidence, business impact, attack chains and fixes |
| Typical use | Regular checks between tests | Before a release, after major change, or as an annual requirement |
Common questions
How long does a test take?
It depends on scope: the number of applications, user roles and systems involved. The proposal gives the dates.
Do you test production or staging?
Either. Staging carries less operational risk. Production shows your real exposure, including configuration that staging doesn't have. We agree which during scoping, along with any techniques you want excluded.
Will testing disrupt our services?
We keep that risk low with the controls under Testing methodology above, and we stop and call you if a system looks unstable.
What do you need from us?
Written authorisation to test, the in-scope targets, test accounts for each user role, and a technical contact. For cloud reviews, read-only access to the accounts in scope.
Is a retest included?
It's agreed during scoping. A retest lets you show customers or auditors that findings were fixed.
Can we share the report with customers?
That's your decision. Buyers usually ask for the leadership summary or a retest letter rather than the full report, which includes reproduction steps.
Does a penetration test make us compliant?
No. A test is evidence for specific controls in ISO 27001, SOC 2, PCI DSS and most regulations. Compliance also depends on policies, risk management and controls running over time.
Can you guarantee we'll pass the audit?
No. The certification body or auditor makes that decision. We work with you to close gaps and prepare evidence before the audit.
Have a question about your own project?
Contact us