CyphrQ
Menu

INSS Data Breach: Why Brazil's ANPD Sanctioned It Without a Fine

In 2022, valid credentials ran 90M+ queries on Brazil's INSS benefits system. What ANPD found, the sanction, and what to check in your own estate.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

Incident: August 202211 min read

What happened in the INSS data breach, and what did Brazil's regulator do about it? In August and September 2022, valid credentials from a partner agency ran more than 90 million queries against the benefits system of Brazil's social security institute (INSS). The INSS told the regulator but not the people affected. In January 2024 the ANPD sanctioned it: no fine, but a public notice it had to publish itself.

This is a case file, not legal advice. Every figure below comes from the ANPD's own published case record (ANPD process 00261.001888/2023-21) or from the Brazilian official gazette and the LGPD text. Quotations from Portuguese documents are our translation.

Case file

Field Value (from official sources)
Organisation Instituto Nacional do Seguro Social (INSS), a federal agency (autarquia)
Region Brazil
Breach/violation date Abnormal queries in August and September 2022; detected 23 September 2022
Decision date 29 January 2024 (Despacho Decisório nº 1/2024/FIS/CGF), published in the official gazette on 1 February 2024
People affected Not determined. The ANPD record says an "indeterminate number" of beneficiaries and insured persons
Data types Name, CPF (tax ID), NIT (social security number), identity document, date of birth, sex, line of work, bank details, number of dependants; the ANPD also cites health data
Penalty "Publicização da infração": a notice on the INSS homepage and in the Meu INSS app for 60 days. No fine
Regulator Autoridade Nacional de Proteção de Dados (ANPD)
Status Appeal filed 16 February 2024; first instance kept its decision on 12 June 2024 and sent the appeal to the ANPD Board. The ANPD now lists the case as concluded

What happened, and when?

According to the ANPD's technical note in the case record, on 23 September 2022 routine performance monitoring of the INSS mainframe showed data queries running 4 to 6 times above previous months, "without apparent operational justification" (ANPD case record, Nota Técnica 54/2023).

The scale is the striking part. In August and September 2022 there were "more than 90 million queries" to SISBEN, the INSS corporate benefits system, and 9 million to BLH00, the single benefits system run by DATAPREV, the state IT company. That was almost three times the volume recorded in June 2022 (same source).

The timeline that follows, all from the same record:

  1. 28 September 2022: credentials of the three heaviest users were blocked and the event was reported to the INSS incident response team.
  2. 19 October 2022: the INSS sent a preliminary incident report to the ANPD.
  3. 29 December 2022: the ANPD issued Aviso 33/2022, ordering more detail and, "if applicable", notice to data subjects.
  4. 9 April 2023: Despacho Decisório 3/2023 ordered the INSS to notify all affected data subjects within 10 working days.
  5. 12 May 2023: an extended deadline passed. The communication plans the INSS sent on 24 May 2023 did not mention the incident.
  6. 3 August 2023: the ANPD issued an infringement notice (Auto de Infração 1/2023).
  7. 29 January 2024: the first-instance decision imposed the sanction (official gazette, 1 Feb 2024).

Whose INSS benefit records were exposed, and how many?

Nobody knows the exact number, and that is the heart of the case.

The INSS told the ANPD it could not identify the people affected. Its monitoring measured query volume only, so "there would be no log showing which data were accessed" (ANPD summary of the INSS response, Nota Técnica 54/2023, in the case record).

What the record does establish is the type of data in the affected systems: name, CPF, NIT, identity number, date of birth, sex, line of work, bank details and number of dependants. The ANPD also treated the incident as touching official identity data, financial data and health data, which is why it later classified the infringement as grave.

How did the INSS breach happen, by the official account?

The official account is short and specific, and parts of it are redacted in the public version.

  • Valid credentials, authorised network. The traffic came from an authorised network using valid credentials tied to the Advocacia-Geral da União (AGU), the federal government's legal service, which had access under an agreement with the INSS.
  • Three accounts did most of it. Most queries came from three users in an access group managed by the AGU.
  • Nobody owned the user list. The INSS said access management was "decentralised" to partner bodies, "without any validation by the INSS".
  • Stale and unknown accounts. The AGU manager of that group did not recognise the queries and said 44 of the 66 registered users could be removed: 39 were unknown people and 5 were former interns. The ANPD noted that "2/3 of the users of the access group were improperly registered".
  • Automation. 84% of 486,503 searches in the period analysed came from just 22 workstations, at more than 17,000 queries every 30 minutes.
  • A repeat pattern. The record links this to an earlier incident on 24 November 2021, where "the same password" was used by several different users.
  • Conclusion. The ANPD's note concludes that, despite the valid credentials, the automated queries were "probably" carried out by malicious actors to capture INSS data.

DATAPREV blocked the AGU traffic on 30 October 2022, according to the same note. In its defence, the INSS described the affected interface as the Plenus benefits-management system and said it had since moved the AGU connection to VPN with digital certificates and tokens. Those are the INSS's own statements, not ANPD findings.

The ANPD found two infringements (Despacho Decisório nº 1/2024/FIS/CGF):

  • Article 48 of the LGPD (Lei nº 13.709/2018, text on planalto.gov.br): the controller "must communicate to the national authority and to the data subject" any security incident that may cause relevant risk or harm.
  • Article 32, §2 of the ANPD's Enforcement Regulation (Resolução CD/ANPD nº 1/2021): failure to comply with a preventive measure, counted as an aggravating factor.

The instruction report classified the infringement as grave under article 8, §3 of the Dosimetry Regulation (Resolução CD/ANPD nº 4/2023), because it involved large-scale processing and sensitive data. That ruled out a simple warning.

So why no fine? The LGPD caps a simple fine at 2% of Brazilian revenue, limited to R$ 50,000,000 per infringement, but article 52, §3 leaves fines out of the sanctions available against public bodies. The ANPD's report says so directly, as quoted in the case record. It chose publicização da infração, where the offender publicises its own infringement. The INSS had to:

  1. Publish a prescribed notice on the first page of its website for 60 days.
  2. Send every Meu INSS app user a notification, flagged as unread, for 60 days.

Status. The INSS appealed on 16 February 2024, arguing among other things that incident details were confidential under federal cyber-incident rules (ANPD appeal record). On 12 June 2024 the ANPD's enforcement division accepted the appeal with suspensive effect, kept its decision and sent it to the Board. We have not found a Board decision we could read. The ANPD's sanctioning-process page lists the INSS case under concluded processes.

Why didn't "we can't tell who was affected" work?

This is the most useful line in the whole file for any organisation. The ANPD's reasoning, from its technical note (our condensed translation):

If a controller could skip notification because it lacks access logs, controllers would have an incentive never to collect or keep logs.

Its instruction report then set out a ladder. A controller with good logs can notify only the people actually affected. One without them must notify everyone potentially affected, up to every person in the database, or use broad public disclosure under article 48, §2. In its words, the less prepared controller "needs to expose itself more".

In plain terms: weak logging does not shrink your notification duty. It widens it.

How does enforcement in the region compare?

We can only speak for Brazil from primary sources in this post. Argentina's AAIP, Colombia's SIC and Mexico's regulators will get their own case files in this series, each from their own records.

Within Brazil, the ANPD's list of sanctioning processes shows a clear pattern:

  • Eight concluded processes are listed. Seven are public bodies. The only private company is Telekall Infoservices.
  • Seven of the eight involve failing to notify a security incident to data subjects, the ANPD, or both, among their listed motives. That includes the Ministry of Health, the Federal District Education Department, the Santa Catarina Health Department and the INSS.
  • Open cases are shifting to the private sector, including ByteDance Brasil (TikTok) and RaiaDrogasil.

The practical takeaway for the region: in Brazil, the first wave of enforcement was mostly about incident notification, not the breach itself.

Going deeper: for security and IT teams

This case turns on three controls: identity governance for third-party access, logging that can attribute records to people, and a notification process that works under a deadline.

The attack path, as officially documented. The ANPD record describes abuse of valid credentials from an authorised partner network, followed by automated bulk queries. That maps to MITRE ATT&CK T1078 Valid Accounts (tactics: Initial Access, Persistence, Privilege Escalation, Stealth). The record does not say whether the accounts were domain, local or application accounts, so we don't assign a sub-technique. ATT&CK lists M1032 Multi-factor Authentication, M1018 User Account Management and M1026 Privileged Account Management as mitigations, and detection strategy DET0560 for valid-account abuse.

Threat model. The attacker needs one live account in any partner group with read access to a large record store. They get bulk personal and financial data through normal application screens, which blend into legitimate traffic. The control that failed was not authentication. It was who is allowed to hold an account: two-thirds of one partner group were unknown people or former interns, and a shared password pattern had already been flagged in 2021.

Controls with specifics.

  • Delegated access needs an owner on your side. If a partner manages its own users in your system, require periodic attestation (named user, role, end date) and reject accounts that are not attested. Federated access is fine; unattested access is not.
  • No shared credentials. One person, one account. Pair it with phishing-resistant MFA or certificate-based authentication for every external user, not only staff.
  • Rate limits and volume baselines per account and per source network. The INSS caught this through mainframe performance monitoring, weeks into a spike that spanned August and September. Alert on per-user query counts against a baseline. Here the signal was obvious: 22 workstations, more than 17,000 queries per 30 minutes.
  • Record-level access logging. The INSS could not say which records were read because it logged volume, not content. For systems holding identity, bank or health data, log user ID, source, timestamp and the record identifiers returned. That is the evidence that lets you notify only the people affected instead of everyone in the database.

Notification, as the rules state it now. The ANPD's incident communication page says controllers must notify the ANPD and affected data subjects within three working days, under Resolução CD/ANPD nº 15 of 24 April 2024, unless a specific law sets another deadline. The notice to individuals must, among other things, describe the data affected, the risks, the reasons for any delay, the mitigation measures, the date the controller learned of the incident and a contact point, including the DPO (encarregado) where applicable. The INSS case predates this regulation. At the time, the ANPD's own decision cited a recommendation of two working days.

Detection and evidence to keep. Your incident file should be able to show: when you became aware, when you contained it, the risk assessment you made, and who you notified and when. The INSS record shows the regulator reading exactly those dates back against the controller.

What to check in your own estate this quarter.

  1. List every external organisation with user accounts in your systems, and the number of active accounts each holds.
  2. Ask each one for a named, dated attestation. Disable anything unattested.
  3. Pick your three most sensitive systems. Can you produce, today, the list of records one user viewed last Tuesday? If not, that is your notification exposure.
  4. Check for per-account query baselines and alerts. Test them with a synthetic burst.
  5. Run a tabletop exercise against a three-working-day clock, ending with the draft notice to individuals.

Questions for vendors and partners. Do you log record-level reads? How fast can you give us the list of affected individuals? Who approves new accounts on your side, and how often are they reviewed?

Key takeaways

  • The breach was bulk querying with valid partner credentials: more than 90 million SISBEN queries in two months, detected by performance monitoring.
  • The penalty was not for the breach but for not telling the people affected, plus ignoring the regulator's orders.
  • No fine was possible because the LGPD excludes fines for public bodies. The ANPD used self-publicity instead: 60 days on the homepage and in the app.
  • Weak logging widens your duty. If you can't identify who was affected, the ANPD expects you to tell everyone who might have been.
  • For Brazil today, the deadline is three working days to notify the ANPD and affected people.

Sources