// Methodology
How we test
A structured, documented approach aligned to OWASP and PTES, designed to find real risk while keeping your systems and data safe.
// Phases
Six phases, every engagement
- 1
Scoping & rules of engagement
We agree exactly what is in and out of scope, testing dates and windows, test accounts, rate limits and emergency contacts. Testing never begins without written authorization from someone entitled to give it.
- Signed authorization
- Defined scope and exclusions
- Emergency stop contact on both sides
- 2
Reconnaissance & mapping
Mapping the attack surface: every page, endpoint, parameter, role, host and service in scope. Most serious findings come from understanding the application well, and this phase is where that happens.
- Application and API mapping
- Role and permission matrix
- Technology fingerprinting
- 3
Vulnerability discovery
Automated tools for breadth, then hands-on testing for depth: access control between users and roles, authentication and session handling, injection, business logic, and configuration.
- OWASP WSTG test cases
- Business-logic abuse
- Every finding verified
- 4
Controlled exploitation
Findings are confirmed with the minimum proof needed to demonstrate real impact, never more. No destructive actions, no denial of service, and no access to real customer data beyond what proves the issue.
- Minimal proof-of-concept
- No destructive testing unless agreed
- Critical issues reported same day
- 5
Reporting & readout
A report written for two audiences: an executive summary for decision-makers, and technical findings with severity, evidence, reproduction steps and specific remediation for developers. Then a call to walk through it.
- CVSS severity scoring
- Reproducible steps
- Stack-specific fixes
- 6
Retest & attestation
Once fixes are deployed, each finding is retested and the report updated with its status. You receive an attestation letter to share with customers, partners or auditors.
- Fix verification
- Updated report
- Attestation letter
// Standards
Frameworks the testing follows
| Standard | Used for |
|---|---|
| OWASP Web Security Testing Guide | Web application test cases |
| OWASP Top 10 & API Security Top 10 | Risk categories for web apps and APIs |
| OWASP ASVS | Verification requirements for deeper tests |
| PTES | Overall engagement structure |
| NIST SP 800-115 | Technical security testing guidance |
| MITRE ATT&CK | Mapping network attack paths |
| CVSS v3.1 / v4.0 | Consistent severity scoring |
// Safety
Your data stays protected
A penetration tester is given unusual access to your systems. Here’s how that access is handled.
- Testing data and evidence are stored encrypted and never shared with third parties.
- Only the minimum data needed to prove a finding is captured; sensitive values are redacted in reports.
- Reports are delivered through an encrypted channel, never as plain email attachments.
- Test data is deleted after the engagement closes, on a schedule agreed with you.
- Automation and AI tools are used to work faster, never to replace verification: every finding is confirmed by the tester before it’s reported, and no client data goes to a third-party AI service without your written agreement.