How to prepare for a penetration test

A penetration test is one of the most effective ways to check an organisation’s real security — provided it is well prepared. In our experience, the difference between a test a company approached deliberately and one “ordered because the auditor said so” can be enormous: the first ends with a list of concrete, fixed vulnerabilities, the second with a report that lands in a drawer. Below is a guide to the whole process: from the decision to test through to the retest.

What a penetration test is actually for

A penetration test (pentest) is a controlled attack on designated systems, carried out by a qualified specialist on the basis of written consent. The goal is simple: to find and document vulnerabilities before a real attacker does — together with proof that they can actually be exploited and an assessment of the business impact.

Typical reasons for ordering a test:

a contractual or regulatory requirement — more and more B2B contracts, cyber insurance policies and regulations (NIS2, DORA, ISO 27001) expect regular testing,
launching a new application or service — a test before go-live is many times cheaper than an incident after it,
verification after changes — a cloud migration, a merger, new infrastructure,
a conscious board decision that it’s worth knowing the actual state rather than the declared one.

It’s worth distinguishing a pentest from a vulnerability scan straight away. A scanner finds known, catalogued weaknesses and produces a long list of alerts — without confirming whether they can be exploited. A pentester combines tools with manual analysis: verifies findings, chains seemingly minor bugs into attack paths and demonstrates real impact. A scan is a screening test; a pentest is a diagnosis.

Types of tests: what to choose

The scope and model of the test should follow from what you want to check:

A web application or API test — the most commonly ordered. It checks authentication, access control, input validation and business logic, usually following OWASP methodology (WSTG, ASVS).
An external infrastructure test — everything exposed to the internet: VPNs, mail servers, login panels, forgotten subdomains.
An internal infrastructure test — the “attacker is already inside” scenario: privilege escalation, lateral movement, paths to Active Directory.
Social engineering tests — controlled phishing and vishing; they test processes and people, not technology.
Red teaming — a multi-week simulation of a real adversary with agreed objectives; for organisations that already run a mature security programme.

Then there’s the level of knowledge given to the tester: black box (the tester knows as much as an anonymous attacker), grey box (a test account and basic documentation) and white box (full documentation, sometimes source code). Counterintuitively, black box is not the “most realistic” option per unit of budget — the tester spends time on reconnaissance that a real attacker would run for weeks. For most companies, grey box gives the best value for money.

Before the test: seven things to agree

Good preparation is mostly decisions and communication. Before the start, agree with the provider:

The goal. “We want to know whether customer data can be reached” is a better goal than “test everything”. The goal drives scenarios and priorities.
The scope. Specific addresses, domains, applications and networks — and what is explicitly out of scope (a partner’s production environment, life-safety systems, the cloud provider’s infrastructure).
Rules of engagement. Testing windows, permitted techniques, rules for potentially invasive actions (exploitation, password attacks), an emergency contact on both sides.
The environment. Production or staging? Testing staging is safer, but it must mirror production configuration, otherwise the results will be misleading.
Test accounts and access. For grey box, prepare accounts with different roles (user, manager, admin) — access control testing requires them.
Notifications. Decide who in the company knows about the test. The SOC/IT team usually should not be fully forewarned (the test also checks detection), but someone with authority must know, so a “suspicious incident” doesn’t get escalated to law enforcement.
Formalities. A contract with a testing-consent clause (the “get out of jail” card), an NDA, and where personal data is involved — a processing basis. Without written consent from the system owner a test is a crime, which is why a professional provider always starts with the paperwork.

What not to do before the test

Two temptations spoil the value of a test. First: a big clean-up right before the start — switching off services, quick-fix patching, hiding test servers. The test is meant to show the actual state; an artificially improved picture means you’re paying to examine fiction while the real gaps remain. Second: narrowing the scope to places you know are safe. The biggest findings almost always come from systems nobody remembered — old panels, forgotten subdomains, “temporary” integrations from three years ago.

What the test itself looks like

The typical course of an application or infrastructure test (1–3 weeks):

Reconnaissance — mapping the attack surface, identifying technologies and entry points.
Scanning and analysis — automated tools plus manual verification; eliminating false positives.
Exploitation — controlled confirmation that a vulnerability is real; collecting evidence (PoC).
Post-exploitation — checking how far one can get: privilege escalation, data access, lateral movement.
Reporting — a description of each finding with a risk rating and remediation guidance.

During the test a good provider communicates continuously: critical findings are reported immediately, without waiting for the final report. And if the tester finds active traces of an earlier break-in — the test turns into incident response, which should also be agreed in advance.

How to read the report and what to do afterwards

The report should have two layers: an executive summary (what was found, what business risk it carries, what to fix first) and a technical section (reproduction steps, evidence, recommendations for the IT team). Every finding should carry a risk rating (e.g. CVSS with business context) and a concrete fix.

After receiving the report:

Walk through the findings with your team and the provider — a report debrief session should be included in the price.
Plan remediation by risk, not by ease. Critical and high findings — in days, not months.
Look for systemic causes: if the test found five access control bugs, the problem is the development process, not five lines of code.
Order a retest. Verifying the fixes is a standard element — for us it’s part of every project. Without a retest you don’t know whether the fix worked.

What it costs and how often to test

Prices depend on scope: a single web application test typically runs to somewhere in the low tens of thousands of złoty; a comprehensive infrastructure test proportionally more. Suspiciously cheap offers usually mean a scanner report with a logo on the cover — you’ll recognise them by the lack of manual verification and recommendations copy-pasted from the CVE database.

A sensible rhythm for most companies: a full test once a year, plus after every significant change (a new application, a migration, a network redesign). Between tests, the gap is covered by ongoing vulnerability management and scanning.

Frequently asked questions (FAQ)

Can a penetration test break something? The risk exists but is manageable: a professional tester agrees invasive actions before performing them, works within agreed time windows and avoids destructive techniques. In practice the vast majority of tests run with no impact on systems at all — and high-risk scenarios can be moved to a test environment.

Black box or grey box for a first test? Grey box. For the same budget you get much deeper coverage: the tester doesn’t burn days guessing things you could simply hand over (test accounts, an endpoint list). Black box makes sense as a supplement — e.g. to see what is really visible from outside.

Does a small company need a pentest too? If you process customer data, run an internet-facing application, or your clients ask about security — yes, though the scope can be smaller. For the smallest companies a security audit with testing elements is often a better start than a full pentest.

How do I check a provider’s competence? Ask about certifications that prove hands-on skills (OSCP, OSEP, PNPT, CRTO), a sample anonymised report and the methodology (OWASP WSTG, PTES). A good provider will gladly show what their report looks like — it’s the best preview of quality.

What should the contract include? Scope and schedule, written consent to testing, rules of engagement, an NDA and data-handling rules, provisions for the report and the retest, plus an emergency contact. These are standard for us — book a consultation and we’ll walk through them together before the start.

Summary

Much of a penetration test’s value is created before it starts: a clear goal, a well-chosen scope, prepared accounts and agreed rules mean the tester spends time hunting vulnerabilities rather than waiting for access. If you’re planning your first test or want to compare approaches with your current provider — see our services or simply write to us. We’ll help match the scope to your risk and budget.