How does certified ethical hacking work in a pentest?

Youri van der Zwart ·

Certified ethical hacking is the structured, authorized process of attacking your own systems before a real adversary does. When organizations commission a penetration test, they are essentially hiring trained professionals to think and act like threat actors, but within a carefully defined legal and operational framework. Understanding how that process works helps you get more value from every engagement and ensures the findings translate into genuine security improvements rather than a report that sits unread on a shelf.

This guide walks you through each phase of a certified ethical hacking engagement, from the groundwork you need to lay before the first packet is sent to the moment you close out verified remediation. Follow these steps in order and you will have a clear picture of what to expect and how to stay in control throughout.

What You Need Before a Certified Ethical Hacking Engagement

Before any technical work begins, you need to have the right people, permissions, and documentation in place. Skipping this preparation is the most common reason engagements stall or produce results that cannot be acted on.

  • Written authorization from a decision-maker with legal authority over the systems in scope
  • A designated internal point of contact who can respond quickly during the test
  • A list of systems, IP ranges, domains, and applications you own or have permission to test
  • Confirmation from any third-party hosting or cloud providers that testing is permitted under your agreement
  • A communication channel for emergency escalation if a critical vulnerability is discovered mid-test

Verify that all authorization documents are signed before the engagement start date. Without them, even a well-intentioned tester is operating outside the law, and your organization carries the liability. With this foundation in place, you are ready to define exactly what the test will cover.

Define the Scope and Rules of Engagement

Scope definition is where the engagement becomes concrete. Work with your testing team to document precisely what is in bounds and what is not. Ambiguity here leads to either missed coverage or accidental disruption of production systems.

  1. List every asset to be tested, including IP addresses, domain names, API endpoints, and physical locations if physical security is in scope.
  2. Specify exclusions explicitly, such as live payment processing systems, third-party SaaS tools you do not own, or systems shared with other tenants.
  3. Agree on testing hours, particularly whether after-hours testing is acceptable or whether all activity must occur during business hours with staff available.
  4. Define which attack techniques are permitted, for example, whether social engineering or denial-of-service simulation is included.
  5. Document the escalation procedure if a tester discovers evidence of an active breach by a real attacker during the engagement.

Once the rules of engagement document is signed by both parties, treat it as the binding reference for the entire engagement. Any request to expand scope mid-test should go through a formal change process, not a verbal agreement.

Conduct Reconnaissance and Vulnerability Mapping

Reconnaissance is the phase where ethical hackers gather information about your environment using the same methods a real attacker would. This includes passive techniques, such as reviewing publicly available data, and active techniques, such as network scanning, depending on what the scope permits.

  1. Passive reconnaissance: review DNS records, WHOIS data, certificate transparency logs, and any information exposed through search engines or social media.
  2. Active scanning: use network scanners to identify live hosts, open ports, and running services within the agreed IP ranges.
  3. Service enumeration: probe identified services to determine software versions, configuration details, and potential entry points.
  4. Vulnerability mapping: cross-reference discovered services against known vulnerability databases to build a prioritized list of potential weaknesses.

At the end of this phase, you should expect a structured inventory of discovered assets and a preliminary vulnerability map. This is not yet a findings report, but it gives both sides a shared picture of the attack surface before exploitation begins.

Execute Controlled Exploitation Within Agreed Boundaries

Exploitation is the phase that distinguishes penetration testing from a simple vulnerability scan. The tester actively attempts to leverage identified weaknesses to gain unauthorized access, escalate privileges, or move laterally through the environment, always staying within the boundaries defined in the rules of engagement.

  1. Prioritize high-severity vulnerabilities first, focusing on those that could provide direct access to sensitive data or administrative control.
  2. Attempt exploitation using techniques appropriate to the agreed scope, such as credential attacks, injection flaws, or misconfiguration abuse.
  3. Document every action taken with timestamps, tools used, and outcomes, so the full attack chain can be reconstructed in the report.
  4. Stop immediately and escalate if an action risks causing unplanned downtime or data loss, even if it falls within scope.

After each successful exploitation attempt, the tester should assess what further access it enables, mapping out the realistic impact a real attacker could achieve. This chained-attack perspective is what makes penetration testing significantly more valuable than automated scanning alone.

Verify Findings and Validate Remediation Steps

Once exploitation is complete, every finding needs to be verified. A result that cannot be reproduced is not a confirmed vulnerability. Verification protects your organization from spending remediation budget on false positives and ensures the report reflects real risk.

  1. Re-test each finding at least once to confirm it is consistently reproducible under the same conditions.
  2. Assess the actual impact of each confirmed vulnerability, distinguishing between theoretical risk and demonstrated harm.
  3. After your team applies fixes, request a targeted re-test to confirm that each remediation actually closes the identified gap rather than partially addressing it.

Remediation validation is a step many organizations skip due to time pressure, but it is critical. A patched system that still carries the original vulnerability because the fix was incomplete gives a false sense of security. Build re-testing time into your project timeline from the start.

Interpret the Pentest Report and Act on Results

A penetration test report is only as valuable as the action it drives. Most reports organize findings by severity, typically critical, high, medium, and low, and include a description of each vulnerability, the evidence collected, and a recommended remediation approach.

  1. Read the executive summary first to understand the overall risk posture and any findings that require immediate escalation to leadership.
  2. Work through the technical findings in severity order, assigning each to an owner with a realistic remediation deadline.
  3. Use the attack narratives in the report to brief your development or operations teams on how vulnerabilities were chained together, not just what individual weaknesses exist.
  4. Schedule a re-test for critical and high findings within a defined window, typically 30 to 60 days after remediation is complete.

Treat the report as the beginning of a remediation cycle, not the end of the engagement. The organizations that get the most from penetration testing are those that track findings in their risk register, measure remediation velocity, and use each engagement to benchmark improvement over time. If you want guidance on structuring that process or commissioning your next engagement, contact us and we will help you build a testing program that fits your environment and budget.

Frequently Asked Questions

Hoe vaak moet een organisatie een certified ethical hacking engagement laten uitvoeren?

V: Hoe vaak moet een organisatie een certified ethical hacking engagement laten uitvoeren?nA: De frequentie hangt af van de grootte van je organisatie, de sector en hoe snel je omgeving verandert. Over het algemeen wordt een jaarlijkse penetratietest aanbevolen, aangevuld met extra tests na grote infrastructuurwijzigingen, nieuwe applicaties of significante updates aan bestaande systemen.

Wat is het verschil tussen een vulnerability scan en een certified ethical hacking engagement?

V: Wat is het verschil tussen een vulnerability scan en een certified ethical hacking engagement?nA: Een vulnerability scan identificeert automatisch bekende zwakke plekken in systemen, maar test niet of deze daadwerkelijk uitgebuit kunnen worden. Een ethical hacking engagement gaat verder door kwetsbaarheden actief te exploiteren en aanvalsketens te simuleren, waardoor je een realistisch beeld krijgt van de werkelijke impact voor je organisatie.

Waarom is het belangrijk om derde partijen te informeren voordat een penetratietest begint?

V: Waarom is het belangrijk om derde partijen te informeren voordat een penetratietest begint?nA: Veel organisaties maken gebruik van cloudproviders of gedeelde infrastructuur die eigendom is van externe partijen. Zonder hun toestemming kan het testen van deze systemen juridische consequenties hebben en de serviceovereenkomst schenden, wat kan leiden tot opschorting van diensten of aansprakelijkheid voor je organisatie.

Hoe kan ik ervoor zorgen dat de bevindingen uit het rapport daadwerkelijk worden opgevolgd binnen mijn organisatie?

V: Hoe kan ik ervoor zorgen dat de bevindingen uit het rapport daadwerkelijk worden opgevolgd binnen mijn organisatie?nA: Wijs voor elke bevinding direct een verantwoordelijke eigenaar aan en stel realistische deadlines vast op basis van de ernst van de kwetsbaarheid. Door bevindingen op te nemen in het risicoregister en een verplichte hertest in te plannen, zorg je dat remediatie niet blijft liggen en dat verbeteringen meetbaar worden over tijd.

Related Articles