Penetration testing: scope, evidence and fixes

What is a pen­e­tra­tion test?

A penetration test is a controlled check of whether an attacker can exploit weaknesses in an application, network, server or configuration. The scope and rules must be agreed before work begins. Unlike a scan, it shows whether a weakness can lead to account takeover, unauthorised data access, privilege escalation or service disruption. The report links technical evidence to business impact, an accountable owner and a retest criterion.

How does an ethical penetration test work?

The specialist works within the agreed scope, documents actions, evidence and risk, and then provides a prioritised report. The goal is to improve security without disrupting the company.

Why is a vulnerability scan alone insufficient?

A scan shows potential problems, while a penetration test verifies context, attack chains and actual impact. This tells the company what to fix first.

How should ethical penetration testing be run?

Ethical penetration testing must be controlled, documented and useful for remediation. Virtline starts with scope, rules of engagement, test accounts, systems, windows, contacts and risk limits. The test then combines manual analysis and tools to show real attack paths, business impact, repair priorities and evidence for retesting.

• Document authorisation, scope, targets, accounts, excluded actions, contacts and emergency stop rules.
• Test authentication, authorisation, input handling, exposed services, APIs, configuration and business logic.
• CVSS (Common Vulnerability Scoring System) describes technical vulnerability severity. State the scoring version and vector in the report; remediation priority should also reflect exposure, exploitation, business impact and safeguards.
• Finish with a report, management summary, technical reproduction steps and optional retest evidence.

Related Virtline services and next steps

Penetration testing has the greatest value when combined with a remediation plan, monitoring and subsequent verification of the environment.

How to define a controlled test scope

Obtain written authorisation from parties entitled to approve testing of the systems. Agree scope, excluded techniques, test windows, load limits, data handling and emergency stop rules. Check provider terms and required permissions for third-party assets. Production testing needs a recovery plan and acceptance of test risk.

Risks that the test should show to the business

A penetration test is supposed to translate technical vulnerabilities into decisions: what can be compromised, what process will fail, what data may leak and how much time is needed to repair it. Without this, the report becomes a CVE list that no one can prioritise.

• User or administrator account takeover due to weak password, lack of MFA, bad sessions or phishing.
• Access to customer data, financial documents, backups, administration panels or code repositories.
• Lateral movement on the network after using a poorly protected VPN, SMB, RDP, Active Directory or application server.
• Bypassing access control in the application, API, customer panel or reporting module.
• Lack of attack visibility in logs, SOC/SIEM/SOAR, infrastructure monitoring and incident procedure.

Is ethical hacking possible?

Ethical hacking is possible if it takes place within a clearly agreed scope, with the consent of system owners and in accordance with the principles of data security and service availability. The tester works similarly to the attacker, but his/her task is to demonstrate risk, collect evidence and provide remediation recommendations. The difference between an attack and a test is legality, control, documentation and responsibility for the consequences.

• The scope defines IP addresses, applications, test accounts, operating hours, techniques allowed and techniques disabled.
• Penetration testing should have an emergency channel, a contact person, and a procedure to stop activities in the event of a risk to production.
• Test evidence must support the vulnerability, but should not copy redundant sensitive data.
• Ethical testing should lead to a remediation plan, agreed retesting and improvements to detection and response.

Which areas need stronger safeguards?

The test result shows which areas require priority: web application, firewall, VPN, Active Directory, Microsoft 365, servers, endpoints, permissions, backup or incident response process. A good investigation not only identifies a technical vulnerability, but explains whether it enables account takeover, access-control bypass, data access, service disruption or deeper network penetration.

What should the report contain?

The report should describe the vulnerability, evidence of exploitation, operational impact, risk level, technical recommendation, priority and owner of remediation. It is useful for management to provide a short summary showing which risks may result in data leakage, interruption of operation or violation of customer requirements. For the IT team, step-by-step reproduction, reference configuration and retest criteria are important.

Client-side activities before launch

The most efficient test begins before the first attack attempt. The customer should prepare contact persons, a copy of the configuration, test accounts, address range, information about critical services and a method of escalating the incident if the test reveals a high-risk vulnerability.

• Confirm system owners, test windows, fallback channel, and business-side decision maker.
• Secure a backup and rollback plan for production systems affected by the test.
• Prepare test accounts with different roles so that authorisation and privilege escalation can be verified.
• Determine whether the target is an application, network, Microsoft 365, Active Directory, VPN, Wi-Fi, social engineering, or full attack path.
• Plan a post-report workshop, ownership assignment, and retest of critical and high vulnerabilities.

Retest and post-test activities

After the report, assign remediation owners and deadlines and agree a retest. Record each finding’s status, test limitations and accepted residual risk. Verification covers the tested scenario and system version; it does not establish the absence of all vulnerabilities.

How to choose the type of test for your business purpose

The test scope should follow the decision the company needs to make. Different circumstances require tailored tests: before launching a customer application, after an incident, before an ISO 27001 or NIS2 audit, and when assessing the team's resistance to phishing. This directs the budget towards business-critical risks instead of scattering it across arbitrary scans. The application of NIS2/KSC and DORA depends on the organisation’s sector, status and activities. Technical records can support assessment, but do not by themselves confirm compliance or certification.

• Web application or API: when a company provides a customer panel, store, B2B portal or data integration.
• Network and infrastructure: when you need to check service exposure, segmentation, VPN, servers and lateral movement paths.
• Active Directory and identity: assess privilege escalation, administrator account takeover and incorrect group permissions.
• Social engineering: when management wants to test people's resilience, reporting procedures and helpdesk response.
• Retest: When after patching you need to have proof that a critical or high vulnerability has actually been fixed.

Test evidence for NIS2, ISO 27001 and customers

A report can support customer audits or assessments against ISO 27001, NIS2 and DORA where relevant to the organisation. Include scope, method, dates, limitations, remediation owners and retest results. A penetration test alone does not demonstrate complete compliance or replace distinct testing programmes such as TLPT where specifically required.

When to repeat a penetration test

Periodicity is important because the IT environment is constantly changing: new applications, updates, suppliers, accounts, integrations and network rules are added. A test performed once does not guarantee resistance after subsequent implementations. In practice, it is worth planning tests after major changes, before a customer audit, after an incident, for new web services and as part of a NIS2, DORA or ISO 27001 compliance programme.

Related articles

Penetration testing is part of a broader risk-management programme. It has greatest value when its findings feed into remediation, monitoring and decision-maker documentation.

Contact

Agree a safe scope, rules of engagement, reporting and retest.