What happens between signing and the report

1. 01

   Scoping, in writing

   Before anything starts

   You tell us the systems, the environment, the roles and what your audit needs. We come back with a fixed price, an asset ceiling, and the earliest date.

   If the test has to support an audit, this is where we compare your scope against the SOC 2 system description or the ISO 27001 scope statement. A report that does not cover the system the audit covers is evidence about something else, and that is much cheaper to catch now than afterwards.

   The most common scoping error is one account and one tenant. Authorization is where the serious findings are, and testing it needs at least two of each.

2. 02

   Rules of engagement

   Before anything starts

   Written authorization covering what may be tested, when, by what methods, what is explicitly out of bounds, and who to contact if something goes wrong. Signed by someone with authority over the systems.

   This is the legal basis for the work. Testing a system you do not own is not authorized because your customer asked for it, so third party platforms in your architecture are identified and excluded here unless their terms allow it.

   Cloud provider testing policies are confirmed at this stage, along with anything resembling denial of service, which stays prohibited.

3. 03

   Access and kickoff

   Day one

   Two accounts per role, two tenants, credentials working, a walkthrough of where the money and the sensitive data live, and a contact who can answer a question within a few hours.

   Bot protection and rate limiting are allowlisted unless they are deliberately in scope, and the report says which choice was made so the coverage claim is legible to an auditor.

   A tester blocked on an environment question for a day has lost a fifth of the engagement, and nobody gets that day back.

4. 04

   Testing

   Three to five business days

   Automation handles reconnaissance, enumeration and evidence capture, which is what it is good at. A named engineer decides what is real, what matters, and how it ranks, which is what it is not.

   Anything critical is reported the day it is found rather than held for the report. If a finding means testing should pause, we call.

   Findings are validated before they reach the report. An unvalidated list of potential issues is scanner output, and triaging it is work we are supposed to be removing.

5. 05

   The report

   Within the delivery window

   An executive summary in language a non-technical reader can act on. Scope, method, access level and dates, stated precisely enough to compare against an audit document. Findings with reproduction steps, contextual impact and a remediation direction.

   Plus a redacted one-page summary you can send to customers and prospects, so the full report does not have to circulate. It is a description of how to attack you, and its distribution list should be short.

   Severity is ordered by exploitability and business impact rather than by score alone. A report ranked purely by CVSS has handed the prioritization back to you.

6. 06

   Remediation and retest

   When you are ready

   One retest is included. You fix, we verify, and the verification is dated and recorded.

   That closed-loop record is usually worth more to the audit than the original findings, because it demonstrates the vulnerability management control functioning rather than only the existence of a vulnerability.

   Anything not fixed gets a documented risk acceptance with a named owner and a review date. Written down, it is defensible. Undocumented, it is indistinguishable from an oversight.

More on the scoping decisions in how to scope a penetration test, and on the report itself in what a good report contains.