PROBLEM
It is unclear what an attacker would see first: a panel, an account, a service, or a path a configuration review never touches.
PODEJŚCIE
An explicit scope and written consent, then a test with a specialist matched to the environment. The report says what was shown and what to fix.
SCOPE
- web application test in the agreed scope
- test of the network and internet-facing services
- access paths (VPN, accounts, Active Directory) when they are in scope
- retest after fixes, when the contract includes it
DELIVERABLE
- a record of authorisation, scope and exclusions
- findings with evidence, impact and priority
- remediation recommendations you can implement
PROCESS
- authorisation and rules of engagement
- reconnaissance inside the scope only
- vulnerability validation
- report and walkthrough
Pentesting is useful when the owner knows what may be touched. We agree hosts, applications, accounts, the time window and the methods. Outside that window I do not scan “just in case”, and I do not test infrastructure that is not yours.
I run the test with a top 1% TryHackMe pentester and with other specialists — the team depends on the scope (application, network, identity, cloud). I set the boundaries, the communication and what in the report has to become a decision rather than a tool list.
Results are split into fact (what was demonstrated), impact and what to fix. No “9/10” score and no promise that nothing gets in after the test. If you need a picture of configuration before a controlled attack, start with a security assessment.
Out of scope: a test without the owner’s written consent, social engineering of people outside an agreed list, DoS, and production exploitation beyond what is needed to confirm impact.