- Home
- Approach
Manual testing, careful handling, clear results.
Every penetration test follows the same process, built on PTES, NIST SP 800-115, and the OWASP testing guides. Here's exactly what happens, how we keep your systems safe, and how we rate what we find.
The phases of a test
These seven phases apply whether we're testing one API or an entire enterprise network.
- 1. Scoping and rules of engagement We agree on targets, objectives, testing windows, source IP addresses, emergency contacts, and anything that's off limits. Nothing is tested until the rules of engagement are signed.
- 2. Reconnaissance and mapping We map the attack surface: hosts, services, application features, user roles, API endpoints, and the technologies behind them.
- 3. Threat modeling We work out where the valuable data and functions are and who would want them, so testing time goes where the real risk is.
- 4. Vulnerability discovery Automated scanning for breadth, then manual testing for depth: authorization, business logic, injection, configuration, and everything the tools can't reason about.
- 5. Exploitation and chaining We confirm each issue is real and show its actual impact, including how lower-severity issues combine into serious ones. We report critical findings as soon as we confirm them, without waiting for the final report.
- 6. Reporting and walkthrough You receive the report, and we walk your team through the findings, answer questions, and help prioritize fixes.
- 7. Retest After remediation, we verify each fix and issue an updated report and attestation letter.
How much we know going in
You choose how much access and information we start with. Most clients get the best value from gray-box testing.
No prior knowledge
We start with only what's public, like an outside attacker. Realistic, but time goes into discovery rather than depth.
Accounts and documentation
We get test accounts for each role and any API documentation. This is the default for most application tests and gives the best balance of realism and coverage.
Full access, including source
We test with source code and architecture documents in hand. Best for critical systems and pairs naturally with secure code review.
Testing safely
Testing is only useful if it doesn't become an incident of its own. These rules apply to every engagement.
- Written authorization firstSigned rules of engagement define exactly what we can and cannot touch.
- Known testing windows and source IPsYour team always knows when we're testing and where traffic comes from.
- Emergency contacts on both sidesTesting can be paused at any time with a single message.
- Nothing destructive without approvalNo denial-of-service testing without written approval, and no changes to data outside agreed test records.
- Minimal data accessWe access sensitive data only as far as needed to prove impact, and never keep more than we need.
- Encrypted, time-limited evidenceEvidence is encrypted at rest and securely deleted at the end of the retention period in our contract.
How we rate findings
Severity starts with a CVSS score, then is adjusted for your context: how exposed the asset is, what data it holds, and whether the issue can be chained with others. Each rating comes with a recommended fix window.
| Severity | What it means | Recommended fix window |
|---|---|---|
| Critical | Direct compromise of critical systems or sensitive data, usually without special access or user interaction. | 7 days |
| High | Significant compromise that needs some access or conditions, such as an authenticated user reaching another tenant's data. | 30 days |
| Medium | Real weaknesses with limited impact on their own, or issues that become serious when chained with others. | 90 days |
| Low | Minor issues and defense-in-depth gaps with little direct impact. | 180 days |
| Informational | Observations and best-practice recommendations with no direct security impact. | As appropriate |
Ready to scope a test?
Send a few details and we'll set up a short scoping call, then follow up with a fixed-fee proposal.