MITRE ATT&CK Framework for
Penetration Testing Guide

The following illustrative example shows how a single raw finding is transformed into a mapped chain. This is a hypothetical scenario, not a client engagement, but it demonstrates the exact output format you should expect from a well-mapped report. Notice how each raw finding is not just labelled but also given a concrete detection implication that your SOC can act on.

Read this as an attack chain, not four isolated labels. The tester did not just find a misconfiguration; they turned it into a full attack path: they gained initial access, stole credentials, and then moved laterally across the network.

Each row's detection column feeds the next step, which is why the chain is more useful to a defender than a list of CVEs. If the report stops at the tactic name or omits the detection question, you have not received a fully mapped finding.

Mapping penetration testing findings to the MITRE ATT&CK framework requires a systematic transition from raw technical observations to classified adversary behaviours.

1. Analyse the raw finding to identify the underlying behaviour. Distinguish between what the tester did and the weakness that allowed it.
2. Determine the primary tactic objective, which is the goal the action achieved, such as Initial Access or Privilege Escalation. If a single action served two purposes, choose the dominant one and note the secondary in the chain.
3. Select the most specific technique or sub-technique that describes the behaviour. Start broad, then narrow to a sub-technique only if the evidence supports it.
4. Verify the chosen technique ID against the official technique record on attack.mitre.org, as the framework is versioned and updated. A revoked ID is a red flag in a provider's report.
5. Note the detection implication for each mapping, which is the specific log source or alert rule that would have identified the behaviour. If you cannot state one, the mapping is incomplete.
6. Repeat for each finding, then assemble the findings into attack chains that tell the story of the breach rather than a flat bullet list.

How deep to map: Map to the sub-technique level only when the evidence from the test clearly supports that level of detail. For example, you might know the exact mechanism of credential dumping was LSASS memory access, which justifies T1003.001. If the evidence only shows credentials were harvested without confirming the source, map to the parent technique T1003 and state that the confidence is at the technique level.

This declared honesty is a marker of a high-quality report and prevents over-claiming in front of your SOC. The precision of these testing approaches often depends on the level of visibility the tester has during the engagement.

What doesn't map: ATT&CK describes adversary behaviours, not every security weakness. A pure misconfiguration, such as an expired TLS certificate or a missing security header, is a hygiene weakness without a corresponding adversary behaviour. These should be reported using severity frameworks. You only map the exploitation act, if one occurred. For example, a missing MFA control is not itself a technique, but a successful account takeover via a brute-force attack against that account maps to T1110.

Be aware that analyst-performed mapping is more reliable than automated tagging. Automated tools can provide a starting point, but they often lack the context needed to select the correct technique or build a realistic chain. Ask your provider which approach they use. An analyst who can explain why one technique was chosen over a similar alternative demonstrates a higher level of rigour than a tool that simply pattern-matches.

Both the 5-step and 7-step pentesting conventions circulate in the industry, and neither is canonical. Regardless of how you divide the work, ATT&CK mapping fits into the process as a classification layer over the exploitation and post-exploitation phases; it is an analytical pass that runs alongside the technical work rather than a standalone phase.

Correction: ATT&CK is a classification language, not a methodology. The two run in parallel.

The matrix layout is a conceptual arrangement of tactics, not a strict chronological attack sequence, so avoid assuming an attacker will follow the matrix from left to right. A real intrusion might bounce between Discovery, Credential Access, and Lateral Movement several times before the objective is reached. When this leads to a retest, the verification of fixes ensures that the specific mapped technique is no longer viable.

To get the best results, agree on the mapping depth and tactic scope during the scoping phase, not after the report is written. This ensures that the ATT&CK coverage is planned, not incidental, and is a key part of defining the test scope.

Furthermore, the known TTPs of adversary groups can inform the test scope, which is known as threat-informed scoping. If a specific threat actor is a concern for your sector, the tester can prioritise the techniques that actor is known to use.

Different test scopes naturally exercise different parts of the ATT&CK matrix. Understanding which tactics are typically evidenced by specific engagement types prevents disappointment when a report does not show the coverage you assumed.

The key takeaway is that ATT&CK coverage is driven by scope; if a report does not include Exfiltration, it is often a scope decision rather than a quality failure. This is why distinguishing between internal network tests and external assessments is so important for managing expectations.

Likewise, an Impact technique like data destruction is rarely tested because the operational risk outweighs the evidence value. Because the final scope is always agreed per engagement, it is critical to align your expectations with the provider before the test begins. Ask what tactics the proposed scope will realistically evidence and record that answer in your scoping notes.

These are the failure modes to look for when reviewing a provider's sample or delivered report. Spotting these patterns allows you to rapidly diagnose whether the mapping is providing analytical value or is merely decorative.

• Tactic-only tagging
  How to spot it: The report labels findings as “Initial Access” or “Lateral Movement” but never identifies a specific technique or technique ID. The tactic is a category, not a finding; without the technique, the SOC does not know what specific behaviour to look for.
• ID wallpaper
  How to spot it: Every finding has a technique ID, but there are no chains, no rationale for the selection, and no detection implications. It is just a list of IDs that adds no analytical value over a standard CVE list.
• Aspirational mapping
  How to spot it: The report claims a technique that the scope never actually exercised, such as an external test claiming a detailed Lateral Movement technique without having gained internal access. This often stems from automated tagging that pattern-matches a finding to a broad range of techniques.
• Severity drift
  How to spot it: The report uses an ATT&CK ID as a proxy for severity. A technique ID is not a CVSS score; a low-severity misconfiguration that enables a high-value technique is more behaviourally significant than the raw CVSS number suggests.

Use the following criteria as a checklist when evaluating a sample report or the quality of a delivered engagement. All of these points should be visibly present; if a provider cannot show you a sample that meets these criteria, treat that as a risk signal.

• ☐ Precise Technique IDs: Findings carry technique IDs at the most precise defensible level, whether that is a technique or sub-technique, and the report states which level applies.
• ☐ Procedure Narratives: Each mapping includes a procedure narrative that explains how the tester did it, mirroring ATT&CK’s own procedure-example convention. This narrative should be specific enough for a detection engineer to act on without a call.
• ☐ Attack Path Chaining: Mappings are chained into attack paths rather than presented as isolated labels, showing how a tester moved from one tactic to the next to tell a coherent story.
• ☐ Detection Implications: Detection implications are stated for each mapped technique, telling the SOC what to look for and converting the mapping from a label into a testable hypothesis.
• ☐ Rationale for Ambiguity: Ambiguous mappings explain the rationale for the choice; where a finding could map to multiple techniques, the report discusses the possibilities rather than silently picking one.
• ☐ Explicit Unmappable Flags: Unmappable findings are explicitly flagged as such without trying to force them into a technique. A finding that does not map is not unimportant; it is just outside the behavioural taxonomy.
• ☐ Declared Confidence Levels: Mapping depth and confidence level are declared within the report, showing whether it is technique-level or sub-technique-level certainty.
• ☐ Analyst-Performed Mapping: The mapping is analyst-performed and the methodology is available on request. Automated tools may be used as a starting point, but an analyst must sign off on the final selection.

Heatmaps or ATT&CK layer visualisations are useful report appendices for a quick overview, but they do not replace narrative chains. A heatmap shows which tactics were hit but not how they connect. If you are assessing a provider, verify that any technique IDs cited in sample material are current against attack.mitre.org, as the framework is updated regularly. A citation to a revoked ID indicates the report was not verified against the live framework.

Questions to ask providers before you buy:

• Can you provide a sample report to review the mapping quality?
• What is your specific mapping methodology?
• Is the tagging performed manually by an analyst or automatically by a tool?
• Can you demonstrate samples that include detection implications and chained attack paths?

Asking these questions when evaluating a provider separates those who treat mapping as a reporting feature from those who treat it as an analytical discipline. Furthermore, a high-quality engagement should culminate in clear deliverables and remediation support that enable the SOC to move from the report to actual implementation.

A mapped report is only the beginning. The next step is to annotate each mapped technique to decide what your organisation did, or should have done, about it. This process converts the report from a list of problems into a set of actionable detection engineering tasks.

Use the following worksheet to map realised findings to SOC visibility and identify logging deficiencies.

Work through this table for every mapped finding, adding columns for ownership and remediation status as needed. For each technique, apply one of the following annotations:

• Detected: The behaviour was seen by your current controls. This is a validation of your detection stack. Record which alert fired so you can confirm it would fire again under similar conditions.
• Prevented: Your controls blocked the action. This is a validation of your prevention stack. Record which control blocked it so you know what to preserve in future architecture changes.
• Missed: The behaviour was not seen. This is your detection gap, and it is the row that requires action. Prioritise these before the detected and prevented rows.

For every “miss,” convert it into a concrete detection requirement. Determine which log source you would need, or which rule would have turned that miss into a detection. This is the definition of a detection gap analysis; the output is not a longer report but a shorter list of specific rules to build or buy.

The goal is to check that the technique IDs in your report align with what your SOC or SIEM already tracks. This is a core part of purple teaming, where offensive findings are handed to the defensive team to improve detection coverage.

The mapped report also becomes your baseline, which you can compare against future engagements to see if your defenses have improved. A retest that shows the same technique succeeding again tells you your detection gap remains open.

A penetration test maps the behaviours that the tester actually realised within an agreed scope, whereas a red team engagement emulates a broader set of adversary tradecraft to test detection against behaviours a penetration test might never touch. The distinction is not just about depth or duration; it is about what gets mapped and why.

The core distinction is simple: a pentest is not an adversary emulation exercise. You should not expect a standard pentest to imitate a named threat actor with precision. A pentest maps the behaviours a tester can realise with the vulnerabilities present; a red team emulates a defined threat profile to see if your detection would catch behaviours you did not know to look for.

Upgrading to a red team assessment makes sense if you encounter the following trigger conditions:

• Your mapped pentest report shows a thin spread of techniques across the tactics.
• You have a SOC that needs validation against a wider set of behaviours.
• You have a specific requirement to emulate named adversary behaviours rather than opportunistic ones.

For a deeper exploration of these advanced scenarios, consider red team assessments that emulate adversary behaviours beyond a pentest's realised findings.

ATT&CK, the Cyber Kill Chain, CVSS, and OWASP answer fundamentally different questions. Understanding these differences prevents you from forcing one framework to do the job of another; a good pentest report may use all four, but it will not present them as interchangeable.

It is critical to reinforce that ATT&CK IDs are not severity ratings. Severity and behavioural significance are independent axes; a low-severity finding, such as a single instance of sensitive data exposure via an unprotected share, can be evidence of a high-value technique like Collection (T1560), which could be part of a larger attack chain.

A finding with a low CVSS score can still be the pivot point for a full domain compromise, which is why the chain matters more than the score. For those focusing on web apps, combining ATT&CK with OWASP standards provides a complete picture of both application weakness and adversary behaviour.

Implementing ATT&CK-mapped reporting is a worthwhile investment for organisations planning to use the findings to improve their security posture over the long term. It is not a universal requirement, and the honest answer is that some buyers will not benefit from it.

For a small, unmanaged estate with no internal technical team, a standard findings report may be sufficient. The extra effort of mapping adds little if there is no one to act on the detection implications. In that context, a clear CVE list with prioritised patching guidance is a better use of the provider's time and your budget.

One objection is that ATT&CK was built for defenders, so why use it in a pentest? Because it is the perfect bridge between the two. It takes offensive output and translates it into a language the SOC and SIEM already understand. The framework is maintained with real-world intrusion data, so the labels carry meaning for both sides of the fence.

Another is that this is just report embellishment. Mapping is worth paying for when it meets the quality criteria listed in this guide. If the report shows “ID wallpaper” or does not go beyond the tactic level, you are paying for buzzwords and should challenge the provider on it.

This structured approach also aids UK organisations in translating technical findings into board and audit-consumable risk language, supporting better governance without replacing your specific compliance obligations. For London and UK-based organisations, adopting this approach positions your reporting to meet the expectations of investors and regulators who increasingly demand to see a direct line between a technical test and business risk. The structured taxonomy makes it easier to evidence that security testing is informed by real-world adversary behaviour rather than a generic vulnerability checklist.

Find definitive answers to common questions regarding the application of the MITRE ATT&CK framework within professional penetration testing engagements.