Penetration test
Also known as: pentest, pen test, ethical hacking
An agreed, simulated attack in which skilled testers try to break in, to show how well systems really hold up.
Draft - this entry has not been reviewed yet.
Formal
An authorised test, limited in scope and time, in which people use the same methods as real attackers to find and actually use weaknesses, chaining them together to show what an attacker could reach.
In plain English
Like hiring a professional burglar to try to break into your shop, with your permission, and then write down exactly how they got in.
In practice
Testers hired by a Danish region find a forgotten test website, use a weak password there to get onto the network, and within two days show the IT security manager they can read the finance folder.
Why it matters
Lists of weaknesses do not show how they combine; seeing a real path from outside to valuable data convinces management and shows what to fix first.
How to put it into practice
The usual steps, in order. Adapt them to your organisation.
- Define the goal and the risk questions the test must answer, for example whether an outsider can reach the finance data or a domain admin account.
- Choose a qualified, independent supplier and agree the test type (external, internal, web and API, cloud) and how much the testers are told (black, grey or white box).
- Sign rules of engagement and a written authorisation from the system owners covering scope, exclusions, test window, allowed techniques, contacts, a stop procedure and personal data.
- Get consent from cloud, hosting and SaaS providers where their policies require it, and decide whether the SOC is told in advance.
- Have the testers follow a recognised method, such as NIST SP 800-115 or the OWASP WSTG for web applications, through discovery, exploitation and post-exploitation.
- Receive a report with an executive summary, attack paths, evidence and severity for each finding, and hold a debrief with IT and the risk owners.
- Put the findings into the remediation plan with owners and deadlines, and ask why your own scanning and monitoring did not catch them.
- Book a retest to confirm the fixes, and repeat testing at least yearly and after significant changes.
Common pitfalls
- Testing without written authorisation from the real system owner, which can be a criminal offence under section 263 of the Danish Penal Code.
- Choosing a scope so narrow that it misses the real attack paths, just to get a clean report.
- Treating a yearly pentest as a replacement for continuous vulnerability management.
- Filing the report without fixing the findings and retesting.
Good guides
- NIST SP 800-115 - Technical Guide to Information Security Testing and Assessment(opens in a new tab) · NIST
- OWASP Web Security Testing Guide(opens in a new tab) · OWASP
- Penetration testing(opens in a new tab) · NCSC UK
- CIS Critical Security Controls - Control 18 Penetration Testing(opens in a new tab) · Center for Internet Security
Technical deep dive
Penetration testing grew out of the "tiger team" exercises commissioned by the US military and government in the late 1960s and 1970s; James P. Anderson's 1972 Computer Security Technology Planning Study for the US Air Force described penetration of systems as a way to demonstrate their weaknesses. Modern practice is codified in methodologies such as NIST SP 800-115 (planning, discovery, attack and reporting phases), the Penetration Testing Execution Standard (PTES), OSSTMM and, for web applications, the OWASP Web Security Testing Guide. A typical engagement moves through reconnaissance, enumeration, vulnerability identification, exploitation, post-exploitation (privilege escalation, lateral movement, access to agreed "flags" such as a file share or a domain admin credential) and reporting.
The legal and contractual frame is not a formality. Testing without authorisation is unlawful access to a computer system; in Denmark that is criminal under section 263(1) of the Penal Code (straffeloven). The rules of engagement therefore fix the scope (IP ranges, hostnames, applications, cloud tenants - and explicit exclusions), the testing window, permitted techniques (is social engineering, denial of service or physical access in scope?), emergency contacts and a stop procedure, handling of any personal data encountered, and written authorisation from someone who actually owns the systems. Cloud and hosting providers have their own policies on testing their platforms, and third-party SaaS is usually out of scope unless the provider consents.
Engagements are classified by the knowledge given to testers: black box (none, emulating an external attacker), grey box (credentials or documentation, often the most efficient use of testing time) and white box (full source code and architecture access). Scope types include external network, internal network (often starting from an "assumed breach" foothold), web and API, mobile, wireless, cloud configuration and social engineering. A red-team exercise differs in objective: it tests detection and response against a stealthy, goal-oriented adversary over weeks, whereas a pentest tries to find as many exploitable weaknesses as possible within a scope. Threat-led penetration testing (TLPT) under the TIBER-EU framework, and mandatory for certain financial entities under DORA Art. 26, is effectively intelligence-led red teaming.
The report is the product: an executive summary, attack narratives showing how findings chain together, each finding with evidence, affected assets, a severity rating (often CVSS with contextual adjustment) and remediation guidance, followed by a retest to confirm fixes. PCI DSS v4.x requirement 11.4 mandates internal and external penetration testing at least annually and after significant changes; CIS Controls v8 Control 18 places pentesting at IG2 and IG3, since it adds most value once basic hygiene is in place. A pentest is a point-in-time sample, not an assurance that no other weaknesses exist.
What to learn first
Everything this builds on, foundations first.
- Threat
- →Vulnerability
- →Penetration test
Relationships
- Requires
- Vulnerability
- Don't confuse with
- Vulnerability scanningVulnerability assessmentAI red teaming
- Mandated by
- CIS ControlsDORA
- Used with
- OWASP Top 10
Sources & further reading
Standards & official texts
- NIST SP 800-115 - Technical Guide to Information Security Testing and Assessment · NIST
- CIS Critical Security Controls v8 - Control 18 · Center for Internet Security
Course material
- Cyber Security Fast Track - Ordliste
Where this data comes from
This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.
See the review queueSuggest a correction on GitHubThis term as JSON
Check yourself
Loading…