Pentest before launch (or before raising): when to do it, how to scope it, and how it unblocks sales and rounds

Pentest vs. scan: what each one does (and does not do)

A vulnerability scanner and a pentest solve different problems. An automated scanner (DAST, SAST, or dependency analysis tools) matches known signatures, outdated versions, and insecure patterns against your application. It is fast, cheap to repeat, and great for running continuously in the pipeline. What it does not do is reason about your business: it does not understand that a free-plan user should not be able to approve their own transaction, nor that two isolated endpoints can be chained to escalate privilege.

A pentest is human work guided by methodology. A professional reproduces the behavior of a real attacker, combines findings, tests abuse hypotheses, and pursues the business logic flaws that tools do not detect. References like the OWASP Web Security Testing Guide (WSTG), the PTES (Penetration Testing Execution Standard), and NIST SP 800-115 structure that execution in phases: reconnaissance, mapping, exploitation, and post-exploitation.

In practice, the two add up. The scan reduces low-level noise and keeps continuous hygiene between cycles; the pentest delivers the depth that enterprise customers and investors expect to see. For a fintech, the difference is concrete: a scanner flags a missing header, while the pentest demonstrates that an IDOR (Insecure Direct Object Reference) in the API lets you read another customer's statement. Presenting a scan and calling it a pentest is a common mistake that does not pass a serious due diligence.

When to do it: before launch and before raising

The best time for a pentest is when the architecture has stabilized, but before exposing the product to real customers. Testing too early, with features changing every day, produces findings that evaporate on the next deploy; testing too late, already in production with traffic and sensitive data, turns any critical flaw into an incident. The sweet spot is when the core flows (registration, authentication, transaction, integrations) are functionally locked down.

There are two triggers founders and CTOs should not ignore. The first is go-live: before opening public registration, moving production data, or connecting to a banking partner, you want to know that an attacker cannot bypass authentication or manipulate balances. The second is fundraising: technical due diligence from investors and enterprise customers asks, directly, whether there is a recent pentest and how the findings were handled. Coming to the table without that answer delays contracts and rounds.

A pentest is not a one-off event. The ideal is to treat it as a cycle: a baseline test before launch and reassessments after significant architecture changes, new integrations, a change of payment provider, or growth that shifts the threat model. For small teams, tying the pentest to milestones (launch, new round, new large customer, certification) tends to be more sustainable than a rigid calendar.

Scope: web, app, API, cloud, and identity

The scope defines what will be tested and, just as importantly, what is left out. Start with the attack surface. A web application covers the front end and the flows reachable through the browser. A mobile app (Android/iOS) requires analysis of the binary, local storage, and communication with the backend, following the OWASP MASVS/MASTG. The API is, in many fintechs, where the greatest risk lives: the OWASP API Security Top 10 lists classes like Broken Object Level Authorization (BOLA), Broken Authentication, and excessive data exposure that generic scanners tend to miss.

Cloud and identity complete the picture. In AWS, GCP, or Azure environments, the focus falls on IAM configuration, exposed buckets and secrets, network segregation, and excessive privileges on functions and services. Identity covers the authentication and authorization flow: tokens, sessions, password recovery, MFA, and the separation between roles (customer, operator, administrator). For fintech, it is worth prioritizing the money flows and the endpoints that touch personal data under the LGPD.

Also define the knowledge approach. Black-box simulates an external attacker with no prior information; gray-box provides regular-user credentials and some documentation, which usually delivers more coverage per hour; white-box includes access to code and architecture. For most startups, gray-box offers the best cost-effectiveness. Document the environment (preferably a staging faithful to production), test windows, limits (rate limit, sensitive data, third parties), and emergency contacts before starting.

What to expect from the report (and why the retest matters)

A useful pentest report is an engineering document, not a spreadsheet of alerts. It should bring an executive summary readable by non-technical people, the methodology applied (WSTG, PTES, NIST), the exact scope tested, and, for each finding, reproducible evidence: steps, requests, screenshots, and the business impact. Severity must be anchored in an objective criterion, ideally CVSS (Common Vulnerability Scoring System), which standardizes scoring by attack vector, complexity, and impact on confidentiality, integrity, and availability.

Good recommendations are actionable. Instead of 'fix the XSS', the report should indicate where, how to reproduce it, and what the suggested fix is (for example, output encoding in the correct context and a CSP policy). Prioritize by real risk: a critical authorization flaw in an API that exposes customer data comes before a cosmetic issue, even if both appear in the same document. This chain between finding, severity, and action is what turns the report into a remediation backlog.

The retest closes the loop. After the team fixes the issues, the same tester validates each item and issues an updated version, separating 'resolved', 'mitigated', and 'open'. Without a retest, you have a list of problems; with a retest, you have proof they were resolved. It is this retest attestation, not the initial report, that is usually attached to customer security responses and due diligence dossiers.

How the pentest unblocks sales and rounds

For B2B startups and fintechs, security has become a purchasing criterion. Procurement teams and enterprise customers' security teams send security questionnaires, ask for evidence of penetration tests, and inquire about how findings were handled. A recent report with a completed retest answers a good part of these questions at once and shortens the sales cycle, instead of stalling the contract in a round of emails about controls you cannot prove.

In fundraising, the logic is the same. Technical due diligence from investors assesses engineering maturity and risk. Demonstrating an offensive security process, rather than a vague answer, signals that the team understands its own threat model and knows how to fix what it finds. This reduces the perception of risk and avoids valuation discounts or conditions imposed by security gaps discovered late in the process.

There is also the internal effect. The pentest, remediation, and retest cycle builds discipline: the team learns the flaw classes that affect it most, adjusts development practices, and starts treating security as part of the product. For a founder, that means turning a one-time cost into a reusable asset, the report and the attestation that open commercial and investment doors.

Practical checklist

1. 1

   1. Map your attack surface

   List what is exposed: web domains and applications, mobile apps, public and internal APIs, cloud accounts, and identity providers. Mark where money and personal data flow. This inventory is the basis of the scope and avoids testing what does not matter.

2. 2

   2. Define scope, approach, and environment

   Choose the surfaces to test, the approach (black, gray, or white-box), and the environment (ideally a staging faithful to production). Document what is out of scope, the third parties involved, and the critical flows that need special attention.

3. 3

   3. Prepare credentials, data, and access

   Create test users with different roles (customer, operator, admin), sample data, and access to the environment. Agree on test windows, rate-limit thresholds, and a contact channel to stop the test in case of unexpected impact.

4. 4

   4. Align methodology and severity criteria

   Confirm the vendor uses a recognized methodology (OWASP WSTG/MASTG, API Top 10, PTES, NIST SP 800-115) and scores findings with CVSS. Settle the report format and what will be delivered as evidence before starting.

5. 5

   5. Track the execution and critical findings

   Keep a technical point of contact available during the test. For critical findings, request immediate notification, without waiting for the final report, so that flaws exposing data or money can be contained in parallel.

6. 6

   6. Treat the report as a prioritized backlog

   Turn each finding into a task with an owner, a deadline, and a defined fix, prioritizing by severity and business impact. Resolve authorization, authentication, and data exposure first, before cosmetic items.

7. 7

   7. Request the retest and archive the attestation

   After fixing, request the retest to validate each item and issue the final report with updated status. Keep this attestation to answer customer questionnaires and to build the due diligence dossier for rounds.

Frequently asked questions