What a Penetration Test Really Looks Like: From Kickoff to Final Report

A penetration test is not a situation where “hackers disappear for a few weeks and then send you a PDF listing everything that is wrong.” It is a structured security assessment with clearly defined stages, agreed rules, and measurable outcomes.

From the client’s perspective, the process may look relatively quiet: a few kickoff meetings, a period with limited communication while the security team performs the technical work, and then a final report. Behind the scenes, however, a significant amount of analysis and hands-on testing is taking place. The quality of that work determines whether you receive a realistic picture of your security posture or simply a list of technical issues.

In this article, we explain what a professional penetration testing process looks like from the client’s perspective, what to expect at each stage, and how to get maximum value from the assessment.

Before the Penetration Test: What Happens During the Kickoff?

The first meeting with the penetration testing team is primarily about defining the scope of work: what exactly will be tested, where the boundaries are, and which rules the testers must follow.

This stage shapes the entire engagement. The agreed scope affects the duration, cost, and, most importantly, the practical value of the results. Before the project starts, it is worth preparing answers to several key questions.

1. What Are We Testing?

A penetration test can cover different parts of your IT environment, including:

• external infrastructure such as servers, VPNs, email gateways, websites, and other internet-facing systems;

• internal networks;

• web applications and APIs;

• mobile applications;

• Wi-Fi networks;

• or a combination of these assets.

The more precisely the scope is defined, the more meaningful the results will be.

The idea of “testing everything” may sound reasonable, but in practice it often results in a superficial assessment of a large number of systems rather than an in-depth examination of the assets that matter most to the business.

2. What Level of Access Will the Testers Receive?

The amount of information and access provided to the penetration testing team determines the testing methodology.

Black Box Testing

In a Black Box penetration test, the security team starts with little or no information about the target environment. This approach most closely resembles a real external attack, where an attacker initially knows only what can be discovered from publicly available sources.

Black Box testing provides a realistic view of how your infrastructure appears to an external attacker. However, it generally requires more time and may not uncover vulnerabilities hidden deep within internal application logic or restricted systems.

Grey Box Testing

In a Grey Box assessment, penetration testers receive limited information or access. This might include a standard user account, a network diagram, or selected technical documentation.

This approach can simulate a scenario where a user account has already been compromised or where an insider with limited privileges attempts to expand their access. Grey Box testing is one of the most common approaches for corporate penetration tests because it provides a practical balance between realism and testing depth.

White Box Testing

In a White Box assessment, the security team receives extensive information about the target environment. This may include architecture diagrams, source code, documentation, administrative accounts, and other technical materials.

White Box testing enables specialists to examine a system in greater depth and identify a larger number of potential security weaknesses within a limited timeframe. However, it does not necessarily demonstrate how difficult the system would be to compromise from an external attacker’s perspective.

The right methodology depends on the objective. If you want to understand what an external attacker can discover and exploit, Black Box or Grey Box testing is usually more appropriate. If the priority is comprehensive security analysis of the system itself, White Box or an extended Grey Box assessment may provide more value.

3. What Is Off-Limits?

Before testing begins, both parties agree on the Rules of Engagement (RoE). This document defines exactly how the penetration test may be conducted.

Typical restrictions may include:

• avoiding active testing during peak business hours;

• prohibiting potentially destructive attacks against production systems without explicit approval;

• excluding third-party services, cloud platforms, or SaaS solutions unless appropriate authorization has been obtained.

Rules of Engagement are not simply a formality. They protect both the client and the penetration testing provider by establishing clear testing boundaries and responsibilities.

For the client, this reduces the risk of the assessment disrupting business operations. For the penetration testing team, it provides documented authorization and clear rules for performing the work.

4. What Documents Are Required?

Several documents are typically prepared before a professional penetration test begins.

An NDA (Non-Disclosure Agreement) ensures that information obtained during the assessment remains confidential.

The Scope and Rules of Engagement define the systems included in the assessment, testing boundaries, permitted activities, and restrictions.

In some cases, a Letter of Authorization (LoA) may also be required. This formally confirms that the penetration testing team has permission to perform the agreed activities. It can be particularly important if questions arise from an internet service provider, hosting provider, cloud provider, or another third party.

Phase 1. Reconnaissance

After the kickoff, there is often a period when the client receives very few updates from the penetration testing team. It can appear as though the project has not really started.

In reality, this is when the foundation of the entire assessment is being built.

Reconnaissance is the first technical stage of penetration testing. During this phase, testers collect as much relevant information about the target as possible before attempting exploitation.

Depending on the type of assessment, reconnaissance may include several activities.

Passive reconnaissance. The team analyzes publicly available information such as DNS records, WHOIS data, SSL certificates, employee profiles on LinkedIn, GitHub repositories, Shodan data, and potentially exposed or leaked credentials.

Active scanning. Testers identify open ports, accessible services, software versions, and configuration details.

Web application reconnaissance. The team analyzes application architecture, technologies, authentication mechanisms, endpoints, and available data input points.

Experienced penetration testers begin developing potential attack hypotheses at this stage.

For example:

“The server is running Microsoft Exchange 2019 without recent security updates. We should investigate whether known vulnerabilities such as ProxyLogon or ProxyShell may be applicable.”

Or:

“Several Azure administrators were identified through LinkedIn. It may be worth checking whether credentials associated with these accounts appear in known data leaks.”

Client involvement during reconnaissance is usually minimal. The most important requirement is simply to remain available in case the testing team needs clarification about specific systems or services.

Phase 2. Vulnerability Scanning and Analysis

Once reconnaissance is complete, the assessment moves into a more active phase.

The team performs automated scanning, reviews configurations, investigates potential vulnerabilities, and manually analyzes anything that appears suspicious.

At this point, it is important to understand the difference between a Vulnerability Assessment and a penetration test.

An automated vulnerability scanner primarily identifies known weaknesses using signatures, CVE databases, and configuration checks.

A penetration tester goes much further. The goal is to determine whether a vulnerability can actually be exploited in your specific environment and what the consequences would be for the business.

For example, a scanner may detect an outdated SSL/TLS configuration and assign it a medium severity rating.

A penetration tester will ask additional questions:

• Is sensitive information transmitted through this channel?

• Can the weakness be used to enable another stage of an attack?

• Could it become part of a larger compromise chain?

This is why the same technical vulnerability can represent very different levels of risk for different organizations.

During this phase, the testing team may occasionally contact the client for clarification, for example, to determine whether a particular system is production or a testing environment.

What Happens When a Critical Vulnerability Is Found?

Critical findings should not wait until the final report.

If penetration testers discover a vulnerability that creates an immediate threat to the organization, a professional provider should notify the client as soon as possible.

Examples may include:

• administrative access without authentication;

• publicly accessible backups;

• exposed secrets or access keys;

• a critical Remote Code Execution (RCE) vulnerability in an internet-facing service.

Immediate notification allows the organization to remediate the vulnerability before the penetration test is complete and reduce the period of exposure.

Phase 3. Exploitation

This is the stage most people imagine when they hear the term “penetration testing.”

In reality, exploitation is only one phase of the overall assessment. However, it is also the phase that most clearly demonstrates whether a technical weakness creates a real security risk.

The goal is not simply to identify a vulnerability. It is to safely demonstrate whether that vulnerability can actually be exploited.

Consider the difference between these two findings:

“SQL Injection was identified.”

and:

“The SQL Injection vulnerability allowed access to a database containing 50,000 customer records.”

The first is a technical finding. The second demonstrates a verified business risk.

During the exploitation phase, penetration testers:

• validate whether identified vulnerabilities can actually be exploited;

• determine what level of access an attacker could obtain;

• investigate opportunities for further compromise and lateral movement;

• identify which additional systems or data could potentially be reached;

• document each step so the results can be verified and reproduced in the final report.

This phase helps answer one of the most important questions for any CTO or security leader: “What could an attacker actually do if they exploited this vulnerability?”

During testing, your security team may notice unusual activity in logs or receive alerts from SIEM, EDR, or other security tools.

That is expected.

In fact, if your monitoring systems detect penetration testing activity, it provides useful evidence that at least some of your detection mechanisms are functioning as intended. These observations can also contribute to the overall assessment of your security controls.

Phase 4. The Penetration Testing Report

Once the technical work is complete, the team prepares the final penetration testing report.

The report is one of the most important deliverables of the entire engagement. Its quality determines whether the assessment becomes a practical security improvement tool or simply a collection of technical findings.

A good penetration testing report is written for different audiences.

Executives need to understand business risks, potential impact, and priorities. Technical teams need detailed evidence and clear remediation guidance.

For this reason, professional penetration testing reports usually contain two complementary sections.

Executive Summary

The Executive Summary should contain very little technical jargon.

Its primary purpose is to answer three questions.

How secure is the organization?

This section provides an overall assessment of the security posture based on the performed testing, relevant industry practices, and previous penetration testing results where available.

Which risks are the most serious?

Management should receive a concise explanation of the most critical findings and their potential business impact.

Instead of:

“CVE-2026-XXXX was identified.”

The report should explain:

“An unauthenticated attacker could gain access to customers’ personal data.”

That is the information decision-makers need in order to evaluate risk and prioritize resources.

What should we fix first?

Rather than presenting management with dozens of isolated recommendations, the Executive Summary should provide a clear, prioritized remediation roadmap.

Technical Findings

The technical section becomes the working document for the IT and Security teams responsible for remediation.

For each finding, the report should typically include:

• a description of the vulnerability;

• the exact affected location, such as a URL, IP address, system, or component;

• a reproduction scenario or Proof of Concept (PoC);

• a CVSS score and justification;

• remediation recommendations;

• references to relevant standards or classifications such as CVE, CWE, or OWASP, where applicable.

The key characteristic of a strong technical report is specificity.

After reading it, the technical team should understand exactly what needs to be fixed, why it matters, and how to verify that the vulnerability has been successfully remediated.

How to Read CVSS Scores

CVSS (Common Vulnerability Scoring System) is an internationally recognized framework for rating vulnerability severity on a scale from 0 to 10. Modern security reports commonly use CVSS 3.1 or CVSS 4.0.

However, CVSS should never be treated as the complete risk assessment.

A CVSS score does not fully account for the specific business context of your environment.

For example, a vulnerability with a CVSS score of 7.5 in an internet-facing system processing payment information may create a significantly greater business risk than a technically similar vulnerability in an isolated internal test environment containing no sensitive data.

That is why a professional penetration testing report should go beyond the numerical score. The provider should explain the real-world impact that each vulnerability could have on your specific organization.

What Else Should You Consider Besides CVSS?

Several additional factors help determine the actual severity of a vulnerability.

Attack Vector (AV)

Attack Vector describes where an attack can originate.

If a vulnerability can be exploited remotely over the internet, the risk is generally higher than if exploitation requires physical access or an existing presence inside the corporate network.

Privileges Required (PR)

Privileges Required indicates whether an attacker needs an existing level of access before exploiting the vulnerability.

Vulnerabilities that can be exploited without authentication are generally more dangerous than those requiring an authenticated or privileged account.

User Interaction (UI)

User Interaction indicates whether exploitation requires an action from another user.

For example, the victim may need to open an attachment, click a malicious link, or approve an operation.

When no user interaction is required, exploitation is generally easier.

Proof of Concept (PoC)

A high-quality penetration testing report provides evidence demonstrating that a vulnerability was successfully exploited where exploitation is safe and within the agreed Rules of Engagement.

Evidence may include:

• screenshots;

• event logs;

• HTTP request and response fragments;

• video recordings;

• other technical evidence.

These materials are not included simply to make the report look impressive. They demonstrate that the risk is not merely theoretical and help both technical teams and management understand why remediation should be prioritized.

The Debriefing

After delivering the final report, the penetration testing provider should conduct a dedicated debriefing session with the client.

This meeting should not simply be a presentation of the PDF.

Its purpose is to help the organization correctly interpret the findings and determine what to do next.

During the debriefing, your team should be able to:

• ask questions about individual findings;

• receive explanations of complex technical issues;

• discuss remediation priorities;

• clarify recommendations and implementation steps.

If a provider disappears immediately after sending the report, the client is left alone with a document that may contain dozens of technical findings without the context needed to prioritize and remediate them effectively.

What Should You Do After a Penetration Test?

The real value of penetration testing appears when the findings lead to concrete improvements in your infrastructure, applications, and security processes.

Step 1. Prioritize the Findings

Not every vulnerability represents the same level of risk. A practical approach is to divide findings into three groups.

Urgent

Critical vulnerabilities and the most dangerous High-severity findings belong here.

Examples include unauthenticated administrative access or the ability to execute arbitrary code remotely.

These issues should ideally be addressed within the first 24–72 hours.

Planned

High- and Medium-risk vulnerabilities that can realistically be exploited but require additional conditions can usually be included in the next patching cycle or security remediation plan.

Backlog

Lower-risk findings still need attention, but they do not represent an immediate threat.

They can usually be addressed as part of planned infrastructure improvements and ongoing security maintenance.

Step 2. Verify That the Vulnerability Is Actually Fixed

After remediation, it is important to verify that the original vulnerability can no longer be exploited.

Your internal security team can perform this verification, or you can request a retest from the penetration testing provider.

Retesting has become a standard part of professional penetration testing because there can be a significant difference between “we implemented the fix” and “the vulnerability can no longer be exploited.”

Step 3. Fix the Root Cause, Not Just the Finding

A penetration test often reveals more than isolated technical vulnerabilities. It can expose systemic security weaknesses.

Examples include:

• missing or inconsistent patch management;

• excessive user privileges;

• weak network segmentation;

• inadequate configuration management.

If you only fix individual vulnerabilities without addressing the underlying process, similar problems may appear again several months later.

A valuable penetration testing report should therefore explain not only what needs to be fixed, but also why the vulnerability appeared and which security processes should be improved to prevent recurrence.

Step 4. Protect the Penetration Testing Report

A penetration testing report contains detailed information about your organization’s security weaknesses.

In the wrong hands, it can effectively become a roadmap showing where vulnerabilities exist.

For this reason:

• restrict access to the report;

• avoid sending it through unencrypted email;

• do not store it in publicly accessible or broadly shared corporate folders;

• use secure document storage and sharing mechanisms.

Frequently Asked Questions After a First Penetration Test

“We Have 47 Vulnerabilities. Is That a Lot?”

The total number of findings tells you very little on its own.

What matters much more is:

• how many are Critical or High severity;

• whether exploitation was successfully demonstrated;

• which systems and business processes are affected.

One critical vulnerability that provides verified access to a customer database may represent a significantly greater risk than dozens of informational findings.

“Our Administrators Say the Vulnerability Is Not Critical. Who Should We Believe?”

Your IT team evaluates the system primarily from the perspective of its operation, architecture, and configuration.

Penetration testers evaluate the same system from the perspective of a potential attacker.

Both perspectives are valuable.

The final risk assessment should therefore be based on evidence rather than opinion—particularly the exploitation evidence and Proof of Concept documented in the penetration testing report.

“When Should We Conduct the Next Penetration Test?”

For most organizations, conducting a comprehensive penetration test at least once a year is a reasonable baseline.

Additional testing should also be considered after:

• launching new services;

• significant infrastructure changes;

• cloud migrations;

• launching new web applications or APIs;

• major changes to network architecture.

Organizations subject to PCI DSS, ISO/IEC 27001, DORA, or other regulatory and compliance requirements may need to conduct security testing more frequently depending on their specific obligations and risk profile.

“We Fixed Every Finding. Does That Mean We Are Secure Now?”

A penetration test represents the security posture of a defined scope at a specific point in time.

New vulnerabilities continuously emerge as new CVEs are discovered, software is updated, configurations change, and new services are introduced.

Penetration testing should therefore not be treated as a one-time security exercise. It should be part of an ongoing cybersecurity risk management program.

The Real Value of Penetration Testing

Ordering a penetration test and receiving the final report is only the beginning.

The real value appears when the findings become the basis for vulnerability remediation, stronger security processes, and better infrastructure decisions.

For a CTO, CISO, or IT Director, the objective should not simply be to “pass” a penetration test. The objective is to gain an objective understanding of the organization’s current security posture and receive a clear roadmap for reducing risk.

If, at the end of the engagement, you understand:

• which security risks exist;

• which risks should be addressed first;

• what changes can prevent similar weaknesses from appearing again;

then the penetration test has achieved its primary purpose.

That is where its real value lies.

Penetration Testing Services by ESKA Security

The ESKA Red Team performs penetration testing for web applications, APIs, mobile applications, external and internal network infrastructure, cloud environments, and Wi-Fi networks.

We do not limit penetration testing to automated vulnerability scanning. Our specialists validate whether identified vulnerabilities can actually be exploited, evaluate their potential business impact, and provide clear, actionable remediation recommendations.

Following the assessment, you receive a detailed technical report, an Executive Summary for management, a prioritized list of security risks, and practical recommendations for your IT and Security teams.

Planning a penetration test? Talk to the ESKA Security team to define the scope of work and receive an estimate of the timeline and cost for your assessment.