BRAZILIAN CENTRAL BANK · CYBERSECURITY
The December 2025 revision replaced a text of principles with a list of what has to exist, item by item. Payment institutions, securities brokers and dealers and foreign exchange brokers licensed by the Central Bank had until 1 March 2026 to comply. Anyone who did not get there is not behind on good practice: they are out of compliance with a rule in force.
DM11 implements the controls with your team and runs the penetration test the rule requires. Where we do both, the test is carried out by a team independent of the one that implemented, because the rule asks for independence and impartiality and mixing the roles weakens the evidence. Supervision belongs to the Central Bank, and regulatory interpretation is followed by your institution's legal function.
Who runs the work
An in-house penetration testing team, with CEH, CPTE, SYCP and SYES
CISA, information systems auditing
ISO/IEC 27001 Lead Auditor certified by BSI
17 years of governance, risk and compliance
WHAT CHANGED
BCB Resolution 85 of 8 April 2021 set the cybersecurity policy for payment institutions, and BCB Resolution 538, of December 2025, rewrote much of it. The earlier text described what the policy should address; the current one lists what has to be in place, and details each item in a paragraph of its own. The same logic applies to financial institutions, through the National Monetary Council's parallel track.
Art. 3º §2º lists authentication, cryptography, intrusion prevention and detection, data leak prevention, protection against malicious software, traceability, backups, vulnerability assessment and remediation, access controls, secure configuration profiles, network protection, digital certificate management, security for integration through electronic interfaces, and, at number fourteen, cyber intelligence activity, with monitoring of information of interest to the institution across the internet, the deep web and the dark web, as well as private communication groups. Dark web monitoring stopped being an optional service.
Art. 22-A is specific: a minimum annual frequency, execution with independence and impartiality by an individual or a specialist firm engaged for that purpose, and documented results with an action plan for the vulnerabilities found. And it states plainly that this does not displace testing carried out by the institution's own teams, meaning the in-house team does not substitute for the independent test. The result also feeds the annual report.
Art. 3º-A covers communication across the national financial system network and requires multi-factor authentication for administrative access to the Pix and reserve transfer environments, physical and logical isolation of the Pix environment from the institution's other systems, with a dedicated instance where cloud services are contracted, end-to-end transaction integrity validation before signing, and a prohibition on service providers accessing the private keys used to sign messages.
Art. 2º of Resolution 538 gave institutions already operating until that date to make the necessary adaptations. There is no staging by size and no transitional regime. For anyone outside it, the question stopped being when to start and became in what order to close, and what can be documented first.
WHO NEEDS IT
Resolution 538 reaches further than many assume: payment institutions, securities brokers and dealers, and foreign exchange brokers licensed by the Central Bank.
The operation scaled, the technology team kept pace with the product, and security stayed at whatever was achievable. A policy exists because somebody had to approve one, and there is distance between it and what actually runs. It is the most common case, and the quickest to resolve once somebody measures before offering an opinion.
Securities brokers and dealers and foreign exchange brokers are named in the resolution. Some of them treated cybersecurity as a matter of good practice, and now hold an obligation with an article, a deadline and a supervisor attached.
It was written for the old wording, approved by the board and filed. It mentions neither the fourteen controls nor the annual independent test, and it will not start mentioning them on its own. Here the work begins by comparing what exists against what the current wording asks for, and the gap is usually smaller than the initial shock suggests.
STORIES
We change our clients' names with the same confidentiality that will protect your institution later. The names change; the pattern of the problems repeats. Where a client agrees, we give named references in a conversation.
Payment institution
An approved cybersecurity policy existed, well written and general. When the new wording brought the item-by-item list, nobody could say which of the fourteen controls were in place, because the document spoke in objectives rather than in controls with an owner and evidence.
We built the reading in the order of the rule, control by control, requiring evidence for each one marked as met. What genuinely existed got proved; what was intent became a plan with an owner and a date. The policy was rewritten afterwards rather than before, so it reflects the real operation.
Nine of the fourteen already existed and nobody could demonstrate them. The heavy work concentrated on the remaining five, and the board started discussing a short plan instead of an open-ended project.
Securities broker
The institution followed the cybersecurity rules at a distance, understanding them to apply to banks and payment institutions. The current wording names brokerage firms, and the perception changed when the deadline was already close.
We started with scoping, alongside legal, so as not to work on an assumption. Once the reach was settled, we prioritised what could be documented quickly, access control, permission reviews and multi-factor authentication for external access, and left what depends on capital spend for later.
Within a few weeks the institution moved from having no answer to holding a dated plan and evidence of what was already closed, which is the difference between being late and having nothing to show.
Fintech running Pix
The environment communicating with Pix ran on the same infrastructure as the rest of the platform, with administrative access through a single credential and no separation. It worked well, and it was precisely what the new wording came to prohibit.
We separated the Pix environment physically and logically from the rest, with a dedicated instance in the contracted cloud, and implemented multi-factor authentication for administrative access. We also reviewed which service providers had reach to the private keys used to sign messages.
The key review was the finding nobody expected: one provider held access it did not need and nobody remembered granting. Cut before it became a supervisory finding.
HOW WE RUN IT
The rule is prescriptive, so the assessment is too: each control is either met or not met, with evidence attached. A subjective score is useless here, because a supervisor does not ask how mature the institution feels, it asks whether the control exists and asks to see it.
We confirm with legal which resolution reaches the institution, because the payment institution track and the financial institution track are different. Then we read the controls against the real environment, one by one, requiring evidence for every positive answer.
Scope confirmed, with the applicable resolution identified
An assessment of the fourteen controls, with evidence per item
A separate reading of the Pix, reserve transfer and network connection requirements
Gaps in order of risk and effort, with the quick items separated from those needing investment
Delivery milestoneCurrent state measured, with no control marked as met without a document behind it.
We implement with your team what the list asks for: network segmentation protecting production, multi-factor authentication for external access, permission reviews including outsourced staff, secure configuration profiles, traceability with defined retention, private key custody, and the intelligence activity, including deep and dark web monitoring.
Network segmentation and isolation of the critical environments
Multi-factor authentication for external access and for administrative access to Pix and the reserve transfer system
Audit trails with retention defined by type of processing
Cyber intelligence monitoring in operation, with periodic reporting
Delivery milestoneThe highest-risk controls implemented and verified, with the evidence filed.
We run the test art. 22-A asks for, with a team independent of whoever implemented. A declared methodology, a documented result, and an action plan for every vulnerability found, in the form the annual report will have to cite.
A penetration test with a declared scope and methodology
A report with the vulnerabilities and the criticality of each
A remediation action plan, with an owner and a date
A retest of the fixes, so the evidence closes the loop
Delivery milestoneTest executed by an independent team, with a documented action plan.
We organise what the annual report has to carry, including test results and remediation plans, and set the routine that keeps it alive: who reviews, when, and where the documentation is held for the period the rule requires.
Annual report inputs organised for the reference date
An evidence repository, with a defined retention period
A review routine for the policy and the incident response plan
A calendar for the next cycle, including the following year's test
Delivery milestoneAnnual report ready for the board, with traceable evidence behind every statement.
HOW LONG IT TAKES
We do not publish a standard timeline, because a published timeline turns into a promise. With the regulatory deadline already past, the conversation that matters is not how long the whole thing takes, but what can be closed and documented first. These are the three factors that move the clock most.
An institution already keeping the Pix environment isolated settles art. 3º-A with adjustments. One running everything together faces an architecture change, and that is the longest stretch of the whole project, cloud or no cloud.
An approved but unimplemented document is the most frequent case, and it misleads in both directions. Sometimes the institution is in far better shape than the paperwork suggests, because the team did the work without recording it. Sometimes it is the reverse, and that is a worse thing to discover during supervision.
The financial system network communication service is now treated as relevant for the contracting rules, which pulls those contracts into the cloud requirements, including prior notice to the Central Bank. Revising a contract depends on the supplier, and that tends to be the slowest conversation.
THE RULE REQUIRES SEPARATION
This is the one point on this page where separating the roles is neither our choice nor market good practice: it is written into art. 22-A. The penetration test has to be carried out with independence and impartiality, by an individual or a specialist firm engaged for that purpose, and the text makes clear that tests run by the institution's own teams do not take that place. Where DM11 both implements and tests, the two fronts are run by different teams.
A minimum annual frequency, and the in-house team's test does not substitute
A documented result, with an action plan for every vulnerability
The results and the plans feed the annual report
Where we implement and test, whoever tests is not whoever implemented
FREQUENTLY ASKED
The questions that come up in almost every first meeting, answered straight.
BCB Resolution 85, in its current wording, names payment institutions, securities brokers and dealers, and foreign exchange brokers licensed by the Central Bank. Financial institutions follow the National Monetary Council's track, with an equivalent structure. Scoping is the first thing we confirm, with your legal function, because working on an assumption here is expensive in both directions.
The assessment runs through the fourteen controls and the Pix and reserve transfer requirements, with evidence required for every positive answer. You come away with a picture of the current state, a list of what is missing in order of risk, and what can be documented first.
Comparisons on this subject
See all 13 comparisons