Most people buying their first penetration test have no picture of what the two weeks will involve. That uncertainty costs money: unprepared clients lose testing days to access problems, and lost testing days come out of the depth of the test, not the invoice.
Before anything starts: scoping
Scoping is a conversation, usually an hour, and it determines most of the value you will get. You will be asked what the systems are, who uses them, what would be worst if it happened, and what must not be touched.
Answer the "what would be worst" question honestly and specifically. "A customer reading another customer's invoices" gives the tester an objective. "We want to be secure" gives them nothing, and they will default to a generic checklist.
You should leave scoping with a written document naming the targets, the dates, the exclusions, and the escalation contact.
The week before: access
This is where engagements most often lose time. You will need to provide:
- Credentials for every role — at least two accounts per role. Two accounts at the same privilege level are what make it possible to test whether one user can reach another's data, which is the single most common serious finding in business applications.
- An environment — production, or a staging environment that genuinely mirrors it. A staging environment with an empty database and a different authentication provider tests something you do not run.
- Allow-listing — if a WAF or rate limiter blocks the tester on day one, you are paying someone to be blocked. Decide deliberately whether you want the WAF tested or bypassed; both are valid, but choose.
- A named contact who can unlock an account within the hour.
Send all of it before the start date and confirm the credentials work. A tester discovering on Monday morning that the staging login is broken loses a day waiting.
Week one: reconnaissance and mapping
Expect your logs to light up and your monitoring to alert. Tell your SOC or provider the dates in advance, unless you are deliberately testing detection — in which case tell one person only and leave the rest blind.
You will hear very little in this period. Silence is normal. The tester is mapping functionality, enumerating endpoints and understanding your authorisation model before attacking it.
Week two: exploitation
This is when the alarming emails arrive. A good firm will contact you immediately for anything critical rather than holding it for the report.
Expect some disruption. Accounts lock out. Test data appears in your database. Occasionally something falls over. Agree in advance who cleans up test accounts and records afterwards.
If you asked for a detection test, you may also get a call that is really a question: "Did anyone notice?" The answer is itself a finding.
The report
Usually three to five working days after testing ends. A useful report has an executive summary that a non-technical director can act on, findings ranked by business impact rather than scanner severity, reproduction steps, and a remediation note that addresses the cause.
Read it with the tester on a call. The things that do not make it into writing — "this one worries me more than its rating suggests" — are often the most valuable part of the engagement.
Remediation and retest
Fix in order of exploitability, not severity label. An easily reachable medium beats a critical that requires administrator access you have never granted.
When you believe the fixes are in, request the retest within the included window. The retest letter is what you give clients and auditors, and it is worth far more than the original report on its own.
How to get more for the same price
Three things, all free. Give the tester a walkthrough of the application on day one — thirty minutes of someone explaining the business saves two days of guessing. Provide documentation if it exists. And do not quietly fix things mid-test without telling them, because they will spend hours chasing a behaviour that no longer exists.
0 comments
Leave a comment