Cyber Defense Matrix (CDM): Explained
The Cyber Defense Matrix (CDM) is a portfolio framework developed by Sounil Yu that arranges security capabilities into a 5x5 grid: five NIST Cybersecurity Framework functions (Identify, Protect, Detect, Respond, Recover) crossed with five asset classes (Devices, Applications, Networks, Data, Users). The 25 cells form a single-page view of where each security capability operates, which makes the matrix the canonical portfolio map for CISOs, security architects, security program leaders, AppSec teams, GRC owners, and security operations leaders. This guide covers the 5x5 structure, the People-Process-Technology cell decomposition, the Cyber Defense Diagonal between structural and situational awareness, how CDM differs from MITRE ATT&CK, MITRE D3FEND, NIST CSF 2.0, FAIR, SABSA, the DIE triad, and the CIA triad, the design pattern for portfolio mapping, the operating pattern for coverage drift detection, the measurement pattern for capability heatmaps, the framework crosswalks the audit reader expects, the recurring adoption pitfalls, and how to connect CDM-driven gap decisions into the operating record where findings, exceptions, and audit evidence live without producing a parallel slide deck.
What the Cyber Defense Matrix Actually Is
The Cyber Defense Matrix is a portfolio framework. It does not catalogue attacker techniques (that is the job of MITRE ATT&CK). It does not catalogue defensive countermeasures (that is the job of MITRE D3FEND). It does not catalogue audit controls (that is the job of ISO 27001, SOC 2, PCI DSS, NIST 800-53, and the other compliance frameworks). It does not define cybersecurity outcomes (that is the job of NIST CSF). The Cyber Defense Matrix sits one layer above all of those: it gives the programme leader a single-page view of where every security capability in the portfolio sits and what that portfolio looks like as a whole.
The 5x5 grid uses the five original NIST Cybersecurity Framework functions on the row axis (Identify, Protect, Detect, Respond, Recover) and five asset classes on the column axis (Devices, Applications, Networks, Data, Users). The asset classes are the columns because the asset class is the immutable subject of every security capability: a tool either operates on devices or it does not; a tool either operates on users or it does not. The functions are the rows because they describe the temporal lifecycle the capability participates in: the tool either identifies the asset class, protects the asset class, detects events against the asset class, supports response when events surface, or supports recovery when assets are impaired.
The framework was developed by Sounil Yu while he was chief security scientist at Bank of America, open-sourced and disseminated through public talks at RSA, Black Hat, and BSides, and documented canonically in the 2022 book Cyber Defense Matrix: The Essential Guide to Navigating the Cybersecurity Landscape. It is widely cited in CISO communities, security architecture practice, security strategy literature, and in the work of several adjacent frameworks. It is a living framework rather than a published standard: the 5x5 structure is canonical, but the contents of each cell evolve with the security tool category landscape.
The Five Asset Classes
The columns of the Cyber Defense Matrix are five asset classes. They are deliberately mutually exclusive and collectively exhaustive: every security capability operates on at least one of them, and most capabilities operate primarily on one. The discipline of placing each capability against its primary asset class is what makes the matrix readable as a portfolio rather than a tool list.
Devices
Physical and virtual endpoints, servers, mobile devices, IoT, OT, and embedded systems. The Devices column covers the host-tier discipline across the asset lifecycle: host inventory in Identify, host hardening in Protect, host-tier behavioural detection in Detect (EDR), host incident response in Respond, host restoration in Recover. Cloud workloads sit in this column because the workload behaves as a device for the security model even when it runs as a container or function.
Applications
Software running on devices, including web applications, APIs, mobile applications, internal applications, third-party applications, and language-runtime workloads. The Applications column covers the software discipline: software inventory and SBOM in Identify, secure development and WAF in Protect, RASP and application telemetry in Detect, application incident response in Respond, application restoration in Recover.
Networks
The connections between devices and applications, including LAN, WAN, cloud VPC, service mesh, VPN, SD-WAN, and the public internet edge. The Networks column covers the connectivity discipline: network discovery in Identify, segmentation and firewalls in Protect, network detection and response in Detect, network incident response in Respond, network restoration in Recover. Some cloud-native organisations have a hollow Networks column because they do not run their own network at the layer that produces meaningful security signal; the discipline still applies but the cell contents shrink.
Data
The information at rest, in transit, and in use across devices, applications, and networks. The Data column covers the information discipline: data discovery and classification in Identify, encryption, tokenisation, and DLP in Protect, data activity monitoring and DSPM in Detect, data incident response in Respond, data restoration in Recover. The Data column has grown substantially in importance over the past several years as the regulatory landscape (GDPR, CCPA, state breach notification, DORA personal data provisions) has put data risk at the centre of the board conversation.
Users
The human and non-human identities that operate against the other four asset classes, including employees, contractors, customers, service accounts, machine identities, and AI agents. The Users column covers the identity discipline: identity inventory and joiners-movers-leavers in Identify, IAM, MFA, and privileged access management in Protect, identity threat detection in Detect (ITDR, UEBA), identity incident response in Respond, identity recovery in Recover. The non-human identity surface (service accounts, machine identities, AI agents) is now treated as a first-class subset of the Users column in mature programmes.
The Five Functions
The rows of the Cyber Defense Matrix are the five original NIST Cybersecurity Framework functions: Identify, Protect, Detect, Respond, Recover. The order is a temporal lifecycle rather than a maturity progression: the programme does not graduate from Identify to Recover. Each function applies to each asset class on every cycle, and the portfolio gap can sit in any cell across any function row.
Identify
Discovery and inventory of the asset class and its attributes. For Devices this is asset inventory; for Applications this is software inventory and SBOM; for Networks this is network discovery; for Data this is data discovery and classification; for Users this is identity inventory and the joiners-movers-leavers feed. The Identify row is the structural awareness layer of the programme: it answers what is on the network, what software runs on it, what data resides where, and who has access. Identify gaps are the most common source of portfolio coverage drift because new assets appear faster than the inventory cadence catches them.
Protect
Preventive controls applied to the asset class. For Devices this is hardening, configuration management, and patching; for Applications this is secure development, code signing, WAF, and API gateway; for Networks this is segmentation, firewalls, and zero trust; for Data this is encryption at rest, tokenisation, and DLP; for Users this is identity and access management, MFA, and privileged access management. The Protect row is the largest in dollar terms in most enterprise portfolios because preventive tooling has the longest history and the largest vendor surface.
Detect
Monitoring and anomaly surfacing against the asset class. For Devices this is EDR; for Applications this is RASP, application telemetry, and ADR; for Networks this is NDR and intrusion detection; for Data this is database activity monitoring, DSPM, and data egress monitoring; for Users this is ITDR and UEBA. The Detect row is the start of the situational awareness side of the matrix: it answers what is happening right now and what just changed.
Respond
Actions taken when a detection or incident surfaces. For each asset class the Respond cell holds the playbook, the runbook, the case management surface, and the named containment action. Many organisations use one centralised incident response discipline rather than per-asset-class response disciplines, but the cell-level read still matters because the response shape differs by asset class: device containment is host isolation, application containment is workload rollback or feature disablement, network containment is segmentation, data containment is access revocation, and user containment is identity disablement.
Recover
Restoration of asset class function after an incident. For each asset class the Recover cell holds backup, disaster recovery, business continuity, and the post-incident learning loop. The Recover row is the most commonly under-invested across the portfolio because the work only matters when something has gone wrong, which makes it easy to underweight relative to the preventive controls in the Protect row.
The Cyber Defense Diagonal
The Cyber Defense Diagonal is a structural observation across the matrix: as the team moves from Identify to Recover across the function axis, the dominant capability shifts from structural awareness (what is on the network, what software runs on it, what data resides where, who has access) to situational awareness (what is happening right now, what just changed, what is in progress, what needs containment). Identify and Protect lean on structural awareness; Detect, Respond, and Recover lean on situational awareness.
The diagonal surfaces a recurring portfolio observation: many programmes overinvest on the structural-awareness side (asset inventory tools, vulnerability scanners, configuration management, policy engines) and underinvest on the situational-awareness side (response tooling, recovery automation, exercised playbooks, tabletop discipline). The result is a portfolio that knows what it has but not what is happening to it, which the next incident exposes as a gap that money spent on the structural side cannot close.
The diagonal is a diagnostic lens rather than a prescriptive rule. Some industries and threat models legitimately concentrate investment on one side of the diagonal: a regulated infrastructure operator with a known threat shape and strong physical controls may legitimately weight Identify and Protect heavily; a high-volume consumer service with an active attack surface may legitimately weight Detect and Respond heavily. The discipline of explicitly reading the balance and naming it as a deliberate portfolio decision is what the diagonal contributes; the rule is not that every cell must be equally invested, but that the imbalance must be named and defended.
People, Process, Technology Inside Each Cell
Each of the twenty-five cells in the Cyber Defense Matrix can be decomposed into People, Process, and Technology, producing seventy-five sub-cells across the full portfolio. Technology is the tool, platform, or capability that operates on the cell. Process is the operating discipline the team runs against the technology. People is the team that operates the discipline.
| Layer | Example: Detect Applications | Intervention timeline if the layer fails |
|---|---|---|
| Technology | RASP agent, WAF, application telemetry, ADR platform, application logging stack. | Quarters: procurement, deployment, calibration. |
| Process | Rule tuning cadence, false positive triage discipline, runbook for RASP-attributed events, exception register lifecycle, latency review. | Weeks to months: documenting, exercising, embedding into the team operating rhythm. |
| People | AppSec engineer who owns RASP rules, on-call rotation that triages RASP-attributed events, application owner who signs the SLO trade-off. | Months to years: hiring, training, sourcing. |
The decomposition matters because the three failure modes have different intervention timelines and different budget conversations. A cell that fails on Technology is solved by procurement, which is a quarterly cycle. A cell that fails on Process is solved by operating discipline, which is a weeks-to-months cycle. A cell that fails on People is solved by hiring, training, or sourcing, which is a months-to-years cycle. A CISO who diagnoses a cell as a Technology gap and asks the board for a tool budget when the actual gap is on the People layer underwrites a tool acquisition that will not close the gap and arrives at the next quarter with the same cell still unresolved. The People-Process-Technology decomposition is what keeps the CDM diagnosis honest.
CDM vs MITRE ATT&CK, MITRE D3FEND, NIST CSF, FAIR, SABSA, DIE, CIA
The Cyber Defense Matrix overlaps with several adjacent frameworks. The boundaries are clear when each framework is read against the question it answers. The table below lays out what each framework buys the programme and how it relates to the CDM.
| Framework | Question it answers | Relationship to CDM |
|---|---|---|
| NIST CSF 2.0 | What cybersecurity outcomes should the programme produce, organised by function (Govern, Identify, Protect, Detect, Respond, Recover) and decomposed into categories and subcategories. | Complementary. CDM uses the five operational NIST CSF functions as its row axis. NIST CSF describes the outcomes; CDM describes the portfolio that produces them. Mature programmes read both in parallel. |
| MITRE ATT&CK | What attackers do, organised by phase of attack and observed in real intrusions. | Adjacent at a different layer. ATT&CK is the offensive knowledge base; CDM is the portfolio map. Programmes use ATT&CK to inform the threat shape the portfolio must address and CDM to surface where the portfolio sits against that threat shape. |
| MITRE D3FEND | How defensive countermeasures work against attacker techniques, organised by the disrupted attacker action and the defender technique. | Adjacent at a different layer. D3FEND is the defensive countermeasure knowledge graph; CDM is the portfolio map. D3FEND describes the technique; CDM describes the cell the technique sits in. |
| MITRE Engage | How adversary engagement (deception, denial, direction) should be planned and operated. | Adjacent at a different layer. Engage is the engagement strategy framework; CDM is the portfolio map. Engage tells the team what to do against the adversary; CDM tells the team where each engagement capability sits in the portfolio. |
| FAIR | How to quantify cyber risk in monetary terms, organised by loss event frequency and loss magnitude. | Complementary at a different layer. FAIR is the risk quantification framework; CDM is the portfolio map. Programmes use FAIR to translate cell-level state into a dollar exposure that the board reads against. |
| SABSA | How to architect security across business, conceptual, logical, physical, component, and operational layers, driven by attributes. | Adjacent at a different layer. SABSA is the security architecture framework; CDM is the portfolio map. SABSA decomposes architecture across layers; CDM decomposes capabilities across cells. The two can be read in parallel for the same programme. |
| DIE triad | Distributed, Immutable, Ephemeral: an architectural posture for resilient cloud-native workloads. | Adjacent at a different layer, also developed by Sounil Yu. DIE is an architectural property of the asset class; CDM is the portfolio map of capabilities against the asset class. DIE shifts the Devices column toward Ephemeral and Immutable workloads, which thins the Protect cell and reshapes the Recover cell. |
| CIA triad | Confidentiality, Integrity, Availability: the foundational properties information security has been organised around since the 1970s. | Complementary at a different layer. CIA describes the security properties the programme must preserve; CDM describes the portfolio that preserves them. Every CDM cell contributes to one or more CIA properties. |
The Cyber Defense Matrix is not a replacement for any of these adjacent frameworks. A mature programme reads CDM for the portfolio coverage map, NIST CSF for the outcome targets, MITRE ATT&CK for the attacker shape, MITRE D3FEND for the defensive technique map, FAIR for the risk quantification, SABSA for the architecture decomposition, the DIE triad where cloud-native architecture applies, and the CIA triad as the foundational grounding. The frameworks compose; they do not compete.
The Three CDM Usage Patterns: Design, Operating, Measurement
Mature programmes use the Cyber Defense Matrix in three named patterns. The patterns are not sequential phases of adoption; they run in parallel against the same matrix and feed each other.
Design pattern: portfolio mapping and investment gap surfacing
Place every existing security capability on the matrix to surface the current portfolio shape, then layer the desired future portfolio over it to surface the investment gaps. This produces the security capability heatmap that the board read and the budget conversation references. Mature programmes refresh the design pattern annually as part of the security strategy cycle, and incrementally whenever a major tool acquisition, divestment, or organisational change shifts the portfolio. The exit artefact is a single-page heatmap with investment-decision rationale per cell.
Operating pattern: coverage drift detection and cadence anchoring
Read the matrix as a coverage map and anchor the recurring disciplines that drive forward motion in each cell: vulnerability scanning cadence in Identify Devices and Identify Applications, recertification cycle in Identify Users, EDR triage in Detect Devices, RASP tuning in Detect Applications, tabletop exercise in Respond across the row, backup validation in Recover across the row. The operating pattern produces the weekly, monthly, and quarterly cadence layers that prevent the structural gap from drifting back open between annual strategy cycles. The exit artefact is a cadence chart with named owner, trigger, frequency, and exit criterion per cell.
Measurement pattern: capability heatmap and audit-grade evidence
Assign metrics to each cell that capture the cell capability state in the current period (coverage percentage, throughput rate, mean time to act, false positive rate, exception count, staleness ratio) and read the cell-level metrics together as the portfolio heatmap. The measurement pattern produces the audit-grade evidence and the board narrative the CISO uses for the quarterly cadence. The exit artefact is the metric set per cell with named source system, named report owner, and named target range, refreshed on the cadence the operating pattern names.
CDM Framework Crosswalk: ISO 27001, SOC 2, PCI DSS, NIST 800-53, NIST CSF 2.0, DORA, NIS2, CIS Controls
The Cyber Defense Matrix is not itself an audit framework, but the cell-level portfolio view crosswalks to most major frameworks. Maintaining the crosswalk alongside the audit evidence pack lets the same operating record read against multiple frameworks at once.
| Framework | Control reference | CDM cell it maps to |
|---|---|---|
| ISO 27001 | A.5.18 (access rights), A.5.16 (identity management), A.8.7 (protection against malware), A.8.10 (information deletion), A.8.16 (monitoring activities), A.5.25 (assessment and decision on information security events). | A.5.18 / A.5.16 map to Identify Users and Protect Users; A.8.7 maps to Protect Devices and Protect Applications; A.8.10 maps to Protect Data; A.8.16 maps to Detect across asset classes; A.5.25 maps to Respond across asset classes. |
| SOC 2 | CC6.1 (logical access), CC6.6 (system access), CC7.1 (system monitoring), CC7.2 (system monitoring for analysis), CC7.3 (evaluation of security events), CC7.4 (response to security events), CC7.5 (recovery from security events). | CC6.1 / CC6.6 map to Protect Users; CC7.1 / CC7.2 map to Detect across asset classes; CC7.3 maps to Respond across asset classes; CC7.4 maps to Respond; CC7.5 maps to Recover. |
| PCI DSS | Requirement 6 (secure systems and software), Requirement 7 (restrict access), Requirement 10 (log and monitor access), Requirement 11 (test security), Requirement 12 (security policy). | Req. 6 maps to Identify Applications and Protect Applications; Req. 7 maps to Protect Users; Req. 10 maps to Detect across asset classes; Req. 11 maps to Identify and Detect across the cardholder data environment. |
| NIST 800-53 | AC (access control), AU (audit and accountability), CM (configuration management), IA (identification and authentication), IR (incident response), RA (risk assessment), SC (system and communications protection), SI (system and information integrity). | AC / IA map to Protect Users; AU maps to Detect across asset classes; CM maps to Protect Devices and Protect Applications; IR maps to Respond across asset classes; SC maps to Protect Networks; SI maps to Detect across asset classes. |
| NIST CSF 2.0 | ID (Identify), PR (Protect), DE (Detect), RS (Respond), RC (Recover), GV (Govern). | Direct row alignment with CDM. ID maps to the Identify row; PR maps to the Protect row; DE maps to the Detect row; RS maps to the Respond row; RC maps to the Recover row. GV sits above CDM as the governance overlay. |
| DORA | Article 9 (ICT security tools), Article 10 (detection mechanisms), Article 17 (ICT-related incident management), Article 12 (backup and recovery). | Art. 9 maps across the Protect column; Art. 10 maps across the Detect column; Art. 17 maps across the Respond row; Art. 12 maps across the Recover row. |
| NIS2 | Article 21 (cybersecurity risk management measures), Article 23 (significant incident reporting). | Art. 21 measures map across Protect, Detect, and Respond rows; Art. 23 maps to Respond across asset classes. |
| CIS Controls v8.1 | Control 1 (asset inventory), Control 2 (software inventory), Control 3 (data protection), Control 6 (access control management), Control 8 (audit log management), Control 17 (incident response). | Control 1 maps to Identify Devices; Control 2 maps to Identify Applications; Control 3 maps to Protect Data; Control 6 maps to Protect Users; Control 8 maps to Detect across asset classes; Control 17 maps to Respond across asset classes. |
The crosswalk above is the standard reading. Specific control language varies by framework revision and by audit scope; the team should validate the precise control reference against the current framework revision before locking the crosswalk into the audit-evidence record.
Seven Common Cyber Defense Matrix Adoption Pitfalls
Seven recurring failure modes appear in CDM rollouts. Most programmes hit at least three of these on the first adoption cycle. Reading the pitfalls upfront is the highest-leverage way to avoid them.
1. Treating CDM as a tool selection scorecard
Treating the CDM as a tool selection scorecard rather than a portfolio map produces a vendor checklist that misses the People and Process layers of each cell. The matrix is most useful when it surfaces gaps that procurement cannot solve alone.
2. Mapping vendor brochures into cells
Mapping vendor product brochures into cells without observing the team operating discipline produces a portfolio map that overstates coverage. A tool present in the environment does not equal cell capability state. The cell is only as strong as the People and Process layers that operate it.
3. Counting tool presence as coverage
Counting tool presence as cell coverage without measuring the cell capability state in the current period produces a static map that ages out as the threat landscape and the asset population evolve. The cell coverage metric should be a living measurement, not a one-time inventory snapshot.
4. Reading the matrix as a maturity model
Reading the matrix as a maturity model rather than as a coverage map produces a misleading conclusion that every cell should be heavily invested. Some asset classes legitimately do not exist in some organisations (Devices is hollow for a serverless-only SaaS, Networks is hollow for a fully cloud-native organisation that does not run its own network). Forcing investment into every cell wastes budget the organisation could have spent on the cells that actually matter for the threat shape.
5. Skipping the People-Process-Technology decomposition
Skipping the People-Process-Technology decomposition produces a portfolio map that cannot diagnose where the gap actually sits, which leaves the CISO defending a budget request without the diagnosis the budget responds to. The same cell can fail on Technology in one organisation and on Process in another; the intervention is different, and naming the difference is what makes the diagnosis useful.
6. Locking the matrix at a single point in time
Locking the matrix at a single point in time without the operating cadence to refresh it allows the portfolio shape to drift away from the documented map as new tools are added, old tools are retired, and the asset population changes. Without an annual refresh and an incremental update on every major portfolio change, the matrix becomes a historical artefact rather than a living portfolio document.
7. Holding the matrix inside a slide deck
Holding the matrix inside a slide deck rather than as a living record alongside the finding-and-engagement system means the cell-level metrics and the audit evidence have to be reconstructed each cycle rather than reading from the operating record. Programmes that connect the cell-level metrics to the live finding store and to the audit-evidence surface collapse the work of the next cycle into a query against the operating record rather than a manual rebuild.
CDM for CISO Board Reporting and Security Budget Conversations
The Cyber Defense Matrix produces a single-page visual the board can read without security domain knowledge. The heatmap variant colours each cell by the capability state in the current period (strong coverage, partial coverage, gap), which makes the portfolio coverage visible at a glance. The investment overlay variant adds a second layer that shows the spend distribution across cells, which surfaces over-investment on the structural-awareness side and under-investment on the situational-awareness side or the inverse where it applies. The trend variant tracks each cell through time across quarters or years to show the programme trajectory. The crosswalk variant connects each cell to the framework controls the auditor reads against and to the regulatory expectations the board signs against.
The combined view is the canonical board pack for the CISO quarterly cadence: portfolio state, investment shape, trajectory, and regulatory mapping in one frame. The conversation moves from a list of tools and a list of incidents to a portfolio diagnosis and an investment ask grounded in named cells. The board conversation about a new EDR investment becomes a conversation about closing the Detect Devices gap; the board conversation about a data classification project becomes a conversation about closing the Identify Data gap; the board conversation about a tabletop exercise programme becomes a conversation about closing the Respond row.
The CDM board pack does not replace the incident-cadence reporting (the named incidents in the current quarter, the current remediation backlog, the open exception register, the next-quarter committed work), but it provides the portfolio grounding that the incident-cadence reads against. The mature CISO produces both layers as one pack: the portfolio map for the strategic conversation, and the operating record extracts for the current-cycle conversation.
A Phased Cyber Defense Matrix Rollout
The mature CDM rollout is a phased programme rather than a one-shot mapping exercise. The phases below are the standard shape; specific durations vary with portfolio complexity and the depth the team is willing to commit to.
Phase 1: Current state mapping (weeks 1-4)
Build the authoritative list of security capabilities the programme currently operates. Place each capability against its primary cell, with secondary cells noted where the capability operates across multiple cells. Capture the People-Process-Technology decomposition for each cell. Surface the cells where coverage is strong, partial, or absent. The exit artefact is the current-state heatmap with cell-level annotations.
Phase 2: Threat shape overlay and gap prioritisation (weeks 5-7)
Lay the threat shape (MITRE ATT&CK techniques relevant to the organisation, FAIR risk quantification of the dominant loss scenarios, the regulatory and contractual expectations that name specific outcomes) over the current-state heatmap. Prioritise the cells where the gap is largest against the threat shape. The exit artefact is the ranked gap list with rationale and proposed intervention per cell.
Phase 3: Cadence anchoring and metric assignment (weeks 8-12)
Anchor the recurring cadence that drives forward motion in each cell. Assign metrics that capture cell capability state in the current period. Name the source system, the report owner, and the target range per metric. The exit artefact is the cadence chart and the metric set, with named owners across the portfolio.
Phase 4: Investment proposal and board narrative (weeks 13-16)
Translate the ranked gap list into an investment proposal with named cells, named intervention type (Technology, Process, People), named cost and timeline, and named expected cell capability state change. Build the board narrative pack with the current-state heatmap, the investment overlay, the trend line, and the regulatory crosswalk. The exit artefact is the board pack and the investment commitment.
Phase 5: Operating discipline and refresh cadence (week 17 onwards)
Lock the operating discipline that maintains the matrix as a living record: monthly cell-level metric refresh, quarterly board pack update, annual portfolio strategy refresh, and incremental updates on every major tool acquisition, divestment, or organisational change. Integrate the cell-level metrics into the live finding store and into the audit-evidence surface so the matrix reads from the operating record rather than a manual rebuild each cycle.
Where SecPortal Fits Alongside a Cyber Defense Matrix Programme
SecPortal is not a Cyber Defense Matrix tool. The matrix itself is a framework, not a product; it is rendered in spreadsheets, slide decks, and dedicated portfolio tools depending on the organisation. SecPortal is the operating record where the security work driven by the CDM portfolio analysis lands. The mature pattern is the matrix holds the portfolio map, and SecPortal holds the finding-and-engagement truth for the remediation, governance, and audit-evidence work that the portfolio analysis surfaces.
SecPortal provides the following verified capabilities:
- Findings management with CVSS 3.1 calibration, named owner, status lifecycle, and evidence attachments, so the remediation work driven by a CDM-surfaced gap (a Detect Applications cell where the WAF tuning produces a recurring finding pattern, a Protect Users cell where the IAM recertification surfaces stale entitlements) is tracked on the same record as the rest of the security backlog.
- Finding overrides for the exception register entries where a cell-level decision deliberately defers remediation against a documented rationale, with the eight-field decision chain (rationale, scope, owner, expiry, compensating control, review cadence, named approver, supersedes link) that the audit reader expects.
- Compliance tracking against ISO 27001, SOC 2, PCI DSS, NIST 800-53, NIST CSF 2.0, NIST SSDF, DORA, NIS2, CIS Controls, and other applicable frameworks, so the CDM cell crosswalk maps to the audit-grade control reference the auditor reads against.
- External scanning across 16 modules for the perimeter side of Identify and Detect on Networks and Applications, and authenticated scanning across 17 modules for the deeper Identify Applications and Identify Data signal that requires session context.
- Code scanning via Semgrep SAST and dependency analysis against connected GitHub, GitLab, and Bitbucket repositories for the Identify Applications and Protect Applications cells.
- Continuous monitoring on daily, weekly, biweekly, and monthly schedules so the cell-level metric for scan-based Identify and Detect cells refreshes on the cadence the operating pattern names.
- AI report generation drafted from the live finding-and-engagement record for the executive cadence read of the portfolio, with the cell-level context the CDM board pack expects.
- Activity log with CSV export and a named-actor timestamped audit trail across the engagement and finding lifecycle, so the cell-level Respond row evidence has a defensible operating record.
- Team management with RBAC (owner, admin, member, viewer, billing), MFA enforcement, and verified domain management for scan authorisation, so the People layer in the cells the workspace operates is tracked alongside the Technology layer.
The honest scope is that SecPortal does not produce the CDM visual itself, does not store the cell-level portfolio map as a first-class object, and does not maintain the People-Process-Technology decomposition in a dedicated data model. There are no built-in CDM rendering features, no Jira or ServiceNow ticket synchronisation, no SIEM or SOAR push connectors, no enterprise SSO or SCIM, and no automated approval routing in SecPortal; the platform provides the unified finding record and the audit-evidence surface the team reads against. The relevant adjacent workflows include security tool consolidation, security leadership reporting, vulnerability acceptance and exception management, control mapping cross-framework crosswalks, and audit fieldwork evidence request fulfilment. On the framework side, the cell-level crosswalk reads against the team primary control framework with full traceability.
Scope and Limitations
This guide describes the operating shape of the Cyber Defense Matrix as it is consumed in mainstream enterprise programmes. The framework is a living portfolio discipline rather than a published standard, so specific cell contents, vendor category mappings, and the precise framework crosswalks evolve as the security tool landscape and the regulatory expectations evolve. Teams adopting CDM should validate the cell-level mappings against the current vendor landscape and the current revision of each compliance framework against the audit scope.
The Cyber Defense Matrix is a portfolio map on top of the existing security stack; it is not a substitute for the underlying capabilities in each cell, for a defensible vulnerability management programme, for a working incident response discipline, for a measured audit-evidence record, or for the operating cadence that drives the work forward. Programmes that adopt CDM as a slide-deck framework without the operating discipline that fills each cell produce a visually attractive portfolio map with no operational lift. Programmes that adopt CDM as the portfolio diagnosis layer on top of the operating record see the strategic conversation grounded in named cells, named gaps, and named interventions.
Run CDM-driven gap closure on SecPortal
Stand up the operating record that holds the findings, exception register entries, control crosswalks, and audit-evidence pack connected to each Cyber Defense Matrix cell in under two minutes. Free plan available, no credit card required.