Critical-infrastructure protection is often described through the things an organization possesses: fences, cameras, access-control systems, cyber controls, alarms, generators, sensors, redundancy, emergency plans, contracts, and trained personnel. Those controls matter, but they do not interpret themselves. A camera records a scene; an alarm reports a condition; a log captures activity; a technician observes equipment; a security officer sees behavior. Somewhere between observation and response, a human being must decide what the condition means. If that person understands the object but not the function it supports, the dependencies attached to it, or the consequence of losing it, a technically visible event can remain operationally invisible.
This is the central problem addressed by the Criticality-Recognition Gap. The gap is not a claim that every employee must become an engineer, intelligence analyst, cybersecurity specialist, emergency manager, or executive. It is a more practical proposition: people need enough role-appropriate criticality knowledge to recognize when an apparently local condition is capable of becoming a mission problem. The difference between merely knowing an asset and understanding its criticality is the difference between asking What is this? and asking What disappears if this stops performing its function?
From Asset Protection to Mission Preservation
Traditional security frequently starts with the object: protect the gate, transformer, reservoir, pump, server, database, control room, or communications node. Critical-infrastructure protection must also reason in the opposite direction. The analytical path begins with the mission and moves toward the asset that enables it:
Mission
→
Essential Function
→
Supporting Function / Dependency / Asset
Protection then returns down the chain: preserve the asset so that the function remains available and the mission continues. This is why two physically similar components can have radically different criticality. A pump serving landscaping irrigation and a pump supporting a hospital complex may be mechanically comparable while producing very different consequences when unavailable. A network switch supporting guest Wi-Fi and another carrying telemetry for an indispensable operational process may have the same product class but not the same security significance. Criticality is relational: it emerges from function, requirement, dependency, consequence, substitutability, restoration, state, and time.
The Criticality-Recognition Gap
The source commentary defines the Criticality-Recognition Gap, or CRG, as the difference between the criticality knowledge required by a role and the knowledge actually demonstrated by the person performing it. If Kr is the knowledge required and Ka the knowledge available, then:
The expression is useful because it changes training from a generic activity into a requirements problem. The correct question is not whether an employee has completed a course. It is whether the employee can demonstrate the criticality knowledge required by that role. A gate officer may not need to calculate power-flow stability, but may need to recognize that access to a relay room carries greater consequence than access to an ordinary office. An IT administrator may not need to run a water-treatment process, but should know when identity, communications, or server services support operational technology whose loss affects water availability. A contractor does not need unrestricted knowledge of every contingency plan, but should understand when maintenance on a specific asset requires coordination because downstream functions depend upon it.
FunctionWhat required capability does the asset, process, service, or role enable?
DependencyWhich other functions rely on it, and under what operating state?
ConsequenceWhat becomes unavailable, unsafe, delayed, corrupted, or degraded if the function is lost?
Escalation thresholdWhen does an abnormal condition stop being routine and require higher-level action?
Authority and reportingWho receives the information, and does the person observing the condition have permission to escalate?
State and contextDoes maintenance, reduced redundancy, weather, staffing, emergency operation, or restoration change the object's importance?
Operationalizing the Gap Without Pretending It Is a Federal Standard
A scalar CRG is conceptually clear, but real roles require several kinds of knowledge. For future empirical work, the same idea can be extended into a weighted multidimensional form. Let each role be assessed across m criticality dimensions, with krj representing the required level for dimension j, kaj the demonstrated level, and wj the importance of that dimension to the role. Then:
An organization could, for example, score each dimension on a 0-4 demonstration scale: 0 for no demonstrated understanding, 1 for basic recognition, 2 for routine application, 3 for reliable application under abnormal conditions, and 4 for advanced role-appropriate judgment. This is an ITAICS Research operationalization proposed for testing, not a NIST, CISA, DHS, DOE, GAO, FEMA, or other government scoring method. Its purpose is to create measurable requirements instead of treating course completion as a proxy for competence.
| Dimension | Required demonstration | Example observable evidence | Why the gap matters |
|---|
| Function | Explains what the protected object enables. | Correctly identifies the mission or essential service supported. | Without function knowledge, anomalies are interpreted only locally. |
| Dependency | Identifies key upstream and downstream dependencies. | Names the systems or services affected by loss of the function. | Propagation paths remain invisible. |
| Consequence | Distinguishes inconvenience from unacceptable mission loss. | Correctly prioritizes scenarios with larger safety, continuity, or cross-sector effects. | Resources may be assigned to the wrong event. |
| Escalation | Recognizes the threshold for higher-level action. | Routes the condition to the correct authority without delay. | Known problems become routine and recur. |
| State / context | Recognizes when criticality changes. | Adjusts judgment when redundancy, staffing, weather, maintenance, or emergency status changes. | Static labels miss time-dependent criticality. |
Recognition Is a Control, Not Merely a Training Topic
The human layer becomes a security control because observations do not generate protective action automatically. The normal chain is observation → interpretation → criticality assessment → escalation → response. If interpretation fails, the chain can become observation → misclassification → no escalation → continued exposure. Repeated exposure can then become recurrence, and recurrence can become normalization. The previous commentary in this series examined how abnormal conditions can become familiar enough to be treated as ordinary. Criticality recognition is one of the points at which that progression can be interrupted.
Observe
→
Interpret Function & Dependency
→
Compare Consequence to Threshold
Escalate
→
Correct / Mitigate
→
Update Knowledge
This is why the answer cannot be reduced to "more training." Training can provide knowledge, but an organization also needs reporting paths, permission to escalate, responsive management, procedures that define thresholds, cross-functional information, and feedback after incidents. If employees recognize consequential conditions but management does not act, the organization teaches them that escalation is pointless. If management wants escalation but employees do not understand what matters, the organization receives noise instead of useful warning. Criticality literacy is therefore an organizational capability, not a classroom event.
Protection Effectiveness Is Multiplicative
The source commentary represents protection effectiveness as the product of three terms:
The multiplicative form captures an important operational property. Strong technical controls do not compensate fully for a near-zero recognition capability, and excellent recognition does not protect the mission if there is no response authority or capacity. If the three factors are normalized between 0 and 1, an illustrative organization with controls at 0.90, recognition at 0.40, and response at 0.80 would yield 0.288, or 28.8 percent of the idealized maximum under this simplified model. That numerical example is not an empirical score of any organization; it demonstrates why one weak term can materially reduce aggregate performance even when the other terms appear strong.
The same logic explains why investment in technology alone can fail to produce protection. Sensors can increase observation. Access controls can reduce opportunity. Logging can improve evidence. Redundancy can preserve capability. But none of those controls determines by itself whether a recurring maintenance condition, unusual access request, abnormal process signal, vendor dependency, or technically moderate cyber event threatens an indispensable function. The human interpretation layer remains part of the architecture.
Criticality Changes With State
Criticality is not a permanent sticker attached to an object. A transmission path may be one of two available paths under normal conditions and therefore have manageable single-loss consequence. During maintenance, the second path may be unavailable, making the remaining path disproportionately important. A technician may be routine staff most days but temporarily become mission-critical because only that person understands a legacy system. A supplier may become critical after alternative inventory is exhausted. A backup generator may become critical when the grid is unavailable. The source commentary summarizes this as:
This state dependence has direct training implications. Static lists of "critical assets" are insufficient if they are not connected to operating conditions. Personnel need to know which changes in state alter escalation thresholds. Otherwise, a condition that was safely routine yesterday may be treated as routine today even though redundancy has disappeared and the system has become fragile.
The Insider Problem Requires Competing Hypotheses, Not Premature Attribution
The human layer intersects with insider risk, but the presence of a human error or repeated failure does not establish malicious intent. The source commentary explicitly preserves competing origins: inadequate knowledge, negligence, organizational pressure, normalization, procedure failure, malicious insider activity, external manipulation of an insider, and coordinated adversarial activity. Observed consequence alone is insufficient to choose among them. That distinction is essential to a disciplined VOSFIT analysis because Origin and Intention must remain analytically separate until evidence supports a relationship.
That separation also protects the integrity of the newsletter. A critical-infrastructure assessment may identify a capability gap, an escalation failure, or a pattern of recurrence without turning those observations into accusations. The correct analytical progression is evidence first, competing explanations second, and attribution only when the evidentiary threshold has been met.
VOSFIT Human-Layer Mapping
| Component | Human-layer interpretation |
|---|
| V - Vulnerability | A personnel capability gap can create or preserve the difference between required protection capability and actual capability. |
| O - Origin | The source may be training deficiency, procedure design, organizational culture, resource shortage, mismanagement, malicious conduct, external manipulation, or another origin. |
| S - Strategy | Actors may exploit predictable personnel behavior through social engineering, credential abuse, physical deception, procurement manipulation, coercion, recruitment, persistence, or other strategies. |
| F - Function | The protected object matters because of the function it supports and the dependencies connected to that function. |
| I - Intention | Poor performance does not establish hostile intention; technically competent action is not automatically benign when evidence suggests purposeful exploitation. |
| T - Time | Criticality changes with maintenance, emergency operation, reduced redundancy, peak demand, weather, staffing, incident response, and restoration state. |
What a Criticality-Literacy Program Should Actually Measure
A serious program would begin with essential functions rather than a generic inventory of assets. It would map the physical, cyber, human, contractual, logistical, and supply-chain elements required by those functions, identify dependencies, define consequence categories, and document the conditions under which criticality changes. Role-based knowledge requirements would then be assigned according to access, authority, function, and consequence. Personnel would be assessed on whether they can recognize and escalate consequential conditions, not merely whether they attended training.
Exercises should also test dependency failure rather than isolated component failure. A tabletop exercise that asks only whether a pump, server, substation, or contractor is unavailable can miss the real question: what other functions become degraded, how quickly does the consequence grow, which thresholds are crossed, and who has authority to act? After-action findings must then modify procedures, controls, staffing, training, system design, or resource priorities. Otherwise the organization has documented a lesson without learning it.
The Final Connection: Failure, Criticality, and People
This series began with recurring failure because recurrence can reveal a persistent condition. It then moved to Puerto Rico's electric grid because criticality is defined by function, dependency, consequence, substitutability, restoration, governance, context, and time. The final step is the human layer because every model eventually reaches a decision point. Someone must detect the condition, recognize the threatened function, understand the dependency, estimate the consequence, compare it with an escalation threshold, and act.
Infrastructure protection therefore does not begin and end with fences, firewalls, generators, sensors, regulations, contracts, or plans. Those are instruments. Protection becomes a capability only when the organization also knows what must not be allowed to fail, why it matters, how its criticality changes, and what people are expected to do when available capability begins moving outside requirement. You cannot prioritize what you cannot distinguish, and you cannot protect critical infrastructure adequately if the people entrusted with it understand the object but not what the object means.
References
Critical Infrastructure Cannot Be Protected by Personnel Who Do Not Understand Its Criticality
The Criticality-Recognition Gap examines why protection depends on role-appropriate understanding of function, dependency, consequence, escalation thresholds, and state-dependent criticality.
Critical-infrastructure protection is often described through the things an organization possesses: fences, cameras, access-control systems, cyber controls, alarms, generators, sensors, redundancy, emergency plans, contracts, and trained personnel. Those controls matter, but they do not interpret themselves. A camera records a scene; an alarm reports a condition; a log captures activity; a technician observes equipment; a security officer sees behavior. Somewhere between observation and response, a human being must decide what the condition means. If that person understands the object but not the function it supports, the dependencies attached to it, or the consequence of losing it, a technically visible event can remain operationally invisible.
This is the central problem addressed by the Criticality-Recognition Gap. The gap is not a claim that every employee must become an engineer, intelligence analyst, cybersecurity specialist, emergency manager, or executive. It is a more practical proposition: people need enough role-appropriate criticality knowledge to recognize when an apparently local condition is capable of becoming a mission problem. The difference between merely knowing an asset and understanding its criticality is the difference between asking What is this? and asking What disappears if this stops performing its function?
From Asset Protection to Mission Preservation
Traditional security frequently starts with the object: protect the gate, transformer, reservoir, pump, server, database, control room, or communications node. Critical-infrastructure protection must also reason in the opposite direction. The analytical path begins with the mission and moves toward the asset that enables it:
Protection then returns down the chain: preserve the asset so that the function remains available and the mission continues. This is why two physically similar components can have radically different criticality. A pump serving landscaping irrigation and a pump supporting a hospital complex may be mechanically comparable while producing very different consequences when unavailable. A network switch supporting guest Wi-Fi and another carrying telemetry for an indispensable operational process may have the same product class but not the same security significance. Criticality is relational: it emerges from function, requirement, dependency, consequence, substitutability, restoration, state, and time.
The Criticality-Recognition Gap
The source commentary defines the Criticality-Recognition Gap, or CRG, as the difference between the criticality knowledge required by a role and the knowledge actually demonstrated by the person performing it. If Kr is the knowledge required and Ka the knowledge available, then:
The expression is useful because it changes training from a generic activity into a requirements problem. The correct question is not whether an employee has completed a course. It is whether the employee can demonstrate the criticality knowledge required by that role. A gate officer may not need to calculate power-flow stability, but may need to recognize that access to a relay room carries greater consequence than access to an ordinary office. An IT administrator may not need to run a water-treatment process, but should know when identity, communications, or server services support operational technology whose loss affects water availability. A contractor does not need unrestricted knowledge of every contingency plan, but should understand when maintenance on a specific asset requires coordination because downstream functions depend upon it.
Operationalizing the Gap Without Pretending It Is a Federal Standard
A scalar CRG is conceptually clear, but real roles require several kinds of knowledge. For future empirical work, the same idea can be extended into a weighted multidimensional form. Let each role be assessed across m criticality dimensions, with krj representing the required level for dimension j, kaj the demonstrated level, and wj the importance of that dimension to the role. Then:
An organization could, for example, score each dimension on a 0-4 demonstration scale: 0 for no demonstrated understanding, 1 for basic recognition, 2 for routine application, 3 for reliable application under abnormal conditions, and 4 for advanced role-appropriate judgment. This is an ITAICS Research operationalization proposed for testing, not a NIST, CISA, DHS, DOE, GAO, FEMA, or other government scoring method. Its purpose is to create measurable requirements instead of treating course completion as a proxy for competence.
Recognition Is a Control, Not Merely a Training Topic
The human layer becomes a security control because observations do not generate protective action automatically. The normal chain is observation → interpretation → criticality assessment → escalation → response. If interpretation fails, the chain can become observation → misclassification → no escalation → continued exposure. Repeated exposure can then become recurrence, and recurrence can become normalization. The previous commentary in this series examined how abnormal conditions can become familiar enough to be treated as ordinary. Criticality recognition is one of the points at which that progression can be interrupted.
This is why the answer cannot be reduced to "more training." Training can provide knowledge, but an organization also needs reporting paths, permission to escalate, responsive management, procedures that define thresholds, cross-functional information, and feedback after incidents. If employees recognize consequential conditions but management does not act, the organization teaches them that escalation is pointless. If management wants escalation but employees do not understand what matters, the organization receives noise instead of useful warning. Criticality literacy is therefore an organizational capability, not a classroom event.
Protection Effectiveness Is Multiplicative
The source commentary represents protection effectiveness as the product of three terms:
The multiplicative form captures an important operational property. Strong technical controls do not compensate fully for a near-zero recognition capability, and excellent recognition does not protect the mission if there is no response authority or capacity. If the three factors are normalized between 0 and 1, an illustrative organization with controls at 0.90, recognition at 0.40, and response at 0.80 would yield 0.288, or 28.8 percent of the idealized maximum under this simplified model. That numerical example is not an empirical score of any organization; it demonstrates why one weak term can materially reduce aggregate performance even when the other terms appear strong.
The same logic explains why investment in technology alone can fail to produce protection. Sensors can increase observation. Access controls can reduce opportunity. Logging can improve evidence. Redundancy can preserve capability. But none of those controls determines by itself whether a recurring maintenance condition, unusual access request, abnormal process signal, vendor dependency, or technically moderate cyber event threatens an indispensable function. The human interpretation layer remains part of the architecture.
Criticality Changes With State
Criticality is not a permanent sticker attached to an object. A transmission path may be one of two available paths under normal conditions and therefore have manageable single-loss consequence. During maintenance, the second path may be unavailable, making the remaining path disproportionately important. A technician may be routine staff most days but temporarily become mission-critical because only that person understands a legacy system. A supplier may become critical after alternative inventory is exhausted. A backup generator may become critical when the grid is unavailable. The source commentary summarizes this as:
This state dependence has direct training implications. Static lists of "critical assets" are insufficient if they are not connected to operating conditions. Personnel need to know which changes in state alter escalation thresholds. Otherwise, a condition that was safely routine yesterday may be treated as routine today even though redundancy has disappeared and the system has become fragile.
The Insider Problem Requires Competing Hypotheses, Not Premature Attribution
The human layer intersects with insider risk, but the presence of a human error or repeated failure does not establish malicious intent. The source commentary explicitly preserves competing origins: inadequate knowledge, negligence, organizational pressure, normalization, procedure failure, malicious insider activity, external manipulation of an insider, and coordinated adversarial activity. Observed consequence alone is insufficient to choose among them. That distinction is essential to a disciplined VOSFIT analysis because Origin and Intention must remain analytically separate until evidence supports a relationship.
That separation also protects the integrity of the newsletter. A critical-infrastructure assessment may identify a capability gap, an escalation failure, or a pattern of recurrence without turning those observations into accusations. The correct analytical progression is evidence first, competing explanations second, and attribution only when the evidentiary threshold has been met.
VOSFIT Human-Layer Mapping
What a Criticality-Literacy Program Should Actually Measure
A serious program would begin with essential functions rather than a generic inventory of assets. It would map the physical, cyber, human, contractual, logistical, and supply-chain elements required by those functions, identify dependencies, define consequence categories, and document the conditions under which criticality changes. Role-based knowledge requirements would then be assigned according to access, authority, function, and consequence. Personnel would be assessed on whether they can recognize and escalate consequential conditions, not merely whether they attended training.
Exercises should also test dependency failure rather than isolated component failure. A tabletop exercise that asks only whether a pump, server, substation, or contractor is unavailable can miss the real question: what other functions become degraded, how quickly does the consequence grow, which thresholds are crossed, and who has authority to act? After-action findings must then modify procedures, controls, staffing, training, system design, or resource priorities. Otherwise the organization has documented a lesson without learning it.
The Final Connection: Failure, Criticality, and People
This series began with recurring failure because recurrence can reveal a persistent condition. It then moved to Puerto Rico's electric grid because criticality is defined by function, dependency, consequence, substitutability, restoration, governance, context, and time. The final step is the human layer because every model eventually reaches a decision point. Someone must detect the condition, recognize the threatened function, understand the dependency, estimate the consequence, compare it with an escalation threshold, and act.
Infrastructure protection therefore does not begin and end with fences, firewalls, generators, sensors, regulations, contracts, or plans. Those are instruments. Protection becomes a capability only when the organization also knows what must not be allowed to fail, why it matters, how its criticality changes, and what people are expected to do when available capability begins moving outside requirement. You cannot prioritize what you cannot distinguish, and you cannot protect critical infrastructure adequately if the people entrusted with it understand the object but not what the object means.
About ITAICS Research
ITAICS Research
Research and publication activity of ITAICS LLC
ITAICS Research develops and disseminates applied and foundational work in cybersecurity, artificial intelligence, security science, critical infrastructure, global supply chains, advanced persistent threats, and resilient systems. It supports the Proceedings of the Institute of Technology of Artificial Intelligence and Cyber Security and the continuing development, testing, and application of the VOSFIT research program.
Its newsletter commentaries and research publications are intended to connect formal models, empirical evidence, public-interest analysis, and operational security questions. Institutionally authored commentary is identified as ITAICS Research to distinguish organizational research and editorial work from individually authored contributions.
Visit ITAICS Research →
References
Methodological note. The Criticality-Recognition Gap, the weighted multidimensional operationalization, the illustrative 0-4 demonstration rubric, the protection-effectiveness relationship, the state-dependent criticality formulation, and the VOSFIT mappings are ITAICS Research constructs intended for conceptual development, testing, and future empirical validation. The weighted extension and numerical protection example in this web commentary are explanatory proposals, not government standards or validated organizational ratings.
Editorial independence and nonpartisanship. This commentary evaluates infrastructure, institutional, and human-factor conditions using public evidence and analytical constructs. References to public officials, agencies, contractors, companies, personnel categories, or other entities are analytical and do not constitute endorsement, opposition, commercial promotion, political advocacy, or a finding of unlawful conduct. Capability gaps, errors, recurrence, or poor performance do not by themselves establish malicious intent.