What is in scope for a penetration test will be tested and what isn’t in scope for a penetration test won’t be tested. Simple enough, right? The problem comes when the hackers don’t follow the same scope that the penetration testers follow.
The choices that are usually made when scoping a penetration test are often made around simple practicalities and the various requirements that pop up for the organisation. Security considerations are important, but can be a secondary factor to it all.
For smaller organisations it’s not uncommon to have a full annual test with the entire internal and external environment in scope. After all, it’s easier to do it in one lot and just get it over with.
For larger organisations a full annual test would be too much since there are too many moving parts. It’s more common to have the scope restricted to a single project, maybe the new web application, new SOE, or the new network environment.
For this project by project testing the idea is that you can potentially get comprehensive coverage over the entire environment by testing each project in isolation. Hopefully a group of secure systems ends up being a secure environment. In the end, though, hackers will end up not targeting the systems directly, but they’ll start manipulating how they integrate and interact together.