From first call to final confirmation.
Ten steps, no surprises. Scope and authorization come first; testing only begins after both are explicit and agreed. Retesting and final confirmation close the loop so your evidence reflects the fixed state, not just the findings.
Initial consultation
A short call or email exchange to understand what you need tested, why (annual testing, customer requirement, SOC 2 or PCI DSS evidence, release validation) and when.Scope definition
Targets, environments, roles and accounts, exclusions, depth and timeline are written down. Scope determines effort and price; nothing is estimated from a URL alone.Rules of Engagement
Testing window, source IPs, permitted methods, exploitation limits, data handling, stop conditions, emergency contacts and communication channels are agreed and documented.Authorization
Written authorization from a person entitled to grant it, covering every in-scope target. Testing only begins after explicit authorization and an agreed scope.Testing
Manual testing guided by OWASP WSTG / ASVS, the OWASP API Security Top 10 and PTES where appropriate, adapted to the agreed scope. Critical findings are communicated as soon as they are validated.Findings validation
Every finding is reproduced and validated before it is reported. False positives are removed; impact is assessed in the context of your application and business.Reporting
Executive summary for security and compliance stakeholders, technical report for engineers. Each finding includes severity, CVSS, evidence, reproduction steps, impact and remediation guidance.Client remediation
Your team fixes what matters. We answer questions about findings and proposed fixes directly, without a ticketing layer between you and the tester.Retesting
Remediated findings are retested and the results are recorded. Retest results become part of the report and of your evidence.Final confirmation
Final report issued with retest status. On request, a CyberZ Penetration Testing Certificate for the assessed scope, verifiable at cyberz.net/verify.
Authorization
Testing is performed only against explicitly authorized targets.
Testing only begins after explicit written authorization and an agreed scope. If scope changes during an engagement, it is re-authorized before any new target is touched.
What every engagement defines.
The Rules of Engagement are agreed before testing and referenced throughout. Our template is available as a starting point — it requires review by your legal counsel.
Rules of Engagement template- 01
Authorized targets
Exact hostnames, IP ranges, applications, accounts and cloud resources that may be tested.
- 02
Prohibited targets
Systems explicitly out of scope — third-party services, shared infrastructure, production data stores where applicable.
- 03
Testing window
Dates and hours during which testing may occur, including any blackout periods.
- 04
Source IPs
Addresses testing traffic originates from, where applicable, so it can be identified and allowlisted.
- 05
Testing methods
Which techniques are permitted: manual testing, automated scanning, credentialed testing, exploitation.
- 06
Exploitation limits
How far a confirmed vulnerability may be exploited — proof of concept only, data access limits, no persistence.
- 07
Social engineering
Whether phishing or other social engineering is included at all, and against whom, if applicable.
- 08
Denial-of-service restrictions
DoS and resource-exhaustion testing are excluded by default and only performed if explicitly agreed.
- 09
Data handling
How any data encountered during testing is handled, minimized, stored, transferred and destroyed.
- 10
Emergency contacts
Who to reach on both sides, at any hour of the testing window, if something needs immediate attention.
- 11
Stop conditions
Events that pause or end testing immediately — instability, unexpected data exposure, a request from your team.
- 12
Communication channels
Where status updates, critical findings and questions are exchanged, and how they are secured.
Direct communication, no account managers.
You talk to the person doing the testing. Status updates are shared through the channel agreed in the Rules of Engagement; critical findings are communicated as soon as they are validated, not at the end of the engagement.
Questions about findings, fixes and retest timing are answered directly. After the final report, you can still ask about remediation approaches for anything in it.
Request a security assessment.
Tell us what you need tested, when, and which evidence you need at the end. We reply with scoping questions, not a sales deck.