Methodology
Every figure on this site derives from a single dated snapshot of public leak-site monitoring. This page states exactly how 192 raw records become the 112 attributed claims reported elsewhere on the site, and where that process can be wrong.
Where the data comes from
The ransomware dataset is collected from ransomware.live, which monitors the public leak sites operated by ransomware groups. A record is created when a group publicly claims an organisation. The snapshot behind this page was taken on and contains 192 records.
A leak-site claim is an assertion made by an attacker. It is not a confirmed breach, it is not verified by the affected organisation, and it is not verified by this site. Counts on this site measure claims, not confirmed incidents, and that distinction is deliberate.
Why the headline figure is not 192
The upstream feed tags each record with a country. That tag is not reliable. The snapshot behind this page includes records tagged for the United Arab Emirates whose subject organisation is demonstrably based elsewhere. Publishing the raw count as "attacks on the UAE" would overstate the figure and would not survive scrutiny.
Each record is therefore classified into one of three attribution levels, using fields that are discarded immediately afterwards:
| Name | Relative volume | Incidents | Share |
|---|---|---|---|
| Confirmed — organisation domain in the .ae zone | 65 | 33.9% | |
| Probable — explicit UAE reference in the record text | 47 | 24.5% | |
| Unverified — neither signal present | 80 | 41.7% | |
| Total | 192 | 100% |
Only confirmed and probable records reach the headline figures, the page titles and the structured data. The 80 unverified records, which are 41.7% of the feed, are excluded from every count on this site. They are not deleted, and they are reported here so the rejection rate is visible.
This test is deliberately conservative in one direction and permissive in the other. A UAE organisation using a .com domain with no UAE reference in the record text will be classified unverified and dropped, so the figures on this site understate rather than overstate UAE ransomware activity.
Which date is used
Records carry two timestamps. This site uses discovered, the date the claim was observed on the leak site, and truncates it to the day. The date a claim was observed is not the date the intrusion occurred, which is typically earlier and is not published by the attacker. Period counts therefore describe when claims surfaced, not when compromises happened.
How sectors are assigned
Sector labels come from the upstream feed and are mapped to fixed slugs through an explicit table. An unrecognised label never creates a page: it fails the build so a person can classify it. Records the upstream feed left unclassified keep no sector at all. There are 2 such attributed records, and they appear in totals but in no sector breakdown, which is why sector rows sum to slightly less than the headline figure.
Which groups get their own page
A ransomware group earns a dedicated page once it has claimed 5 or more attributed UAE organisations. Below that threshold the record describes an episode rather than a pattern, and a profile built on it would restate its own table row at greater length. Those groups are counted in every figure on this site and are tabulated on the short record page. Groups seen once are listed on the groups hub without a page, because a single data point cannot describe a pattern.
Versioned operations such as LockBit 2.0 and LockBit 3.0 are counted separately. Merging them would be an editorial claim about actor identity rather than something recorded in the source data.
What this site does not publish
Affected organisations are never identified. Names, domains, leak-site URLs, leak contents, data volumes and employee names are removed before the data is stored, not merely omitted at display time, and an automated check fails the build if any of them appear in the published pages. The reasoning is set out in the editorial policy.
Known limitations
- Counts measure attacker claims, not verified breaches.
- Groups that do not operate a leak site are invisible to this method entirely.
- Organisations that pay before publication never appear in the data.
- Attribution is inferred from record text, so both false positives and false negatives are possible.
- The current year is always partial and will rise as it completes.
- No emirate-level breakdown exists, because the source data carries no emirate field.
Corrections are welcome. If a figure on this site is wrong, the snapshot it came from is in version control and the calculation is reproducible.