Mutiny Labs

Security basics · Part 2 of 3 · 5 min read

Your vendors are part of your security.

Three Puerto Rico incidents show why access, data sharing, and vendor ownership belong in your security review.

In this series · 3 parts
  1. 1. Start with the security gaps you can fix.
  2. 2. Your vendors are part of your security.
  3. 3. Puerto Rico security rules: start with coverage.

This is not someone else’s problem.

↳ three incidents, shown through four affected organizations

You do not have to look at a foreign retailer to understand the stakes. In the last year, Puerto Rico has watched its payment infrastructure, its government agencies, and its property records all get reached. Two of these cards describe the same Evertec event, because Popular was one of the downstream institutions.

May – June 2026 · payments infrastructure

Evertec

Evertec discovered potential unauthorized access on May 13, 2026, involving a third-party support platform, and disclosed it in a Form 8-K filed with the SEC on June 9, 2026.

The exposure included transaction records, some payment card numbers, and some names and contact details, primarily affecting Puerto Rico financial-institution clients and their customers. Public reporting identified proposed federal class actions; we have not verified the current docket count, so treat the number as reported rather than established.

⚠ entry point: a third-party support platform
Sources: SEC Form 8-K News is my Business
June 2026 · downstream exposure

Banco Popular

Popular’s customers had data exposed through a third-party provider: the Evertec incident. Popular’s own 8-K states that its systems were not accessed.

That distinction matters, and it is exactly the point. An institution can run its own security well and still have its customers’ information exposed, because the data was sitting in a partner’s environment. Your customers do not experience that nuance. They experience a letter.

⚠ entry point: a vendor holding your customers’ data
Source: Popular, Inc. Form 8-K
November 25, 2025 · government services

TrueNorth

Puerto Rico officials publicly confirmed a ransomware attack involving TrueNorth Corporation, an IT vendor, affecting three government agencies: the Department of Education, ASES, and the CFSE. Officials also said no citizen data was lost.

Beyond that, the detail is reporting rather than a public forensic finding. According to reporting that cited an internal government report, attackers used compromised vendor credentials and more than 150 CFSE servers were affected. We are flagging the sourcing because the distinction matters: one vendor relationship becoming three agencies’ outage is the pattern worth learning from, and it rests on a document nobody outside government has seen.

⚠ reported entry point: compromised vendor credentials
Source: DataBreaches.net
July 2026 · public records

CRIM’s Catastro Digital

CRIM’s Catastro Digital property map exposed roughly one million Social Security numbers, downloadable without any authentication. The hole was patched within days.

The agency denied that a breach had occurred and did not notify the affected citizens. Reported by ProPublica on July 9, 2026.

⚠ entry point: no authentication at all
Source: ProPublica
the pattern, if you squint:

Read the four cards as three incidents. Popular and the three agencies were downstream victims of somebody else’s compromise. Evertec was itself compromised, through a third-party support platform. CRIM was a direct exposure of its own system. The pattern worth taking is the downstream one: a support platform, a vendor’s credentials, a partner’s environment. You inherit the security of every vendor and every platform in your stack: their patch discipline, their access hygiene, their incident response, whether you ever met their engineers or not. Which is the whole argument for knowing exactly what your stack is made of, and owning the parts that hold anything you would hate to lose.

A breach isn’t the end of the harm. It’s the raw material.

↳ what someone can build with what just came back

Whatever that panel returned, the damage of a leak is not the moment it happens: it is everything the data enables afterwards, for years, in the hands of whoever buys it. Records get dumped, aggregated by brokers, cross-referenced with the last eight leaks, and assembled into a profile more complete than anything you would have handed over voluntarily.

And where that profile used to need a human to exploit it slowly, one target at a time, it now feeds tools that write like you, sound like you, and can appear as you on a video call. Yesterday’s leaked password becomes tomorrow’s convincing impersonation.

Email addressesPasswords

Account takeover, everywhere you reused it

Credentials get replayed automatically across hundreds of services. The attacker does not need to break your password: they need you to have used it twice.

Phone numbers

SIM swap and targeted texts

A number tied to your name is a route to your SMS second factor, and a channel for messages that already know who you bank with and who you work for.

Dates of birthGovernment IDs

Identity and credit fraud

The static facts about you never expire and cannot be rotated. Once they are out, they are out, which is what makes an exposure like the CRIM one so hard to undo.

Your public writingPhotosRecorded audio

The impersonation raw material

Never leaked, never stolen, simply published. Your posts, your interviews, your voice on a webinar. Combined with the leaked profile, this is what makes an impersonation of you specific enough to work.

where this goes next, on two other pages:

Leaked contact details and public recordings can make impersonation more convincing. Review personal-account exposure alongside vendor and workplace access, without assuming that any particular leak caused a later fraud. The deepfake guide gives finance teams a callback procedure they can use.

Ask a vendor to show you the controls.

Custom software and commercial platforms both need inventory, access control, maintenance, and recovery. The useful comparison is how well each option supports your actual requirements and who owns the work after launch.

  1. Inventory: what runs, which third parties receive data, and who maintains each component?
  2. Access: which roles exist, who approves access, and how is it removed?
  3. Publishing: what gets reviewed before release, and how is a bad change reversed?
  4. Recovery: when was a backup last restored and what did the test reveal?
  5. Responsibility: who responds, during which hours, under which agreement?

Mutiny can help design and build around those requirements. Our work includes custom platforms and publishing workflows; the proposed controls and service commitments should be explicit in the engagement. No architecture is unhackable, and custom work is not automatically safer.

See the work → · Discuss the gaps you found →

Edited September 29, 2026. Research and source dates are retained; this edit is not a fresh review of every statistic or legal development.