This is the technical note behind one number on our site. It is written for the people who will check it.
Why
Saying a control “defends against” an attacker technique is a strong claim. Many compliance tools make it loosely: link a framework to MITRE ATT&CK (Adversarial Tactics, Techniques and Common Knowledge, MITRE’s public catalogue of how attackers operate) through a broad topic, then count everything under that topic. The result is a large number that nobody can defend line by line.
We wanted figures a security engineer could audit. That meant choosing sources we did not write, stating the method, and showing where the sources disagree.
What
We use two published sources. Each answers a different question.
| CIS mapping | MITRE mitigations | |
|---|---|---|
| Source | The Center for Internet Security’s (CIS) published mapping of the CIS Controls v8.1 to ATT&CK | MITRE’s own data on which mitigation reduces the risk of which technique (ATT&CK Enterprise v20.1) |
| Reached through | Our 34 subjects, such as “Multi-factor authentication” | Our 164 specific controls, such as “MFA for remote and cloud access” |
| Question it answers | Which attacks does a framework, taken as a whole, help defend against? | Which attacks does this one control help defend against, and which stay more open without it? |
| Techniques reached | 383 | 504 |
| Links | 1,467 (subject to technique) | 1,526 (specific control to technique) |
| Where we use it | Every public figure, and the framework pages | The galaxy side panel for a specific control, the threat layer in an assessment, and capability gaps |
361 techniques appear in both sources. Where two independent sources name the same technique for the same control, we mark it “CIS + MITRE”. That is the strongest claim we make, and we show it as such.
The headline stays on the CIS figure. It is the more conservative of the two, it comes from a published third-party mapping, and it changes only when CIS or our subject links change. One number on the site, with the method here for anyone who wants the second.
How
The CIS route
CIS publishes which ATT&CK techniques each CIS safeguard helps with. We hold that mapping against our subjects, then follow each framework’s controls to their subjects. A framework control reaches a technique when:
- it is linked to a subject by a reviewed equivalent mapping, and
- it is a technical or process control. A policy document does not stop an attack, so policy and governance controls never claim a technique. This rule cut an earlier figure from 1,870 to 1,467.
The MITRE route
MITRE lists 44 mitigations in ATT&CK v20.1, each with the techniques it addresses. We gave each mitigation a home on the specific control it describes: “Multi-factor Authentication” (M1032) on our four MFA controls, “Data Backup” (M1053) on “Backup taken and protected”, “User Training” (M1017) on security awareness for everyone. 42 of the 44 have a home. The other two, “Do Not Mitigate” and “Pre-compromise”, describe no control and need none.
A framework control reaches a technique when it is placed on a specific control whose mitigation addresses that technique, under the same technical-or-process rule. Every placement was reviewed by a person before it counted.
Where the two disagree, and why that is useful
For most security frameworks the two sources land close together. ISO 27001 reaches 383 techniques through CIS and 432 through MITRE; PCI DSS 4.0.1 reaches 383 and 424. The gaps open up where a framework asks for broad outcomes rather than specific controls:
| Framework | CIS route | MITRE route | What it shows |
|---|---|---|---|
| NIST SP 800-53 r5 | 383 | 500 | Detailed technical catalogue: MITRE’s finer route finds more |
| ISO 27001 | 383 | 432 | Close agreement |
| UK GDPR and EU GDPR | 360 | 101 | Privacy law asks for security in broad terms; at subject level that borrows a whole subject’s techniques. Article 30 (records of processing) alone links to asset management, which carries 294 CIS techniques |
| NIS2 | 369 | 157 | Same pattern: broad duties, few specific controls |
| DORA | 350 | 9 | DORA’s technical articles are about testing and resilience, which reduce risk overall but carry few specific ATT&CK mitigations |
Neither column is wrong. The CIS route says “this framework touches subjects that defend against these attacks”. The MITRE route says “these specific controls, as this framework asks for them, defend against these attacks”. If you are choosing what to fix first, the second is the one to act on.
What we do not claim
- A mapped technique is not a stopped attack. A mitigation reduces the risk of a technique. We say a control “helps defend against” a technique, never that it “covers” it.
- Detection is separate. ATT&CK mitigations are mostly preventive. Logging and monitoring appear where MITRE lists them (“Audit”, M1047), not as a claim that you would see the attack.
- Every compliance framework now counts. Until 12 November 2026, IEC 62443, Dubai ISR, Kuwait NCF, Oman NCF, Bahrain NCSC and the CBUAE framework had 397 controls we had not classed as technical, process or policy, so neither route counted them. We have classed them by hand from each control’s wording; they now reach between 269 and 383 techniques through CIS and between 63 and 433 through MITRE. Six Bahrain sector standards are held at domain level only, with no control text, and claim no techniques.
- Every control type has been reviewed. The other frameworks’ types were first set by a keyword rule in July 2026. On 12 November 2026 we reviewed all 2,346 of them against one written rubric and corrected 810: penetration tests and incident response typed as technical became process, audit logging typed as process became technical, and legal articles typed as technical became governance. The headline figures did not move. A few framework figures rose where a control had been wrongly left out (GDPR, for example, from 328 to 360 on the CIS route).
Questions
Which ATT&CK figure does 786 Cyber quote on its website?
The figure from CIS’s published mapping of the CIS Controls v8.1 to MITRE ATT&CK: 1,467 coverage links across 383 techniques. It is the more conservative of our two sources and comes from an external, published mapping.
Why use MITRE’s mitigation data as well?
It works at the level of one specific control, such as MFA for remote and cloud access, rather than a whole subject. That makes it the right source for showing which attacks a missing control leaves more open.
Does a mapped technique mean the control stops that attack?
No. A mitigation reduces the risk of a technique. It does not detect or stop it every time, so we say a control helps defend against a technique, never that it covers it.
Sources
- MITRE ATT&CK Enterprise v20.1, mitigations and their “mitigates” relations, from MITRE’s published STIX data: attack.mitre.org/mitigations/enterprise
- CIS Controls v8.1 mapping to MITRE ATT&CK, published by the Center for Internet Security: cisecurity.org
- Our control model and its review: the Compliance & Control Galaxy shows both sources for any specific control, marked “CIS”, “MITRE” or “CIS + MITRE”.