The necessary ones make the site work. The others measure which pages help and which ads bring the people who need DM11. Your choice, and you can revisit it from the footer.
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.
Translation
Before anything else, you need to know which regulatory track applies: payment institutions follow the central bank's own resolutions, financial institutions follow those of the National Monetary Council. The content converges, the texts are not the same, and answering under the wrong resolution is the kind of mistake that only surfaces during an inspection.
| What reaches you | What it means | What changes in the work |
|---|---|---|
| “We need to comply with the resolution” | A request with no scope. It does not say whether the institution is a payment or a financial institution, or which regulatory track applies. | That is the first question. The structure of the work is similar, but the text behind each piece of evidence changes, and the evidence is what the supervisor reads. |
| “Internal audit flagged the policy as out of date” | An audit finding with a response deadline. The policy has to reflect today's operation and carry a recorded approval. | Short work if the operation exists and simply is not written down. Long if the policy describes a company that no longer exists. |
| “We are about to contract material cloud services” | Contracting with its own rules: prior notice, contractual requirements and an exit plan. | It jumps the queue, because it has its own deadline and blocks the contract. Doing it after signing means doing it twice. |
| “We have never run a penetration test” | An annual obligation, with independence and impartiality on the part of whoever runs it. | Whoever implemented the control cannot test it. That decides who you hire, and DM11 says where it cannot go itself. |
| “We missed the 1 March 2026 deadline” | A common situation, and the work does not change because of it. The order does. | Prioritise what the supervisor asks about first and what supports an answer to a query, rather than following the order of the text. |
| “We are a partner of a regulated institution, does this apply to us?” | It usually arrives through a contract rather than the regulator. The institution passes the requirement to whoever supports its service. | The scope is the service provided, not the whole company. Closer to third-party due diligence than to a regulatory programme. |
None of this is price. The regulatory track and the current state of the policy change the effort by orders of magnitude, which is why the conversation starts there.
What recurs
The part almost nobody budgets for is the part that comes back every year. An institution that treats the resolution as a project delivers everything, takes a breath, and is out of compliance again the following year, with an expired policy and a test that was never run.
Senior management
Review and approval on record. A policy untouched since 2021 is the most common finding, and a new date on the cover does not fix it.
Independent third party
A minimum annual frequency, covering the infrastructure and the applications behind the service. The report and the remediation plan are part of the evidence, not just running the test.
The institution
Exercise the plan, not just maintain it. A plan never rehearsed fails the first time it is used, which is exactly the worst moment to find out.
The responsible area
An annual report on how the controls actually behaved, going up to senior management and to audit. It is the document the supervisor asks for first.
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.
SELF-ASSESSMENT
Twenty-one questions: three about scope and eighteen about the controls the rule requires. The full result appears on screen, with a score for each front. It is your own self-assessment, made with our reading of the rule, and not a position of the Central Bank on your institution.
The reading for each area, across the three result ranges. It is the same text emailed to those who identify themselves, published here for anyone who wants to understand what the score measures before answering.
Below 50
A low score here usually means the subject exists by custom rather than by designation: somebody in technology answers for it in practice, and no act of governance says so. The effect shows up at the first question from whoever comes to verify, because there is nobody to address it to and no document that answers it. The concrete step is to take a single act to the competent authority designating the accountable director, describing the duties and naming the person in post. Once that is done, the policy review and the assembly of the annual report have an owner and stop depending on a mobilisation.
50 to 79
In this band the formal cycle exists and does not close. The two patterns we see most are a policy reviewed by calendar, without an item by item comparison against the wording in force, and a report presented without the cited evidence being retrievable afterwards. What resolves it is simple, repetitive work: a table linking each statement in the report to the document behind it, with the file's location. Until that link exists, every annual cycle restarts from zero and consumes more time than it should.
80 or above
Formal governance is in place. What still slips in this band is the lag between the review and a change in wording: a policy reviewed in January and a rule amended in March produces a document that was correct on the day and out of date on reading. It is worth scheduling a short check at every relevant publication, recording that it was done even when nothing changes. The record that nothing changed is what demonstrates monitoring, and it is precisely what almost nobody keeps.
Below 50
Access is where the distance between what people believe and what exists tends to be greatest, because the exception does not appear in the inventory of whoever created it. The route with the best return is to map every path in from outside, including old VPNs, cloud consoles, supplier support tools and service accounts, and only then decide where the second factor goes. Doing it the other way round protects the main path and leaves open what nobody remembered. The permission review comes next, starting with people who no longer work here.
50 to 79
An intermediate score in access almost always means good coverage with outsourced staff left out. The rule names permission reviews for outsourced staff expressly, and that is where the cycle stops: the contract ends, the badge comes back, the account stays. The concrete step is to cross the list of active contracts against the list of active accounts and record what gets revoked, with a date and an owner. That cross-check usually reveals more than any new tool.
80 or above
Coverage is demonstrable. The point of attention here stops being the rule and becomes the authorised exception: emergency access, integration accounts and credentials shared by a legacy system survive the best policy when nobody records them as exceptions. Keep a short list of them, with a justification, a deadline and a compensating control. A documented exception is defensible; an exception nobody mapped is what surfaces late.
Below 50
This is the slowest front to recover later and the one that causes the least trouble day to day, because a flat network and scattered logs do not get in the operation's way. The greatest effect of a low score here is not regulatory, it is operational: on the day of an incident, with no segmentation and no reliable trail, nobody can say what was reached. Start by separating production from the rest and deciding a retention period by type of processing, even if the initial period is conservative. Private key custody belongs to the same front, and the first step is finding out where the keys are today.
50 to 79
Here the pattern is good technique and an absent decision: the logs exist, they sit in three different places and nobody decided how long each type is kept. Accumulated firewall rules show a similar symptom, growing on demand and never shrinking. What closes the gap is a written retention decision by type of processing and a dated review of the rules, with whatever was removed recorded. Neither needs a new tool, and both produce evidence immediately.
80 or above
A mature front. What still tends to be missing in this band is protection of the trail itself against alteration, and validation of revoked certificates, the two items almost everyone assumes the tool has solved. It is worth testing for real: ask somebody to try to delete an audit record and see what happens. And check whether the key and certificate inventory has an owner per item, and not just an expiry date.
Below 50
Two different things fall into this score, and they are worth separating. Detection with no reader produces a record, not detection: if the alert arrives and nobody has a duty to look, the control does not exist in practice. Cyber intelligence activity is the fourteenth item on the list of controls and is usually the most forgotten, because nobody associates it with network security. The first step is to define who reads what and how quickly it escalates, before discussing which tool comes in.
50 to 79
In this band coverage is partial and almost always unknown: you know what the tool detects and you do not know what it leaves out. Informal escalation is the other symptom, working while the right person is available and failing on a public holiday. The next step is to map coverage against the environments supporting critical processes and to write the escalation path with a name, a channel and a deadline. On the intelligence side, in-house monitoring counts: what the rule asks for is regularity and somebody who acts, not a supplier.
80 or above
Detection is watched and intelligence is running. What sustains this score over time is the record of what was done with each finding, rather than the volume of alerts. Keep what turned into action, what was dismissed and why, because that series is what demonstrates the control operates. It is worth reviewing coverage whenever a new environment comes in, which is when the gap reappears without warning.
Below 50
A response plan that lives as a paragraph inside the policy does not survive the first real incident, because at the moment it happens nobody goes looking for the policy. The hardest part is not the technical side, it is the communication: who speaks to the customer, who speaks to the supervisor, with what wording and how quickly. Write the roles and the playbook for a single type of incident first, the most likely one in your environment, and record the next occurrence handled, however small. A history of occurrences is what proves the plan operates, and it only builds over time.
50 to 79
A plan written and never exercised is an assumption about how people would react under pressure. A short tabletop exercise, with the right people in the room, reveals more gaps than any review of the text. On the communication side, what is usually missing is the template approved in advance: a statement reviewed by legal while nobody is under pressure is worth more than a handsome flowchart. Formal dealings with the supervisor always belong to the institution itself, and that is exactly why they need to be agreed beforehand.
80 or above
The plan is exercised and communication is defined. What sets this band apart is the aftermath: every relevant occurrence should change something, a control, a playbook or a training session, and that change needs to be recorded. The question that reveals maturity is simple, what changed after the last incident. It is worth revisiting the statement templates when the product or the customer base changes, because approved wording ages along with the operation.
Below 50
This is the most contractual domain in the rule and the slowest to resolve, because every fix depends on a third party agreeing. A low score here usually means nobody ever classified what counts as a relevant service, and without that classification there is no way to know which contracts need security requirements or which engagements required prior notice. Start with the list of who processes, stores or hosts your data, with each one's role, before opening any contract. Involve compliance and legal from the first meeting, because half the answers sit with them.
50 to 79
In this band the list exists and has aged, or the clauses vary from contract to contract depending on who negotiated at the time. One caution before concluding that prior notice was not given: whoever answers this assessment is usually from technology, and the record of those notices usually lives in compliance or legal. Confirm before treating it as a gap. The next step is to standardise the security annex in the contracts and define who updates the list when a new supplier comes in.
80 or above
Contracting is under control. The point of attention in this band is the financial system network communication service, which came to be treated as relevant and was not always reclassified in lists drawn up before that. Check whether it entered yours, and whether the corresponding contract carries the same requirements as the other relevant services. It is also worth checking the exit: a supplier that ends a contract while keeping access or keeping data is the quietest finding on this front.
Below 50
An automated scan and a penetration test are not the same thing, and the difference shows up precisely in what the rule asks for: an annual frequency, independence from whoever implemented the controls, a documented result and an action plan. A low score here usually comes from one of two scenarios, no test in the period or a test run by the very team that operates the environment. The concrete step is to define the scope and the date of the next test before discussing who runs it, because an undefined scope is what stalls the decision. Worth remembering that no supplier, ourselves included, attests compliance before the Central Bank: what is delivered is the test with independence and the documented result.
50 to 79
The most common intermediate pattern is a test done and a cycle left open: a report delivered, some fixes applied and no retest proving closure. On the vulnerability side, the symptom is a queue with no owner, with deadlines defined on paper and the same list repeating from one report to the next. What closes this is combining a deadline by criticality with somebody responsible for chasing until evidence of closure exists. The retest is the shortest part of the work and the part that most turns a report into proof.
80 or above
A complete cycle, with an independent test and remediation followed through. What sustains this score is the calendar: an annual test is not concluded, it repeats, and the scope has to follow what changed in the environment since the previous one. It is worth recording in writing who ran it and why that person or firm is independent of whoever implemented, because that is the information missing when somebody asks for the evidence months later. Independence is a characteristic of the arrangement, and the one who assesses it in supervision is the Central Bank.
Below 50
A backup that runs and has never been restored measures a routine, not the ability to come back. It is the score that causes the least trouble day to day and weighs most on the worst day, because the discovery happens exactly when there is no alternative. The first step is not a continuity project, it is a real restoration of one system, timed, with the result recorded. That single test usually reveals a dependency no document anticipated.
50 to 79
In this band a plan exists and it was written on perception rather than on measurement. The symptom is the absence of a measured recovery time: you know the data comes back, you do not know how long it takes or whether the critical systems are covered. The concrete step is to choose the two or three processes that genuinely cannot stop and test their restoration against the clock, recording what caused delay. Where it is not yet known which processes are critical, that is the question to settle before any test.
80 or above
Continuity is exercised and restoration is measured. What still slips in this band is protection of the backup itself against alteration and deletion, which is the point where a good plan stops working. Confirm that the copy cannot be deleted by whoever administers the source environment, and that the exercise also covers the scenario in which the main environment is entirely unavailable. Recording the improvements that came out of each exercise is what keeps the evidence alive between one cycle and the next.
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.
It does, considerably. Compliance is not a switch: what changes the conversation with a supervisor is holding an honest picture of the current state, a dated plan, and evidence of what has already been closed. An institution arriving at supervision with a plan in execution is in a different position from one arriving with no answer. That is why we prioritise what can be documented quickly ahead of what depends on investment.
You do, and the rule leaves no margin. Art. 22-A requires a test with a minimum annual frequency, executed with independence and impartiality by an individual or a specialist firm engaged for that purpose, and states that this does not displace tests carried out by the institution's own teams. In other words, the internal test remains valid and remains valuable, and it does not take the place of the independent one.
Two things. The Pix environment needs a dedicated, segregated instance where the service is contracted in the cloud, which is an architecture decision rather than only a contractual one. And the electronic data communication service on the financial system network is now treated as relevant, which brings that contract inside the rules for contracting data processing, storage and cloud computing, including prior notice to the Central Bank and specific requirements where the service is provided abroad.
The fourteenth control on the list covers cyber intelligence activity, including monitoring information of interest to the institution across the internet, the deep web and the dark web, as well as private communication groups. In practice that means looking for leaked credentials, customer data for sale, brand mentions in fraud forums, and material suggesting an attack is being prepared. It is not a tool you switch on and forget: the value lies in somebody reading what surfaces and acting on it.
It helps considerably and it does not substitute. Much of the fourteen controls has a counterpart in Annex A, and the evidence carries over almost intact: access control, logging, third-party management, incident response, backups. What ISO does not supply is what the rule holds that is specific to the financial system: Pix, the reserve transfer system, connection to the financial system network, and the annual test whose independence is required by an article.
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