When the Ticket System Is the Data Store

TechCentral reported on 15 September 2026 that MIP Holdings, a South African provider of software to insurers, was breached. According to that reporting, the intrusion ran from late May into mid-June 2026 and was discovered by MIP in mid-June.

The access chain reported is worth stating precisely, because each step is ordinary. Credentials reused from a previously breached external service gave access to an employee's personal laptop. From there the attackers reached MIP's Jira support platform, which was in the process of being decommissioned. The support tickets in that platform contained customer data that had been pasted in as screenshots and error messages, unencrypted.

TechCentral reported roughly 400,000 records exposed, including email addresses, mobile numbers, and policy numbers paired with identity numbers, with one file containing around 200,000 phone numbers gathered for a messaging campaign. Just under half of MIP's insurer client base was affected. TechCentral attributed the intrusion to a group calling itself The Gentlemen, reported that MIP notified the Information Regulator and the Prudential Authority, and subsequently reported that MIP paid a ransom in exchange for an undertaking to destroy the data, after which the group listed one of the affected insurers on its leak site anyway.

The number of affected customers per insurer, the ransom amount, and whether any data was actually destroyed were not established in that reporting.

Why this shape of breach is so common

Screenshots defeat field-level protection. Masking, tokenisation, and redaction operate on fields. An image of a screen containing those fields is just an attachment. Any control that depends on recognising a data type will miss it, including most data loss prevention scanning, and the agent pasting it is not doing anything unusual.

Decommissioning is a dangerous state. A system being retired still holds everything it ever held, and has usually lost its owner, its patch cadence, and its place in access reviews. The data outlives the attention. Anything marked for decommissioning should be treated as in scope until the data is gone, not until the replacement is live.

Credential reuse turns an unrelated breach into your incident. A password reused from a service you do not control, on a device you do not manage, is outside every control you own. This is the argument for phishing-resistant multi-factor authentication on the platforms that hold data, rather than only on the ones that feel important.

Support platforms are often reachable from anywhere. They are built for distributed agents and integrations, which means broad network reachability is a feature. That reachability applies equally to someone holding valid credentials.

Retention is the control with the largest effect. A ticket from four years ago is almost never useful and is fully exposed in a breach. Most support platforms will not delete anything unless configured to, and the default is to keep everything forever.

Classify the support platform as a data system. That single reclassification pulls it into encryption requirements, access review, retention policy, and logging. Everything below follows from it more easily.

Give agents a reason not to paste. Agents paste records because looking them up is slow. A read-only lookup that shows the customer record next to the ticket, with sensitive fields masked, removes the motive. Policy alone loses to friction, every time.

Set attachment and ticket retention deliberately. Decide how long a resolved ticket and its attachments are useful, and enforce it. Then check that attachments are actually deleted rather than detached.

Put decommissioning on a checklist that ends with data destruction. Access revoked, data exported if needed, data destroyed, record closed. A system is not decommissioned when traffic stops.

Scan what you already have. Existing tickets are the accumulated backlog of this problem. Searching historical tickets and attachments for identity-number and card-number patterns tells you your actual exposure, and it is a finite piece of work.

Decide your position on ransom before you need it. Paying for a promise to delete data buys an undertaking from someone who has already demonstrated bad faith, and the reporting on this incident illustrates what that undertaking is worth. The notification obligations to regulators and customers are not discharged by payment either.

Log reads, not just writes. In a breach the question is what was viewed. Support platforms often log changes thoroughly and views barely, which makes the scope of an incident unknowable.