> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cymph.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Identify and close response gaps
> Define what you should be ready for, measure your playbook coverage against it, and generate the procedures you are missing.
Are your response procedures actually covering the threats that matter to your organisation? Cymph gives you a structured way to answer that question using established cybersecurity frameworks such as MITRE ATT\&CK, D3FEND, ATLAS and NIST CSF 2.0, and compliance standards such as ISO 27001, NIS2, GDPR and DORA.
The model is simple:
1. [Decide what you should be ready for](#1-define-the-scope) by defining a scope, either by hand or derived from what your security stack actually detects.
2. [Measure response coverage](#2-measure-response-coverage) by mapping your playbooks to that scope.
3. [Find the gaps](#3-find-the-detection-to-response-gap), in particular the techniques you can detect but cannot yet respond to.
4. [Close them](#4-close-the-gap) by generating the missing playbook, then reassess.
All of this happens in the **Mind Maps** section. If you are new to it, read [Mind Maps](/key-features-explained/mindmaps) first: it explains frameworks, presets and coverage.
# 1. Define the scope
A framework such as MITRE ATT\&CK is deliberately broad. It covers platforms, tactics and techniques that may have nothing to do with your environment. A **preset** is your tailored version of a framework: the subset of techniques or controls that you want to measure readiness against. Cymph gives you two ways to establish that subset.
## Path 1: Custom scope
Start from what you decide matters. Create a preset, pick a framework and version, and select the techniques yourself. For example, a preset named **Ransomware Readiness** based on MITRE ATT\&CK for Enterprise would include initial access, credential access, lateral movement and impact techniques typically seen in ransomware campaigns.
You do not have to click through the matrix manually. The scope can also be imported from a **MITRE ATT\&CK Navigator layer** or from a set of **Sigma rules**, which is useful when a threat intelligence team or an assessment has already produced a technique list. Cymph also offers ready-made **scenarios**, such as phishing or ransomware, as a starting point.
Custom scopes suit questions like: are we ready for this threat, this customer environment, or this audit?
See [Manage presets](/how-tos/create-and-manage-presets) for the full wizard, and in particular [Step 2: Select the scope source](/how-tos/create-and-manage-presets#step-2-select-the-scope-source).
## Path 2: Detection-derived scope
Or start from your live environment. Connect Cymph to your SIEM and let your detection capabilities define the scope. Cymph reads the detection rules from the integration, collects the MITRE ATT\&CK technique tags on each rule, and turns the result into the preset scope. When several integrations are selected, their techniques are merged.
Supported detection sources are [Wazuh](/integrations/detection/wazuh), [Microsoft Sentinel](/integrations/detection/microsoft-sentinel), [Splunk Enterprise Security](/integrations/detection/splunk-es) and [Cortex XSIAM](/integrations/detection/cortex-xsiam). The integration must exist in the workspace before you can pick it in the wizard. See [Configure live source](/how-tos/create-and-manage-presets#configure-live-source).
Detection-derived scopes stay in sync with your SIEM. Cymph refreshes the scope from the configured sources whenever the preset is opened, so a rule added or removed in your SIEM is reflected the next time you look at the preset.
Both paths produce the same thing: a set of techniques that should have response coverage.
| | Custom scope | Detection-derived scope |
| ----------------- | ---------------------------------------------------------- | --------------------------------------------------------------- |
| **Answers** | What do we decide matters? | What can our security stack actually detect? |
| **Source** | Manual selection, Navigator layer, Sigma rules or scenario | Detection rules from Wazuh, Sentinel, Splunk ES or Cortex XSIAM |
| **Best for** | Threat, customer or assessment-driven readiness | Detection-to-response gap analysis |
| **Maintained by** | You | Your SIEM, refreshed automatically |
# 2. Measure response coverage
When you save the preset, you also choose which playbooks count towards coverage and what "covered" means. In the preset settings you scope the playbook set, for example only playbooks created by you or only those matching a saved filter, and in the coverage criteria you decide whether a mapped playbook is enough on its own or whether it must also have a certain status, such as Completed. See [Step 4: Configure the preset settings](/how-tos/create-and-manage-presets#step-4-configure-the-preset-settings) and [Step 5: Set coverage criteria](/how-tos/create-and-manage-presets#step-5-set-coverage-criteria).
Cymph then maps your playbooks to the scope through their framework mappings and shows you the result:
* **Insights** summarise coverage across the preset, for example the share of techniques covered and a per-tactic breakdown, so you can see at a glance where you perform well and where you fall behind.
* **Detailed Overview** shows every technique in scope. Green means covered, purple means partially covered, and grey means no playbook is mapped to it.
Coverage depends on playbooks being mapped to the framework. If your playbooks are not mapped yet, enable **Use automatic framework mappings when manual mappings are not set** in the preset settings, or set mappings on the playbooks with [AI suggestions](/howto/playbook_actions#ai-suggestions). Playbooks that are draft, revoked or expired never count towards coverage, so keep the stage of your playbooks accurate. See the [governance use case](/use-cases/governance) for how to keep that metadata in order.
# 3. Find the detection-to-response gap
With a detection-derived scope, the Detailed Overview becomes a direct comparison between what you detect and what you can respond to. Every technique in the preset is one your SIEM has a rule for. Every grey technique is therefore a place where you can detect an attack but have no defined procedure to respond to it.
Click a technique to see its details. For example, **T1548.003 Sudo and Sudo Caching** might show a detection rule in Wazuh but no mapped playbook. That is the gap this use case is about: you can detect it, but can you respond to it?
The same view answers the question for custom scopes, where a grey technique means a threat you decided matters but have not prepared a response for.
# 4. Close the gap
Identifying the gap is only the beginning. From an uncovered technique, Cymph can help create the missing procedure.
1. In the Detailed Overview, click the uncovered technique.
2. Browse the **detection** and **mitigation** strategies listed for it.
3. Click **Generate Playbook** on the strategy that applies to your context. Cymph AI drafts a playbook for that technique and maps it to the framework.
The generated playbook is a starting point, not a finished procedure. From here the workflow continues as with any other playbook:
* **Review and refine** it in the editor, and add the governance context described in the [governance use case](/use-cases/governance): responsible and accountable persons, review settings and linked assets.
* **Deploy** it to your SOAR or ticketing system if it should run there. See [Deploy playbooks](/how-tos/deploy-playbooks).
* **Reassess.** Any change to your playbooks is reflected in your presets automatically. Once the new playbook meets the coverage criteria, the technique turns green.
AI-powered playbook generation is available for MITRE ATT\&CK for Enterprise presets and requires the AI settings of your instance to be configured. For techniques where a template playbook already exists, the technique details also offer a **recommended playbook** that you can duplicate into your library instead. See [Closing the gaps](/key-features-explained/mindmaps#closing-the-gaps).
# Frameworks without framework maintenance
Whichever path you use, Cymph provides the underlying framework structure and keeps it up to date. Frameworks are versioned, and you choose the version when you create a preset, so a new release of MITRE ATT\&CK never silently changes the meaning of an existing preset. When imported tags do not match the selected version, the wizard reports them as validation errors instead of remapping or dropping them, and lets you switch version.
The currently supported frameworks and versions are listed under [Frameworks supported](/key-features-explained/mindmaps#frameworks-supported).
Define what matters yourself, or derive it from what you actually detect. Cymph shows you where you are ready and where response gaps remain.
The generated playbook is a starting point, not a finished procedure. From here the workflow continues as with any other playbook:
* **Review and refine** it in the editor, and add the governance context described in the [governance use case](/use-cases/governance): responsible and accountable persons, review settings and linked assets.
* **Deploy** it to your SOAR or ticketing system if it should run there. See [Deploy playbooks](/how-tos/deploy-playbooks).
* **Reassess.** Any change to your playbooks is reflected in your presets automatically. Once the new playbook meets the coverage criteria, the technique turns green.