What the attacker would do we do first.

An automated scanner (Nessus, ZAP, Acunetix, etc.) is signature-based: it searches known patterns, most results are false positives and business-logic flaws are never caught. A pentester, by contrast, builds hypotheses specific to your app, chains three weak points into a critical attack, manually attempts privilege escalation and proves every finding with reproducible steps. In practice half of a scanner's "10 critical" results are noise; every finding in a pentest report has been exploited and proven — the engineering team can skip the debate and jump straight to fixing.

All three are valid and measure different things. Black-box starts with the attacker knowing nothing about you — closest to a real attacker but expensive in time and scope. White-box gives the tester source code, architecture diagrams and admin accounts — the deepest test per hour, ideal pre-production. Gray-box sits in the middle: a regular user account plus high-level architecture; for most enterprise pentests this is the most practical compromise because it covers both external and internal attacker models in one engagement. The right choice depends on the goal; we decide it together in the first call.

Managed correctly, no. The Rules of Engagement (RoE) document spells out allowed hours, concurrency limits, isolated test accounts and forbidden actions (DoS, persistent deletions, etc.). In most engagements destructive checks (e.g. brute-force triggering account lockout, payload uploads) only run in staging; in production we collect read-only evidence. There is always a rollback plan: snapshots before testing, on-call engineer reachable for anomalies. 280+ engagements and zero production outages — because the discipline demands the discipline.

It varies by scope. A single web app typically takes 5–10 working days; a medium API engagement 7–12 days; a mobile app 8–14 days; a full red-team scenario 4–8 weeks. On top of this, after fixes ship (usually within 4–8 weeks) the free retest takes about 2–3 working days. Three factors drive duration: breadth of scope, the number of roles/permissions to check and accessibility of the test environment. In the first call we lock the scope and quote fixed days and fixed price; it does not change later.

The report has three layers. First, an executive summary: 1–2 pages, a non-technical risk table, finding counts and overall posture. Second, technical findings: per-finding description, affected component, exploitation steps with screenshots, CVSS 3.1 score and a recommended fix (with code samples). Third, a prioritised action plan: what to fix first, what to fix next — aligned to your sprint cadence. The whole report ships in Markdown + PDF; after the retest it is reissued with "remediated" annotations. Clients submit it directly to ISO 27001, SOC 2 and PCI-DSS audits.

No. The retest of all Critical and High findings from the main engagement is included in the contract price. Only condition: fixes must be deployed within 4–8 weeks (extendable to 12 by agreement) and a testable environment must be available. Closed findings are marked "remediated"; open ones are re-reported. This is our quality guarantee: we don't hand over a report and disappear, we stay until closure. Retesting Medium and Low findings is optional and costs a small fraction of the main engagement.

We use all three in the same engagement. For web apps: OWASP Top 10 (2021) and OWASP ASVS Level 2; for APIs: OWASP API Top 10; for mobile: OWASP MASVS. The methodology follows PTES (Penetration Testing Execution Standard) phases: pre-engagement, intel gathering, threat modelling, vuln analysis, exploitation, post-exploitation, reporting. CVSS 3.1 for risk scoring; NIST SP 800-115 referenced in the report layout. ISO 27001, SOC 2 and PCI-DSS aligned — meaning the report has the shape your auditor expects. Combining the three guarantees both technical depth and audit-readiness.

Yes, every engagement has a lead engineer with at least one industry-recognised certification: OSCP (Offensive Security Certified Professional), OSWE (Offensive Security Web Expert), CEH (Certified Ethical Hacker), CRTP (Certified Red Team Professional) or GPEN (GIAC Penetration Tester). For mobile we also hold eMAPT; for cloud, AWS Security Specialty or AZ-500. Certifications are not mandatory — but when clients ask for the credentials (especially finance and public-sector tenders) we can attach them to the procurement package. More important is that the team produces reproducible findings; certifications signal that but don't guarantee it — we deliver both.