Mandatory pentesting for Central Bank of Brazil institutions: what BCB 538 and CMN 5,274 require

What changed: an annual pentest went from good practice to obligation

Until 2025, many Brazilian fintechs treated penetration testing as a checklist item for a customer or an auditor: run it when a partner asked, file the PDF, move on. CMN Resolution 5,274/2025 and BCB Resolution 538/2025, published in December 2025, changed that. They update the cybersecurity policy of institutions authorized by the Central Bank of Brazil (the baseline came from CMN Resolution 4,893/2021 and BCB Resolution 85/2021) and give penetration testing its own rule: it must run at least once a year, performed by an independent company or professional, with formal documentation of the results and of the action plans. The compliance deadline for institutions already operating was March 1, 2026.

If your institution passed that date without a documented test, the question is no longer "if" but "when, and with what evidence". If you tested in 2026, the next cycle falls due in 2027 and the supervisor will compare both reports. This guide summarizes what the rules say, what you should still confirm against the official text, how to scope a test with a concrete example, what usually gets a report rejected and how to choose who runs it.

Who is in scope

The resolutions apply to financial and payment institutions authorized to operate by the Central Bank of Brazil: banks, credit unions, securities brokers and dealers, payment institutions, direct credit companies (SCDs), peer-to-peer lending companies (SEPs) and other entities of the National Financial System. CMN 5,274 covers institutions under the National Monetary Council’s regulation; BCB 538 covers payment institutions and others authorized by the Central Bank. The rule depends on the type of authorization, so confirm your exact classification with legal or compliance. Size is not an exemption: it changes the depth of the scope, not whether the test happens.

What the rules require about pentesting

We could not open the official text on the Central Bank’s regulations portal (the page depends on JavaScript). The points below come from analyses by law firms and financial-sector companies quoting the resolutions, and the sources agree on the main items.

• Minimum annual frequency. A pentest must run at least once a year. A relevant change in the environment (cloud migration, new product, new critical integration) justifies a complementary test.
• Independence. Execution belongs to a company or professional independent of whoever built and operates the tested environment. An internal automated scan does not replace the test.
• Formal documentation. Results and action plans for the risks found must be formalized, and the matter should reach the institution’s governance in periodic reports.
• Critical systems in scope. The rules treat RSFN services, including Pix and STR, as critical, and extend controls to systems acquired or developed by third parties. In practice the test must justify its coverage of those interfaces and dependencies.
• Five-year retention. Several sector analyses report that the test documentation and action plans must remain available to the Central Bank for five years. Because we did not verify the article in the official text, treat the period as strong guidance and confirm the exact provision with legal before fixing your internal policy.

Other controls come in the same package and often show up in the test scope: multi-factor authentication for administrative access, tamper-resistant audit trails, certificate and cryptographic key management, periodic vulnerability remediation, isolation of critical networks and stricter rules for contracting cloud services.

What the rule does not do is dictate the report format. Demonstrated exploitation, control mapping and retest are good-practice recommendations that make the document defensible, not clauses we quote as resolution text.

A worked example: scoping a payment institution

The case below is hypothetical and only shows the reasoning. Picture a mid-sized payment institution with a digital wallet in a mobile app, merchant integration APIs, a Pix connection and cloud infrastructure.

Asset	Why it is in scope	Test focus
Mobile app (iOS and Android)	End-customer access to balance and transfers	Authentication, local storage, pinning, limit logic
Transactional and merchant APIs	They move money and expose data	Object-level authorization (BOLA), limits, idempotency, mass assignment
Pix integration / RSFN messaging	Service the rules treat as critical	Network segregation, administrative MFA, message validation
Admin panel and back office	High privilege, target of internal fraud	Access control, audit trail, sessions
Cloud (accounts, IAM, storage, secrets)	Hosts all of the above	Excessive permissions, exposed secrets, network between environments
Third-party software and SaaS	Controls extend to acquired systems	Contract and test authorization, configuration, integration

In this example, a test covering only the corporate website would leave out five of the six rows. That is exactly the kind of gap an auditor finds when cross-checking the scope against the asset inventory. For the APIs, the roadmap in our API pentest guide using the OWASP API Top 10 helps define what to test.

What the regulator and the auditor expect versus what a scanner delivers

What the report must contain	Scanner report	Well-run manual pentest
Independence from whoever builds and operates	Often produced by the same team	External team, with an independence statement
Exploitation evidence	List of possible vulnerabilities	Request/response, reproducible steps and demonstrated impact
Business-logic and authorization flaws	Not detected	Core focus of the test
Chained flaws	Each item in isolation	Attack scenario from initial access to impact
Treatment plan	Generic suggestion	Owner and deadline per finding, ready for the board
Retest	A new scan	Status per finding: fixed, partial, pending, risk accepted
Traceability	A loose PDF	Scope, methodology and evidence archived

The difference between the two columns is covered in detail in scanner, pentest or bug bounty.

What the report must show (in practice)

To survive an internal audit, an external audit or a supervisor request, the report must answer three questions: what was tested, what was found and what was done about it. We recommend, and deliver by default:

1. Scope and rules of engagement that match the asset inventory and the architecture diagram.
2. A named methodology (OWASP WSTG, PTES, NIST SP 800-115).
3. Exploitation evidence per finding, with the business impact described.
4. Regulatory mapping, a table linking each result to the controls in the resolutions (authentication, segregation, vulnerability management, key protection).
5. A treatment plan with owner and deadline, ready for senior management.
6. A documented retest, with date and status per finding.
7. An attestation identifying the independent team and the test period.

Many institutions reuse the same package for PCI DSS. See what the card auditor expects in Pentesting for PCI DSS 4.0.

Suggested timeline: from kickoff to archive

A full cycle fits in roughly eight to twelve weeks, depending on scope. Use this as a starting point:

• Weeks 0 to 1: preparation. Update the asset inventory, name owners, set up test accounts (regular user, merchant, administrator) and confirm what belongs to third parties.
• Weeks 1 to 2: authorizations. Formalize scope, rules of engagement and the authorizations of cloud providers and vendors whose systems will be touched.
• Weeks 2 to 5: execution. Manual testing, with a direct channel for critical findings, which should not wait for the final report.
• Weeks 5 to 6: report. Delivery with evidence, mapping and treatment plan; a walkthrough with technology and risk.
• Weeks 6 to 10: remediation. Teams treat the findings by priority.
• Weeks 10 to 12: retest and closure. Retest per finding, final attestation and archiving of all the material.
• Afterwards: governance. Take the result to the board, record risk-acceptance decisions and keep the dossier somewhere retrievable.

Common reasons for rejection

• Presenting a vulnerability scan as a pentest.
• Hiring the same team that built or operates the system, which compromises independence.
• Testing only the corporate website and leaving out APIs, the mobile app and the back office.
• A scope that does not match the asset inventory.
• A report with no treatment plan and no owners.
• Critical findings with no retest, or "fixed" only with a WAF rule.
• Not archiving the report, action plan and retest evidence in a retrievable way.
• Testing once and forgetting: the cycle is annual.

How to choose who runs it

Ask the proposal for objective answers. Our checklist for hiring a pentest lists ten questions; the ones that weigh most for a regulated institution are:

• Is the team independent of whoever develops and operates your systems?
• Is the test manual? Ask for an anonymized sample report and check for exploitation evidence.
• Does the report include mapping to the Central Bank resolutions and a treatment plan?
• Is the retest included? How many rounds, and within what time window?
• Does the team have experience with financial APIs, mobile apps and cloud?
• How does the vendor protect the data and evidence it collects during the test?
• How will critical findings be handled during execution?

On price, it varies with the number of applications, APIs and the test model (black, grey or white box). Real ranges are in How much does a penetration test cost in 2026. To understand the models, read What is penetration testing.

How Pentest Machine helps

We run manual pentests with a report built for audit: exploitation evidence per finding, mapping to the Central Bank resolutions, a treatment plan and a retest included. If you need to close the 2026 cycle or plan 2027’s, request a proposal: we reply with scope and timeline within one business day.

Frequently asked questions

Is a pentest mandatory for a small fintech?

The rules apply to institutions authorized by the Central Bank within the scope of the resolutions, regardless of size. What changes with size is the scope and depth. Confirm your classification with compliance or legal.

Is a vulnerability scan enough?

No. The rules speak of penetration testing and require independence and formal documentation. The market reading is that the supervisor distinguishes a scanner report from one with documented manual exploitation.

Who can be the independent team?

Companies or professionals with no conflict of interest with the development and operation of the tested system. An internal team that also builds the system tends not to meet the requirement. Keep a record of who ran the test and what link they have to the environment.

How long should I keep the report?

Sector analyses indicate five years for the documentation and action plans. Validate the exact period with legal and write it into your internal retention policy.

Does the test need to cover Pix?

If the institution operates or connects to Pix, STR or RSFN, those services are treated as critical by the rules and should be in scope, or the scope must justify why they are not.

Can I run the pentest once and use the report for two years?

No. The frequency is at least annual, and relevant changes to the environment justify a complementary test. Plan the 2027 cycle now so you do not repeat the 2026 rush.

Does a retest count as another pentest?

No. A retest verifies whether each finding was fixed and closes the treatment cycle. It complements the annual pentest but does not replace it.

Can I test vendors’ systems?

Only with contractual authorization and the provider’s consent. Agree on scope and rules in writing before testing any asset that is not yours, and record it in the report.