Brazil software supply chain and AI security rules: a 90-day plan

If you build, buy or run software in Brazil, three layers of rules decide most of what your security programme has to prove. The General Data Protection Law (Lei Geral de Proteção de Dados, LGPD) and the 2024 Security Incident Communication Regulation of the national data protection authority (ANPD) set the baseline for anyone handling personal data, including a three business day clock to report a serious incident. For banks, payment institutions and other entities authorised by the Central Bank, CMN Resolution 4,893 and BCB Resolution 85, both rewritten in December 2025, now spell out vulnerability correction, annual independent penetration tests, end to end traceability and hard isolation of the Pix environment, with adaptation due by 1 March 2026. On top of that sit the National Cybersecurity Policy of December 2023 and an AI bill, PL 2338/2023, that the Senate approved and that is still in a special committee of the Chamber of Deputies.

This guide reads each rule from its primary text, maps it to the evidence a supervisor or auditor will ask for, and ends with a 30/60/90-day plan that works with whatever tools you already have. It is a practical reading of public documents, not legal advice. Where a rule needs interpretation for your entity, take it to counsel or to your supervisor.

Key takeaways

• LGPD (Law 13,709/2018) reaches processing in Brazil, aimed at people in Brazil, or of data collected there. Article 46 requires security measures from design onward; article 48 requires incident communication.
• Resolution CD/ANPD 15/2024 sets the clock: three business days to notify the ANPD and data subjects, and a five-year incident record.
• CMN Resolution 4,893/2021, as amended by CMN 5,274 of 18 December 2025, now lists fourteen control areas, Pix and STR safeguards and annual independent penetration tests, with adaptation due by 1 March 2026.
• BCB Resolution 85/2021, amended in parallel by BCB 538/2025, applies the same model to payment institutions and other BCB-regulated firms.
• Pix security (article 3-A) means MFA for administrative access, an isolated Pix environment, credential and certificate monitoring, integrity checks before signing, and no supplier access to signing keys.
• Decree 11,856/2023 created the National Cybersecurity Policy and its committee; it sets direction, not duties on private firms.
• PL 2338/2023, the AI bill, passed the Senate and on 26 October 2026 awaited the rapporteur's opinion in a Chamber special committee. It is not law.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis, SCA and vulnerability management with EPSS and KEV, reachability analysis, autonomous remediation (ships switched off), policies and gates, license compliance, CSAF and VEX upload, the Compliance and GRC suite with a Brazil LGPD framework page, TPRM SBOM requests, Trust Center, AI-BOM discovery, AI-SPM, AI Gateway, MCP Guardrail, agent identity, Package Firewall, the CLI and local runner, Zero AI mode, bring your own model, and private VPC, on-prem and air-gapped deployment.

Who this applies to in Brazil

Brazil has no single horizontal software security statute. Obligations stack by who supervises you, and most organisations that handle money or personal data sit under at least two layers.

Insurers, pension funds and securities market participants have their own supervisors (SUSEP, PREVIC and CVM) and rules, outside this guide's scope; LGPD applies to all of them.

For foreign software companies: LGPD article 3 can reach you directly, and the Central Bank rules arrive in your contract the day a Brazilian bank or payment institution buys from you.

The rules, regulator by regulator

LGPD: the General Data Protection Law (Law 13,709/2018)

The LGPD is the horizontal baseline. The provisions that matter most for software and security teams are these:

• Article 3 (scope). The law applies to any processing carried out in Brazil, processing aimed at offering goods or services to individuals located in Brazil, or processing of data collected in Brazil.
• Article 6 (principles). Security (VII), prevention (VIII) and accountability (X) require agents to demonstrate effective measures.
• Article 33 (international transfer). Personal data may leave Brazil only in the cases the article lists.
• Article 37 (records). Controllers and processors must keep records of the processing operations they carry out.
• Article 46 (security). Agents must adopt security, technical and administrative measures able to protect personal data from unauthorised access and from accidental or unlawful destruction, loss, alteration, communication or dissemination. Paragraph 2 says these measures must be observed from the design phase of the product or service through its execution.
• Article 48 (incident communication). The controller must communicate to the ANPD and to the data subject any security incident that may create relevant risk or damage to data subjects. Paragraph 1 lists the minimum content, including the data and data subjects affected, the security measures used, the risks and the mitigation taken.
• Article 49 (systems). Systems used to process personal data must be structured to meet security requirements, good practice and governance standards.
• Article 52 (sanctions). Sanctions run from warnings to a fine of up to 2% of the group's revenue in Brazil in its last fiscal year, excluding taxes, capped at R$50 million per infraction, and suspension of processing.

Status today: in force. The sanctions articles have applied since 1 August 2021 (article 65, item I-A). The supervisor is the ANPD; article 55-A, as amended by Law 15,352 of 2026, now names it the National Data Protection Agency (Agência Nacional de Proteção de Dados), a special autarchy linked to the Ministry of Justice and Public Security.

ANPD Security Incident Communication Regulation (Resolution CD/ANPD No. 15/2024)

The ANPD's Board of Directors approved the Regulamento de Comunicação de Incidente de Segurança through Resolution CD/ANPD No. 15 of 24 April 2024, published in the Official Gazette on 26 April 2024. It is the rule that turns LGPD article 48 into an operational duty.

• What counts (article 5). An incident must be communicated when it may cause relevant risk or damage to data subjects. That is the case when it can significantly affect data subjects' interests and fundamental rights and also involves at least one of six criteria: sensitive data; data of children, adolescents or elderly people; financial data; authentication data for systems; data protected by legal, judicial or professional secrecy; or data at large scale.
• The clock (articles 6 and 9). The controller communicates the incident to the ANPD within three business days, unless a specific law sets another period, counted from when it became aware that the incident affected personal data. Affected data subjects are told within the same three business days, and the controller then files a declaration that it has done so.
• Supplementing (article 6, paragraph 3). Information not available at the first communication can be added, with justification, within twenty business days of the communication.
• The record (article 10). The controller keeps a record of every security incident, including those not communicated to the ANPD, for at least five years from the date of the record.
• Small agents. For small processing agents under Resolution CD/ANPD 2/2022, the deadlines in articles 6 and 9 are doubled.

Status today: in force since its publication in April 2024.

CMN Resolution 4,893/2021 as amended by CMN Resolution 5,274/2025

This is the National Monetary Council's rule on cybersecurity policy and on contracting data processing, storage and cloud services, for institutions the Central Bank authorises to operate. It replaced CMN Resolutions 4,658/2018 and 4,752/2019 from 1 July 2021, and it is in force.

The original text already required a cybersecurity policy (article 2), an incident response plan (article 6) with an annual report (article 8), due diligence on relevant cloud providers (article 12), notice of relevant contracts to the BCB (article 15), conditions for services abroad (article 16), contract clauses (article 17), crisis communication (article 20) and five-year retention of core documents (article 23).

CMN Resolution 5,274 of 18 December 2025, published in the Official Gazette (DOU) on 22 December 2025 and in force on publication, rewrote the core. Institutions already operating had until 1 March 2026 to adapt. The changes that touch software directly:

• Article 3, paragraph 2: fourteen minimum control areas. Authentication; cryptography; intrusion prevention and detection; leakage prevention; protection against malicious software; traceability; backup management; assessment and correction of vulnerabilities in computing resources and information systems (item VIII); access control; secure configuration profiles (item X); network protection; digital certificate management (item XII); security requirements for integrating information systems through electronic interfaces (item XIII, which covers APIs); and cyber intelligence, including monitoring the internet, the deep web, the dark web and private messaging groups for information about the institution (item XIV).
• Article 3, paragraph 3. These controls apply to secure information system development and to the adoption of new technologies.
• Article 3, paragraph 6. The institution must verify secure development, where applicable, for systems it acquires or that third-party providers develop, when they run on the institution's own computing resources. This is the clause that pulls bought software into the secure development duty.
• Article 3, paragraph 7. Traceability means end to end audit trails, log definitions that reveal processing failures or atypical behaviour, retention periods by processing type, and secure retention of the trails.
• Article 3, paragraph 8. Vulnerability assessment and correction must include periodic tests and analyses to detect vulnerabilities in information systems, periodic scans for devices improperly connected to the corporate network, periodic analyses of technology resources, penetration tests, and timely correction of identified vulnerabilities (item V, "correção tempestiva").
• Article 3, paragraphs 9 and 10. Periodic review of access permissions, especially for outsourced staff, MFA for remote access, life cycle management of computing resources, and regular application of security fixes.
• Article 3-A: Pix and STR. For electronic communication on the RSFN: multifactor authentication for administrative access to the Pix and STR environments; physical and logical isolation of each environment, with a dedicated instance when cloud services are used; monitoring of credentials and digital certificates, especially those used in the Instant Payment System (SPI); end to end integrity validation of transactions before the associated messages are digitally signed; and a ban on third-party providers accessing the private keys used to sign messages. Institutions connected to authorised financial market systems must also run fraud prevention, detection and response controls.
• Article 22-A: penetration tests. At least annual, run with independence and impartiality by a specialised person or firm the institution hires (internal teams may test as well), with documented results, including vulnerabilities found and the action plans to fix them.
• Article 22-B. Electronic communication services on the RSFN, including message processing within the National Financial System and the Brazilian Payment System, count as relevant services for the cloud and processing contracting rules, however the connection is made.
• Article 23, item X. Penetration test results and correction plans must be kept available to the BCB for five years from the date of the test.

BCB Resolution 85/2021 as amended

BCB Resolution 85 of 8 April 2021 applies the same structure to payment institutions, securities brokers and distributors and the other firms the Central Bank itself regulates. It took effect on 1 August 2021, replacing parts of Circular 3,909/2018 and all of Circular 3,969/2019. BCB Resolution 368/2024 broadened its scope and wording from 1 March 2024. BCB Resolution 538 of 18 December 2025, published on 22 December 2025 with the same 1 March 2026 adaptation date, inserted the same fourteen control areas, the Pix and STR article 3-A, the penetration test article 22-A, the RSFN article 22-B and the five-year retention of test results that CMN 5,274 inserted into CMN 4,893. BCB Resolution 552 of 3 March 2026 then amended its heading and article 1 to bring virtual asset service providers authorised by the BCB into scope. It is in force.

Payment institutions and fintechs should cite this resolution rather than CMN 4,893; the obligations line up almost clause for clause.

Pix security rules

There is no single "Pix security law". The security duties sit in three places:

1. The cybersecurity resolutions. Article 3-A of CMN 4,893 and of BCB 85, described above, is now the binding baseline for the Pix environment: multifactor administrative access, isolation, credential and certificate monitoring, end to end integrity before signing, and no third-party access to signing keys.
2. The Pix regulation. The Pix Regulation, approved by BCB Resolution 1 of 12 August 2020, sets participant duties, including the Special Return Mechanism (Mecanismo Especial de Devolução). It is amended often; BCB Resolution 493 of 28 August 2025, for example, added a value recovery functionality that became mandatory for transactional account providers and special settlement participants from 2 February 2026, and BCB Resolution 597 of 30 September 2026 amended participant duties again. Check the version in force on the BCB site rather than relying on any summary, including this one.
3. The BCB's technical manuals. Article 3-A's sole paragraph requires compliance with all RSFN technical requirements in the SFN Service Catalogue, the SFN Network Manual and the SFN Security Manual published by the BCB.

For software teams: the systems that build, sign and send Pix messages must be inventoried, isolated, patched on time, and kept away from any supplier who could reach the signing keys.

National Cybersecurity Policy (Decree 11,856/2023)

Decree 11,856 of 26 December 2023, published in the Official Gazette on 27 December 2023, established the National Cybersecurity Policy (Política Nacional de Cibersegurança, PNCiber) and created the National Cybersecurity Committee (Comitê Nacional de Cibersegurança, CNCiber), which brings together sixteen federal bodies (among them the Central Bank and Anatel) with three representatives each from civil society, scientific and technological institutions, and business. The Institutional Security Office of the Presidency (GSI/PR) chairs the committee and runs its executive secretariat.

The policy sets seven principles, among them preventing incidents and attacks, particularly against critical national infrastructure and essential services, and the resilience of public and private organisations, plus objectives that include developing regulation and oversight mechanisms. Its instruments are a National Cybersecurity Strategy and a National Cybersecurity Plan. It does not place reporting deadlines or control lists on private companies. Its practical effect today is on federal bodies and on the direction of future regulation. Treat it as context and watch CNCiber outputs for anything that becomes binding.

The AI bill: PL 2338/2023

PL 2338/2023 was presented in the Federal Senate on 3 May 2023 by Senator Rodrigo Pacheco. The Senate's page records that the plenary approved it and that it was sent to the Chamber of Deputies for review on 17 March 2025. On the Chamber's page on 26 October 2026, its status was "awaiting the rapporteur's opinion" in the special committee created to give an opinion on the bill, under priority procedure, with other AI bills being attached to it as recently as September 2026.

It is not law, and its text can still change. What applies to AI in Brazil today is existing law: LGPD for any AI system that processes personal data (including the article 20 right to request review of decisions taken solely on automated processing), consumer law, and the sector rules above for financial institutions, whose cybersecurity controls cover "new technologies" under article 3, paragraph 3 of CMN 4,893.

What the rules ask of software and open source

The table maps each requirement to the evidence a supervisor, auditor or enterprise buyer will usually request.

Two clocks, one pipeline. The ANPD clock runs in business days from awareness that personal data was affected. The BCB expects timely communication of relevant incidents that amount to a crisis, under criteria the institution must document (article 20). Build one incident process with both outputs.

The supplier is now inside the perimeter. Article 3, paragraph 6 asks the institution to verify secure development in software that suppliers build and that runs on its resources. Article 3-A bans supplier access to Pix signing keys. Article 22-B treats RSFN messaging services as relevant services. For a technology provider to a Brazilian bank or payment institution, expect these to appear as contract clauses and audit rights.

SBOMs are not named, but they are the shortest path to the evidence. Timely correction, verifying bought systems and telling the ANPD what an incident touched are all easier with a current component inventory per system.

Location is a contract question. LGPD article 33 allows transfers on listed bases, and CMN 4,893 article 16 allows relevant services abroad if the institution defines countries and regions in advance and the BCB has a cooperation agreement with the foreign supervisor. Neither requires everything to stay in Brazil; both require you to know where it is.

Real public incidents in or affecting Brazil

Public, primary reporting on software supply chain incidents in Brazil is thin; most coverage is press reporting that this guide does not rely on. One incident has a primary account from the affected company's own regulatory filing.

Sinqia Pix environment, August 2025

In a Form 8-K filed with the US Securities and Exchange Commission on 2 September 2025, EVERTEC, Inc. reported that its Brazilian subsidiary Sinqia S.A. identified unauthorised activity on 29 August 2025 in its environment for Pix, the Central Bank's instant payment system. According to the filing, Sinqia halted processing in that environment and engaged outside forensics experts, and the BCB told Sinqia it could not resume processing in the Brazilian Payment System and Pix until the BCB reviewed and approved the actions taken. The company said about R$710 million in unauthorised transactions affecting two of its financial institution customers had passed through the environment, that part had been recovered, and that preliminary forensics indicated the transactions were introduced by exploiting the credentials of legitimate Sinqia IT vendors. It said it had no indication that personal data was compromised.

The filing shows the shape of supplier risk on the payment rails: a provider's environment, credentials held by that provider's own vendors, and a supervisor that can keep the provider disconnected. The December 2025 amendments cover that territory in general terms. This guide draws no conclusion about what any company should have done.

Other 2025 incidents involving Pix connectivity providers were widely reported in the Brazilian press, but this guide could not find the Central Bank's own statements on them and so does not describe them.

The personas who own the problem

CISO. Triggers: a BCB supervisory request, a supplier incident on the payment rails, an ANPD inquiry. Needs one runbook for the ANPD clock and the BCB crisis communication, a defensible measure of how fast exploitable vulnerabilities are corrected, and an owner for each of the fourteen control areas.

Head of AppSec or Product Security. Triggers: the annual independent penetration test, the article 3 paragraph 8 scan cycle, a bank customer's due diligence. Needs component inventories per release, findings ranked by real exposure, and fix evidence that ties a vulnerability to a merged change.

VP or Director of Engineering or Platform. Triggers: Pix environment isolation work, API integration requirements, a release blocked by an open critical. Needs one pipeline step that produces the inventory, applies policy and opens upgrade pull requests.

GRC or regulatory affairs lead. Triggers: inspections testing the 1 March 2026 adaptation, the annual report with a 31 December base date, internal audit. Needs a control map by article and paragraph with dated evidence, five-year retention for the article 23 documents, and an exceptions log.

Procurement and vendor risk owner. Triggers: a new relevant cloud or processing contract (BCB notice within ten days), a renewal, an RSFN connectivity review. Needs article 12 due diligence files, article 17 clauses, supplier SBOMs, and a register of which suppliers touch Pix, STR or personal data.

Data protection officer (encarregado). Triggers: an incident, a data subject request, a new AI use case. Needs records of processing tied to systems, an assessment method that matches Resolution 15/2024, and a transfer mechanism for each foreign processor.

Startup CTO or fintech founder. Often owns all of the above. Needs a policy covering the fourteen areas at sensible depth, an inventory per release, an incident process that can hit three business days, and one place for the evidence.

A practical 30/60/90-day plan

Days 1 to 30: know what you have and set the clocks

1. Decide which rules apply. Use the "Who this applies to" table. Write down every regulator, every resolution number, and whether you are a direct addressee or a supplier to one.
2. List systems that matter. Personal data systems for LGPD; relevant services and the Pix and STR environments for BCB entities. For each, record owner, supplier, hosting country and region, and whether you build it, buy it or both.
3. Build the incident clock. One runbook that covers the ANPD three business day communication, data subject communication, the five-year incident record, and the BCB crisis criteria under article 20. Write down how "business day" is counted and who starts the clock.
4. Generate first inventories. For every system you build, produce a CycloneDX or SPDX SBOM in CI. For bought systems that run on your resources, ask suppliers for an SBOM with a deadline.
5. Map the fourteen control areas. One row per item in CMN 4,893 article 3, paragraph 2, with an owner, the current control and the evidence location.

Template, supplier request for a Brazilian financial institution:

Subject: Component inventory and vulnerability information for [product] [version]
(CMN 4,893 / BCB 85, art. 3 para. 6 and para. 8)

Please provide an SBOM in SPDX or CycloneDX for the version deployed with us.
Include component name, version, supplier, license, package URL, hashes and
dependency relationships including transitive dependencies.
Please also describe:
1. how you correct vulnerabilities and your target times by severity;
2. how and when you will tell us about vulnerabilities and incidents affecting us;
3. whether any of your staff or systems can access our private keys or certificates;
4. the countries and regions where our data is processed and stored.
Deadline: [date].

Days 31 to 60: turn inventory into decisions

1. Match inventories to vulnerabilities. Scan every SBOM against public vulnerability data. Flag known exploited vulnerabilities and high EPSS scores first.
2. Define "timely". Article 3, paragraph 8, item V asks for timely correction but sets no number. Write your own standard, short for known exploited criticals on exposed systems and longer for the rest, and record exceptions with approval. A supervisor will test whether you meet the standard you wrote.
3. Add gates. In CI, stop releases that add a known exploited critical or a disallowed license, and warn on the rest.
4. Check the Pix and STR environments. Confirm isolation, MFA for administrative access, the certificate inventory and that no supplier can reach the signing keys. Record evidence for each sub-item of article 3-A.
5. Inventory AI. List models, AI SDKs in code, inference endpoints, agents and MCP servers, and which agents hold which tool access. Mark which ones process personal data under LGPD.
6. Contracts. For each relevant cloud or processing contract, check the article 17 clauses and that the BCB was notified.

Decision table for open findings:

Days 61 to 90: make it repeatable and auditable

1. Run a tabletop. Simulate a compromised supplier on the payment rails or a vulnerable dependency in a personal data system, and time both the ANPD communication and the BCB crisis call.
2. Prepare the penetration test. Scope the annual independent test under article 22-A, make sure the tester is independent, and decide where results and correction plans will be kept for five years.
3. Close the loop on suppliers. Chase missing SBOMs, add vulnerability disclosure, key access and region clauses to renewals, and record legacy exceptions.
4. Build the evidence pack for each row of the requirements table.
5. Measure. Track inventory coverage of relevant systems, median time to correct exploited vulnerabilities, supplier SBOM response rate, and incidents assessed inside the three business day window.

How Safeguard does this

Everything below comes from Safeguard's offering documentation and docs.safeguard.sh, and every capability named is GA. Safeguard helps a team produce and keep the evidence these rules ask for. It does not make an organisation compliant, and it holds no Brazilian certification, approval or listing.

1. Choose where Safeguard runs. SaaS is multi-region (US, EU and Gov); there is no Brazil region. For teams that need code or data to stay inside their own perimeter, the GA options are private VPC or dedicated tenancy, full on-prem, and fully air-gapped deployment with the AI models running inside the customer's environment and signed offline snapshot delivery. The air-gapped deployment docs describe how signed bundles are verified and how the control plane runs without outbound calls. This matters when you have defined, under CMN 4,893 article 16, where your relevant services may run.
2. Keep source code on your machines if you prefer. The Safeguard CLI (GA) scans a directory, repository, container image or SBOM locally, and the local runner (GA) executes platform scan jobs on your machine, sending only encrypted results. Install with curl -fsSL https://cli.safeguard.sh/install | bash, run safeguard, type /login, then /scan .. In the docs, safeguard scan builds an SBOM and matches it against vulnerability databases, and safeguard validate checks CycloneDX, SPDX and VEX documents you receive from suppliers. Zero AI mode (GA) runs the platform with no LLM in the loop, and bring your own model (GA) lets you use a provider you have already approved.
3. Generate inventories for every relevant system. SBOM generation and analysis (GA) produces SPDX and CycloneDX from connected repositories, container registries and uploaded manifests, with scanning triggers on push or on a schedule, as the Generate SBOM docs describe. That is the inventory behind an LGPD article 48 assessment and a CMN 4,893 article 3, paragraph 8 cycle.
4. Turn on the Brazil LGPD framework page. In Compliance, the Brazil LGPD framework is on unless you switch it off in Compliance › Manage. Each product scan checks requirements that Safeguard derived from LGPD articles 6(X), 37, 39 to 42, 46, 48 and 50, using the product's SBOM, for example whether the inventory identifies suppliers and carries a document identity and creation timestamp. The framework adds policy templates written for LGPD on lawful basis and consent, data subject rights, and incident notification and impact assessment. The Compliance and GRC suite (GA) keeps controls, evidence, tests, questionnaires, risks and vendors in one place. Safeguard has no framework page for the CMN or BCB resolutions; map those articles yourself as custom controls or through your existing control set.
5. Rank and fix vulnerabilities. SCA with deep transitive dependency scanning (GA) and vulnerability management with EPSS and CISA KEV enrichment (GA) give you the list. Reachability analysis (GA) ranks the vulnerable code paths your application actually calls, which helps you show "timely correction" with work in the right order. Autonomous remediation (GA) opens tested, policy gated upgrade pull requests, single or in bulk. It ships switched off, with every category set to Manual, so your team chooses what runs on its own.
6. Gate releases. Policies, gates and guardrails (GA) evaluate scan results that combine SBOM, vulnerability, license and reachability data. Gate actions are Block, Warn and Notify, and approvals are handled through exceptions. Policies can be written in plain English. License compliance (GA) covers SPDX expressions and attribution.
7. Collect supplier SBOMs. In the Third-Party Risk Manager (GA), SBOM requests go to one vendor or many, with a deadline, status tracking, reminders, format and completeness validation, an automatic vulnerability scan on receipt, and a revision request if the SBOM falls short. CSAF and VEX upload (GA) lets suppliers' exploitability statements sit next to findings. This is evidence for CMN 4,893 article 3, paragraph 6, where you verify secure development in software suppliers build.
8. Stop risky packages at install. Package Firewall (GA) is an install-time proxy for npm and pip that blocks malicious, typosquatted and dependency-confusion packages before they reach a build.
9. Inventory and govern AI. AI-BOM discovery (GA) finds AI SDK imports, model files, prompts, notebooks, MCP server configuration, managed inference endpoints, vector stores and agents and assembles them into an AI-BOM. AI-SPM (GA) scans model artifacts. AI Gateway (GA) evaluates LLM interactions against prompt injection, jailbreak and PII egress guardrails, and its monitor mode shows what a policy would do before you decide on enforcement. MCP Guardrail (GA) generates guardrail proxy URLs for MCP servers, and agent identity (GA) tracks which agent holds what access, at what level. Together they give the DPO and the CISO an AI inventory today, whatever the final shape of PL 2338/2023.
10. Answer customers once. Trust Center (GA) publishes your security posture and answers questionnaires, which helps a software supplier facing Brazilian bank and payment institution due diligence. Safeguard's own posture wording is "SOC 2 Type II audit in progress" and "designed for FedRAMP High".

What Safeguard does not do

• It does not communicate incidents for you. The ANPD communication, data subject notices and BCB crisis communications are your organisation's duty. Safeguard can hold the policy, the incident evidence and the component data that feed a communication; a person decides and files it.
• It has no framework page for CMN 4,893 or BCB 85. The Brazil framework page covers LGPD. The Central Bank resolutions have to be mapped in your own control set.
• It does not perform your independent penetration test. Article 22-A asks for an independent, impartial specialist. Safeguard's scanners and inventories support that work; they are not the independent test.
• It does not isolate your Pix environment or hold your keys. Network isolation, MFA for administrative access and custody of signing keys are architecture and operations decisions you own.
• It has no Brazil SaaS region. If you need everything inside your own environment, use private VPC or dedicated tenancy, on-prem or air-gapped deployment, or the local runner.
• It does not interpret the law or certify you. Framework pages map controls to articles. Whether an article applies to you, and whether your controls are enough, is a question for counsel and your supervisor.

Common mistakes

• Counting the ANPD clock in calendar days, or from the wrong moment. Resolution 15/2024 counts business days, and the clock starts when you become aware that personal data was affected. Write down who starts it.
• Treating 1 March 2026 as a future date. The CMN 5,274 and BCB 538 adaptation period has ended. Inspections can now test the fourteen control areas, the Pix article and the penetration test rule.
• Scoping secure development to code you write. Article 3, paragraph 6 reaches systems suppliers build that run on your resources. Ask for their inventories and their correction process.
• Leaving "timely" undefined. The rule gives no number. If you do not write one down, you cannot show you met it.
• Letting a supplier near the signing keys. Article 3-A, item I(f) bans third-party access to private keys used to sign messages. Check managed service and connectivity contracts.
• Treating PL 2338/2023 as law. It is a bill in the Chamber. LGPD already applies to AI that processes personal data.

FAQ

Does the LGPD apply to foreign software companies?

It can. Article 3 applies the law to processing carried out in Brazil, processing aimed at offering goods or services to people in Brazil, and processing of data collected in Brazil, wherever the company is based. Our post on LGPD's software security implications goes deeper.

How fast must a security incident be reported to the ANPD?

Within three business days of the controller becoming aware that the incident affected personal data, under Resolution CD/ANPD 15/2024, when the incident may cause relevant risk or damage to data subjects. Affected data subjects are also told within three business days.

What did CMN Resolution 5,274/2025 change?

It amended CMN 4,893 to list fourteen minimum control areas, add requirements for Pix and STR environments, require annual independent penetration tests with results kept five years, and treat RSFN messaging services as relevant services. Institutions had until 1 March 2026 to adapt.

Is an SBOM mandatory in Brazil?

No rule in this guide uses the term. In practice, an SBOM is the most direct evidence for timely correction under CMN 4,893 article 3, supplier secure development under paragraph 6, and "which systems were affected" under LGPD article 48.

Does Brazil have an AI law?

Not yet. PL 2338/2023 passed the Senate and was sent to the Chamber of Deputies on 17 March 2025. On 26 October 2026 the Chamber's page showed it awaiting the rapporteur's opinion in a special committee. LGPD already applies to AI systems that process personal data.

Must data be stored in Brazil?

Not as a general rule. LGPD article 33 allows international transfers on listed bases. CMN 4,893 article 16 allows relevant services abroad under conditions, including that the institution defines the countries and regions in advance. Your contracts and your supervisor may set stricter terms.

Can Safeguard run without our code leaving our environment?

Yes. Safeguard's SaaS regions are US, EU and Gov, with no Brazil region. To keep code in your environment, use the local runner (code stays on your machine and only encrypted results are sent), private VPC, on-prem or fully air-gapped deployment, and Zero AI mode if you want no LLM in the loop.

What evidence will the Central Bank usually look for?

The documents CMN 4,893 article 23 keeps on file for five years, which since CMN 5,274 include penetration test results and correction plans. Expect sampling of how vulnerabilities were found and corrected.

Before you fix anything

Every rule in this guide comes back to one question: when a component you ship is vulnerable, how quickly does a correction reach production, and what do you do when no fix exists yet? The section below covers how Safeguard closes both gaps.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session that fixes a lodash CVE in a repository. It reads the finding and advisory, asks before any command that changes something, edits package.json, runs the install and tests with approval, and pushes nothing. That is how a "timely correction" under CMN 4,893 article 3 paragraph 8 becomes a reviewed change with a record.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, and scans from the terminal. For a Brazilian bank or payment institution that will not grant repository access to an outside platform, this is how inventories and findings are produced while source code stays on its own systems.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It shows the kind of scoped agent access a DPO or CISO should inventory before AI agents touch systems that hold personal data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• LGPD, Law 13,709/2018, consolidated text (Planalto)
• Resolution CD/ANPD No. 15/2024, Security Incident Communication Regulation (text reproduction, Legisweb)
• CMN Resolution 4,893/2021, consolidated (Banco Central do Brasil)
• CMN Resolution 5,274/2025 (Banco Central do Brasil)
• BCB Resolution 85/2021, consolidated (Banco Central do Brasil)
• BCB Resolution 538/2025 (Banco Central do Brasil)
• BCB Resolution 552/2026 (Banco Central do Brasil)
• BCB Resolution 1/2020, Pix Regulation, consolidated (Banco Central do Brasil)
• Decree 11,856/2023, National Cybersecurity Policy (Planalto)
• PL 2338/2023 (Federal Senate)
• PL 2338/2023 (Chamber of Deputies)
• EVERTEC, Inc. Form 8-K, 2 September 2025 (SEC EDGAR)
• Safeguard docs: Brazil LGPD framework
• Safeguard docs: Safeguard CLI
• Safeguard docs: Generate SBOM
• Safeguard docs: TPRM SBOM requests
• Safeguard docs: AI-BOM discovery
• Safeguard docs: AI Gateway
• Safeguard docs: Air-gapped deployment
• Safeguard docs: Guardrails and enforcement

Related reading: LGPD implementation steps for a software company, the LGPD evidence binder by article, AI data centres in Canada and Brazil in 2026 and the India edition of this guide.

To try it, download Safeguard at https://safeguard.sh/download and read the documentation at https://docs.safeguard.sh/docs .

Last reviewed: 26 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.