What does a certified ethical hacker actually do during an engagement?

As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.

What happens in the scoping and rules-of-engagement stage?

This is where the engagement is won or lost, and it is usually 3 to 5 working days. The tester and the client agree what is in scope: which applications, which environments, which APIs, which roles, and which test accounts are provided. The rules of engagement then fix the ground rules: testing dates and hours, source IP addresses, permitted techniques, prohibited techniques such as denial of service or social engineering of third parties, escalation contacts, and what happens if a test accidentally breaks a production service. In Indian practice the deliverable from this stage is a signed document, and under the IT Act, 2000 it is the document that makes the work lawful. Scoping done properly routinely removes 30% of the proposed scope and makes the test cheaper and more useful, because it drops what was never actually at risk.

What does reconnaissance and vulnerability discovery involve?

Reconnaissance is passive and active: mapping the domains and subdomains you own, identifying the technology stack from headers, certificates and error pages, finding exposed admin panels, exposed storage buckets, forgotten staging environments, and leaked credentials in public repositories. Discovery then works through the OWASP Top 10 and OWASP API Security Top 10, plus whatever the stack makes likely: an outdated framework, an unpatched dependency, a misconfigured storage bucket, a missing rate limit on a login. A good tester treats the scan output as a to-do list rather than a result. The value of manual work here is proportion, because automated scanners find roughly the same issues in every environment and miss the configuration mistake that is specific to yours.

What does the exploitation stage actually prove?

Exploitation is the part that separates a penetration test from a vulnerability assessment, and it is where the tester earns the fee. A scanner may flag an outdated library; a tester proves that a request crafted against your application reads rows it should not, and captures the data. A scanner may flag an open S3 bucket; a tester shows that the bucket holds a customer export, and lists what is in it without taking it. Proof has to be safe, minimal and reversible, and it has to be recorded in a way a developer can reproduce. In most engagements, roughly 60% to 70% of tester time is spent in this stage, and it is where the money is: an unproven issue is a hypothesis, and a proven issue with a captured impact is something a developer can fix in an afternoon.

What should the report and the retest look like?

The report is the deliverable the client actually paid for, and it should be readable by an engineer, not just by a security team. Each finding needs a title, a severity with a stated reason, the exact reproduction steps, the evidence, the business impact expressed in plain terms, and a specific remediation that names the code, the configuration or the control to change. Findings are ordered by risk, not by discovery order. The retest then re-tests every finding that was fixed, and the closure note is attached to the original finding so the client has a single document showing what was open and what was closed. A report with no reproduction steps is the most common reason a client is told to retest the same finding three times.

What are the frequently asked questions?