What’s new in Cymph: Feature release round-up Q2 2026

At Cymph, we ship toward one goal: giving security teams a complete, always-current picture of their response readiness, and everything they need to act on it.

This round-up covers three additions that push that further. A new operational layer for running manual procedures. A new category of coverage visibility that connects what your SIEM detects to what your team can actually respond to. And new integrations that make it easier to pull procedures into Cymph from wherever they already live.

‍

Executions: Run and audit manual procedures without leaving Cymph

Running a manual response procedure is rarely as simple as it sounds. In practice, most teams spread the work across a ticket, a message thread, a shared document, and whatever else is at hand. It holds together until it doesn't, and when it breaks, the gaps become visible: steps missed, ownership unclear, a post-incident scramble to reconstruct what actually happened.

Executions gives teams a single, structured environment to run those procedures from start to finish.

When a procedure is ready to run, an execution owner starts it directly from within Cymph, assigns steps to specific people, and the team works through it in a shared view where every action is tracked in real time. Step status updates, notes, attachments, and skip or fail reasons all sit in one place. When the execution closes, an immutable, timestamped audit record is generated automatically. No reconstruction effort. No gap in the evidence.

This is not automated orchestration. Executions is designed for the procedures that require a person to act, decide, or verify, the steps that live outside a SOAR. For responders participating in more than one concurrent execution, a personal task queue shows every assigned step across all active runs in a single view.

For the full breakdown of how Executions works, including use cases for both live incidents and tabletop exercises, read the dedicated article.

‍

Detection-to-response dynamic coverage maps: Know if you can respond to what you detect

Detection coverage and response readiness are related, but they are not the same thing. Knowing which threats your SIEM detects is one question. Knowing whether your team has a procedure ready to respond to each of those threats is another, and it is often the harder one to answer.

Detection coverage tells you what your tooling can see. Response readiness tells you what your team can do when something gets through. Until now, connecting those two pictures required manual work: exporting detection rules, cross-referencing MITRE ATT&CK tags, checking which techniques had procedures in the playbook library. Even when teams did it, the result was a point-in-time snapshot that went stale the moment either side changed.

Cymph now does this continuously. By connecting directly to your SIEM, Cymph fetches your detection rules, extracts their MITRE ATT&CK tags, and uses them to automatically scope a coverage preset to the techniques your environment actually detects.

The result is a live map that shows, for each detected technique, whether a response procedure exists, where coverage is partial, and where there is nothing at all. Tactics with no coverage surface immediately, and drilling into any uncovered technique shows the specific gap.

The loop closes without leaving the platform. From a missing technique, a draft playbook can be generated directly, refined in the no-code editor, and added to the library. The coverage map updates to reflect it.

Supported SIEM integrations:

• Microsoft Sentinel. Import playbooks and incident workflows from Microsoft's SIEM platform. Detection rules are used to scope coverage presets dynamically, giving teams running Sentinel a continuous detection-to-response view across the techniques their environment monitors.
• Wazuh. Connect your Wazuh instance and import workflows based on its alerts and detections. MITRE ATT&CK tags from Wazuh detection rules drive automatic preset scoping, so the coverage map reflects what Wazuh actually sees, not a manually selected subset of the framework.

‍

New integrations: SharePoint, GitLab and GitBook

Response procedures don't live in one place. They never have. Some teams version-control them in code repositories. Others maintain them in documentation platforms alongside the rest of their technical knowledge base.

Cymph's job is to meet procedures where they are, so they can be included in the coverage map and kept current, without requiring anyone to rebuild them from scratch.

Three new integrations extend that reach:

• SharePoint. Files stored in SharePoint can be imported directly into Cymph. If you maintain processes and playbooks there, you can bring them seamlessly into your library, map them to frameworks and govern them.
• GitLab. Teams that store playbooks or workflow files in GitLab repositories can now import them directly into Cymph. If your procedures are already version-controlled there, they no longer need to be duplicated to be visible in your coverage map.
• GitBook. Security documentation maintained in GitBook can now be brought into Cymph without manual copying. Procedures that already exist in a team's GitBook knowledge base become part of the unified inventory, mapped to frameworks and included in gap analysis alongside everything else.

Both integrations reinforce the same principle: the more completely Cymph reflects what your team actually has, the more accurate and useful your response coverage picture becomes.

‍

Get started

All of the above is available now. If you're already using Cymph, log in to explore these capabilities. If you're evaluating the platform, book a demo to see how they work together.

‍