A Brazilian credit union wants to buy your penetration testing service and asks whether it is allowed to. The answer is not in its procurement policy: it is in Chapter III of Resolução CMN nº 4.893, of 26 February 2021 — and, if the client is a payment institution, in Chapter III of Resolução BCB nº 85, of 8 April 2021, which is the same chapter addressed to someone else. Eight articles almost nobody on the supplier side has read, and they say exactly what the institution must verify before signing, what the contract has to provide for, and how long it has to tell the Banco Central. This piece walks the eight articles as the Diário Oficial publishes them, shows where a penetration testing provider almost certainly lands, and what an operation built on Wardizon can put on the table when the question arrives.
Chapter III, and who it binds
Resolução CMN nº 4.893 covers two things in one text: the cybersecurity policy, and the requirements for contracting data processing, data storage and cloud computing services. Art. 1º addresses it to the institutions authorized to operate by the Banco Central do Brasil, and its sole paragraph expressly excludes payment institutions, which must observe the regulation issued by the Banco Central itself.[1]
That regulation is Resolução BCB nº 85, of 8 April 2021 — same subject, different addressee. And here is the finding that saves a supplier work: Chapter III of the two is the same chapter. Same numbering, arts. 11 to 18, and the text is substantively identical; the difference is that 4.893 says “the institutions referred to in art. 1º” where BCB 85 says “payment institutions”. There are not two sets of requirements to learn.[1][2]
The obligations in those articles belong to the contracting institution, not to the supplier. But each of them is discharged with something you either have or do not have. A supplier who arrives with the answers ready shortens the purchase; one who does not becomes the reason the project stalls in the risk committee, usually without anyone saying so in those words.
What makes a service “relevant”
The chapter only bites when the service is relevant, and the rule publishes no list. Art. 12, § 1º, directs the contracting institution to weigh the criticality of the service and the sensitivity of the data and information to be processed, stored and managed by the contractor, taking into account the classification it makes itself under art. 3º, item V, letter “c”.[1]
Art. 13 defines what counts as cloud computing for the resolution. Three cases, and one is enough:[1]
A penetration testing provider delivered through a browser falls under item III: an application deployed and developed by the provider, executed over the internet, on the provider's own computing resources. On sensitivity, the honest test applies: a list of a financial institution's still-unremediated vulnerabilities, with the evidence behind each one, sits near the top of what that institution holds. The prudent conclusion is to assume the service is relevant — and to remember that the assessment belongs to the institution, not to the supplier. A provider declaring itself non-relevant is not in a position the rule recognizes.
There is one exception to that case-by-case judgment. Art. 22-B, added by Resolução CMN nº 5.274 of 18 December 2025, states that the service provided for electronic data communication on the Rede do Sistema Financeiro Nacional is considered relevant for the purposes of the contracting chapter, regardless of the form of connection. It is the only service the rule classifies on its own.[3]
- Data processing, data storage, network infrastructure and other resources that let the contracting institution deploy or run software.
- Deployment or execution of the institution's own applications on the provider's computing resources.
- Execution, over the internet, of applications deployed or developed by the provider, on the provider's own computing resources.
The eight checks that precede the signature
Art. 12 is the heart of the chapter. Before contracting a relevant service, the institution must adopt procedures covering corporate governance and management practices proportional to the relevance of the service and to the risks — and the verification of the potential supplier's capacity to ensure eight things, named one by one in letters “a” to “h”:[1]
The § 2º closes the point: the procedures, including the information relating to that verification, must be documented. Read from the supplier's side, that means the request arrives in writing and has to be answered in writing. The § 4º adds that the institution itself must hold the resources and competence to manage the contracted service, which is why “trust us, it is secure” fails on the buyer's side even when the buyer wants to buy.[1]
And one paragraph is addressed precisely to whoever delivers software over the internet: § 3º requires that, in the case of art. 13, item III, the institution ensure the provider adopts controls that mitigate the effects of vulnerabilities in the release of new versions of the application. It is a direct question about your release process, put by the rule to your client.[1]
- Compliance with the law and the regulation in force.
- The institution's access to the data and information processed or stored by the provider.
- The confidentiality, integrity, availability and recoverability of that data.
- Adherence to the certifications the institution requires for the service.
- The institution's access to the reports of an independent specialized audit firm contracted by the provider, on the procedures and controls used in delivering the service.
- The provision of information and management resources adequate to monitoring the service.
- The identification and segregation of the institution's clients' data through physical or logical controls.
- The quality of the access controls protecting that data.
The letter that stings
Letter “e” is worth re-reading slowly, because it does not ask what people assume. What the institution must verify is its own access to the reports prepared by an independent specialized audit firm contracted by the service provider, covering the procedures and controls used in delivering the service. The audit is of the supplier, paid for by the supplier, and the client gets to read it.[1]
The letter has a twin in art. 17, item V, letter “b”, which turns that access into a contract clause. So it is not a pleasant line in a questionnaire; it is something the contract has to grant. A supplier who has never commissioned an independent audit of its own controls discovers the requirement mid-negotiation, when there is no longer time to produce one.[1]
This deserves saying plainly, against commercial interest: an MSP that sells security and cannot show an independent assessment of its own controls is asking the client for something it does not do itself. The rule names no certification — it says “independent specialized audit firm” and “procedures and controls used in delivering the service”. Which standard satisfies that is the institution's judgment. Arriving with nothing leaves that judgment with no material.
The nine clauses of art. 17
Art. 17 is the part legal counsel will read. It lists what contracts for relevant services must provide for — nine items, with no licence to pick a few:[1][2]
The sole paragraph covers the case where the Banco Central decrees a resolution regime over the contracting institution. The contract must then give the person in charge of that regime full and unrestricted access to the contracts, the documentation, the stored data, the backups and the access codes. And it must oblige the provider to give at least thirty days' notice of any intention to interrupt the service, accepting a request for a further thirty days — including where the interruption is caused by the client's non-payment. That is the clause commercial teams find out about late.[1]
- The countries and the region within each country where the services may be delivered and the data stored, processed and managed.
- The security measures for transmitting and storing that data.
- Keeping, for the life of the contract, the segregation of data and the access controls protecting client information.
- On termination, transfer of the data to the new provider or to the institution, and its deletion by the replaced company after the transfer and after integrity and availability are confirmed.
- The institution's access to the information evidencing the first three items, to the certifications and audit reports, and to the monitoring resources.
- The provider's obligation to notify any subcontracting of services relevant to the institution.
- Permission for the Banco Central to access the contracts, the documentation, the data, the backups and the access codes.
- The adoption of measures by the institution following a determination of the Banco Central.
- The provider's obligation to keep the institution permanently informed of limitations affecting the service or regulatory compliance.
Two clocks, and they are not the same one
Art. 15 requires the contracting to be communicated to the Banco Central, with the name of the contracted company, the relevant services contracted and, where contracted abroad, the countries and regions. The § 2º sets the term: within ten days after contracting. After, not before. The § 3º extends the same ten days to contract changes that alter that information.[1]
The other clock is art. 16, and it only starts running when the service is delivered abroad. Contracting then requires an information-exchange agreement between the Banco Central and the supervisory authorities of the countries involved, an assurance that the service will not obstruct the Banco Central's work, the countries and regions defined in advance, and business-continuity alternatives. And the § 1º: where no such agreement exists, the institution must request the Banco Central's authorization at least sixty days before contracting. The § 2º further requires assurance that local law does not restrict the institution's or the Banco Central's access to the data.[1]
Second-hand summaries merge the two into “notify the Banco Central in advance”. The text does not say that. The due diligence of art. 12 is prior; the communication of art. 15 is after, within ten days; and the sixty-day authorization exists only where the agreement is missing. For a supplier the consequence is concrete: hosting in Brazil keeps the client on the ten-day clock, and hosting abroad can put the deal in a sixty-day queue before anything is signed.
What an operation built on Wardizon puts on the table
Letter “b” of art. 12 asks for the institution's access to the data the provider processes, and item V of art. 17 turns that into a clause. In an operation built on Wardizon, what bounds that access is the document the rule presupposes without ever describing: the Rules of Engagement signed by the client, stating the targets, the window, the depth and who authorized it. It is the record from which the rest of the question can be answered at all.[4]
Letters “g” and “h” are the most literal of the eight: identification and segregation of the institution's clients' data through physical or logical controls, and the quality of the access controls protecting that data. That is exactly the question a multi-client MSP has to answer about its own platform, and it returns in art. 17, item III, as an obligation for the life of the contract.[5]
The rest of the chapter asks for material, not assurances. The report with its evidence, severity and remediation guidance is what supports letter “f” and the monitoring in item V; the mapping to control areas is what lets the institution tie the contracted service to its own inventory. One thing the platform does not substitute for, though: the independent audit report on the provider's controls, in letter “e”, belongs to the MSP and has to be commissioned by it.[6][7]
What this article is not
This article describes what the resolutions say; it does not replace reading the official texts or the institution's own legal advice. Two limits inside the chapter are worth keeping: art. 14 holds the contracting institution responsible for the reliability, integrity, availability, security and secrecy of the contracted services, so outsourcing does not move that responsibility; and art. 18 lifts arts. 11 to 17 off the contracting of systems operated by clearing houses, by clearing and settlement service providers and by registration or central depository entities. The three resolutions cited are published in the Diário Oficial da União and they are short.[1][2][3]
Letter “b” of art. 12 asks what the institution will be able to reach, and that is settled in writing before anything runs: the Rules of Engagement template carries the twelve clauses, the pre-flight checklist and the authorization email to send the institution.