South African insurance software provider MIP Holdings has confirmed that attackers spent roughly three weeks inside a legacy Atlassian Jira support platform in June 2026, exfiltrating personal data belonging to customers of approximately 45 insurance companies. The confirmation came only after the ransomware crew "The Gentlemen" listed Hollard Insurance Group on its leak site on 7 September, prompting Hollard to publicly state on 14 September that it found no evidence of compromise in its own environment and that the actor's claims appear attributable to the MIP incident instead. Record counts differ sharply across reporting: MIP CEO Richard Firth told TechCentral that "in the region of 400 000 records" were taken, while an aggregator republication of that same TechCentral reporting is headlined as revealing "millions of personal records" despite its own body text repeating the ~400,000 figure. MIP's 23 June breach notification, signed by CIO Fergus McLoskey and reported by ITWeb, gives no total at all and states the scope assessment was still underway.
What Happened
The timeline that emerges from MIP's own notification and its CEO's subsequent comments is reasonably consistent, even where the public framing is not.
MIP detected a cyber extortion attack on 14 June 2026 targeting its third-party Jira project management platform. The company notified South Africa's Information Regulator on 16 June under section 22 of POPIA, and issued a breach notification to affected stakeholders on 23 June. Firth's account to TechCentral adds that the intruders were resident in the platform for about three weeks before detection, which places initial access somewhere in late May.
The compromised system was a Jira instance on which MIP's clients logged support tickets. It was already being decommissioned. Firth said MIP had concluded it could not migrate to a newer version and was moving to a different structure entirely, partly for security reasons. The migration did not finish before the attackers arrived.
MIP maintains that its core systems and client policy administration databases were not touched, and that the breach was confined to the Jira environment plus certain FTP/SFTP sites the attackers reached using credentials harvested from that platform. Hollard's statement is consistent with this: the insurer says it identified the leak site post through proactive threat intelligence monitoring, activated incident response, engaged external forensic investigators, and found no evidence of compromise within its own environment.
Accounts diverge on the extortion outcome. ITWeb reports that MIP "received undertakings" from the attackers that unlawfully accessed data had been deleted and would not be published or misused, without stating what was given in return. The headtopics republication of TechCentral's reporting states more directly that the incident "led to a ransom payment" and that "MIP confirmed the extortion payment and the destruction of data." Neither MIP's breach notification as quoted by ITWeb nor Hollard's statement addresses a payment. Treat the payment as reported rather than independently confirmed, and treat the deletion assurance for what it is: an unverifiable promise from an extortion crew.
What Was Taken
The affected Jira environment held personal information relating to MIP employees, client users, and the members and customers of those clients. MIP's notification specifies that data was exposed in screenshots, task attachments, and in some cases as access credentials sitting in ticket bodies.
Firth's description of the contents is the most granular account available:
- Email addresses and cellphone numbers
- Policy numbers with South African identity numbers attached
- A small number of residential addresses
- One single file containing roughly 200,000 cellphone numbers, assembled for an SMS campaign
The 45 affected organisations represent just under half of MIP's client base, and Firth said almost all of them are life insurers.
The root cause of the exposure is the part defenders should sit with. Tickets logged on the platform were supposed to contain obfuscated data. They did not. Firth described the mechanism plainly: when a client's staff member logged a problem, they would paste in whatever they were looking at, an error message, a screenshot, a report someone had complained about, and the underlying record came with it. Identity numbers, email addresses and cellphone numbers sat in the tickets in the clear. "That's why we were taken aback that all of this data was actually sitting in" the system, he told TechCentral.
MIP's 23 June notification states that its investigation was still determining the precise scope and categories of data affected, and whether information had been downloaded, copied, misused or disclosed. That caveat was still standing as of the September reporting.
Why It Matters
Hollard is not a small downstream casualty. It is South Africa's largest independent privately owned insurance group, founded in 1980 by the Enthoven family, with 4,000+ employees and 6 million+ policyholders, operating in 18 countries across four continents. The Gentlemen's listing framed this as a breach of that organisation. It appears instead to be a breach of a shared supplier, and the two are not the same thing for either attribution or remediation.
This is the second South African third-party concentration event in two weeks. Over the weekend of 12 and 13 September, Bidvest Bank, Cell C, EasyEquities and Peregrine Capital all issued near identical customer notices about an incident at a shared provider. Peregrine named it outright: RelyComply, an AML and KYC compliance platform. The Dire Wolf ransomware group posted a listing dated 9 September claiming it took roughly 200GB from RelyComply's production databases and cloud storage across more than twenty organisations, a claim RelyComply has neither confirmed nor denied and which nobody credible has verified. Different actor, different vendor, identical structural failure: dozens of regulated firms with clean internal networks writing to customers because they all handed the same job to the same supplier.
There is also a data quality warning buried in this incident. Leak site aggregators carried Hollard's listing with visibly wrong enrichment. Breach House classifies Hollard as "Manufacturing / Engineering" with "51-100" employees, for a 4,000+ employee insurance group. Victim counts for The Gentlemen are similarly unstable across trackers, with one profile simultaneously citing "over 320 victims" since the group emerged in July or August 2025, "835 victims since February 2023" (predating the group's own existence), 840 total, and more than 1,570 linked victims recovered from a compromised C2 server in 2026. Do not build a risk assessment on leak site metadata without validating it.
For POPIA purposes, the notification obligations here flow to every one of the 45 affected organisations, not just to MIP. Data subjects whose identity numbers were paired with policy numbers and phone numbers are now prime targets for insurance themed vishing and SIM swap fraud, and the 200,000 number SMS campaign file is a ready made target list.
The Attack Technique
Initial access is the least settled part of the record. The headtopics summary of TechCentral's reporting says the intruders got in "after infiltrating an employee laptop." MIP's own notification, as reported by ITWeb, describes the Jira platform as the target and says the attackers then reached certain FTP/SFTP sites "using credentials obtained from the platform." These two accounts are compatible, with the laptop as entry and the Jira instance as the pivot, but MIP has not publicly confirmed the laptop vector in its own words.
What is documented consistently is the post access pattern, which maps cleanly to MITRE ATT&CK T1078 (Valid Accounts). Threat intelligence profiling of The Gentlemen describes exactly this: obtaining and abusing credentials for existing accounts to gain initial access, persistence, privilege escalation, and defense evasion, bypassing access controls on resources across the network. In this case the credentials were not stolen from a password vault. They were sitting in support tickets, pasted there by well meaning users troubleshooting problems.
The Gentlemen is a ransomware as a service operation that emerged around July or August 2025, recruiting affiliates with a 90% revenue share and deploying a Go based locker against Windows, Linux, NAS and BSD systems. Its South African targeting is not incidental; the group has been running an active campaign against the region's financial sector. Note that in the MIP case there is no public evidence of encryption. This reads as exfiltration and extortion only, consistent with the group monetising a data trove it found rather than a network it owned.
Three weeks of dwell time in a system already scheduled for decommissioning is the operational failure worth naming. Systems in the process of being retired routinely fall out of monitoring coverage, patching cycles and access reviews, precisely when their accumulated historical data makes them most valuable.
What Organizations Should Do
- Audit your ticketing and collaboration platforms for clear text PII right now. Jira, ServiceNow, Zendesk, Confluence and Slack accumulate exactly this kind of data through screenshots and attachments. Run regex sweeps for national ID formats, policy numbers, card patterns and credential strings across ticket bodies and attachments. A policy that says data "should be obfuscated" is not a control, as MIP discovered.
- Treat decommissioning systems as elevated risk, not reduced risk. Any platform scheduled for retirement should stay in full EDR, logging and MFA scope until the day it is switched off, and should have its data purged before that date rather than after. Put a named owner and a hard sunset date on every legacy system in your estate.
- Kill credentials pasted into tickets and rotate anything that touched the platform. MIP's attackers pivoted from Jira into FTP/SFTP using harvested credentials. Assume any secret ever pasted into a support system is compromised, rotate it, and add secret scanning to the ingestion path so the next one is redacted on arrival.
- Map your fourth party exposure, not just your third party exposure. Hollard's own environment was clean and its customers' data still moved. Ask each supplier which of their suppliers process your data, and require contractual notification timelines that reach you directly rather than through a chain.
- Rehearse the "we were not breached, our vendor was" disclosure. Hollard's response is the model here: proactive leak site monitoring caught the listing, incident response and external forensics ran immediately, and the public statement distinguished its own environment from the third party without hiding behind that distinction. Have that statement drafted before you need it.
- Push identity fraud warnings to affected data subjects, not just breach notices. With identity numbers, policy numbers and phone numbers in circulation, the realistic follow on is vishing and SIM swap. Warn customers that your organisation will not call to request OTPs or policy verification, and brief your call centre on the inbound social engineering that follows.
Sources: Hollard rejects hacking claim, points to MIP cyber breach ITWeb | Customers of 45 insurers exposed in South African cyber breach | Data Breach at MIP Reveals Millions of Personal Records, Incidents... | Hollard Insurance Group Listed as Victim by 'the gentlemen' Ransomw... | Four Breach Notices, One Shared Vendor | Hollard Insurance Group Ransomware Attack by Thegentlemen (2026) C... | Hollard Insurance Group — THEGENTLEMEN Ransomware Attack Breach House | Hollard Insurance Company Ltd (via Public) / Hollard statement rega...