NIST SP 800-18r2 ― Security・Privacy・C-SCRMを別々の計画書にしない
Executive Summary
NISTは2026年6月30日、SP 800-18 Revision 2「Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems」を最終公開しました。約20年ぶりのRevisionで、System Security Plan、System Privacy Plan、C-SCRM Planを相互に関連する「System Plans」として整理します。1
ポイントは文書を増やすことではなく、Asset、Data Flow、Control、Owner、Risk DecisionをSecurity・Privacy・Supply Chainで共有し、一つのSystem Boundaryを同じ情報から管理することです。
なぜ今なのか
Security、Privacy、Procurementが別々に同じSystemを評価すると、Asset、Data、Supplier、Ownerの情報が不一致になり、Control gapや重複作業が生まれます。Cloud / SaaS / AI Serviceの利用拡大で、System Boundaryは自社内だけでは閉じなくなっています。
何が起きているのか
SP 800-18r2は3種類のSystem Planに必要なEssential Elementを整理し、NIST RMFのStep / Taskと関連付けます。Systemが扱うData、Responsible Person、Environment、Component、Internal/External Data Flow、Planned/In-place ControlをCentral Referenceとして維持する考え方です。
経営インパクト
| 観点 | 影響 |
|---|---|
| Governance | Security / Privacy / C-SCRMの責任分界と共通情報を明確化 |
| Evidence | 監査・認可・Risk Reviewで同じ情報を再利用できる |
| Third-party | Supplier / External ServiceをSystem Boundary内のRiskとして扱う |
| AI / Cloud | Data FlowとExternal Dependencyが多いSystemほど効果が大きい |
日本企業への示唆
日本企業でもISMS、Privacy、委託先管理、Cloud審査、AI審査が別Formで実施されることがあります。共通のSystem / Service Recordを作り、その上に各専門Controlを重ねる方式へ変えると、利用部門の審査負荷と管理部門の情報不整合を減らせます。
推奨アクション
- System / Service単位の共通Recordを定義する
- Asset / Data Flow / Owner / Supplier情報を一元化する
- Security / Privacy / C-SCRMのControl Mappingを作る
- System変更時に3領域を同時更新する
- Risk Acceptanceを一つのDecision Logへ集約する
- AI / SaaS Reviewにも同じSystem Planを再利用する
用語解説
System Plan
Systemの目的、Boundary、Control、責任、Risk Decision等を記録する計画・管理情報。
C-SCRM
Cybersecurity Supply Chain Risk Management。SupplierやService Dependencyを通じたCyber Riskの管理。