Do Not Mitigate (M1055)

Defensive objective

Do Not Mitigate is the defensive objective identified by MITRE ATT&CK® as M1055. In practical terms, the objective is to represent a deliberate decision not to apply a direct preventive treatment to a specific adversary behavior while governing the remaining risk.

The mitigation should be treated as a control objective rather than a product label. An organization still has to identify the systems, identities, data, workflows, and adversary behaviors that are in scope, then choose technical and procedural safeguards appropriate to its architecture.

A useful implementation makes the boundary of Do Not Mitigate explicit: where it applies, who owns it, what evidence demonstrates operation, what exceptions remain, and which detection, response, and recovery layers address residual risk.

Do Not Mitigate is not permission to ignore risk, disable monitoring, or leave ownership undefined. It records that direct preventive treatment is not being applied and therefore demands an explicit residual-risk decision with compensating detection, response, resilience, and recovery.

Scope and design decisions

Governance mitigations turn threat, vulnerability, control, audit, and human-behavior information into owned decisions with measurable evidence and reassessment.

For Do Not Mitigate, begin with the decision points that make the relevant adversary behavior possible. Map the required access, privilege, trust, exposure, configuration, and dependencies before choosing enforcement. This prevents a broad control statement from hiding uncovered platforms or alternate paths.

• Define the decision or behavior the mitigation is intended to improve.
• Assign accountable owners for operation, evidence, findings, exceptions, and remediation.
• Use current threats, assets, business impact, and control dependencies to set scope.
• Measure quality and risk reduction, not only activity volume or completion.
• Set review triggers for incidents, architecture changes, threat shifts, and expired assumptions.

Implementation priorities

The implementation priorities below turn M1055 into an operating capability. They are intentionally technology-neutral so they can be applied to on-premises, cloud, hybrid, endpoint, application, identity, and service-provider environments.

Sequence the work so visibility and rollback exist before disruptive enforcement. High-consequence controls should be introduced through representative testing, documented change authority, and a time-bounded exception process.

• Identify the exact ATT&CK behavior, systems, identities, and business processes covered by the decision.
• Name the executive or business risk owner who is authorized to accept the residual risk.
• Document why direct mitigation is infeasible, disproportionate, deferred, or intentionally excluded.
• Require compensating detection, response, containment, continuity, and recovery measures.
• Set an expiration date and reassessment triggers for threat activity, exposure, architecture, impact, or control changes.
• Retain evidence that the decision was reviewed and remains within the organization’s risk authority.

Validation and evidence

Validation should show that Do Not Mitigate is deployed where intended, resists unauthorized change, produces usable evidence, and affects the targeted path. A policy document or enabled feature is not enough by itself.

Use at least one controlled positive test, one controlled negative test, and one legitimate business workflow. Confirm timestamps, identity attribution, field meaning, retention, alert delivery, escalation, and recovery. Evidence should support both operational troubleshooting and an independent assurance review.

• Program charter, scope, authority, roles, criteria, and operating cadence
• Threat, vulnerability, audit, training, risk, and decision records
• Finding, remediation, escalation, acceptance, and closure-validation evidence
• Quality, timeliness, coverage, behavior, and outcome metrics
• Lessons learned and documented changes to controls, priorities, training, or response

Common failure modes

Do Not Mitigate can appear complete while leaving meaningful bypasses. The following conditions should be treated as test hypotheses, not merely checklist cautions.

Where a failure mode cannot be removed immediately, record the residual risk, compensating visibility, response expectation, accountable owner, and date by which the decision must be reconsidered.

• The program measures activity counts without showing which decision or risk changed.
• Findings and risks lack accountable owners, deadlines, or closure evidence.
• Threat information is collected but not translated into architecture, detection, vulnerability, or response action.
• Training is generic and completion-based rather than role- and threat-informed.
• A risk assumption remains in force after the environment, exposure, or adversary behavior changes.

Ownership, exceptions, and review

The business or risk owner decides how much residual risk is acceptable; the control owner designs and maintains Do Not Mitigate; operators respond to control health and security events; and assurance functions independently evaluate evidence. Those roles may be performed by different teams, but they should not be left implicit.

Every exception should state the affected asset or population, business reason, approving owner, compensating controls, monitoring requirement, expiration date, and reassessment trigger. A change in exposure, privilege, data sensitivity, threat activity, platform support, or recovery capability should force review before the ordinary cadence.

• Name the risk owner, control owner, operator, and independent reviewer.
• Set measurable coverage, health, effectiveness, and response indicators.
• Require expiration dates for exceptions and temporary workarounds.
• Retain evidence of approval, testing, incidents, remediation, and closure.
• Reassess after material threat, architecture, identity, data, or supplier changes.

Using this mitigation with ATT&CK

ATT&CK associates mitigation objects such as M1055 with adversary techniques and sub-techniques for which the defensive objective may be relevant. A relationship is a research and engineering lead—not a guarantee that one implementation prevents every procedure represented by a technique.

Start with the observed or prioritized adversary behavior, inspect the official relationship and its supporting context, then determine whether this mitigation changes a required precondition, blocks an action, limits consequence, improves recovery, or creates evidence. Preserve the distinction between preventive coverage, detective visibility, response readiness, and resilience.

Bare Metal Cyber will add a separately validated relationship layer in a later release. This foundation release does not fabricate or overstate technique coverage where the official relationship edge has not yet been imported and reviewed.

Attribution, version, and scope

© 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation.

MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation. Bare Metal Cyber is not affiliated with or endorsed by MITRE.

This is an original Bare Metal Cyber educational profile reviewed against Enterprise ATT&CK catalog v19.2. The official M1055 page controls the current object name, status, version, relationships, source citations, and changes. MITRE identifier, name, version, creation date, modification date, and official URL are preserved as source metadata; the explanatory and implementation guidance is original.

Certification relevance

This subject appears in or supports the following certification bodies of knowledge:

Authoritative sources

• MITRE ATT&CK® M1055 — Do Not Mitigate
• MITRE ATT&CK® Enterprise Mitigations
• MITRE ATT&CK® Data & Tools
• MITRE ATT&CK® Legal and Branding Guidance