ATT&CK lists mitigations for a technique and your estate implements all of them. Is it handled?

## What a mitigation entry actually is Each mitigation on a technique page is a named class of defence with an `M####` identifier — things at the altitude of *privileged account management*, *password policies*, *multi-factor authentication*, *disable or remove feature or program*. It is a pointer to a family of controls, written to be true across every estate that could ever read the page. That generality is exactly what makes it useless as a completeness test: a sentence that must hold for a two-person company and a global bank cannot also specify what either of them must configure. So "we have all of them" decomposes into three separate claims, and the page supports none of them. ## Claim one: the class is implemented Usually true, and usually irrelevant. Every organisation of any size has *some* privileged account management. The question the technique poses is whether the control removes the specific thing the behaviour depends on, in the places where the behaviour would occur. A control class implemented for the datacentre and not for the three legacy hosts nobody owns is, from the adversary's point of view, not implemented — they only need the exception. The catalogue does not know your exceptions and cannot ask about them. ## Claim two: the list is complete The mitigations section is not an exhaustive specification of everything that would frustrate the behaviour, and it is not ordered by effectiveness. Two entries on a page can be wildly unequal: one may remove the precondition the technique cannot substitute, the other may merely raise the cost slightly. Nothing on the page distinguishes them, because there is no effectiveness field any more than there is a severity field. More pointedly, some techniques carry an explicit note that they **cannot be easily mitigated with preventive controls**, because the behaviour consists of legitimate system functionality being used as designed. There the list is short or effectively empty, and reading emptiness as "nothing can be done" is the mirror-image error to reading a full list as "everything is done". What it actually means is that the leverage has moved: away from blocking the behaviour, toward removing the precondition it depends on, constraining what it can reach, or making the operator substitute something more expensive. ## Claim three: therefore the ordering is settled This is the part the argument is usually smuggling. "We have all the mitigations, so this technique is not a concern" is a statement about *rank*, and rank is precisely what the catalogue does not hold. There is no severity value for the mitigations to have reduced, and no residual figure left over after they are applied. The page cannot certify your estate against a behaviour any more than it can rate that behaviour's danger, and the sentence quietly assumes both. ## How to make the claim checkable Rewrite it in terms the estate can answer. Instead of *we implement every listed mitigation*, say what the behaviour cannot do without, and then state where that thing has been removed and where it has not: *this behaviour requires X; X is unavailable on every host in scope except these nine, which are owned by that team and tracked*. Now the claim has a subject, a scope, an exception list and an owner, and someone can disagree with it on facts. That rewriting is also the honest version of the mitigations section's real value. It is a prompt — a short list of the defence families that are usually relevant to this behaviour, so you do not start from a blank page. It is a good prompt. It is not an audit. ## The pattern to recognise "We are fully patched, so we are safe" and "we have every listed mitigation, so it is handled" are the same argument. Both substitute the completion of a list someone else wrote for a claim about your own estate, and both are attractive because the list is finite and the estate is not. Naming that structure out loud is usually the strongest thing you can say in the room.