ISO/IEC 29147 と 30111 は必ず一緒に整備するのか

対で整えることを勧めます。CRA の脆弱性に関する義務は対外的な開示と社内の対応の両方にわたり、別々に進めると引き継ぎの部分に監査上の欠落が残りがちです。

小さな会社でも専任の製品セキュリティチームが必要か

大きな体制は必ずしも必要ありませんが、明確な報告窓口、責任者、応答の手順は必要です。

CRA の脆弱性報告義務はいつからか

第 14 条の報告義務は 2026 年 9 月 11 日から適用され（第 71 条第 2 項）、2027 年 12 月 11 日より前に市場に出された製品にも及びます（第 69 条第 3 項）。実際に悪用された脆弱性は、認識から 24 時間以内に早期警告、72 時間以内に通知、是正措置または緩和措置が利用可能になってから 14 日以内に最終報告です。製品のセキュリティに影響する重大インシデントは、24 時間以内に早期警告、72 時間以内に通知、インシデント通知から 1 か月以内に最終報告です。報告は ENISA の単一報告プラットフォームで行い、このプラットフォームは 2026 年 9 月 11 日に稼働しました。

ISO/IEC 29147 に新しい版はあるか

改訂が ISO/IEC JTC 1/SC 27 で始まっています。ISO/IEC 29147 第 3 版は 2025 年 10 月 8 日に作業項目として登録され、ISO/IEC 30111 の改訂作業原案は脆弱性の対応と開示を一つの規格にまとめるものです。新しい版はまだ発行されておらず、現行版は ISO/IEC 29147:2018 と ISO/IEC 30111:2019 です。

台湾で ISO/IEC 29147 コンサルタントを選ぶには：八つの判断基準

直答：ISO/IEC 29147 のコンサルタントに最初に聞くべきことは「外部の研究者や顧客が自社製品の脆弱性を見つけたとき、報告窓口を見つけられるか、どれくらいで返事が届くか」です。ISO/IEC 29147 は、ベンダーが脆弱性の報告をどう受け付け、報告者とどう調整し、修正のアドバイザリをどう公開するかを定めます。つまり協調的脆弱性開示（CVD）の対外的な窓口の規格です。報告を受けた後の検証、優先度付け、修正は ISO/IEC 30111 が扱い、両者は対で整備します。次に、コンサルタントがこれを EU の CRA につなげられるかを確認します。CRA（規則 (EU) 2024/2847）附属書 I 第 2 部は、製造業者に、協調的脆弱性開示の方針を定めて実施すること（第 5 点）、脆弱性を報告するための連絡先を設けること（第 6 点）、セキュリティアップデートが利用可能になった後に修正済みの脆弱性の情報を公開すること（第 4 点）を求めています。第 14 条の報告義務は 2026 年 9 月 11 日から適用され、実際に悪用された脆弱性は、認識してから 24 時間以内に早期警告、72 時間以内に通知、是正措置または緩和措置が利用可能になってから 14 日以内に最終報告を、ENISA の単一報告プラットフォームを通じて、調整役に指定された CSIRT と ENISA に同時に提出します。CRA 自体は ISO/IEC 29147 を名指ししていませんが、EU の共同研究センター（JRC）と ENISA による 2024 年の規格対応分析は、EN ISO/IEC 29147 が附属書 I 第 2 部の八つの脆弱性対応要求のうち四つ（第 2、4、5、6 点）に対応するとしています。

29147 と 30111 の役割分担

規格	扱う範囲	主な成果物
ISO/IEC 29147（脆弱性開示）	対外：報告の受付、報告者とのやり取り、アドバイザリの公開	報告窓口と security.txt、協調的開示の方針、アドバイザリのひな形
ISO/IEC 30111（脆弱性対応）	社内：検証、優先度付け、根本原因分析、修正とリリース	対応プロセス、優先度付けの基準、対応記録と期限

八つの判断基準

基準	どのコンサルタントにもそのまま聞ける質問
報告窓口	外部の人はどうやって報告窓口を見つけるのか。security.txt で公開するか
受付と応答の期限	報告を受けてから、どれくらいで受付を伝え、進捗を知らせるのか。誰が担うのか
協調的開示の方針	方針にはどんな約束と期待を書くのか。善意の研究者に対する立場は何か
アドバイザリと修正情報	アドバイザリに何を書き、どの経路で、いつ公開するのか
脆弱性の識別番号	必要なとき、CVE 番号をどう取得するのか
30111 との接続	外部から受けた報告を社内の対応プロセスにどう引き継ぎ、状況を報告者にどう返すのか
EU CRA との対応	CRA 附属書 I 第 2 部の八つの要求と一点ずつ照らし合わせられるか。29147 が対応するのは第 2、4、5、6 点で、SBOM（第 1 点）、セキュリティのテストとレビュー（第 3 点）、アップデートの安全な配布（第 7 点）は何で補うのか。第 14 条の報告は誰が担うのか
誰が主導し、外注するか	実際に案件を率いるのは誰で、どんな資格を持つのか。再委託はあるか

コンサルタントが必要ない場合

製品が EU 市場に出ず、顧客からも協調的開示の方針を求められていない場合は、ISO/IEC 29147 にもとづいて報告窓口と簡単な対応方針を自社で公開することから始められます。製品が CRA の対象であれば、報告義務はすでに適用されているため、プロセス全体を整えて訓練しておくことを勧めます。

積穗科研の取り組み

以下は積穗科研自身による説明です。上の質問で、他のコンサルタントと同じように私たちも確かめてください。

報告窓口：security.txt と報告用のメールアドレスまたはフォームを整えます
受付と応答の期限：報告の受付と応答の期限を定めます
協調的開示の方針：協調的脆弱性開示の方針文書（セーフハーバー条項を含む）を作成します
アドバイザリと修正情報：アドバイザリのひな形と公開の手順を整え、必要に応じて CVE 番号の申請を支援します
30111 との接続：対外的な開示を社内の脆弱性対応プロセスにつなげます
実務の経験：積穗科研は自ら脆弱性の監視とコンプライアンスの証拠の仕組みを運用しており、支援の内容は実際の導入経験にもとづきます
誰が主導するか：副社長・取締役クラスのコンサルタントが全工程を担当し、外注しません

コンプライアンスは三位一体、コンサルタントの価値は統合にある

CRA、TISAX、ISO 27701、AI Act はどれも単独の技術課題ではなく、プロセス・セキュリティ技術・法令遵守の三つが同時に成立して初めて完成します。一つだけ補っても、残り二つの欠落は審査・通報・顧客デューデリジェンスの場面で露呈し、結局やり直しになります。

側面	答えるべき問い	その側面だけ補った場合によくある欠落
プロセス（マネジメントシステム）	誰が、何を、いつ行うか。実施の証拠はどこにあり、どう継続的に改善するか	ツールは揃っているが定期的に運用する人がおらず、審査時に記録が出せない
セキュリティ技術	管理策をどう設計し、有効性をどう検証するか	文書は整っているが、システムが実際にはそのとおり動いていない
法令遵守	どの法規が適用され、自社の役割は何か。期限と罰則は何か	管理策は作ったが、法規や役割を取り違えており、義務が網羅されていない

積穗科研のコンサルティングチームはこの三つの側面を同時にカバーし、法規判定からプロセス設計、技術的管理策までを一括で設計します。一つの証拠セットで複数の法規と顧客要求に対応できます。

関連サービス無料のメカニズム診断を申し込む