WardizonWARDIZON
← All resources
Regulation · Banco Central

The annual cybersecurity report, and the date nobody watches

Art. 8º of Resolução CMN 4.893 and BCB 85 gained a fifth item. The deadline that decides whether it has content is not 31 March: it is 31 December.

· 9 min read

Every year, by 31 March, the board of a Brazilian institution authorized by the Banco Central receives a report on the implementation of its action and incident-response plan. That is art. 8º of Resolução CMN nº 4.893, and art. 8º of Resolução BCB nº 85 for payment institutions. In December 2025 that article gained a new item, and it changed who has to be involved long before March: the report must now carry the results of the penetration tests and the action plans for correcting whatever they find. This piece walks through what art. 8º asks for, shows why the date that really decides is 31 December rather than 31 March, and what an operation built on Wardizon has to have produced before then for the paragraph to exist at all.

Which report this is

Art. 8º requires the institution to produce an annual report on the implementation of the action and incident-response plan of art. 6º, with a base date of 31 December. It is not a general security report: it is the account of one specific plan, which under art. 6º covers the actions to align the organizational and operational structures with the cybersecurity policy, the routines, procedures, controls and technologies used in preventing and responding to incidents, and the area responsible for recording and controlling the effects of relevant incidents.[1]

It has a named recipient. The § 2º requires it to be submitted to the risk committee, where one exists, and presented to the board of directors or, failing that, to the executive board, by 31 March of the year following the base date. And art. 7º requires the institution to designate a director responsible for the cybersecurity policy and for executing the plan. There is a person who signs, and for that person the report is not paperwork: it is the document they answer for.[1]

For anyone selling a security service, that moves the conversation. The counterpart is not the analyst who receives the technical report; it is whoever will have to present a summary to the board in March and does not want to arrive there with a blank line.

The five minimum items of § 1º

The § 1º lists what the report must address, at a minimum. There were four items until December 2025; there are now five:[1]

Item V was added by Resolução CMN nº 5.274 and, on the payment-institution side, by Resolução BCB nº 538 — both published on 18 December 2025, with the same wording. Before it, nothing in art. 8º obliged the report to mention penetration testing at all. Now the test and the correction plan are minimum content.[3][4]

  • The effectiveness of implementing the actions described in art. 6º, sole paragraph, item I.
  • A summary of the results obtained in implementing the routines, procedures, controls and technologies for preventing and responding to incidents.
  • The relevant incidents related to the cyber environment that occurred in the period.
  • The results of the continuity tests, considering unavailability scenarios caused by incidents.
  • The results of the penetration tests and of the periodic tests, scans and analyses for vulnerability detection under art. 3º, § 8º, and the action plans established for their correction.

What item V actually asks for

Item V does not ask for “a pentest”. It points to art. 3º, § 8º, which sets out what vulnerability assessment and correction must cover, at a minimum — five things, of which the penetration test is one:[1][3]

And it points as well to art. 22-A, caput, item III, which requires the results of the execution to be documented, especially any vulnerabilities identified and the action plans established for correcting them. Put the two references together: the report has to say what was tested, what turned up and what was agreed for correction — with a plan, not an intention.[3]

It is worth noticing what is not there. Item V does not require the vulnerabilities to be fixed; it requires the results and the plans. But a report that repeats the same findings year after year, always with a plan and never with a close, tells the board a story — and it is a story the director designated under art. 7º will have to explain.

  • Periodic tests and analyses for detecting vulnerabilities in information systems.
  • Periodic scans to identify devices improperly connected to the corporate network.
  • Periodic analyses of technology resources for vulnerabilities that could compromise the institution's assets.
  • Penetration tests.
  • Timely correction of the vulnerabilities identified.

The date that decides is 31 December

Art. 8º carries two dates and they do different jobs. The base date is 31 December: it bounds the period the report speaks about. The presentation falls by 31 March of the following year: that is the deadline for taking the finished document to the board. Almost all of the market conversation revolves around March, and March is the wrong date to worry about.[1]

Item V asks for the results of the tests in the period. A test run in February does not enter the report for the previous base date — it enters the next one. An institution that reaches 31 December without having tested cannot fill item V afterwards, because what is missing is not a document to be drafted: it is an execution that did not happen inside the period. The real deadline is the end of the base year; March is only the delivery.

The first report that unambiguously carries item V is the one with a base date of 31 December 2026, due by 31 March 2027. The two December 2025 resolutions came into force on publication, but gave institutions already operating until 1 March 2026 to adapt — which leaves open, for the report with a base date of 31 December 2025, a question that belongs to each institution's legal advisers and not to this article. For the 2026 base year there is no such doubt.[3][4]

Where the two regimes are not the same

Art. 8º of BCB 85 is almost the same as 4.893's, and both received item V with identical wording. But two differences decide who the document is taken to and what it measures, and it is worth knowing which of them applies to your client.[1][2]

The first is in § 2º. In 4.893 it has two steps: submission to the risk committee, where one exists, and presentation to the board of directors or the executive board by 31 March. In BCB 85 there is only the second step — presentation to the board, with no risk-committee stage.[1][2]

The second is in item IV. In 4.893 it is the results of the business continuity tests; in BCB 85, the results of the continuity tests of the payment services provided. It is the same idea cut to each kind of institution's activity, and it changes what your client needs to have exercised.[1][2]

What the MSP actually owes

The deliverable art. 8º calls for is not a test: it is a paragraph. Someone will write, in the report the board receives, what was tested in the period, what was found and what is planned for correction. If the MSP hands over an eighty-page technical PDF and nothing else, that paragraph gets written by someone who did not follow the execution — and that is how the summary ends up vague enough to serve nobody.

There is a practical difference between supplying the input and supplying the report item. The input is the list of findings. The item is that list with the execution date, the authorized scope, severity, evidence and the correction plan with an owner and a deadline — which is exactly what art. 22-A, item III, requires to be documented. Delivering the second is more work, and it is what brings the client back the following year.[3]

And there is the retest, which appears in no item and solves the problem raised at the end of the previous section. A finding reopened and verified after the fix turns “we plan to correct” into “we corrected, and here is the verification”. For the director who signs, that is the difference between presenting a plan and presenting a result.

What an operation built on Wardizon produces before December

The period the report covers begins and ends on fixed dates, so everything depends on the execution falling inside it and on there being a record of that. In an operation built on Wardizon, what fixes that marker is the authorization: the Rules of Engagement signed by the client, with the targets, the window, the depth and who approved it. It is the record that answers “when was it tested, and under what authorization” — the first question whoever drafts the item has to settle.[5]

The report delivered to the client carries the MSP's branding with the “Powered by Wardizon” signature, and holds the findings with their evidence, the severity and the remediation guidance. That material is what the action plan with an owner and a deadline is built from, and it is what a retest inside the same RoE closes once the fix is applied. None of it declares compliance on its own — the judgement on residual risk and on what goes to the board belongs to the institution.[6]

The mapping to control areas is what ties each finding to the inventory the institution already keeps, so that the report item is not a loose list of vulnerabilities but something that talks to the rest of the art. 6º plan. The arithmetic of time is simple: if the base year closes on 31 December, the execution, the correction and the retest all have to fit before that.[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. In particular, whether item V applies to the report with a base date of 31 December 2025 turns on a reading of the adaptation deadline that belongs to each institution and its counsel, not to a supplier. The four resolutions cited are published in the Diário Oficial da União and they are short.[1][2][3][4]

An execution inside the base year needs a date and an authorization on the record before it starts: the Rules of Engagement template carries the twelve clauses, the pre-flight checklist and the authorization email to send the institution.