Israel ICDM gap analysis: where the Cyber Defense Methodology fails in practice
Julian ThorneApril 29, 2026
Key takeaways
The Israeli Cyber Defense Methodology (ICDM) 2.0, published by the INCD in 2021, is built on NIST CSF 1.1 and NIST SP 800-53 Rev. 5 and incorporates Threat-Informed Defense and Zero Trust requirements that ICDM 1.0 assessments do not cover.
Organizations that self-classify as ICDM Category A when their actual risk profile meets Category B thresholds face a control gap that grows over time and is the most common misconfiguration found in Israeli compliance assessments.
ICDM gap assessments scoped to documentation review produce clean reports that do not reflect what INCD facilitators examine during guided assessments.
Supply chain controls under ICDM are satisfied by contract language in most organizations but have never been operationally verified against sub-vendor environments.
External attack surface exposures -- forgotten subdomains, exposed management interfaces, code repository leakage -- are outside ICDM's internal control scope and require a parallel assessment workstream.
CERT-IL notification decision logic is absent from incident response procedures in the majority of Israeli organizations that otherwise have complete ICDM documentation.
TL;DR
Most Israeli organizations that have completed ICDM gap assessments have done document reviews against a control checklist. That is not what the framework requires and not what the INCD examines in facilitated assessments. ICDM 2.0 requires controls to hold against realistic threat scenarios, not just to exist in policy documents. The gap between documentation-based compliance and operationally verified security posture is where Israeli organizations carry their actual enforcement exposure.
The framework was complete. The attack surface was not.
A 400-person Israeli SaaS company completed an ICDM gap assessment 14 months before we engaged them. The report covered all required control domains, mapped controls to NIST CSF categories, and identified four low-severity findings. The assessment scope was their documented asset inventory. During our external reconnaissance, we identified 23 subdomains they had not included in the assessment scope, three of which were running services with administrative interfaces exposed to the internet, one of which was a legacy customer portal running software with a known remote authentication bypass. None of these appeared in the ICDM documentation. None were in scope for the gap assessment that had produced a clean report 14 months earlier.
The problem was not that the ICDM assessment was wrong about what it assessed. It assessed what the organization knew it had. The problem is that the framework's internal control scope does not surface what the organization does not know it has. External attack surface is the delta between the two. For Israeli organizations operating in a threat environment where nation-state and criminal actors actively probe Israeli infrastructure, that delta is not a theoretical gap. It is the reconnaissance layer that precedes most targeted intrusions.
What ICDM 2.0 actually requires and where assessments miss it
The Israeli Cyber Defense Methodology was first published by the Israel National Cyber Directorate in 2017 as ICDM 1.0, adopting NIST Cybersecurity Framework 1.0. The 2021 update to ICDM 2.0 incorporated NIST CSF 1.1, NIST SP 800-53 Rev. 5, Threat-Informed Defense principles, and Zero Trust architecture requirements. The shift matters for gap analysis scope. ICDM 1.0 assessments evaluated whether controls existed and were documented. ICDM 2.0 requires evaluating whether controls hold against the threat scenarios relevant to the organization's category and sector. An organization that completed a thorough ICDM 1.0 assessment and has not updated its scope to 2.0 has a compliance gap that its existing documentation does not reveal.
Example
The Category A versus Category B distinction is the most consequential assessment decision an organization makes under ICDM. Category B applies to organizations whose compromise would produce national-level or sector-wide impact. The control requirements for Category B are materially more demanding than Category A, including mandatory penetration testing cycles, stricter supply chain verification, and more intensive INCD facilitator interaction. The self-classification process is where the most significant structural gap appears: organizations with significant customer databases, critical infrastructure dependencies, or sector-wide service exposure routinely classify as Category A because nobody has formally challenged the classification. A fintech operating payment infrastructure for 200,000 Israeli customers classifying itself as Category A because it has fewer than 500 employees is not an edge case. It is the most common category mismatch we find.
Threat-Informed Defense under ICDM 2.0 means controls need to be evaluated against the MITRE ATT&CK techniques most relevant to the organization's threat profile. An organization in Israeli finance or healthcare is operating against a specific set of threat actors with documented TTPs. A gap assessment that does not map the organization's control posture against those TTPs is not producing a 2.0-compliant assessment. It is producing a 1.0 assessment labeled as 2.0.
What ICDM assessments of Israeli organizations actually find
Assessment base: Vulnox assessment data, 2024-2025, Israeli organizations across technology, finance, and healthcare sectors
Category self-classification underestimates organizational risk consistently
In our assessments of Israeli organizations, the most common structural gap is Category A classification by organizations whose actual risk profile warrants Category B. The classification is not always wrong in isolation. Organizations apply reasonable judgment about their own criticality. The problem is that the classification determines the control requirements the organization builds its compliance program around. A Category A program at a Category B organization produces documented compliance at the wrong standard. When an INCD facilitator engages or an incident triggers scrutiny, the control gaps relative to the correct category become visible simultaneously.
The client assumption is usually that their category classification was reviewed at some point and is accurate. The root cause is that category classification is typically a founding decision that is never formally reviewed as the organization grows, acquires customers, or develops infrastructure dependencies. A 60-person Israeli SaaS company that classified as Category A three years ago and now operates services that 40 Israeli hospitals depend on is still running a Category A program.
Supply chain controls stop at contract language
ICDM requires supply chain security controls, and most organizations satisfy this requirement with documented vendor assessment processes and data processing agreements that include security obligations. When we probe whether those obligations are operationally verified, the answer is consistently no. Vendor certifications are accepted at face value. Sub-vendor environments are not reviewed. Security questionnaire responses are not validated against technical evidence. The supply chain control exists as a documented process. Whether that process produces actual assurance about supplier security posture is an untested assumption.
The threat model here is specific and documented: supply chain intrusions targeting Israeli technology companies to reach their customers are a known attack pattern used by multiple threat actor groups. An ICDM supply chain control that satisfies documentation requirements but cannot detect a compromised supplier is not addressing the threat the control was designed to prevent.
External attack surface is outside ICDM scope and unassessed
ICDM gap assessments are scoped to the organization's known asset inventory and documented control environment. External attack surface -- the externally visible infrastructure that an attacker enumerates during reconnaissance -- is not an ICDM control domain. Organizations that rely on ICDM gap assessments as their primary security review have no structured process for discovering what they look like from the outside. In our external reconnaissance of Israeli organizations that have completed ICDM assessments, we regularly identify exposed management interfaces, legacy services running on organizational infrastructure that IT is unaware of, and data leakage through code repositories that contradicts the organization's assumed confidentiality posture.
The attacker's starting point is passive reconnaissance of publicly available information. ICDM compliance does not address that starting point. An organization with a complete ICDM compliance program and an unreviewed external attack surface has documented internal controls and unknown external exposure. The attacker sees the external surface. The compliance assessment does not.
ICDM 2.0 Threat-Informed Defense requirements are not reflected in assessment methodology
ICDM 2.0 explicitly incorporates Threat-Informed Defense, requiring that control adequacy be evaluated against the realistic threat scenarios relevant to the organization. In practice, the gap assessments organizations conduct and commission do not include threat scenario mapping. They assess whether controls exist and are documented. The 2.0 requirement to evaluate controls against specific adversary TTPs is described in the framework documentation and absent from most assessment methodologies we review.
An Israeli financial services organization completing an ICDM 2.0 assessment without mapping controls against the MITRE ATT&CK techniques documented for the threat actors known to target Israeli financial infrastructure is producing a 1.0-methodology assessment called a 2.0 assessment. The control gaps that the Threat-Informed Defense requirement is designed to surface remain unidentified.
ICDM compliance and security posture move in opposite directions for fast-growing organizations
Common belief
Organizations that maintain their ICDM compliance documentation and complete annual gap assessments have a compliance posture that reflects their actual security posture. Compliance and security track together.
What we found
We assess organizations where the compliance documentation is current -- updated within the last three months -- and the documented environment has not reflected the actual operating environment for 18 months or more. Documentation currency and documentation accuracy are not the same thing. Annual compliance maintenance processes that update policy documents without verifying that the documented environment matches the actual environment produce current documentation of a fictional organization.
For Israeli technology organizations growing faster than their security program, the opposite dynamic operates. The organization completes its initial ICDM gap assessment when it is 80 people and Category A. The compliance program is accurate at that point. Over the next two years the company grows to 250 people, acquires two smaller companies, moves infrastructure to a multi-cloud environment, and becomes operationally critical to 60 enterprise customers. The ICDM documentation is updated annually. The category classification, asset inventory scope, and supply chain controls are not revisited. The compliance documentation continues to describe an 80-person Category A company operating in a known asset environment. The actual organization is a Category B risk profile operating with Category A controls in an environment the documentation no longer describes.
Where Israel ICDM gap assessments consistently do not look
Threat actor reconnaissance data already collected
By the time an organization engages in an ICDM gap assessment, threat actors may have already completed reconnaissance against their external infrastructure. Passive DNS data, certificate transparency logs, and historical web archive data create a record of an organization's external footprint going back years. Organizations that have never reviewed what this data reveals about their infrastructure do not know what threat actors already know about them. This information is publicly available and does not require any active scanning to collect.
Acquired entity attack surface
Israeli technology organizations that have grown through acquisition commonly inherit the acquired company's security posture, compliance status, and external attack surface. The acquisition closes. The integration project begins. The acquired entity's ICDM compliance status is typically not assessed until 12 to 18 months post-acquisition, if at all. During that window, the parent company's ICDM compliance program describes its own environment and does not include the acquired entity. The acquired entity is running whatever security program it had before the acquisition, which may be materially weaker.
Developer tooling and CI/CD pipeline exposure
Israeli technology companies with active engineering teams routinely have secrets, internal service endpoints, and infrastructure configuration details exposed through code repositories, CI/CD pipeline configurations, and package manager dependencies. These exposures are not surfaced by internal control reviews. They are visible to anyone who conducts passive reconnaissance against the organization's public code repositories and developer tooling. The exposure frequently predates the current compliance program and has not been cleaned up because nobody looked for it.
Zero Trust implementation gaps in legacy network architecture
ICDM 2.0 incorporates Zero Trust architecture requirements. Most Israeli organizations operating legacy network architectures with implicit east-west trust have not assessed the gap between their current architecture and the Zero Trust requirements in the 2.0 framework. The Zero Trust requirements are in the documentation. The architecture review that would reveal the gap has not been conducted. Organizations document the Zero Trust requirement as a future roadmap item and assess the current architecture against it as partial compliance. The actual control gap is not quantified.
Where ICDM enforcement is heading
The INCD will begin requiring external attack surface evidence as part of ICDM-guided assessments for Category B organizations within 18 months, following documented intrusions that exploited exposures the ICDM assessment scope did not cover.
The structural gap between ICDM's internal control scope and external attack surface is visible in the incident data. Intrusions against Israeli organizations that follow the attack pattern of external reconnaissance leading to exploitation of unmapped assets are not consistent with the threat environment ICDM 2.0's Threat-Informed Defense requirements anticipate. The INCD has added external surface visibility requirements to sector-specific frameworks in finance and telecommunications. Extending this to ICDM-guided assessments is the logical next step. The signal to watch is INCD guidance updates that reference passive reconnaissance or external footprint mapping.
Confidence: mediumNo INCD guidance update referencing external attack surface requirements for ICDM-guided assessments by end of 2026Category self-classification accuracy will become an explicit INCD inspection criterion for Category B candidates within 24 months, as the gap between self-classified Category A organizations and their actual risk profile becomes visible in incident data.
The current self-classification process produces a predictable distribution: organizations classify at the lower category where possible to reduce control obligations. The INCD facilitator process provides some correction but does not apply uniformly. As incident data from Israeli organizations accumulates, the pattern of Category A classified organizations experiencing Category B threat scenarios will be visible in the national incident dataset that INCD maintains. Enforcement response to that pattern is category classification review criteria.
Confidence: highNo INCD guidance update or enforcement action citing category misclassification by end of 2026
The unresolved debate: framework-driven versus threat-driven assessment methodology
There is a genuine disagreement among Israeli security practitioners about whether ICDM-structured gap assessments or threat-driven red team assessments produce more useful risk information. Framework proponents argue that the ICDM's systematic coverage of control domains ensures no area is missed. Threat-driven proponents argue that framework assessments identify the controls that exist and miss the exploitable gaps between them. My position is that the debate is a false choice for most Israeli organizations but not all of them. For organizations below 200 people that have not yet built baseline security programs, ICDM-structured gap assessment is the right starting point -- it builds coverage and documentation discipline. For Category B organizations in finance, healthcare, and critical infrastructure, a framework assessment that is not paired with external attack surface review and threat scenario testing produces a clean report and an inaccurate picture of actual exposure. The framework is the floor. Threat-informed testing is the ceiling. Most Israeli compliance programs stop at the floor.
Counterargument
The counterargument holds: red team assessments without framework discipline produce organizations that defend well against the specific scenarios they rehearse and have systematic coverage gaps they are unaware of. The framework provides the coverage structure that adversarial testing alone cannot guarantee. Both are right. The organizations that treat them as alternatives rather than complements are the ones that discover the gap under the wrong conditions.
One action before the end of the week
Find your ICDM category classification document and identify when it was last formally reviewed. If the organization has grown by more than 30% in headcount, acquired another company, or significantly expanded its customer base since the classification was made, the classification needs to be re-evaluated against the current organizational profile. Category misclassification is the gap assessment finding with the largest downstream effect and the easiest to check without a full assessment engagement. That review costs an afternoon. Discovering the mismatch during an INCD-facilitated assessment costs considerably more.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysis toolsNIST Vulnerability Assessment Definition
NIST's vulnerability assessment definitionNational Vulnerability Database NIST
NIST National Vulnerability DatabaseDigital Footprint - Canadian Cyber Centre
digital footprint best practices
Frequently Asked Questions
What is the Israel ICDM and who is required to comply with it?
The Israeli Cyber Defense Methodology (ICDM), published by the Israel National Cyber Directorate (INCD), is Israel's national cybersecurity framework based on NIST CSF 1.1 and NIST SP 800-53 Rev. 5. ICDM 2.0, released in 2021, also incorporates Threat-Informed Defense and Zero Trust principles. Compliance is not universally mandatory but is required for organizations guided by INCD sector facilitators, and is effectively mandatory for critical infrastructure operators and government ministries. Organizations in finance, health, and telecommunications face parallel sector-specific requirements that reference or overlap with ICDM controls.
What is the difference between ICDM Category A and Category B organizations?
ICDM classifies organizations into Category A (lower cyber risk) and Category B (higher risk, including organizations whose compromise would have national or sector-wide impact). Category B organizations face more demanding control requirements, including mandatory penetration testing cycles, stricter supply chain security obligations, and more frequent interaction with INCD facilitators. The category assignment is based on the organization's criticality to national infrastructure and its potential attack surface. A significant gap assessment finding is that many organizations self-classify as Category A to avoid the more demanding Category B control set, when their actual risk profile warrants Category B treatment.
How does an Israel ICDM gap analysis differ from a standard ISO 27001 assessment?
An ISO 27001 assessment evaluates whether documented controls meet a predefined control set and whether the management system is functioning. An ICDM gap analysis must additionally assess whether controls hold against the specific threat actors targeting Israeli organizations, whether the organization's external attack surface is mapped and managed, and whether INCD reporting and notification obligations are integrated into incident response procedures. ICDM 2.0 explicitly incorporates Threat-Informed Defense, meaning control adequacy is assessed against realistic threat scenarios, not just against a control checklist. Organizations with ISO 27001 certification still need to close a subset of ICDM-specific requirements.
What external attack surface exposures does the ICDM framework not adequately address?
ICDM focuses on organizational controls and internal security posture. It does not provide detailed methodology for assessing externally visible attack surface: forgotten subdomains, exposed management interfaces, third-party services running on organizational infrastructure, or data leakage through code repositories and job postings. These exposures are the primary reconnaissance targets for threat actors and are not surfaced by ICDM control reviews. Organizations that complete an ICDM gap assessment without a parallel external attack surface review have a clean framework score and an unmapped external exposure profile.
What are the most common ICDM gap findings in Israeli technology organizations?
Three gaps appear consistently: asset inventories that exclude cloud workloads and SaaS applications adopted outside IT procurement, supply chain controls that satisfy the ICDM documentation requirement but have never been operationally verified against sub-vendor environments, and incident response procedures that reference CERT-IL notification obligations without defining who makes the reportability determination and in what timeframe. A fourth pattern specific to ICDM assessments is Category A self-classification by organizations whose actual risk profile and potential impact on dependent services clearly meets Category B thresholds.
How does ICDM 2.0 change the gap assessment requirements compared to ICDM 1.0?
ICDM 2.0 incorporates NIST CSF 1.1, NIST SP 800-53 Rev. 5, Threat-Informed Defense principles, and Zero Trust architecture requirements. The shift from ICDM 1.0 to 2.0 means organizations need to assess controls against realistic threat scenarios rather than just verifying control existence, and need to evaluate whether network architectures assume implicit trust in ways that would not survive a Zero Trust review. Organizations that completed ICDM 1.0 gap assessments and have not updated their assessment scope to 2.0 requirements have compliance gaps that may not be visible in their existing documentation.
What does an ICDM gap assessment need to include to reflect what the INCD actually inspects?
An ICDM gap assessment that reflects actual INCD inspection methodology needs to include: verification that control implementation matches documentation (not just that documentation exists), a test of incident response procedures against a realistic scenario including CERT-IL notification decision logic, an external attack surface review to identify exposures the framework does not surface internally, and a supply chain control verification that goes beyond contract review to operational confirmation. Organizations that scope gap assessments to documentation review only produce audit-ready reports that do not reflect what an INCD-facilitated assessment actually examines.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.