What actually happens in each phase.

Before anything is tested, we jointly define in writing what may be examined. This is not a formality — without this agreement, the same activity would be legally indistinguishable from a real attack.

• Which systems, domains, or IP ranges are in scope
• Which methods are excluded (e.g. denial-of-service)
• Testing window and escalation path for critical findings
• Points of contact on both sides

I systematically map what's visible from the outside (and, where relevant, the inside): open services, technologies in use, subdomains, configurations. This mirrors what a real attacker would see first.

• Passive and active information gathering within the agreed scope
• Identification of services, versions, and attack surfaces
• Initial prioritization of possible weak points

Identified vulnerabilities are exploited in a controlled way to demonstrate their real-world impact — not to cause damage. Critical or potentially destructive tests are discussed with you in advance.

• Manual, targeted verification of every finding (not just raw scanner output)
• Documentation of every step with evidence (screenshots, requests)
• Immediate notification of critical, actively exploitable gaps — even before the report is finished

The report is the actual deliverable of a test. It's written so that both technical teams and decision-makers without an IT background understand what was found and what to do about it.

• Plain-language management summary
• Every finding with a risk rating, evidence, and a concrete recommendation
• Prioritized order for remediation

After remediation, we verify whether the reported vulnerabilities are genuinely closed — not just whether a change was made.

• Targeted re-verification of every original finding
• Brief closing note per finding: resolved, partially resolved, or still open