MITRE ATT&CK
MITRE ATT&CK is the public catalogue of adversary tactics and techniques that MITRE has maintained since 2013, built from incidents observed and publicly reported. It trades a vague sense of being protected for a checkable list: which behaviours your environment sees today, which pass without leaving a trace, and which of them stand any chance of turning up in your sector.
ATT&CK is the knowledge base that describes how attacks actually unfold, maintained by MITRE and adopted by defence teams worldwide. What DM11 delivers is the measurement of your detection coverage against the techniques relevant to your sector, the gaps in order of risk, and the same vocabulary applied to simulation exercises and penetration test reports. Where the goal also includes a document to send a customer, the ISO 27001 or SOC 2 pages explain that route.
Who runs the mapping
CEH, ethical penetration testing certified by EC-Council
SYCP and SYES, exploitation and post-exploitation from Solyd
DSFE, digital forensics applied to incident response
17 years of governance, risk and compliance
WHAT IT IS
MITRE started ATT&CK in 2013, inside a research project investigating whether endpoint telemetry and behavioural analysis were any use in detecting someone already inside the network. The catalogue grew out of public incident reporting and published research, and today it describes adversary behaviour across three domains: enterprise environments and cloud, mobile devices, and industrial control systems. It is updated twice a year, and the current version is 19, released on 28 April 2026.
The tactic is the adversary's goal at that moment, such as obtaining credentials or moving across the network. The technique describes the way of reaching that goal, and the sub-technique goes one level down to say exactly which variation was used. Below them sit procedures, the uses observed in the wild, each with the public reference it came from. In version 19 the enterprise domain holds 15 tactics, 222 techniques and 475 sub-techniques. The tactic count is worth noticing: until the previous version there were 14, and version 19 split the old evasion tactic in two, separating what an adversary does to hide from what it does to break the tooling that watches it.
The enterprise matrix covers Windows, macOS, Linux, network devices, containers, infrastructure and software cloud services, office suites and identity providers. The mobile matrix covers Android and iOS, with 12 tactics, 77 techniques and 47 sub-techniques. The industrial matrix covers control systems, with 12 tactics, 79 techniques, 18 sub-techniques and 18 asset types typical of a plant floor, and it only gained sub-techniques in version 19. A company with an industrial environment that measures coverage using the enterprise matrix alone is measuring the wrong environment, and that confusion is frequent.
The catalogue also records 178 threat groups, 949 pieces of software, split between legitimate tooling and malicious code, and 59 campaigns, all tied to the techniques each of them used. That is what lets you ask who you need to defend against before asking what you need to detect. MITRE is explicit about the limit: the mapping comes only from public reporting, so it represents a subset of what any group can actually do, and group names used by different vendors overlap without coinciding. Reading those maps as if they were the complete list is the commonest mistake made by anyone starting alone.
Worth settling the expectation early, because it shapes the plan. What the work produces is a coverage map, technique by technique, recording what was tested and what the detection actually registered. MITRE does not accredit consultancies, does not assess companies, and the ATT&CK terms of use forbid any use of the name that suggests endorsement of a vendor or a service. Where your customer needs a document issued by a third party, ISO 27001 or SOC 2 is what answers that, and the evidence produced here carries into that project intact, because the ability to detect and respond is required by both.
WHO USUALLY NEEDS IT
None of them starts with someone demanding a document. ATT&CK comes in when the question is about what the environment genuinely sees, rather than about what the security policy says.
There is an endpoint tool, there is an event correlation platform and there is a team watching dashboards. When somebody from outside asks what the company is protected against, the only answer available is the vendor's own marketing material. Measuring coverage against known techniques replaces that material with a result of your own, obtained in your environment.
The team responded, contained and wrote a document that is a list of alerts with timestamps. Nobody can reconstruct how the attacker got in, what they did to stay, or how far they reached. Without that thread there is no way to know which control would have cut the route, and the next occurrence starts the investigation from scratch.
The report holds a list of vulnerabilities ordered by severity, and the board cannot see a consequence in any of them on its own. Once each step of the test is tied to a technique, the sequence appears that led from a mundane foothold to the data that matters, and that is what gets the budget approved.
STORIES
We change our clients' names with the same confidentiality that will protect your company later. The names change; the pattern of the problems repeats. Where a client agrees, we give named references in a conversation.
Healthcare
A network of healthcare sites had swapped its endpoint solution for a well-rated one on the market and kept an outsourced team watching alerts. The question the clinical board kept asking was simple and never answered: if ransomware of the kind reported across the sector arrived, would the company notice before or after the patient records stopped.
We narrowed down the techniques most associated with groups known to attack healthcare providers and measured coverage of each one in the live environment, running each behaviour under control and checking what the dashboard showed afterwards. Nothing was accepted on the strength of vendor documentation.
Execution and persistence came out well covered, which was what a good endpoint tool should deliver. Credential access and lateral movement between servers passed almost entirely without an alert, because server authentication logging had never been forwarded anywhere. The most valuable fix in the project was switching on a log source that already existed.
Energy and utilities
After an incident contained in a hurry, the company had two reports of the same event: one written by corporate security, in the vocabulary of alerts and signatures, and one written by the automation team, in the vocabulary of process and downtime. The two versions never met, and the discussion about what to invest in stalled for months.
We rewrote the incident timeline once, with every step tied to a technique, using the enterprise matrix for the office stretch and the industrial matrix for the automation stretch. Where the evidence did not support a step, we recorded the gap as a gap rather than filling it with a hypothesis.
The single narrative showed that the crossing between the two environments had happened through an engineering workstation with access to both sides, and that neither team monitored it, each treating it as the other's responsibility. The investment decision came out of the next meeting, and the report format became the standard for later incidents.
Higher education
The institution commissioned a penetration test every year and always received the same format: a list of findings with a severity rating. IT fixed the critical items, the medium ones rolled from one year into the next, and the chancellery never understood why it mattered, because no single item looked serious.
We ran the next test with every step mapped to a technique, from first access to the agreed objective, and recorded step by step what the detection saw, what it merely logged and what it ignored completely. The report acquired a route, along with the points where it could have been cut.
The route to the academic database ran through three medium-severity findings that had been deferred for two cycles. Put in sequence, they stopped being list items and became a script, and the chancellery approved fixing all three in the same week it read the report.
HOW WE RUN IT
The step that separates this work from a handsome report is the third. Coverage declared in vendor documentation stays off the map. Only a technique executed under control in your environment goes on it, with a record of what the detection did about it.
MITRE itself advises against chasing total coverage, because every organisation faces its own set of threats and not every technique applies to everyone. We start by choosing groups, campaigns and techniques with a real bearing on your sector, your technology and what has already happened to comparable companies, and we record the reason for each inclusion.
A threat profile for the sector, with the relevant groups and campaigns
A prioritised list of techniques, with the reason for each inclusion recorded
The matrices in scope agreed: enterprise, mobile and industrial
The exclusion criteria recorded, covering what was left out and why
Delivery milestoneThe technique shortlist agreed with your team, with a justification per technique.
Before any talk of detection rules, we establish what telemetry exists, where it comes from and how long it is kept, because a technique with no matching data source cannot be detected by any tool at all. Only then do we assess, technique by technique, whether a rule exists, whether it is enabled and whether anyone reads it.
An inventory of telemetry sources, with origin and retention
An assessment per technique, separating what is not collected from what is collected and not analysed
A visual coverage map, readable on one screen
Gaps ordered by risk and by the effort needed to close them
Delivery milestoneCoverage mapped per technique, with the data source each one requires identified.
We execute the selected techniques under control, in an agreed window and with everything recorded, and compare what should have been detected against what the operation actually saw. Where the scope includes a penetration test, every step of the test is tied to a technique, so the report delivers a route travelled along with the points where it could have been cut.
Controlled execution of the prioritised techniques, with evidence of what was done
A comparison of expected detection against observed detection
A penetration test report with each step mapped to a technique
The interruption points identified along the route
Delivery milestoneEvery technique executed with a record of what the detection saw, what it merely logged and what it ignored.
We turn the gaps into a plan with an owner and a date, alongside your team or your monitoring provider, and measure again using the same method so the result is comparable. Since the catalogue is updated twice a year, we also settle who rereads the shortlist at each release, because new techniques arrive and technique names change.
A closure plan with an owner and a date per gap
Rules and log sources adjusted alongside the team or the provider
A second measurement comparable to the first, with the catalogue version recorded for both
A rereading routine defined, with who reviews and how often
Delivery milestoneSecond measurement completed with the same method, showing the direction of travel.
HOW LONG IT TAKES
We do not publish a standard timeline, because a published timeline turns into a promise. The initial shortlist is usually the short part; the proof is the part that varies, because it depends on an agreed window and an available environment. These are the three factors that move the clock most, and the first conversation already shows which one your company is in.
The enterprise environment alone is a project with a visible end. Adding mobile devices widens it a little. Adding an industrial environment changes the size of the project, because the industrial control matrix has its own tactics, its own assets and testing constraints that do not exist in an office.
A company with central collection and a defined retention period starts measuring in the first week. A company that discovers halfway through that domain controller logs vanish after seven days has to fix collection before measuring coverage, because no detection rule works over data that was never kept.
In a lab faithful to production, execution moves quickly. In production, each technique needs an agreed window, an approval and a rollback plan, and that is negotiated with whoever answers for availability. The conversation starts early in the project, because it is the one that stretches the schedule most.
FREQUENTLY ASKED
The questions that come up in almost every first meeting, answered straight.
There is none. MITRE maintains the catalogue, publishes an update twice a year and makes it available at no charge to any person or organisation, and it accredits no consultancy and assesses no company. The terms of use are explicit in forbidding any use of the name that suggests endorsement of a product or a service, and this page follows that rule. What the work delivers is your coverage map, measured, with evidence of testing. If what you need is a document to send a customer, ISO 27001 or SOC 2 are worth looking at.
Narrowing down the techniques relevant to your sector and measuring coverage in your environment answers, with evidence of testing, the question the tool you bought cannot answer on its own. It is the cheapest possible start, and it serves both the company adjusting what it already has and the one that will certify later.
Comparisons on this subject
See all 13 comparisons