RNBP Cyberattack: Portugal's Firefighter Register and 60,000 Records

Portugal's civil protection authority, ANEPC, confirmed on 24 October 2026 that the RNBP, the national register of Portuguese firefighters, suffered a cyberattack in which personal data may have been copied. ANEPC suspended the application and warned of follow-on fraud. Firefighters should verify any unexpected request through their own command structure.

The RNBP (Recenseamento Nacional dos Bombeiros Portugueses) is the information and management system ANEPC runs for the register of Portuguese firefighters across the command, active, reserve and honour cadres. The data reported as exposed is unusually dense: national ID card number, tax number, social security number, national health service user number, driving licence, photograph and blood group, all in one record. The president of the Portuguese Firefighters' League (Liga dos Bombeiros Portugueses, LBP) put the register at about 60,000 records. This post works from the Lusa news agency's reporting on ANEPC's internal notice, the ANEPC press note carried in full by Portuguese regional media, and the GDPR texts and Portuguese regulator guidance that govern what happens next. All Portuguese sources are translated by us. ANEPC has not said how the attacker got in, and we do not guess.

What happened

On the morning of Saturday 24 October 2026, Lusa reported that it had seen an ANEPC communication sent to all regional commands and to the officials responsible for the autonomous regions of the Azores and Madeira. In it, ANEPC, which manages the RNBP platform, acknowledged a cyberattack on the register and stated that a copy of the personal data had been made. The communication listed the data fields involved and said ANEPC, the National Cybersecurity Centre (Centro Nacional de Cibersegurança, CNCS) and the Ministry of Internal Administration's National Internal Security Network (Rede Nacional de Segurança Interna, RNSI) had suspended the application immediately.

In the afternoon ANEPC sent a note to newsrooms. Its Algarve Regional Command distributed it to regional media, and Diário de Aveiro and Região Sul published it in full. That note confirms the attack, says personal data of the registered firefighters may have been copied, confirms the suspension, describes work to reinforce the application's security, and gives an email address for the ANEPC data protection officer.

Timeline

All times are as printed by each outlet, Lisbon time (WEST, UTC+1, on 24 October 2026). We list publication times, not the time of the attack, which has not been disclosed.

Is there an official ANEPC text?

We looked for one on 25 October. The prociv.gov.pt home page and its "Notícias e comunicados" page listed nothing about the incident; the most recent items were dated 13 October. The RNBP link on the same site, www.rnbp.prociv.pt/rnbp, listed under "Sites ANEPC", did not respond to our request. That is consistent with the reported suspension but does not prove it. The CNCS website did not load for us (it returned a redirect loop and then an error), and the CNPD website had no news item about the incident.

So the official wording exists, but not on a government web page we could reach. It exists as two documents: the internal notice Lusa saw and quoted, and the press note ANEPC sent to newsrooms, which regional outlets published word for word. This post treats the press note, as carried by Diário de Aveiro and Região Sul, as ANEPC's public statement, and the Lusa quotations as the internal notice.

What the press note says, in translation

Summarised closely from the Portuguese, paragraph by paragraph:

1. ANEPC reports that the RNBP database was the target of a cyberattack in which it "terá sido possível copiar dados pessoais" (it may have been possible to copy personal data) of the firefighters registered in it.
2. After the incident was detected, ANEPC, working with the CNCS and the RNSI of the Ministry of Internal Administration, immediately suspended the RNBP application.
3. Work is under way to reinforce the application's security mechanisms and to protect the personal data held in it.
4. ANEPC sent an internal communication to the Entidades Detentoras dos Corpos de Bombeiros (the bodies, often humanitarian associations or municipalities, that hold and run each fire corps) and to the fire corps themselves, informing them and warning of possible fraud attempts. The communication included a set of procedures to follow.
5. ANEPC asked all firefighters to be doubly careful with unexpected calls, messages or other communications asking them to open links or web pages, disclose personal data or fill in forms.
6. ANEPC states that communications addressed to firefighters, including those to update data or pass on information, always favour institutional channels, through the command structure of each fire corps.
7. It therefore recommends not opening suspicious links, not giving personal data and not filling in surveys or forms after unconfirmed contacts. In case of doubt, firefighters should confirm the communication with their corps' command structure through the usual channels.
8. Data subjects who want more information about the incident and their personal data can contact ANEPC's data protection officer at incidentes.dados@prociv.pt.
9. ANEPC will continue the work needed to strengthen its systems and protect personal data, keeping information security and firefighters' trust in institutional channels as its priority.

Two documents, two wordings

The internal notice and the press note do not say quite the same thing about the copy. Lusa quotes the internal notice as saying the register was attacked, "tendo sido possível efetuar uma cópia dos dados pessoas" (a copy of the personal data having been possible to make; "pessoas" appears as printed, almost certainly a typo for "pessoais"). JN and ECO, carrying Lusa, describe the access and copying as clear in that document.

The press note uses the Portuguese conditional, "terá sido possível copiar", which reads as "it may have been possible to copy". It is a softer, less certain formulation. Neither document gives a record count for the copy.

António Nunes, the LBP president, told Lusa that he did not yet have information on whether data had actually been taken. Lusa set that beside the internal notice, which it described as clear on access and copying. Readers should hold both: the operator's own internal text says a copy was made; its public text says one may have been made.

What is still unknown

• When the intrusion happened, how long it lasted and when ANEPC detected it.
• How the attacker got in. No vulnerability, CVE, credential, supplier or component has been named.
• How many records were copied, and whether every field was copied for every record.
• Whether any group has claimed the attack. We found no claim in the reporting we read.
• Whether the data has been published, sold or used.
• Whether ANEPC has notified the CNPD, Portugal's data protection authority, and whether it will write to each registered firefighter.
• When the RNBP will come back, and what will change in it.

The 60,000 figure

The number in this post's title comes from the firefighters' league, not from ANEPC. Lusa reports that António Nunes said the RNBP application has about 60,000 records ("cerca de 60 mil registos"). Neither the internal notice as quoted nor the press note gives a count.

Treat it carefully:

• It is a size of the register, not a count of victims. Postal notes that the number does not show how many people actually had data compromised.
• Records are not necessarily people. The register covers command, active, reserve and honour cadres. Whether former members, honour cadre members or duplicate entries sit in that number has not been explained.
• Some headlines go further than the source. Diário de Notícias headlined "dados pessoais de 60 mil bombeiros" (personal data of 60,000 firefighters). The Lusa text it carries attributes the figure to the register's size, and the LBP is the only named source for it.

We use "about 60,000 records, according to the LBP president" throughout.

Technical details

ANEPC has published no technical description of the intrusion. What follows is what the primary statements and the Lusa reporting on the internal notice say, organised for defenders. We do not speculate on the method.

The system

Data fields

Lusa lists these fields from the ANEPC internal notice. Postal and Portugal Resident carry the same list from Lusa. We give the Portuguese terms as reported.

Not included, per the LBP: bank data. António Nunes told Lusa the application holds personal data but not banking data. ANEPC's statements do not mention bank data either way.

Why the combination matters

One record can join ID card, tax, social security and health numbers with a photograph and contacts: close to a complete identity kit. Health data, here the health subsystem and blood group, is a special category under GDPR Article 9.

What ANEPC has not published

No indicators of compromise, no affected versions, no software or supplier names, no log excerpts, no dates. There is nothing in the public record that ties this incident to any CVE or to any of the other incidents of this autumn, and we make no such link. Lusa contacted ANEPC and the CNCS for details of the measures being taken and had no reply at the time of publication.

The fraud ANEPC warned about

ANEPC's notice names four kinds of fraud. Lusa's report translates them for readers, and so do we:

The data set makes each of these more convincing. A caller who already knows your citizen card number, tax number, address and blood group sounds official. That knowledge proves nothing: it is exactly what was in the register.

Firefighters are also a trusted group. A fraudster holding a photo and full name could pose as a firefighter to the public, not only as ANEPC to a firefighter.

What affected firefighters should do now

These steps follow ANEPC's warning and general good practice for an identity data exposure. None requires you to know whether your record was copied.

1. Verify through your command, every time. ANEPC says genuine communications to firefighters, including data updates, go through the command structure of your corps. If a message, call or letter asks for anything, confirm it with your command using a number or channel you already know. Do not use contact details given in the message.
2. Treat any "RNBP" login request with suspicion. The application is suspended. A message asking you to log in to the RNBP, reactivate your record or re-enter your data online is suspect until your command confirms it.
3. Do not open links or scan QR codes from unconfirmed contacts. If you must check something, type the address yourself. Be careful with QR codes on letters, stickers or posters you did not expect.
4. Never read out one-time codes. No real institution needs the code your bank, the tax portal or a messaging app sends you. A caller asking for one is a fraudster, whatever they know about you.
5. Hang up and call back. If a caller claims to be from ANEPC, your corps, the tax authority, social security or the health service, end the call and ring the organisation on its published number.
6. Watch your public service accounts. Check your tax, social security and health service accounts for activity you do not recognise, using the official sites you normally use. Turn on any login or activity notifications those services offer.
7. Watch for credit and contracts you did not start. Letters about loans, phone contracts or purchases you never made can be the first sign your identity numbers are being used.
8. Tell your family. Contacts and addresses were in the record. Relatives may receive calls that use your name or claim you were injured. Agree a simple way to check with each other.
9. Ask what was held about you. Write to ANEPC's data protection officer at incidentes.dados@prociv.pt. ANEPC's own note invites data subjects to do this. You can ask which of your data the RNBP held.
10. Report fraud attempts. Report attempted fraud to the police, and tell your command so it can warn others in your corps. Keep the message, number or letter.
11. Do not pay anyone to "remove" your data. Offers to delete leaked data for a fee are a known follow-on scam.

What corps and holding bodies can do this week

The bodies that hold fire corps received ANEPC's internal communication and its procedures, which are not public. Beyond them, brief every member in person, including reserve and honour cadre members who rarely visit; name one person or line members can call to check a message; keep a shared list of suspicious numbers and wording and pass it up the command chain; and do not rebuild records through ad hoc email forms or spreadsheets while the RNBP is down.

The notification question

The LBP said the information about the attack should have gone individually to each registered member. That is the league's view, and we report it as such. It sits next to two legal questions that apply to any EU controller.

What the GDPR requires

In Portugal the supervisory authority is the CNPD (Comissão Nacional de Proteção de Dados). Its guidance says the controller must notify the CNPD within 72 hours of becoming aware of a breach, unless it is unlikely to result in a risk, using a specific form; must document every breach even when it decides not to notify; and must tell data subjects when the conditions of Article 34 are met. The CNPD points controllers to the European Data Protection Board's guidelines on breach notification.

Where this incident stands

We do not know whether ANEPC has notified the CNPD; neither body has said. We do not know whether individual letters or emails will follow. What is public is a press note, an internal communication to commands and corps, and a DPO address for questions. Whether that is the "public communication or similar measure" Article 34(3) allows in place of individual notice, or a first step before individual notice, is a matter for ANEPC and the CNPD. The EDPB's guidelines on breach notification, which the CNPD points controllers to, set out how to judge that risk; identity numbers and health data together are the kind of combination that assessment has to weigh.

What changed since first reports

The morning Lusa story, based on the internal notice, said a copy had been made and listed the fields. The LBP then added the 60,000 figure, the absence of bank data, its uncertainty about extraction and its view on individual notice. The afternoon press note softened the copy to "may have been possible", named the RNSI as part of the Ministry of Internal Administration, mentioned procedures sent to the bodies holding fire corps and published the DPO address. By 25 October no official web page, claim or technical detail had appeared in the sources we checked.

Open questions

1. Was the copy confirmed, as the internal notice says, or possible, as the press note says? What evidence underlies each?
2. How many of the roughly 60,000 records were copied, and do they include former members?
3. When did the intrusion start and when was it detected?
4. Will ANEPC write to each registered firefighter, as the LBP wants?
5. Has the CNPD been notified, and will it publish anything?
6. Has the CNCS issued guidance to other public bodies running similar registers?
7. When will the RNBP return, and with what changes to access, authentication and the data it keeps?

What would have helped

None of this judges ANEPC, which suspended the application quickly, brought in the national cybersecurity centre, warned the people at risk about the specific kinds of fraud to expect, set a clear channel rule and published a data protection contact on the same day the story broke. The question for everyone else who runs a register of people is how to make the same class of event smaller. We do not know RNBP's design, so the lessons below are general.

Practices any team can use

• Collect only what the register needs. A roster needs a name, a corps, a rank and a way to reach someone. Blood group, health subsystem and three separate national identity numbers in the same record make a breach far worse. If a field is needed for a specific process, such as medical readiness, keep it in a separate store with its own access rules.
• Split identity numbers from the rest. Store citizen card, tax, social security and health numbers in a separate table or service, encrypted with keys the web application cannot read in bulk. Most screens need to show only the last few digits.
• Put strong authentication on every account that can read many records. National and regional administrators and corps level accounts that can list or export members should use phishing resistant multi factor authentication. A password alone should not open a national register.
• Limit bulk reads. Few legitimate users need to export the whole register. Rate limit and alert on large queries or exports, and require a second approval for them.
• Log enough to answer "what was copied". Record who read which records and when, keep those logs away from the application server, and keep them long enough to investigate. A clear answer to "how many records left" is what lets an operator tell people precisely.
• Inventory every internet facing application and its components. Know which frameworks, libraries, container images and servers each public application runs on, and how old they are. When a fix ships for one of them, rebuild and redeploy in days.
• Prepare the notification before you need it. Keep a template for individual notices, an up to date contact list for data subjects, and a decision path for Article 33 and 34 calls.
• Agree an out of band verification channel in advance. ANEPC's rule that real requests come through the command structure is exactly the kind of channel that makes fraud harder. Setting it before an incident means people already know it.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. Gold Open Source (gold.safeguard.sh, free, no login) gives searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API.

The limits: ANEPC has not said how the RNBP was breached, and there is no evidence that any open source vulnerability was involved. Safeguard has no advisory for this incident and no patched build related to it. These capabilities help in the shared layer of frameworks, libraries and base images that web registers are built from, where pulling patched, signed components and rebuilding fast removes one common way in. They do nothing about data minimisation, account security or notification, which may matter more here.

Where Safeguard fits

Safeguard would not have prevented this incident, and it does not decide what data a register holds or how its users log in. What it covers, at GA:

• Dependency and image scanning of the repositories, container images and SBOM files behind a web application, with JSON results under ./output.
• Component search across projects, showing every project that contains a given component and version when an advisory lands.
• Vulnerability matching and reachability analysis, ranking the vulnerable code paths your application actually calls.
• Policies and gates, so a build carrying a known exploited vulnerability can be blocked or held for approval.
• Autonomous remediation with tested fix pull requests, off by default.
• The Safeguard CLI assistant, which edits code and runs commands with your approval, under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. In this context you could ask it to move identity number columns behind an encryption layer, or to add a test that fails if an API response returns a full tax number, and approve each change.

safeguard scan --dir .                 # a repository
safeguard scan --image <name>          # a container image
safeguard scan --sbom <file>           # an SBOM file

Where Safeguard does not help: it does not monitor logins or database traffic, does not detect an intrusion in progress, does not manage retention or data minimisation decisions, and does not see inside a supplier's hosted service.

Checks for teams that run a register of people

These are generic checks for any team holding a national or regional register of staff or volunteers. They do not describe RNBP, whose stack is not public. Run them only on systems you own or are authorised to test.

1. Find where identity and health fields live

On PostgreSQL, list columns whose names suggest identity or health data:

SELECT table_schema, table_name, column_name
FROM information_schema.columns
WHERE column_name ILIKE ANY (ARRAY['%nif%','%tax%','%cc%','%citizen%','%social%','%nss%',
  '%utente%','%sns%','%health%','%blood%','%sangu%','%licen%','%birth%','%nasc%','%photo%','%imagem%'])
ORDER BY 1, 2, 3;

Every hit is a question: does this screen, report or export need it?

2. See who can read everything

On PostgreSQL, list roles that can select from a sensitive table:

SELECT grantee, privilege_type
FROM information_schema.role_table_grants
WHERE table_name = 'members' AND privilege_type = 'SELECT';

Replace members with your table. Any application or reporting role that can read every row deserves a second look.

3. Look for bulk reads in web logs

For an nginx or Apache access log, count requests per client to export or list endpoints:

grep -E "/(export|download|list|report)" /var/log/nginx/access.log \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

On Windows with IIS logs, a PowerShell equivalent:

Select-String -Path "C:\inetpub\logs\LogFiles\W3SVC1\*.log" -Pattern "/export|/download" |
  ForEach-Object { ($_.Line -split ' ')[8] } |
  Group-Object | Sort-Object Count -Descending | Select-Object -First 20

The client IP field position depends on your log format; check the #Fields header first.

4. Check administrator authentication

List accounts with administrative roles in your application and confirm each one has multi factor authentication enforced, not just available. Remove accounts that have not logged in for months. Check that shared or test accounts do not exist.

5. Scan what the application is built from

From the application's repository and its image:

safeguard scan --dir .
safeguard scan --image registry.example.org/register-app:current

Review results in ./output, starting with findings on internet facing code paths.

Common mistakes and troubleshooting

• "They already know my details, so the caller must be real." The leaked fields are exactly what a fraudster would use to sound official. Knowledge of your NIF or blood group proves nothing.
• Trusting the sender name. Email display names and SMS sender IDs can be set to anything, including "ANEPC" or "Proteção Civil".
• Assuming you are not affected because you left the service. Whether former members are in the roughly 60,000 records has not been said. Stay careful if you were ever registered.
• Waiting for a personal letter before acting. The steps above cost nothing and do not depend on confirmation.
• For operators: deleting logs during cleanup. Logs are the only way to answer how much left. Preserve them before rebuilding anything.
• For operators: restoring the old application unchanged. If the cause is unknown, bringing the same system back invites a repeat.

FAQ

What did ANEPC confirm?

On 24 October 2026 ANEPC confirmed that the RNBP database was the target of a cyberattack and that personal data of registered firefighters may have been copied. It suspended the application with the CNCS and the RNSI, and is reinforcing its security.

How many firefighters are affected?

Nobody has said. The LBP president told Lusa the register holds about 60,000 records. That is the register's size, not a confirmed count of people whose data was copied.

What data was involved?

According to the ANEPC internal notice reported by Lusa: full name, citizen card number, tax number, social security number, health service user number and health subsystem, driving licence, marital status, date of birth, contacts, addresses, photograph and blood group.

Was bank data taken?

The LBP president said the RNBP application does not hold bank data. ANEPC's statements do not mention bank data.

Was the data definitely copied?

The internal notice, as quoted by Lusa, says a copy was made. The public press note says it may have been possible to copy the data. The LBP president said he did not yet know whether data had actually been taken.

How did the attackers get in?

ANEPC has not said. No vulnerability, supplier or component has been named, and we do not guess.

What should a firefighter do now?

Confirm every unexpected request through your corps' command structure, open no links or QR codes from unconfirmed contacts, never read out one-time codes, and contact ANEPC's data protection officer at incidentes.dados@prociv.pt with questions.

Would Safeguard have prevented this?

No. The cause has not been disclosed. Safeguard scans and fixes the open source components and images that applications are built from; it does not control what data a register holds, how its users authenticate, or how an intrusion is detected.

Nothing public ties the RNBP incident to an open source flaw. But every web register runs on frameworks, libraries and images that do get advisories, and closing those gaps quickly is one of the few parts of the problem a team fully controls.

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 have helped

None of these demos shows ANEPC, the RNBP or its systems; each is a real Safeguard session applied here to a team that runs a register of people.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For a member register, you would run /scan . in the application's repository, then ask the assistant to add a test that fails if any API response returns a full tax or citizen card number, approving each edit and command as it runs.

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

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. A team could pick the folder holding its register's web application, ask for an outdated framework to move to its fixed release, and approve or deny every change before it lands.

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

This real Android session sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. If an advisory lands on a weekend for a library your register's login page uses, the on call engineer could approve the dependency bump and test run from a phone, and deny anything that touches the member database until a second person has looked.

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

To try it on your own services, download Safeguard and follow the CLI docs. For related cases, read Denmark's CPR breach and one company's access, the ICO reprimand of Data Cymru and Ogi, finding affected products fast with SBOMs and October 2026 security incidents and what would have helped.

Quick check

Sources

• Diário de Aveiro: Bombeiros foram alvo de ciberataque, full ANEPC press note (24 Oct 2026, 16:22)
• Região Sul: Base de Dados dos Bombeiros Portugueses foi alvo de ciberataque, ANEPC note via the Algarve Regional Command (24 Oct 2026, 16:00)
• ECO, Lusa: Piratas informáticos atacam base de dados dos bombeiros e acedem a dados pessoais (24 Oct 2026)
• Jornal de Notícias, Lusa: Piratas informáticos atacam base de dados dos bombeiros (24 Oct 2026, 11:21)
• Diário de Notícias: Base de dados dos bombeiros foi alvo de ciberataque comprometendo dados pessoais (24 Oct 2026, 10:34)
• TSF, Lusa: Piratas informáticos atacam base de dados dos bombeiros (24 Oct 2026)
• CNN Portugal: Proteção Civil confirma ciberataque e aconselha "atenção redobrada" aos bombeiros (24 Oct 2026)
• SÁBADO, Lusa: Proteção Civil confirma ciberataque e aconselha "atenção redobrada" aos bombeiros (24 Oct 2026, 13:43)
• Postal: Proteção Civil confirma ciberataque, dados pessoais de bombeiros foram acedidos (24 Oct 2026)
• Portugal Resident, Lusa: Cyberattack exposes personal data of thousands of Portuguese firefighters (24 Oct 2026)
• ANEPC: prociv.gov.pt home page, with the RNBP link under "Sites ANEPC"
• ANEPC: Notícias e comunicados
• CNPD: Violação de dados ou data breach
• GDPR Article 33: Notification of a personal data breach to the supervisory authority
• GDPR Article 34: Communication of a personal data breach to the data subject
• GDPR Article 9: Processing of special categories of personal data
• EDPB: Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0
• EDPB: Guidelines 01/2021 on examples regarding personal data breach notification

Last reviewed: 25 October 2026. This is a developing story; check the linked advisories for the latest status.