DragonForce says it holds 234.63 gigabytes of internal files taken from Isegen South Africa, the Durban chemical manufacturer that is the country's sole producer of certain plasticisers and food acidulants. The ransomware group has set 6 August as the date it publishes that data if Isegen does not pay. Isegen says its own investigation has found no evidence that anyone got in at all, and that its production and business operations have continued without interruption throughout. One of those two statements is about to be tested in public, and it is not the only unresolved ransomware claim sitting against a South African company right now.
What's claimed, and what's confirmed
Isegen is one of four South African organisations named on ransomware leak sites since the middle of July. IT distributor Rectron, a subsidiary of JSE-listed Mustek, confirmed on 15 July that an unauthorised party had accessed its systems and that personal information relating to customers, business contacts, and staff may have been taken, in an incident Rectron says is suspected to involve the DragonForce ransomware group. Rectron reported the incident to the Information Regulator. By 27 July, its branches had reopened and its core systems were operational, though some non-core functions were still being restored, a reminder that operational recovery and a completed forensic picture are not the same thing. That is a confirmed breach, with a date, a named group, and a regulator notified. The other three incidents are still just claims. Energy and petrochemical investment holding company Reatile Group was listed by the Incransom group on 18 July. Business services firm Recsa was listed by Qilin on 22 July. Neither company has made a public statement, and neither claim has been independently verified.
Ransomware-as-a-service (RaaS) operations such as DragonForce, Incransom, and Qilin extort through public pressure. Naming a company on a leak site, often before any ransom is paid and before the group has shown it holds anything at all, is the extortion tactic itself. Groups like DragonForce typically pair file encryption with data theft, a combination known as double extortion, so a company can restore its own systems from backup and still face a public data release over a claim it has never confirmed. The publicity is meant to force a response regardless of whether the underlying claim holds up, and the trackers that catalogue these listings simply inherit whatever the ransomware group typed in. One tracker lists Recsa as a South African business services firm based at recsasec.org. Another lists a same-named Recsa victim of the same Qilin claim as based in Costa Rica, with the impact confined there. Nobody has reconciled which one is right, and that gap says as much about how thin this intelligence gets as it does about Recsa itself.
Why the gap hits harder in South Africa
Section 22 of the Protection of Personal Information Act (POPIA) requires a responsible party to notify the Information Regulator and affected individuals as soon as reasonably possible once there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person. That threshold sits well short of certainty, and the Regulator's own paperwork reflects it. The SCN1 Security Compromises Notification form, published to standardise breach reporting, asks whether the compromise being reported is confirmed or alleged. The Regulator built room for uncertainty into the process itself, because it expects businesses to report suspicion rather than wait for proof.
That cuts against the instinct to wait. A business that sees itself named on a leak site, or hears about a claim from a client, an insurer, or a journalist before its own systems raise any alarm, already has grounds to start the questions Section 22 requires, whatever the ransomware group can or cannot prove. Isegen's public denial is a reasonable response if its investigation genuinely found nothing, but it is also the exception. Most named businesses in South Africa say nothing at all, which leaves the clients and suppliers who rely on them working from a leak-site listing and little else. Under POPIA, an operator, meaning any business that processes personal information on another's behalf, has its own duty to flag a suspected compromise to the business it works for, so the obligation to ask does not stop at your own front door.
What to do this week
- If your business turns up on a ransomware leak site, start your Section 22 assessment immediately. Do not wait for the group to publish proof first.
- Verify the listing before you react to it. Attribution on these trackers is often wrong, sometimes by an entire country, the way one tracker placed Recsa in South Africa and another placed the same name in Costa Rica.
- Send a short written question to any of the four named companies you do business with, Isegen, Rectron, Reatile Group, or Recsa, asking whether they have seen unusual access and whether your information was affected. It costs nothing, and it creates the record an insurer or the Regulator may ask for later.
- Log what you asked, when you asked it, and what you were told.
- Put 6 August on your own calendar. If DragonForce publishes and Isegen's investigation turns out to have missed something, the businesses that already asked questions this week are the ones already ahead of it.
Where Ubuntu Guard fits
If your business has been named on one of these leak sites, or a supplier's listing has left you unsure what it means for your own data, our incident response service is built for exactly this kind of uncertainty. We help you work out what a claim means for you in practice, what Section 22 requires in your specific case, and how to document what you did while a situation is still unresolved. That includes reviewing what a named supplier can reach inside your own environment, since a compromise you cannot yet confirm is still one you may need to plan around. No jargon, no waiting on a ransomware group's deadline to tell you what to do next.
Waiting to see who is proven right on 6 August is not a plan, it is a delay. Think you or a supplier have been named? WhatsApp us now. We respond fast: wa.me/27791595040
Cybersecurity Made Simple
© 2026 Ubuntu Guard Cybersecurity | Durban, South Africa
ubuntuguard.co.za