Hiring a penetration tester is a seven-step process. Done properly it takes two to four weeks from first conversation to testing start. Here is the sequence.
Step 1 — Decide what you are testing and why
Write the objective first. "Prove that a customer cannot access another customer's data" is a testable objective. "Do a security check" is not. Your objective determines the type of test:
- Web application test — your main product.
- API test — public or partner-facing endpoints.
- Mobile application test — the app plus its backend.
- Internal network / Active Directory — what an insider or a phished employee could reach.
- Cloud configuration review — IAM, storage, network, logging.
- Red team — a goal-based simulation of a real attacker, including detection and response.
Step 2 — Choose black box, grey box or white box
Black box (no information) simulates an outsider but wastes days on discovery. White box (full source and docs) finds the most bugs per dollar. Grey box — credentials for every role plus documentation, no source — is the right default for most companies and what I recommend unless you have a specific reason otherwise.
Step 3 — Write a one-page scope document
Include: in-scope assets, out-of-scope assets, user roles, testing window, environment (production or staging — and staging must mirror production or the results are fiction), constraints (no DoS, no social engineering), success criteria, and emergency contacts.
Step 4 — Get three quotes, compared properly
Normalise every quote to consultant-days and manual-versus-automated split. A cheaper quote with three days of scanning is more expensive per unit of value than a higher quote with ten days of manual testing. Also compare: retest included, report format, attestation letter, and who the named tester is.
Step 5 — Verify credentials
Certifications worth weighting: OSCP, OSWE, OSCE3, CREST CRT/CCT, eWPTX, GPEN, GWAPT. Beyond paper, look for public write-ups, CVEs, conference talks, bug bounty rankings and client references in your sector. Ask for one reference you can actually call.
Step 6 — Run the engagement well
- Provide access on day one — credentials, allowlisting, documentation.
- Open a shared channel (Slack, Teams) for real-time questions and critical findings.
- Do not fix bugs silently mid-test; tell the tester so results stay coherent.
- Have an engineer available for a mid-engagement check-in.
Step 7 — Turn the report into fixes
Triage into fix-now, fix-this-quarter, and accept-with-rationale. Give each finding an owner and a due date in your normal issue tracker so it competes with feature work on equal footing. Then book the retest, get the clean attestation letter, and diarise the next test — annually at minimum, plus after any major architectural change.
Employee, contractor or consulting firm?
Hiring a full-time security engineer makes sense above roughly 50 engineers or when you ship continuously in a regulated sector. Below that, an independent consultant or small specialist team on a project or retainer basis gives you senior expertise at a fraction of the cost, with independence that an internal hire structurally cannot provide.
A practical timeline
Week 1: scope document, request quotes. Week 2: evaluate, verify credentials, sign. Week 3: prepare access and accounts. Weeks 4-5: testing. Week 6: report and debrief. Weeks 7-10: remediation. Week 11: retest and attestation.
---
Need a second opinion on your security posture?
I'm Michael Adeyanju, a penetration tester and security consultant working with companies globally — web app, API, mobile and network security. Based in Lagos, Nigeria, available for remote and on-site engagements worldwide.
Book a 15-minute call: cal.com/michaeladeyanju/15min
See what an engagement covers: michaeladeyanju.com/security-engineer