[ { "category": "GV.OC", "function": "GOVERN", "category_name": "Organizational Context", "verdict": "Gap", "frameworks_present": "CPG", "rationale": "Only CPG (goal 1.D, medium-confidence mapping) touches organizational context, and only indirectly via IT/OT relationship-building. Neither NERC CIP nor TSA imposes a category-level obligation to document mission, stakeholders, or dependencies." }, { "category": "GV.RM", "function": "GOVERN", "category_name": "Risk Management Strategy", "verdict": "Gap", "frameworks_present": "TSA", "rationale": "Only the PROPOSED TSA rule (CRM program: annual evaluation + COIP + CAP) creates an explicit enterprise risk-management-strategy obligation at this level, and it is not yet final. CPG and NERC CIP address risk management only through subordinate, narrower categories, not a standalone program-level requirement." }, { "category": "GV.RR", "function": "GOVERN", "category_name": "Roles, Responsibilities, and Authorities", "verdict": "Partial", "frameworks_present": "CPG; TSA", "rationale": "CPG (1.B/1.C) and the CURRENTLY EFFECTIVE TSA Security Directive (named Cybersecurity Coordinator) both require an accountable named role -- these reinforce each other. NERC CIP has no equivalent standalone roles/authorities requirement (CIP-003's governance content maps to Policy, not Roles), so NERC is a gap within an otherwise-reinforcing pair." }, { "category": "GV.PO", "function": "GOVERN", "category_name": "Policy", "verdict": "Gap", "frameworks_present": "NERC CIP", "rationale": "Only NERC CIP-003 explicitly mandates a documented cybersecurity policy at the entity level. Neither CPG nor the TSA public-proxy sources name a standalone, category-level policy requirement (policy is implicit, not stated, in both)." }, { "category": "GV.OV", "function": "GOVERN", "category_name": "Oversight", "verdict": "Gap", "frameworks_present": "CPG", "rationale": "The only entry here is CPG-GOV-NEW, a placeholder for an unextracted CPG 2.0 Govern-function goal (primary PDF blocked by CISA's WAF this session -- see docs/NEXT_STEPS.md). Author reviewed and accepted this as an UNRESOLVED_SOURCE_BLOCKED cell for v0.1 (sign-off 2026-09-19), not a confirmed CPG position: NERC CIP and TSA have no oversight-category requirement in any source used here, but whether CPG 2.0 actually does is deferred to v0.2." }, { "category": "GV.SC", "function": "GOVERN", "category_name": "Cybersecurity Supply Chain Risk Management", "verdict": "Partial", "frameworks_present": "CPG; NERC CIP", "rationale": "CPG (1.G/1.H/1.I) and NERC CIP-013 both impose vendor/supply-chain risk-management obligations and reinforce each other closely. TSA has no supply-chain-specific pipeline cyber obligation in its currently effective SDs; the 2022 NPRM only requests public comment on Secure-by-Design principles, so this is an emerging, not yet binding, area for TSA -- a gap pending the final rule." }, { "category": "ID.AM", "function": "IDENTIFY", "category_name": "Asset Management", "verdict": "Partial", "frameworks_present": "CPG; NERC CIP", "rationale": "CPG (1.A/2.O/2.P) and NERC CIP-002 both center asset identification/categorization as a foundational, reinforcing obligation. TSA's public SD summary names 'Critical Cyber Systems' as a scoping concept but does not impose a standalone asset-inventory duty independent of the proposed COIP -- a gap on the currently-binding side." }, { "category": "ID.RA", "function": "IDENTIFY", "category_name": "Risk Assessment", "verdict": "Reinforce", "frameworks_present": "CPG; NERC CIP; TSA", "rationale": "All three frameworks require some form of periodic vulnerability or risk assessment: CPG 1.E, NERC CIP-010's 15-month vulnerability assessments and CIP-014's substation risk assessment, and the CURRENTLY EFFECTIVE TSA SD vulnerability-assessment and architecture-design-review requirements. This is one of the two strongest three-way alignments in the crosswalk." }, { "category": "ID.IM", "function": "IDENTIFY", "category_name": "Improvement", "verdict": "Gap", "frameworks_present": "CPG", "rationale": "Only CPG (1.F, third-party validation of control effectiveness) maps here, and only at medium confidence. Neither NERC CIP nor TSA imposes a standalone continuous-improvement/audit obligation distinct from their compliance-monitoring processes." }, { "category": "PR.AA", "function": "PROTECT", "category_name": "Identity Management, Authentication, and Access Control", "verdict": "Partial", "frameworks_present": "CPG; NERC CIP; TSA", "rationale": "All three converge on the same control objective (authenticated, least-privilege, physical-and-logical access), but enforceability differs sharply: CPG (six goals, 2.A-2.E/2.H) and NERC CIP-006/CIP-007 are specific and currently binding; TSA's access-control specificity exists only in the PROPOSED rule (49 CFR 1586.207) -- the currently effective SDs are more general. This is a regulatory-maturity gap, not a substantive disagreement." }, { "category": "PR.AT", "function": "PROTECT", "category_name": "Awareness and Training", "verdict": "Partial", "frameworks_present": "CPG; NERC CIP", "rationale": "CPG (2.I/2.J) and NERC CIP-004 both impose explicit, currently-binding training obligations and reinforce each other. TSA's public SD summary names no standalone training requirement -- pipeline-specific cyber training is less codified than the electric-sector equivalent." }, { "category": "PR.DS", "function": "PROTECT", "category_name": "Data Security", "verdict": "Partial", "frameworks_present": "CPG; NERC CIP", "rationale": "CPG (2.K/2.L/2.R/2.U) and NERC CIP-011/CIP-012 both impose data-protection obligations (encryption, sensitive-data handling, backups, control-center communications integrity) and reinforce each other. TSA has no counterpart -- notable given pipelines transmit SCADA/telemetry data much as NERC-regulated control centers do." }, { "category": "PR.PS", "function": "PROTECT", "category_name": "Platform Security", "verdict": "Partial", "frameworks_present": "CPG; NERC CIP; TSA", "rationale": "The strongest three-way convergence on control CONTENT: patch management, malicious-code prevention, and platform hardening appear in CPG (2.M/2.N/2.Q/2.V/2.W), NERC CIP-007/CIP-010, and TSA. But TSA's ransomware-mitigation actions are currently effective while its patch-management specificity (49 CFR 1586.207) is still only PROPOSED -- reinforcing in intent, partial in current binding force." }, { "category": "PR.IR", "function": "PROTECT", "category_name": "Technology Infrastructure Resilience", "verdict": "Partial", "frameworks_present": "CPG; NERC CIP; TSA", "rationale": "Network segmentation / IT-OT boundary protection is a genuinely converging theme: CPG (2.F/2.X), NERC CIP-005 (currently binding), and TSA's PROPOSED 49 CFR 1586.207 segmentation requirement. Reinforcing in principle; TSA's version is not yet binding." }, { "category": "DE.CM", "function": "DETECT", "category_name": "Continuous Monitoring", "verdict": "Partial", "frameworks_present": "CPG; NERC CIP; TSA", "rationale": "CPG (2.G/2.T/3.A) and NERC CIP-007 logging are currently-binding and reinforcing; TSA's continuous-monitoring requirement (49 CFR 1586.221) is currently only PROPOSED. Same reinforcing-in-principle / partial-in-force pattern as PR.PS and PR.IR." }, { "category": "DE.AE", "function": "DETECT", "category_name": "Adverse Event Analysis", "verdict": "Gap", "frameworks_present": "(none)", "rationale": "No framework in this crosswalk imposes a standalone adverse-event-ANALYSIS obligation distinct from monitoring/logging itself. All three frameworks require collecting signals (DE.CM) but none explicitly requires correlating or analyzing them as a separate duty -- a genuine blind spot shared across the entire regulatory landscape studied here." }, { "category": "RS.MA", "function": "RESPOND", "category_name": "Incident Management", "verdict": "Partial", "frameworks_present": "CPG; NERC CIP", "rationale": "NERC CIP-008-PLAN is the most explicit incident-response-PLAN-maintenance requirement (including periodic testing); CPG's 2.S is present but more aspirational. TSA's currently-effective obligations address recovery (RC.RP) and reporting (RS.CO) but not incident-management-plan maintenance as its own duty -- a gap specific to TSA within this category." }, { "category": "RS.AN", "function": "RESPOND", "category_name": "Incident Analysis", "verdict": "Gap", "frameworks_present": "(none)", "rationale": "No framework imposes a standalone incident-ANALYSIS (root-cause, scope, impact determination) obligation distinct from response and reporting. A second blind spot in the same family as DE.AE." }, { "category": "RS.CO", "function": "RESPOND", "category_name": "Incident Response Reporting and Communication", "verdict": "Conflict", "frameworks_present": "CPG; NERC CIP; TSA", "rationale": "Marquee finding, author-reviewed 2026-09-19 (docs/VERIFY_CHECKLIST.md): all three frameworks require incident reporting, but with materially different clocks and destinations: NERC CIP-008-REPORT requires E-ISAC/NCCIC notification within 1 HOUR of determining a Reportable Cyber Security Incident (next calendar day for an attempted compromise); the currently-effective TSA Security Directive requires CISA notification within 24 HOURS; CPG's reporting goal (4.A) sets no fixed mandatory clock at all. A single operator jointly touched by NERC CIP and TSA obligations (e.g., a pipeline compressor station co-located with, or interconnected to, BES facilities) faces genuinely different timers and different recipient agencies for what may be the same incident. This mirrors CRS's independently documented finding (R49009) of a 24h-vs-72h-vs-'without delay' conflict among TSA/CISA-CIRCIA/USCG reporting rules -- extended here to show NERC CIP's 1-hour clock is tighter still, and that CRS's own analysis did not previously include NERC CIP in that comparison. Unlike several other Partial cells in this crosswalk, this conflict is not a temporary artifact of TSA's still-proposed rule: NERC CIP-008's clock and the CURRENTLY EFFECTIVE TSA Security Directive's 24-hour clock are both already binding today, so the misalignment is live now, not merely a risk the final TSA rule might create." }, { "category": "RS.MI", "function": "RESPOND", "category_name": "Incident Mitigation", "verdict": "Gap", "frameworks_present": "(none)", "rationale": "No framework imposes a standalone in-incident MITIGATION obligation distinct from the protective controls that precede an incident (PR.PS) or the recovery that follows one (RC.RP). A third blind spot in the same family as DE.AE and RS.AN -- together these three gaps suggest all frameworks studied emphasize monitoring and protection over analysis and in-the-moment mitigation, a pattern worth naming explicitly in the discussion." }, { "category": "RC.RP", "function": "RECOVER", "category_name": "Incident Recovery Plan Execution", "verdict": "Reinforce", "frameworks_present": "CPG; NERC CIP; TSA", "rationale": "CPG (5.A), NERC CIP-009, and the CURRENTLY EFFECTIVE TSA Security Directive (Cybersecurity Incident Response Plan / contingency and recovery plans) all require recovery planning, and notably all three are ALREADY BINDING or in force (none depends on the still-proposed TSA rule). This is the cleanest, strongest three-way alignment in the entire crosswalk." }, { "category": "RC.CO", "function": "RECOVER", "category_name": "Incident Recovery Communication", "verdict": "Gap", "frameworks_present": "(none)", "rationale": "No framework separately requires recovery-phase stakeholder communication (as distinct from the initial incident-reporting duty captured under RS.CO). A fourth blind-spot category." } ]