This is what a real pentest looks like
No magic, no movie-style green matrix, no hoodies and no people typing at 300 keystrokes per minute. This is what actually happens during a security audit.
Kick-off and defining the rules of engagement
Before touching a single port, we define the rules of engagement with you. This isn't Hollywood — we don't start 'hacking' without permission or without knowing exactly what we can and cannot do.
We sign a non-disclosure agreement (NDA). We establish the scope: which IPs, which domains, which applications are included in the audit? We define the testing window, emergency contacts and the systems that must never be touched under any circumstances (critical production databases, medical systems, etc.).
We also agree on the type of test: black box (no prior information, like a real external attacker), grey box (with standard user credentials) or white box (full access to code and documentation). Most of our clients choose grey box because it offers the optimal balance between realism and efficiency.
Reconnaissance: mapping the terrain
The first two days are dedicated to reconnaissance. We don't launch exploits and we don't try to access anything. We simply observe and map. Which services are exposed to the internet? Which software versions? Which subdomains exist that even the company didn't know were there?
We use discovery tools such as Nmap to identify open ports and services, Amass and Subfinder to enumerate subdomains, Shodan and Censys to find already public information about the infrastructure, and OSINT techniques to gather information about employees, technologies in use and potential data leaks on GitHub, Pastebin or forums.
By the end of day 2, we have a detailed map of the attack surface. In many cases, this map already reveals serious problems: admin panels exposed to the internet without authentication, services running known vulnerable versions that haven't been patched, and employee accounts with credentials leaked in previous data breaches.
Exploitation: what a real attacker would see
This is where the most technical phase begins. With the day 1-2 map, we prioritize the most promising attack vectors. Every finding is exploited in a controlled way to confirm its real impact. It's not enough to say 'you have SQL Injection': we demonstrate which data we could extract through it, without actually extracting it all.
The tests are manual. An automated scanner finds the obvious vulnerability; a pentester finds the chain of vulnerabilities that turns a minor flaw into full system access. Real example from a recent audit: an API endpoint that returned too much information in error messages → we discovered valid user IDs → one of them had MFA disabled → their password appeared in a 2023 breach → full access to the admin panel. No automated scanner would have traced that chain.
During these days we keep communication with the client to a minimum. We only reach out if we find something that requires immediate action (a completely exposed critical system, evidence that someone has already been there before us). These 'critical findings' are reported hot, without waiting for the final report.
Documentation: a report that actually serves you
Day 6 is dedicated entirely to documentation. We don't produce 200-page reports that nobody will read. We produce two documents: a 3-4 page executive summary for management, and a detailed technical report for the systems and development teams.
The executive report answers the questions that matter to the business: what is my real risk? How likely is this to happen? How much would it cost to fix, and in what order? The technical report includes every vulnerability with its CVSS score, screenshot evidence, exact reproduction steps, and specific remediation recommendations — with commands, code snippets and references.
Every finding is classified as critical, high, medium or low based on its real impact, not on what a tool says. An XSS in an internal search field can be low; a SQL injection in the login that allows authentication bypass is critical. We prioritize by business risk, not by numeric score.
Presentation and next steps
We deliver the report in a one-hour meeting with your technical team and, if you want, with management. We don't send the PDF by email and disappear. We explain every finding, answer technical questions and help prioritize the remediation plan.
If the most critical finding takes 2 hours of development to fix and the second most critical takes 2 weeks, we don't list them in numerical order. We tell you: 'Start with this one today. This other one you can plan for the next sprint.'
Three months later, if you want, we run a retest: we re-test the corrected findings to verify that the fixes work. We don't charge for re-finding what was already fixed. The retest confirms that the corrections are effective and that no new problems have been introduced.
Throughout the process, communication is direct. There's no account manager acting as intermediary. You talk to the pentester who ran the tests. If something in the report isn't clear, the person who wrote it explains it to you. This isn't a traditional consultancy: it's technicians talking to technicians.
Want to experience this in your company?
All of this, applied to your systems, by people who have done it hundreds of times. No magic, no surprises, no fine print.