Penetration Testing: The Four Questions Clients Actually Ask
/ CybeRaccoon / 4 min read
Four questions come up in almost every scoping call, so here are the answers in one place. A penetration test usually takes up to 14 business days, with the exact length set by scope rather than by a fixed package. Testing covers every component, every endpoint and every request your system sends, not a sample of them. You choose between black box, grey box or white box testing depending on how much we are told in advance, and grey box is the one we recommend most often. And to begin, we need exactly one thing: access to the system being tested. Everything below is the long version.
How long does a penetration test take?
Most engagements finish within 14 business days. That is the common case, not a cap.
Duration follows scope. A single marketing site and a multi-tenant platform with a mobile app and three cloud accounts are not the same job, and quoting them as though they were is how people end up with a rushed test or an unexpected invoice. We work the length out on the scoping call, before anyone commits.
That window covers active testing. Reporting comes after it, and the retest after you have made your fixes is included in the original price rather than billed as a second engagement.
If someone quotes you a duration before asking what you have, they are quoting a package rather than a test.
What exactly gets tested?
Every component, every endpoint, and every request that gets sent.
That phrasing is deliberate. Plenty of assessments cover only what is easy to reach: the login page, the obvious forms, whatever a crawler found. The interesting failures are rarely there. They are in the request that fires only when you change a setting, the internal endpoint the front end calls but never links to, and the parameter nobody validates because the UI will not let you reach it.
The work is exhaustive by design. Depending on scope that means web applications, APIs and source code, mobile builds and their backends, internal and external networks, and cloud configuration and privileges. Our security services page breaks each of those down.
A scanner runs first, but only to clear the noise so the human time goes where the logic problems are. Testing by hand is the whole point of how we work, not a detail of it.
Black box, grey box or white box: which testing style?
Three options, and the difference is simply how much we are told before we start.
Black box means no information at all. We start where an anonymous attacker starts. It gives the most realistic picture of an opportunistic external attack, and it spends real budget on reconnaissance a determined attacker would happily do for free.
Grey box means minimal information plus working user accounts. This is the one we recommend most often. Most damaging breaches involve an attacker who already holds some access, through a stolen credential or a compromised integration, so testing from that position tests what is most likely to actually happen. It also puts the budget into finding flaws rather than finding the front door.
White box means full disclosure and direct work with your development team, architecture and source included. Deepest coverage, and it suits systems where a missed flaw is expensive.
None of these is a difficulty setting. They are different questions. Black box asks what a stranger can do, grey box asks what a user can do, white box asks what is actually wrong.
What do you need from us to start?
Access to the system being tested. That is the requirement.
No lengthy onboarding, no tooling to install, no infrastructure to prepare. For a grey box test that means credentials for a normal user account. For anything internal, a route in.
An NDA is signed before any technical detail is exchanged, so you are never describing your infrastructure to a stranger on the promise that paperwork will follow. Whatever your environment looks like, get in touch and we will scope it properly. Newer questions, like whether your encryption survives the move to post-quantum standards, fit into the same conversation.
Frequently Asked Questions
Can a penetration test be done faster than 14 business days?
Yes, for smaller scopes. A single application with a limited attack surface can finish faster than the 14 day period. What we will not do is compress a large environment into a short window, because the result covers the easy surface and misses what matters.
Will testing take our systems down?
No. Testing is designed to avoid disruption, and anything genuinely risky is agreed in advance rather than sprung on you. If you would rather certain actions run outside business hours, that is arranged during scoping.
Which testing style should we choose if we are unsure?
Grey box, in most cases. It reflects how real breaches usually unfold, since the attacker already holds some access, and it puts your budget into finding flaws rather than into reconnaissance you could have simply handed over.
What happens after we fix the findings?
We retest them. The retest is included in the original price, and it is what actually closes a finding. A fix is not confirmed because a commit says it is; it is confirmed when the same attack is tried again and no longer works.