A cybersecurity consultant finds the ways an attacker could get into your systems, proves it safely, and hands your engineers a prioritised, fixable list. The scan is maybe five percent of the work. Here is the other ninety-five.
The engagement, week by week
Week 0 — Scoping and rules of engagement
We agree on exactly what is being tested: which domains, which API base URLs, which mobile builds, which IP ranges, which user roles. We agree what is off-limits (production payment rails, denial-of-service, social engineering unless requested), the testing window, and who to call if something breaks. You get a signed authorisation letter; I get test accounts for every role.
Week 1 — Reconnaissance and threat modelling
Before touching a single payload, I map the real attack surface. That means subdomain enumeration, certificate transparency logs, exposed cloud storage, forgotten staging environments, leaked credentials in public repos and paste sites, and the technology fingerprint of every host. Then I write the threat model: who would attack you, what they want, and the three most likely paths to it.
Weeks 1-2 — Manual testing
This is where consultants differ from tools. Typical areas:
Authentication and session management — password reset flows, token expiry, MFA bypass, session fixation, JWT signature handling.
Access control — the single biggest source of real breaches. Can a low-privilege user reach an admin endpoint? Can tenant A read tenant B's records by changing an ID? Can a cancelled subscription still call the API?
Business logic — negative quantities, race conditions on withdrawals, coupon stacking, replaying a signed webhook.
Injection and input handling — SQL, NoSQL, template injection, SSRF, deserialisation, file upload handling.
Infrastructure and cloud — over-permissive IAM roles, public buckets, exposed management ports, missing network segmentation.
APIs — the OWASP API Top 10, especially broken object-level authorisation and excessive data exposure.
Week 2 — Exploitation and impact proof
A finding without impact gets ignored. My job is to turn "this endpoint lacks an authorisation check" into "here is a screenshot showing another customer's invoices, retrieved from an unauthenticated session". That is what makes an engineering team prioritise the fix and a board approve the budget.
Week 3 — Reporting
A good report has two halves. An executive summary in plain language: what the risk is, what it would cost you, what to do first. And a technical section: each finding with severity based on real business impact, exact reproduction steps, request/response evidence, and a specific remediation recommendation — not "sanitise input" but "use parameterised queries in this file".
Week 4 — Debrief and retest
A live walkthrough with your engineers, questions answered, then a retest once fixes land, plus a clean attestation letter you can send to customers and auditors.
What a consultant is NOT
- Not a compliance rubber stamp. A report that says "no issues found" after two days is a red flag, not a win.
- Not a replacement for your engineering team. I find and explain; your team fixes.
- Not a one-off. Your code changes weekly; test at least annually and after every major release.
Specialisations to look for
Consultants are not interchangeable. Web application testing, API testing, mobile (Android/iOS), internal network and Active Directory, cloud configuration review, and red teaming are genuinely different skill sets. Match the specialisation to your actual risk, and ask for a redacted sample report before you sign anything.
---
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