Methodology
Penetration testing methodology,
from scope to proof
Good testing starts with a defined scope and a proven standard. Every engagement is manual-first, aligned to PTES, OWASP, and MITRE ATT&CK,
and applied consistently from scoping through reporting and retest. Read our PTES explainer.
Standards we align to
Grounded in recognized frameworks
We don’t improvise. Our process maps to the standards your auditors, customers, and engineers already trust.
PTES
Penetration Testing
Execution Standard
The seven-phase backbone of every engagement, from pre-engagement to reporting.
OWASP
Open Web Application
Security Project
Testing guides for web, API, and mobile: the Top 10 and the deeper WSTG/MASVS checks.
ATT&CK
MITRE ATT&CK
Adversary Knowledge Base
Real-world adversary tactics and techniques, so we test the way attackers actually operate.
CVSS
Common Vulnerability
Scoring System
Consistent, defensible scoring every finding is rated against, so fixes are prioritized by real risk.
The seven phases
Our penetration testing methodology, phase by phase
Every engagement follows the seven phases of the Penetration Testing Execution Standard, and each phase produces something you can hold. This is the documented methodology PCI DSS Requirement 11.4.1 asks for, the one SOC 2 auditors and ISO 27001 certification bodies recognize, and the one written into every report.
- 1
Pre-engagement
A scoping call defines the targets, roles, environments, testing windows, rules of engagement, escalation contacts, and success criteria. The result is a fixed-scope, fixed-price proposal, signed before any testing begins.
Deliverable
Signed scope and rules of engagement
- 2
Intelligence gathering
Open-source intelligence and internet-wide scan data map what an attacker can actually find: subdomains, cloud services, staging environments, leaked credentials, technology fingerprints. The scope you provided is the floor, not the ceiling.
Deliverable
Asset inventory reconciled with yours
- 3
Threat modeling
We work out what matters and who would come for it: the data, the roles, the trust boundaries, and the paths between them. Targets are prioritized by business impact, so testing time goes where a real adversary would spend theirs.
Deliverable
Test plan by target, role, and priority
- 4
Vulnerability analysis
Tooling maps the surface; testers verify it. Every candidate finding is confirmed or discarded by hand, false positives are removed, and the OWASP, MASVS, and API test cases for the target type are worked through one by one.
Deliverable
Validated vulnerability list
- 5
Exploitation
Findings are exploited safely, within the rules of engagement, to prove impact rather than assert it. Weaknesses are chained the way an attacker would chain them. Anything critical is escalated the day it is confirmed, not held for the report.
Deliverable
Proof of concept for every serious finding
- 6
Post-exploitation
From each foothold we establish how far access reaches: what data, what systems, what privileges, and whether segmentation and monitoring held. Nothing persistent is left behind, and every action is logged with timestamps for your defenders.
Deliverable
Attack narrative and blast radius
- 7
Reporting
An executive summary in plain language, technical findings with reproduction steps and CVSS ratings, remediation guidance in priority order, and the framework mapping your auditor needs. Then a free retest and an updated report showing findings closed.
Deliverable
Report, retest, attestation letter
Phases 4 and 5 are where a penetration test earns its name. Automated tooling supports them but never replaces them: a scanner produces candidates, and only a tester can confirm which are real, chain them, and prove what they reach. Our guide to manual vs automated penetration testing explains what each finds.
Frameworks side by side
How the major methodologies compare
Security policies, RFPs, and auditors name different frameworks. They are not interchangeable: some define an engagement, some supply test cases, and one is a catalog of attacker behavior. Here is what each one covers and where it fits in our testing.
| Methodology | What it covers | Where it fits in our testing |
|---|---|---|
| PTESPenetration Testing Execution StandardEngagement standard | Seven phases, from pre-engagement interactions to reporting. The standard defines what each phase involves; a separate technical guide covers how to carry it out. | Our backbone. Every engagement runs its seven phases, listed above. |
| OWASP WSTG / MASTGWeb Security Testing Guide / Mobile Application Security Testing GuideTest-case guides | OWASP’s test cases for web applications (WSTG) and for iOS and Android apps (MASTG, the testing companion to the MASVS requirements). | The test cases inside phases 4 and 5 for web and mobile targets, alongside ASVS, MASVS, and the OWASP Top 10 lists. |
| NIST SP 800-115Technical Guide to Information Security Testing and AssessmentUS government guidance | Review, target identification, and vulnerability validation techniques, with a penetration test in four stages: planning, discovery, attack, and reporting. Social engineering gets a short section; physical testing techniques are left out of scope. | Its four stages map onto our seven phases (below), which helps when a policy or auditor cites NIST. |
| OSSTMMOpen Source Security Testing Methodology ManualTesting and metrics methodology | ISECOM’s methodology for security testing, security analysis, and measuring operational security, with its own attack-surface metrics and report format. | Suits programs that want operational security scored with its metrics. Not a framework we run engagements to. |
| ISSAFInformation Systems Security Assessment FrameworkAssessment framework | The Open Information Systems Security Group’s detailed assessment framework, published as drafts in the mid-2000s and not revised since. | Mostly of historical interest. Not a framework we run engagements to. |
| MITRE ATT&CKAdversarial Tactics, Techniques, and Common KnowledgeAdversary knowledge base | A knowledge base of adversary tactics and techniques based on real-world observations. It catalogs attacker behavior rather than prescribing a test procedure. | The shared vocabulary for network and red team findings, mapped to its tactics and techniques so defenders can act on them. |
NIST SP 800-115 in our phases
NIST describes a penetration test in four stages and places vulnerability analysis inside discovery. Mapped onto the seven phases above:
- PlanningPhase 1
- Pre-engagement
- DiscoveryPhase 2–4
- Intelligence gathering, threat modeling, vulnerability analysis
- AttackPhase 5–6
- Exploitation, post-exploitation
- ReportingPhase 7
- Reporting, then the free retest
Black, gray, and white box
How much we know going in
Before testing starts, the scope sets what the tester is given: nothing, an account and documentation, or the source code. These are our defaults by target. Any of them can change at scoping, and the proposal states which one applies. Our guide to black box vs white box penetration testing explains what each approach finds and misses.
Black box
Starts with. Nothing but the scope. The tester sees only what an outsider can find.
Models. An external attacker with no inside knowledge.
Our default for
- External network tests, run from the internet with no credentials
- Red team operations that start from nothing and earn their own way in
- Public web or mobile apps, on request, for a first outside look
Gray box
Starts with. Partial knowledge: an account for each role and the documentation your developers use.
Models. A phished employee or a malicious customer with a real login.
Our default for
- Web applications, APIs, and mobile apps, with a test account for each role
- Internal networks, as an assumed breach from a standard user account
- Cloud environments, usually from a read-only identity
- Red team operations that start from a foothold you grant
White box
Starts with. Full knowledge: source code, architecture, and configuration.
Models. The deepest coverage per day of testing, rather than an attacker’s view.
Our default for
- Secure code review, traced from input to sink in the source
- Web application tests paired with a code review
Coverage by target
The standard each test is judged against
The seven phases are constant. The test cases inside phases 4 and 5 change with the target, and every report states which standard was applied and which cases were exercised, so coverage is evidence rather than a claim.
The engagement
Seven phases, zero surprises
From first call to final retest, you always know where things stand and what comes next.
Getting started
Steps 01–03- 01
Discovery & scoping call
30–45 minWe learn your environment, drivers, and constraints, then define exactly what is in and out of scope: targets, testing windows, rules of engagement, and success criteria, in writing.
- 02
Fixed proposal
Same dayYou receive a clear, fixed-scope proposal with timeline and cost. No hourly surprises, no vague deliverables.
See typical starting prices - 03
Platform onboarding
Within 24 hoursOnboarding begins within 24 hours of a signed proposal, and testing typically starts within a week. Your engagement goes live in the Invadel platform: follow findings in real time and track remediation and retests.
Explore the platform
Testing & delivery
Steps 04–06- 04
Execution
1–3 weeksSenior in-house testers run the engagement to PTES and OWASP standards, with agreed communication checkpoints and immediate escalation of anything critical.
- 05
Reporting
2 days after testingAn executive summary plus technical findings with reproduction steps, CVSS ratings, and remediation guidance.
- 06
Retest
IncludedAfter you remediate, we verify the fixes with a complimentary retest so you can prove the risk is actually closed. Request it any time within two months of report delivery, enough room to fix properly, retest, and close the engagement with verified results.
07 · Final deliverable
Final report & attestation letter
On completionOnce your retest clears, we issue the closing deliverables you can share with customers, partners, and auditors.
Updated final report
Reflecting your remediated findings
Attestation letter
Shareable proof of testing
How we rate risk
Every finding scored on CVSS
Severity isn’t a gut call. Each finding is rated against the Common Vulnerability Scoring System
so your team can fix what matters most, first.
Immediate, unauthenticated path to sensitive data or full compromise.
Serious exposure that a motivated attacker could exploit with modest effort.
Meaningful risk, often requiring specific conditions or chaining to exploit.
Limited impact or hard-to-reach issues worth fixing as hygiene.
Every report pairs these ratings with reproduction steps, evidence, and prioritized remediation.
See a sample reportFAQ
Methodology questions
What buyers, auditors, and assessors ask about how we test.
01What are the phases of a penetration test?
Our tests run the seven PTES phases: pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, and reporting, followed by a free retest. Other frameworks group the same work differently; NIST SP 800-115 uses four stages. For what happens in each and what we need from you, read the penetration testing process, phase by phase.
02Which methodology does Invadel follow?
PTES for the structure of every engagement, OWASP’s guides (WSTG, ASVS, the API Security Top 10, MASVS, and MASTG) for the test cases on web, API, and mobile targets, MITRE ATT&CK to map network and red team findings, and CVSS for severity. Every report states which standard was applied.
03Do you test black box, gray box, or white box?
Gray box by default for web applications, APIs, and mobile apps, with a test account for each role. External network tests start with no credentials, internal tests start from a standard user account, and white box testing pairs a test with a secure code review. The proposal states which applies.
04How long does each phase take?
The scoping call takes 30 to 45 minutes and the fixed proposal follows the same day. Onboarding begins within 24 hours of signing, and testing typically starts within a week and runs one to three weeks. The report follows two days after testing, and the free retest can be requested any time within two months of report delivery.
Let’s define your scope.
Tell us what to test and get a fixed-scope proposal back, no hourly surprises.
Prefer to talk it through first?