How it works
The penetration testing process, step by step
A structured process protects both sides: you know what's tested and when, and we work within defined, approved boundaries.
Discovery and scoping
We learn the system, its user types, its APIs and the business goal of the test, and define a precise scope.
Authorization and coordination
Written authorization from the authorized party, approved environments, a coordinated time window and a stop/escalation contact.
Manual testing, supported by tools
The work is led by a human tester; tools support discovery and coverage, not as a substitute for understanding the application.
Validation and documentation
Every finding is validated to reduce noise, and documented with evidence and reproduction steps from the authorized test environment.
Report and prioritization
Executive summary, severity and business impact, prioritized remediation guidance and a review call with your team.
Retest per agreement
Retesting of fixed findings, within the scope and timing agreed in advance.
Authorization, environment and time window
The three things agreed in writing before testing begins.
What should Scope and Rules of Engagement include? →
Written authorization
Testing starts only after written approval from a party authorized to approve it for the asset under test. If the system is hosted by a provider, we check whether their approval is also required.
Approved environments
We define exactly which addresses, environments and accounts are included, and what's out of scope. What isn't approved isn't tested.
Time window and contact
We set a testing window and a stop/escalation contact, available outside working hours if needed.
Advance coordination significantly reduces the risk of disrupting availability or data, but zero impact can't be guaranteed. That's why a stop procedure and contact are defined in advance.
Test preparation checklist
The more of these details are ready in advance, the better the testing time is used.
- A business goal for the test: what matters most to protect
- A list of in-scope environments and assets, and what is out of scope
- Test accounts for every relevant permission level
- API documentation or a sample request collection, if available
- A technical contact available for questions during the test
- A stop/escalation contact, including outside working hours
- Written approval from the party authorized to approve the test
- Coordination with infrastructure or third-party providers, if required
What happens during the test
- Notification when testing starts and ends
- Immediate notice of a severe finding that needs early attention
- Clarifying questions to your team when system behavior is unclear
- Validation of findings before they enter the report, to reduce false positives
- Staying within scope: no testing of unapproved assets, and no use of real data beyond what's necessary
Process FAQ
How long from first contact until testing starts?
Who needs to be involved on your side?
What happens if a critical finding is discovered mid-test?
Is there a retest?
Let's understand what needs testing in your application
We'll start with a short scoping call.