How a penetration test works
A penetration test is a controlled attack with your permission. It follows a clear process so the testing stays safe, the results are repeatable and your team knows what is happening at every stage. Here is how we run one, from the first call to the clean exit.
The five steps of an engagement
The same for web applications, APIs, mobile apps and networks.
- Day 0
Scoping call
A free call to understand what you want tested and why: the applications, networks or APIs, your deadlines and any compliance requirement behind the test. You get a written quote with the scope, timeline and deliverables set out.
- Before testing
NDA and rules of engagement
We sign a mutual NDA, or work under yours, then agree the rules of engagement: targets, testing windows, contacts, and anything that must not be touched. Testing can start within 48 hours of the scope being signed.
- Testing
Hands-on testing
Our testers combine tools with manual testing, following OWASP, PTES and NIST SP 800-115. If we confirm a critical issue, we tell you straight away instead of waiting for the report.
- Report
Report and walkthrough
Every finding is reproduced by a tester before it goes in the report, with severity, evidence and a fix written for your stack. We walk your team through the results and answer questions.
- After
Retest and clean exit
When you have fixed the issues, we can retest and issue an updated report. When the engagement ends, we remove test accounts, credentials and working files, and confirm it in writing on request.
Inside the testing phase
The testing itself follows OWASP, PTES and NIST SP 800-115. Each phase builds on the last. The kind of test you need decides where we spend most of the time: see our penetration testing services.
Reconnaissance
We map what is in scope: hosts, open services, application routes, API endpoints and the technology behind them. Public information shows what an outside attacker would see first.
Vulnerability analysis
Automated scanners cover known weaknesses quickly. Then we review the results by hand, discard false positives and look for the issues tools cannot find.
Exploitation
We confirm which weaknesses are real by exploiting them safely, within the rules of engagement. This is what separates a penetration test from a scan.
Impact analysis
From any foothold, we check what an attacker could reach next: other users' data, admin functions, other systems. That shows the real business risk of each finding.
Reporting
Each confirmed finding is written up with a CVSS severity, evidence, steps to reproduce and a fix, plus an executive summary for leadership.
Retest
Once you have fixed the issues, we can test them again and update the report, so auditors and customers see what is resolved.
What the report contains
- An executive summary: overall risk, the most serious issues and what to do first
- The scope, dates, approach and standards used, stated plainly for auditors
- Every finding with severity, evidence, reproduction steps and a fix
- Attack paths showing how smaller issues combine
- Positive findings: the controls that held up
- After a retest, an updated report showing what is resolved
How to prepare
- Choose the environment: staging is safest, production needs agreed windows
- Create test accounts for every role, and for two tenants if you are multi-tenant
- Share documentation: API specs, architecture diagrams, user guides
- Tell your hosting provider and security team when testing will run
- Name one technical contact who can answer questions during testing
- Take a backup before testing a production system
Process questions
What methodology do you follow?
We follow the OWASP Web Security Testing Guide, the OWASP API Security Top 10 and MASVS for applications, and PTES and NIST SP 800-115 for networks. Severity is rated with CVSS. The report names the standards used for your test.
Will testing break anything?
We plan every test to avoid disruption. The rules of engagement set testing windows and anything off-limits, we avoid destructive actions, and we do not run denial-of-service tests unless you ask. If anything behaves unexpectedly, we stop and tell you.
What happens if you find something critical?
We tell your named contact as soon as we have confirmed it, with enough detail to start fixing it. You do not have to wait for the final report.
How long does the whole process take?
Testing can start within 48 hours of the scope being signed. Most single-application tests take one to two weeks of testing, larger scopes longer, and the report follows shortly after. Your quote states the timeline.
What happens to our data afterwards?
Reports and findings stay confidential under the NDA. When the engagement ends, we remove test accounts, credentials and working files, and confirm it in writing if you ask.
Start your security assessment.
Tell us about your application, architecture or compliance requirements. Our team will scope a penetration test around them.