The question almost always reaches the CISO, the DPO or the IT manager in the same form. Is it worth contracting a point-in-time pentest or migrating to a continuous model, in the Pentest as a Service — PTaaS format? The answer is not in the product, it is in the context of the operation. A point-in-time pentest serves scenarios well where the goal is to assess a system at a specific moment, generate formal evidence for an audit or validate a delivery. PTaaS serves scenarios where the system is in constant evolution and security needs to keep pace with that evolution week by week.

This article describes how each of the two modalities is structured, what is included in each, in which situations each format makes sense and how to decide between them.

The descriptions below reflect the methodologies we apply. Other providers structure scope, cadence, deliverables and prerequisites differently, and that variation matters when comparing proposals. When evaluating a contract, check in each case the technical standard adopted, what is included in the scope, how the retest is handled and what documentary evidence is generated at the end.

How the point-in-time pentest works

The point-in-time pentest is an offensive assessment conducted within a defined interval, over a previously agreed scope. The test has a beginning, a middle and an end, and at the end a technical report is delivered with the vulnerabilities identified, evidence of exploitation, criticality classification and remediation recommendations.

A well-executed assessment goes beyond the use of automated tools. Targets are tested manually, with custom tooling developed when the context requires it, ensuring precise analysis of each feature of the assessed system. The scope includes not only known vulnerabilities catalogued in public databases, but also flaws specific to the system's context, including business logic and insecure configurations.

Read also: Pentest: what it is, what it is for and why it is essential for your business security.

Execution modalities

The point-in-time pentest is usually executed in one of three modalities, chosen according to the objective of the assessment.

Black-box. The testing team receives minimal information, such as an access address or application link, and there is no access to source code nor interaction with the development team. It is the modality that simulates the perspective of an external attacker with no prior knowledge.

Gray-box. The team receives additional information, such as details about the system and user credentials, but without access to the source code. It balances realism and efficiency, allowing reasonable coverage when there are time or budget constraints.

White-box. The team receives all relevant information, including source code, API documentation and architecture, with direct interaction with the development team. It is the most effective and efficient modality for identifying vulnerabilities, including business logic flaws that would hardly appear in closed tests.

When to contract a point-in-time pentest

The point-in-time pentest is the appropriate choice when:

  • The company needs dated formal evidence for audits, regulatory requirements (LGPD, PCI DSS, ISO 27001, CMN Resolution 4,893/2021, BCB Resolution 85/2021) or due diligence processes;
  • A new system is about to enter production and needs assessment before go-live;
  • There has been a significant change in an application, infrastructure or integration and it is necessary to validate the impact on the security posture;
  • The assessed system has a slow change cycle and does not justify continuous monitoring;
  • The organization is still structuring its testing program and needs a baseline before evaluating more complex formats.

The recommended frequency is at least annual, or after significant changes in the environment. In well-structured engagements, critical vulnerabilities identified during the test are communicated immediately to the client's technical team, even before the final report, so that emergency fixes can be started in parallel. After the fixes, the retest must be foreseen in the scope.

How PTaaS (Pentest as a Service) works

PTaaS is a continuous security testing modality integrated into the client's development cycle. Unlike the point-in-time pentest, PTaaS presupposes systematic monitoring and aims to maintain and progressively raise the level of security over time, and not merely assess the posture at a specific moment.

There is no market standardization for the composition of a PTaaS, and the definition varies considerably between providers. In the model we practice, the service comprises three continuous activities, provided regularly throughout the term of the contract.

Threat Modeling

Threat models triggered by the client, aimed at identifying and mitigating weaknesses originating in the design and architecture decisions of the systems, in whole or in part. The client has monthly hours reserved to engage the consultancy on new projects under development. Threat Modeling allows risks to be addressed while still in the design phase, before implementation.

Continuous Pentest

Penetration tests in short cycles, typically one week, over the increments delivered by the client's team. Each execution verifies the security of the implementation carried out and may require inserting activities into the backlogs to fix the vulnerabilities identified. The tests are supported by direct access to the client's code repositories, which allows execution in white-box modality and the direct correlation between vulnerabilities observed at runtime and the exact points in the code where they reside.

This correlation is what differentiates code-supported continuous pentesting from closed testing models. When a vulnerability is identified, the development team receives not only the description of the problem, but the direct indication of the code excerpt where the flaw resides, significantly reducing remediation time.

Fix validation

After the client applies fixes, retests are carried out to verify the effectiveness of the measures adopted. Validation is included in the service within the weekly hours limit, with no need for new engagements at each remediation cycle.

Technical standard applied

The tests follow the most recent stable version of the OWASP Web Security Testing Guide (WSTG), complemented by verification of the items on the OWASP Top 10 and CWE Top 25 Most Dangerous Software Weaknesses lists in their current versions. Items may be considered not applicable according to the characteristics of the environment, and additional techniques may be included at technical discretion or at the client's request.

Onboarding and maintenance cycle

PTaaS is executed in two sequential phases.

The first is the initial onboarding, with the objective of establishing a security baseline. It includes reconnaissance of the architecture, components and flows of the systems in scope, configuration of access to repositories and necessary credentials, initial Threat Modeling and a comprehensive pentest to map existing vulnerabilities. The duration of the onboarding varies according to the complexity and the number of systems involved.

Once onboarding is concluded, the service enters a continuous maintenance regime. The Threat Modeling, Pentest and Fix validation activities start to occur in short cycles, following the evolution of the systems, with a focus on identifying vulnerabilities introduced by new features and validating the effectiveness of the fixes applied.

Infrastructure scanning

As an optional activity, automated infrastructure scanning is usually offered, on an annual or semiannual basis, with no limit on the number of assets. This activity runs in parallel with the PTaaS core, in previously agreed execution windows.

Access to repositories

Read access to source code repositories is an essential prerequisite of PTaaS. It is what makes the white-box pentest and the correlation between vulnerabilities and code viable. Commonly supported platforms include GitHub, GitLab and Bitbucket. Access must be read-only, with no possibility of commits, changes or deletions. Source code is treated as confidential information, with no permanent storage, no sharing with third parties and no use for any purpose other than the execution of the contracted activities.

When to contract PTaaS

PTaaS makes sense when:

  • The company develops software internally and has frequent release cycles;
  • The operation demands security monitoring integrated into the development cycle, and not isolated assessments;
  • The organization needs permanent and continuous evidence of vulnerability management for audits, due diligence or client requirements;
  • There is an internal team with the capacity to absorb findings over time, applying fixes and triggering retests;
  • Technical leadership seeks not only to identify vulnerabilities, but to progressively reduce the time between the introduction and the detection of new flaws.

The minimum contract duration is typically twelve months. This duration is necessary due to the nature of the service, which requires initial onboarding followed by a continuous maintenance cycle to deliver consistent value. Short contracts do not allow the service to reach the point where most of the value is generated, which is the systematic monitoring phase after the baseline is established.

Penetration testing as a regulatory requirement in the financial sector

Since December 2025, the Brazilian Central Bank's cybersecurity rules treat penetration tests as a minimum control to be addressed by the Cybersecurity Policy. CMN Resolution 5,274, of 12/18/2025, amended CMN Resolution 4,893/2021, applicable to institutions authorized to operate by the BCB. BCB Resolution 538, of the same date, amended BCB Resolution 85/2021, applicable to payment institutions, securities brokerage and distribution companies and foreign exchange brokerage companies. The amendments are mirrored in both texts.

In both rules, vulnerability assessment and remediation now covers, at a minimum, penetration testing (art. 3, § 2, item VIII of CMN Resolution 4,893). The new art. 22-A of this resolution determines that these tests have a minimum annual frequency, be carried out with independence and impartiality by a natural person or specialized company contracted by the institution for that purpose, without prejudice to tests carried out by the institution's own teams, and have the results of their execution documented, especially the vulnerabilities identified and the action plans established for their remediation. Institutions in operation had until March 1, 2026 to make the necessary adaptations.

For those within the scope of these rules, the requirement bears directly on the format decision. What the rule requires is an annual test, documented and conducted with independence and impartiality. A PTaaS contract produces continuous evidence of vulnerability management and serves the requirement for periodic tests and analyses well, but compliance with art. 22-A depends on how the engagement is structured, on who executes it and on how results are consolidated into dated documentation. It is a point to verify in the service design, not to presume from contracting a continuous model.

Our assessment here is technical. The regulatory framework applicable to each institution should be handled with your compliance area or legal counsel.

The differences that matter in practice

Reducing the debate to "continuous vs. point-in-time" oversimplifies the decision. The distinctions that effectively guide the choice are the following.

Depth vs. cadence

The point-in-time pentest allows prolonged immersion in a defined scope. The team has time to map business logic, chain vulnerabilities, explore privilege escalation paths and identify flaws that depend on contextual analysis. PTaaS distributes the effort over time, with shorter windows focused on increments. For systems that change little, the point-in-time format covers more. For systems that change every week, the continuous format covers what the point-in-time cannot: the changes between one assessment and the next.

Relationship with the development team

In a point-in-time pentest in white-box modality, interaction with the development team exists, but it is occasional and limited to the test period. In PTaaS, this interaction is continuous, with Threat Modeling triggered on new projects and Continuous Pentest following increments. The practical consequence is that PTaaS works as a permanent layer of security review alongside the product team.

Type of evidence generated

The point-in-time pentest generates a formal, dated report, with documented scope and methodology. It is the evidence that auditors, regulators and corporate clients expect to see in due diligence processes. PTaaS generates continuous evidence of vulnerability management, which meets requirements that demand not only the existence of tests, but the demonstration of a recurring and documented security monitoring practice.

Contractual model

The point-in-time pentest is contracted per project, with closed scope and defined deadline. PTaaS is contracted for a minimum term of twelve months, with weekly hours allocated and activities distributed in cycles. In companies with few critical assets and slow change, the point-in-time format tends to be more efficient. In companies with active development and multiple releases, PTaaS dilutes the unit cost per test and reduces the overhead of recurring contracting.

How to decide

The questions below are usually sufficient to guide the choice.

  1. What is the trigger for contracting? If the objective is to meet a specific regulatory requirement, validate a delivery before production or generate a formal report for an audit, the point-in-time pentest delivers the expected artifact. If the objective is to establish a continuous practice of security validation in the development cycle, PTaaS is the appropriate format.
  2. How often do critical assets change? Weekly or daily releases justify a discussion about PTaaS. Annual or semiannual changes rarely require continuous testing.
  3. Can the internal team absorb findings continuously? Without agile remediation capacity, PTaaS turns into accumulated backlog. The point-in-time pentest, with volume controlled per window, tends to be more realistic for teams that are still structuring their vulnerability management process.
  4. What is the expectation regarding integration with development? If the objective is to have security present from the Threat Modeling of new projects through to the validation of each increment, PTaaS delivers that integration. If the objective is an independent assessment at defined moments, the point-in-time format serves.
  5. Is there a horizon for a twelve-month contract? The minimum PTaaS duration is not a contractual detail, it is a technical consequence of the service. Companies that cannot commit to twelve months should start with the point-in-time pentest and structure the program before migrating to the continuous model.

The two models are not mutually exclusive

Point-in-time pentest and PTaaS do not compete with each other. They serve different objectives at different moments of the company's security program. Mature organizations frequently combine both formats: PTaaS gives rhythm to the security validation cycle during development, and the point-in-time pentest delivers depth at specific moments, such as regulatory audits, critical product launches or independent assessments requested by clients and investors.

The correct question for an IT manager or a CISO is not "which model is better". It is "which combination meets the company's operational reality, the applicable regulatory requirement and the capacity of the internal team".

For companies still structuring their testing program, the starting point is usually the point-in-time pentest in white-box modality, with frequency defined according to the criticality of the systems. For companies with active development and a requirement to continuously demonstrate security management, PTaaS offers the appropriate format to integrate security into the product cycle.

BrownPipe has worked since 2012 with pentesting and data protection, offering both point-in-time pentests in black-box, gray-box and white-box modalities and PTaaS structured around Threat Modeling, Continuous Pentest and Fix validation, always supported by the OWASP standard. If you want to discuss the specific scenario of your operation and understand which format best serves your context, get in touch.