Penetration testing
Validate exploitability and impact within an agreed assessment.
The idea
Penetration testing uses controlled techniques to assess whether weaknesses can be used to achieve agreed objectives. It differs from a vulnerability scan because findings are examined in context and may be validated through limited exploitation. A test is bounded by time, access, scope, and methodology, so absence of findings is not a guarantee of security. Reporting should explain evidence, limitations, and practical remediation.
In practice
A tester validates that one user can access another user’s lab record, captures minimal proof, and avoids collecting unnecessary data.
A common misunderstanding
A penetration test is not an exhaustive certification that no vulnerability exists.
Check your understanding
What should accompany a finding?
Think it through: A reproducible explanation, affected scope, impact, evidence, and an actionable recommendation.
Start with the question the test must answer
A penetration test is most useful when its objective is specific. 'Assess security' leaves too much room for mismatched expectations. 'Determine whether a customer account can access another customer's invoices' identifies an important boundary and suggests the accounts, data, and environments needed. Scope can then include related export and download interfaces without expanding into unrelated infrastructure.
The access provided to testers changes what they can assess. Testing without credentials explores an outsider's view. Supplied user accounts reveal controls behind authentication. Architecture diagrams and source access can expose assumptions that are difficult to discover within a short external assessment. More information is not cheating; it can make limited testing time more productive when that matches the objective.
Validation should be proportionate
In a fictional inventory application, a scanner flags a potentially vulnerable component. A tester checks whether the component is actually installed, whether the affected functionality is reachable, and whether vendor fixes were backported. If a controlled demonstration is appropriate, it should use synthetic data and stop when the agreed consequence is established. Collecting additional sensitive records rarely makes a report better.
A finding may also arise without a known vulnerability identifier. A valid employee might approve their own expense because workflow permissions are flawed. Automated tools can assist discovery, but understanding the intended business rule is essential to recognizing this failure.
Understand the boundary of assurance
Tests examine a particular system state during a defined period. A new deployment, identity integration, or configuration change can alter the attack surface afterward. Findings should feed engineering improvements and verification rather than becoming an annual document that nobody revisits.
For practice, define a lab assessment with three explicit questions, required accounts, excluded actions, and success criteria. After completing it, distinguish 'tested and prevented' from 'not reached' and 'not tested.' These categories communicate coverage honestly and reveal where further review would add value.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
NIST: Technical Guide to Information Security Testing and AssessmentNCSC: Penetration testing