IT製品調達セキュリティ要件リスト第2.1版 ― ProcurementをSecurity Controlとして使う
Executive Summary
2026年2月6日、経済産業省は「IT製品の調達におけるセキュリティ要件リスト」第2.1版を公開し、IPAも活用Guidebook第2.1版を公開しました。1
このListは政府機関等の調達で参照されるSecurity Requirementを整理するもので、第2.1版では従来11製品分野の要件が更新されています。
企業にとって重要なのは、Securityを導入後の設定問題だけでなく、製品選定・契約前に要求すべき品質として扱う考え方です。
なぜ今なのか
導入後に「Logが取れない」「Patch Supportが短い」「Strong Authenticationに対応しない」と判明しても、Architectureを変えるCostは高くなります。Security RequirementはProcurement段階で入れる方が効率的です。
Procurementで見るべき観点
- Authentication / Access Control
- Logging / Audit
- Secure Update
- Vulnerability Handling
- Cryptographic Function
- Management Interface
- Security Certification / Evidence
- Support / Lifecycle
経営インパクト
| 観点 | 影響 |
|---|---|
| Procurement | Price / FunctionだけでなくSecurity Requirementを評価 |
| Architecture | 後付けControl Costを下げる |
| Vendor Risk | Product Security Evidenceを契約前に確認 |
| Lifecycle | Support / Update条件をTotal Costへ反映 |
日本企業への示唆
政府調達向けListをそのまま適用する必要はありませんが、自社RFP / RFIのSecurity Requirementを作るReferenceとして有用です。
推奨アクション
- Critical Product向けSecurity Requirement Templateを作る
- RFPへLogging / MFA / Update / Vulnerability要件を入れる
- Vendor Evidenceの提出条件を決める
- ExceptionをRisk Acceptance Processへ接続する
- Support / EOLをCommercial条件と同時に評価する
- Procurement / Security / Architectureで共同Reviewする
用語解説
Security by Procurement
Security Requirementを製品・Serviceの購入前に明示し、Vendor選定・契約条件を通じてRiskを低減する考え方。