TSA surface cyber proposal needs scope-and-status lineage

Store rule status as a decision field

The direct answer is to preserve the Federal Register action as a proposal, not a current universal control mandate. The record identifies a notice of proposed rulemaking, publication date, docket, comment deadline, cited CFR parts, and proposed text. A control library should retain those fields together with the observation date, source URL, later Federal Register actions, and the person responsible for status review. A proposed requirement may support impact analysis without being represented as effective law. ^[1]

Use separate states for proposal, comment period, supplemental proposal, withdrawal, final rule, effective date, compliance date, court or agency action, security directive, recommendation, and internal policy. Similar control language can appear in several authorities while applying to different audiences and dates. The register should link those instruments without replacing their individual status, scope, exceptions, or evidence requirements.

Resolve the operator and mode before mapping requirements

The proposal does not assign one identical program to every surface-transportation organization. It discusses designated freight railroads, passenger railroads and rail transit, specified pipeline facilities and systems, and a narrower incident-reporting obligation for certain over-the-road bus owner/operators. A scope record should identify the legal entity, operating mode, facility or system, cited applicability provision, designation or threshold evidence, exclusions, source date, reviewer, and unresolved facts. ^[1]

Do not infer coverage from a company name, industry code, asset type, supplier relationship, or a platform's compliance label. Complex groups may operate several modes through different legal entities, and a shared network may support both covered and noncovered functions. Preserve the organizational and system boundary used for the assessment, who approved it, and what change—acquisition, route, facility, designation, service, or later rule—requires reevaluation.

Keep each proposed program object traceable

The proposal describes a cybersecurity-risk-management program and related roles, implementation planning, assessment, incident response, reporting, testing, and governance elements for covered populations. An impact record should map each proposed section to the affected entity and system boundary, present-state evidence, gap, dependency, responsible function, estimated work, decision, and review trigger. It should not mark a proposal complete or overdue as though a final compliance clock had started. ^[1]

Where the proposal refers to cybersecurity coordinators, operational implementation plans, assessment plans, incident-response plans, reporting, or independent evaluation, preserve those as separate governed objects. Appointment, plan approval, implementation, operating evidence, test results, exceptions, remediation, and regulator communication are different states. Limit public reporting and buyer evaluation to governance evidence; do not expose sensitive architecture, vulnerability, response, or facility details. ^[1]

Reconcile later authority without rewriting history

The existing TSA Pipeline-2021-02F analysis answers a different question: it warns that a directive with a stated May 2, 2026 expiration cannot power a current control badge without successor authority. This article governs a broader proposed surface-rule record and the decision to keep proposal status and mode-specific scope attached. A future final action could change the answer, but it would add a new source, date, scope comparison, and transition decision rather than convert the 2024 proposal into a final record.

A representative review should select one organization from each potentially affected mode, resolve the legal entity and applicability facts, map the proposed requirements, identify existing directive or voluntary-framework evidence, and record every uncertainty. Then introduce a scope change and a later agency action. The test passes when reviewers can reproduce which source controlled each decision at the time and can update the program without erasing prior proposal analysis.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

OT Defense Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.