# How we test: our penetration testing methodology

Source: https://penetrationtestservices.com/methodology/
Publisher: Excession Labs (penetrationtestservices.com)
Last updated: 2026-11-09

Pentest methodology of Excession Labs: written authorization, evidence standard, controls, safety limits, evidence labels, severity scale and report contents.

> **Short answer:** We test only with written authorization, inside a written scope. A finding counts only when we can show its effect, for example by reading a changed record back through another account or showing an attack in a real browser. Controls run next to every attack. Destructive proofs use test-owned data only. The report labels how each result was observed.

## 1. Authorization and scope

We test only systems whose owner has authorized the test in writing. The scope names the hosts, user roles, test windows, actions that are off limits and the people to contact. If something outside the scope looks relevant, we stop and ask.

## 2. How we test

We choose from five methods for each application:

- Direct HTTP requests against the web application and API, with each user role.
- Browser-observed tests in Chromium. We prove cross-site request forgery and stored cross-site scripting in a real browser, in addition to reading the raw response.
- Client-side review of the JavaScript bundles your application ships.
- Differential comparison of anonymous, low-privilege and high-privilege callers on the same request.
- Read-back from a second account, to prove that a change or exposure crosses an account or tenant boundary.

We use Incursion, the Excession Labs testing agent, to run these tasks in parallel under tool rules set for your scope. Excession Labs checks the evidence for each finding and writes the report. For more on the agent, read [how AI-assisted testing works](https://aipentestservices.com/how-it-works/).

We draw test ideas from public references such as the OWASP Web Security Testing Guide, the OWASP API Security Top 10 and OWASP ASVS. They guide coverage and are not certifications.

## 3. The evidence standard

A finding goes in the report as confirmed only when we can show its effect:

- A write is proven by reading the changed record back through another session. A response that says "success" is not proof.
- An exposure is proven by showing the exposed data from a test-owned record.
- A browser attack is proven by the attack working in a real browser.

## 4. Controls next to every attack

Each attack request has controls: a nonexistent identifier, the wrong record type, an unsigned or wrongly signed token, another account's token, and an anonymous caller. Controls show whether the first result means what it seems to mean. When a control shows that it does not, we downgrade or drop the finding.

We also report controls that held: protections we tried to break and could not. Your engineers can then avoid weakening them while they fix other issues.

## 5. Safety limits

- Destructive proofs use only test-owned accounts and records, marked as test data.
- Tests of uploads, password guessing, email sending and paid third-party services are bounded. The report states what each cost.
- Reproduction scripts are read-only where possible, and must only be run with authorization and test-owned identifiers.

## 6. Evidence labels

| Label | Meaning |
|---|---|
| Observed | We reproduced the behavior during the assessment |
| Browser-observed | A real browser demonstrated the behavior |
| Inferred | A likely path we did not fully demonstrate. It is labeled as inferred and never presented as confirmed |

Open questions go into a "Limitations and open questions" section, not into the confirmed impact.

## 7. Severity

We rate each finding on a four-level scale with a written definition for each level. The definitions appear in every report, so a reader can see why a finding is High and not Medium.

| Rating | Typical meaning |
|---|---|
| Critical | Remote destruction or compromise of other users' data or accounts without special preconditions |
| High | Serious data exposure, cross-tenant changes, account takeover or script execution with a practical attack path |
| Medium | Bounded disclosure, resource abuse, or attacks with real preconditions |
| Low | Hardening gaps and limited information exposure |

We do not add CVSS scores by default. If your program needs CVSS vectors, tell us during scoping.

## 8. The report

Each report holds project details and scope, the method, safety constraints, evidence labels, an executive summary with priority actions, findings at a glance, the reproduction environment, a section per finding (description, impact, verified results, reproduction, remediation), controls that held, a remediation plan, limitations and open questions, an evidence index, and reproduction scripts. We deliver it in HTML, PDF and Markdown. See the [sample report](/sample-report/).

Requests and responses are saved with timestamps. Key evidence can carry a SHA-256 manifest so you can check that it has not changed.

## Sources

- [OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/)
- [OWASP API Security Top 10 (2023)](https://owasp.org/API-Security/editions/2023/en/0x11-t10/)
- [OWASP Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard/)
- [NIST SP 800-115, Technical Guide to Information Security Testing and Assessment](https://csrc.nist.gov/pubs/sp/800/115/final)