CRA対応、2つのデッドライン：2026年「報告義務」／2027年「適合義務」で必要な実務タスクとは？

実務的課題と「今やるべき」ドキュメント・プロセス整備

　ここまで見てきた通り、2026年と2027年では求められるアクションが異なります。規格の要求事項から逆算し、直近の対応から順に「今すぐ整備すべきタスク」を整理します。

1.【2026年対応】脆弱性ハンドリングおよびCVDポリシーの策定

　最優先は、EN 40000-1-3に基づく「脆弱性ハンドリングポリシー（社内向け）」と、「協調的脆弱性開示（CVD）ポリシー（対外向け）」の策定です。 外部からの報告をどの窓口で受け付け、誰が24時間以内にENISAへ初期報告を行い、どのように修正パッチを開発・公開するのか。その運用ルールを文書化し、社内体制を整えます。

　この際、実務の具体性を高めるための参考情報として、GCVEのガイドライン『GCVE-BCP-02』などをあわせて確認してみるのもよいでしょう。GCVE（Global CVE Allocation System）は、従来のCVEシステムを補完する新たなグローバル・イニシアチブであり、そのベストプラクティス集であるBCP-02には、報告者とのやり取りやアドバイザリ公開の具体的な手順など、現場目線のノウハウがまとめられています。規格が求める抽象的な要求事項を、自社の運用マニュアルへと落とし込む際の一つのヒントとして活用できるリソースです。

2.【2026年対応】過去製品の棚卸しと、製品監視と受領プロセスの構築

　2026年の報告義務で注意すべきは、監視対象が「これから開発する新製品」だけでなく、「既に市場に出回っているサポート期間中の全製品」になるという点です。そのため、監視プロセスを構築する前提として、自社が過去にリリースした製品の棚卸しを行い、「監視対象を正確に把握すること」が重要な準備タスクとなります。 対象を特定した上で、出荷済み製品の脆弱性情報を収集し続ける「監視（Monitoring）体制」を構築します。外部の脆弱性データベースや脅威情報を夜間・休日問わず検知し、担当者へ連携・エスカレーションできる仕組みが不可欠です。

3.【2027年対応】SBOMの自動生成・管理プロセスの確立

　EN 40000-1-3（Clause 5.3.8）で規定されるSBOMは、2026年時点でも脆弱性の影響範囲特定に有用ですが、2027年以降は適合証明の必須要件となります。ソフトウェアのビルドごとに最新のSBOMを生成し、機械可読形式で管理するプロセスを開発パイプラインに組み込む必要があります。

4.【2027年対応】リスクアセスメント手法の定義と適用

　EN 40000-1-2に沿って、自社製品に対する「リスク評価の手法と受容基準（どこまでのリスクを許容するか）」を定義します。2027年に市場に出る製品は現在設計フェーズにあると考えられるため、早期にこの手法を適用し、「なぜこのセキュリティ機能を選択したか」という設計根拠を技術文書として蓄積し始める必要があります。

まとめ＆次回予告

　CRAの要求事項を満たすためには、以下2つのマイルストーンに対して並行して取り組む必要があります。

　ここで実務上の最大の課題となるのが、「誰がこれらのプロセスを回すのか」という組織の問題です。24時間体制の監視や、部門横断的なリスク評価を、既存の開発部門や品質保証部門だけで兼任するのは現実的ではありません。

　そこで次回（第3回）は、今回整理したタスクを現実に稼働させるための「CRA各要求事項への対応の鍵（1）：組織体制づくり」について解説します。インシデント対応の司令塔となる「PSIRT（Product Security Incident Response Team）」の役割や、社内外のリソース活用について深掘りしていきます。