【テンプレあり】英語セキュリティロードマップ計画書の書き方｜ITプロジェクトで使える日英フォーマット付き

セキュリティ施策を英語でどう説明すればいいかわからない。グローバルチームに脅威対策や改善計画を共有しても、優先度や根拠が伝わらず会議が停滞する。そんな経験を持つエンジニアは多い。

セキュリティロードマップ計画書は、組織のセキュリティ強化を時系列で可視化し、ステークホルダーに方針を伝えるための文書だ。英語で書くことで、CISO・CTO・経営層への報告が格段にスムーズになる。

この記事では、英語セキュリティロードマップ計画書を4つのセクションで構成する方法を解説する。日英テンプレートをそのまま流用できる。

英語でセキュリティ計画を文書化することで、承認プロセスが加速し、予算確保の根拠も明確になる。

---

セキュリティロードマップ計画書を英語で書く理由

セキュリティロードマップ計画書を英語で作成する目的は、技術的な施策をビジネス言語に翻訳して伝えることだ。

日本語のみの設計書では、海外拠点・外部監査・グローバルパートナーとの連携で情報共有に遅れが生じる。特にISO 27001やSOC 2などの国際規格対応では、英語ドキュメントが必須になるケースが多い。

英語で書く主なメリットは3つある。

• 国際規格対応：ISO 27001・SOC 2・NISTフレームワークとの整合が取りやすい
• 経営層への報告：リスクと投資対効果をビジネス言語で説明できる
• グローバルチームとの連携：全拠点のエンジニアがセキュリティ方針を理解できる

セキュリティロードマップ計画書は4つのセクションで構成する。次のセクションから順に解説する。

---

Section 1：Scope & Governance（スコープとガバナンス）

最初のセクションでは、セキュリティロードマップの対象範囲と意思決定の仕組みを定義する。

スコープを明確にしないまま進めると、施策が分散し、優先度の高い資産が保護されないリスクがある。ガバナンス体制を文書化することで、CISO・セキュリティチーム・各部門の責任範囲が明確になる。

Scope（対象範囲）の書き方

項目	英語表現	日本語訳
対象システム	Systems in scope	対象システム
対象データ	Data in scope	対象データ
対象外	Out of scope	対象外
計画期間	Planning horizon	計画期間
フレームワーク	Security framework	セキュリティフレームワーク

英語テンプレート：

## Scope

### Systems in Scope
- Corporate network and endpoints
- Cloud infrastructure (AWS, Azure, GCP)
- SaaS applications (Salesforce, Workday, GitHub Enterprise)
- On-premises data centers

### Data in Scope
- Customer PII (Personal Identifiable Information)
- Financial records
- Intellectual property and source code

### Security Framework
NIST Cybersecurity Framework (CSF) — Identify, Protect, Detect, Respond, Recover

### Planning Horizon
This roadmap covers a 24-month period: FY2026–FY2027

日本語テンプレート：

## スコープ

### 対象システム
- 社内ネットワークとエンドポイント
- クラウドインフラ（AWS・Azure・GCP）
- SaaSアプリケーション（Salesforce・Workday・GitHub Enterprise）
- オンプレミスデータセンター

### 対象データ
- 顧客PII（個人識別情報）
- 財務データ
- 知的財産・ソースコード

### セキュリティフレームワーク
NISTサイバーセキュリティフレームワーク（CSF）— 識別・保護・検知・対応・回復

### 計画期間
本ロードマップはFY2026〜FY2027の24ヶ月間をカバーする。

Governance（ガバナンス）の書き方

役割	英語表現	責任
CISO	Chief Information Security Officer	セキュリティ戦略の最終責任者
セキュリティリード	Security Lead	施策の設計・実行管理
リスクオーナー	Risk Owner	各部門のリスク管理責任者
コンプライアンス担当	Compliance Officer	規制対応・監査窓口
インシデント対応チーム	Incident Response Team	検知・封じ込め・回復

英語テンプレート：

## Governance

| Role | Assignee | Responsibility |
|------|----------|---------------|
| CISO | | Overall security strategy and accountability |
| Security Lead | | Design and execute security initiatives |
| Risk Owner | | Manage risks within each business unit |
| Compliance Officer | | Regulatory compliance and audit coordination |
| Incident Response Team | | Detect, contain, and recover from incidents |

### Decision-Making Process
- Strategic changes: Approved by CISO and executive leadership
- Tactical initiatives: Approved by Security Lead
- Emergency response: Incident Response Team has authority to act immediately

---

Section 2：Current State Assessment（現状評価）

2つ目のセクションでは、現在のセキュリティ態勢を客観的に評価する。

現状を正確に把握しないまま施策を立案すると、リソースが優先度の低い領域に集中するリスクがある。ギャップ分析を文書化することで、経営層が投資判断を下しやすくなる。

リスク評価マトリクスの書き方

リスクを「影響度」×「発生可能性」で分類する。

リスクレベル	英語表現	対応優先度
重大	Critical	即時対応（30日以内）
高	High	優先対応（90日以内）
中	Medium	計画対応（180日以内）
低	Low	モニタリング継続

英語テンプレート：

## Current State Assessment

### Security Maturity Summary

| Domain | Current Maturity | Target Maturity | Gap |
|--------|-----------------|-----------------|-----|
| Identity & Access Management | Level 2 | Level 4 | 2 |
| Network Security | Level 3 | Level 4 | 1 |
| Data Protection | Level 1 | Level 3 | 2 |
| Endpoint Security | Level 2 | Level 3 | 1 |
| Incident Response | Level 2 | Level 4 | 2 |
| Cloud Security | Level 2 | Level 4 | 2 |

Maturity Scale: 1 = Initial / 2 = Developing / 3 = Defined / 4 = Managed / 5 = Optimizing

### Top Risk Register

| Risk | Likelihood | Impact | Risk Level | Owner |
|------|-----------|--------|-----------|-------|
| Phishing / social engineering | High | Critical | Critical | Security Lead |
| Unpatched third-party software | Medium | High | High | IT Operations |
| Excessive privileged access | High | High | High | IAM Team |
| Unsecured cloud storage buckets | Medium | Critical | High | Cloud Team |
| Lack of MFA on critical systems | High | High | High | IAM Team |

日本語テンプレート：

## 現状評価

### セキュリティ成熟度サマリー

| ドメイン | 現在の成熟度 | 目標成熟度 | ギャップ |
|---------|------------|----------|--------|
| ID・アクセス管理 | Level 2 | Level 4 | 2 |
| ネットワークセキュリティ | Level 3 | Level 4 | 1 |
| データ保護 | Level 1 | Level 3 | 2 |
| エンドポイントセキュリティ | Level 2 | Level 3 | 1 |
| インシデント対応 | Level 2 | Level 4 | 2 |
| クラウドセキュリティ | Level 2 | Level 4 | 2 |

成熟度スケール：1=初期 / 2=開発中 / 3=定義済み / 4=管理済み / 5=最適化

### トップリスク一覧

| リスク | 発生可能性 | 影響度 | リスクレベル | オーナー |
|-------|----------|--------|------------|--------|
| フィッシング・ソーシャルエンジニアリング | 高 | 重大 | Critical | セキュリティリード |
| サードパーティソフトウェアの未パッチ | 中 | 高 | High | IT運用チーム |
| 過剰な特権アクセス | 高 | 高 | High | IAMチーム |
| 保護されていないクラウドストレージ | 中 | 重大 | High | クラウドチーム |
| 重要システムへのMFA未適用 | 高 | 高 | High | IAMチーム |

セキュリティ計画はエンタープライズアーキテクチャ全体と整合させる必要がある。英語エンタープライズアーキテクチャ計画書の書き方も合わせて参照してほしい。

---

Section 3：Roadmap & Initiatives（ロードマップと施策）

3つ目のセクションでは、セキュリティ強化施策をフェーズ別に整理する。

施策をフェーズに分けず一括で列挙すると、優先度が不明確になる。Quick Wins（短期成果）とLong-term Investments（長期投資）を分けて提示することで、経営層の承認を得やすくなる。

フェーズ構成の書き方

フェーズ	期間	英語表現	目標
Phase 1	0〜6ヶ月	Foundation & Quick Wins	最重要リスクの即時対処
Phase 2	7〜12ヶ月	Consolidation	セキュリティ基盤の強化
Phase 3	13〜24ヶ月	Optimization	自動化と継続的改善

英語テンプレート：

## Security Roadmap

### Phase 1: Foundation & Quick Wins (Months 1–6)

| Initiative | Priority | Owner | Estimated Cost | Status |
|-----------|---------|-------|---------------|--------|
| Deploy MFA on all critical systems | Critical | IAM Team | $20K | Planned |
| Conduct phishing simulation & training | High | Security Lead | $10K | Planned |
| Patch management automation | High | IT Operations | $30K | Planned |
| Cloud storage audit and remediation | High | Cloud Team | $15K | Planned |
| Privileged access review | Critical | IAM Team | $5K | Planned |

### Phase 2: Consolidation (Months 7–12)

| Initiative | Priority | Owner | Estimated Cost | Status |
|-----------|---------|-------|---------------|--------|
| Zero Trust network architecture | High | Network Team | $150K | Planned |
| SIEM deployment (centralized logging) | High | Security Lead | $80K | Planned |
| Data classification and DLP rollout | Medium | Data Team | $60K | Planned |
| Endpoint Detection & Response (EDR) | High | IT Operations | $70K | Planned |
| Vendor security assessment program | Medium | Compliance Officer | $20K | Planned |

### Phase 3: Optimization (Months 13–24)

| Initiative | Priority | Owner | Estimated Cost | Status |
|-----------|---------|-------|---------------|--------|
| Security automation (SOAR) | Medium | Security Lead | $120K | Planned |
| Red team / penetration testing | High | External Vendor | $80K | Planned |
| ISO 27001 / SOC 2 certification | High | Compliance Officer | $150K | Planned |
| AI-driven threat detection | Medium | Security Lead | $100K | Planned |
| Security champions program | Medium | All Teams | $30K | Planned |

日本語テンプレート：

## セキュリティロードマップ

### Phase 1: 基盤整備とQuick Wins（1〜6ヶ月）

| 施策 | 優先度 | オーナー | 概算コスト | ステータス |
|-----|--------|---------|----------|----------|
| 重要システム全体へのMFA展開 | Critical | IAMチーム | 200万円 | 計画中 |
| フィッシングシミュレーション・研修 | High | セキュリティリード | 100万円 | 計画中 |
| パッチ管理の自動化 | High | IT運用チーム | 300万円 | 計画中 |
| クラウドストレージ監査と是正 | High | クラウドチーム | 150万円 | 計画中 |
| 特権アクセスレビュー | Critical | IAMチーム | 50万円 | 計画中 |

### Phase 2: 基盤強化（7〜12ヶ月）

| 施策 | 優先度 | オーナー | 概算コスト | ステータス |
|-----|--------|---------|----------|----------|
| ゼロトラストネットワーク構築 | High | ネットワークチーム | 1,500万円 | 計画中 |
| SIEM導入（集中ログ管理） | High | セキュリティリード | 800万円 | 計画中 |
| データ分類とDLPの展開 | Medium | データチーム | 600万円 | 計画中 |
| EDR（エンドポイント検知応答）導入 | High | IT運用チーム | 700万円 | 計画中 |
| ベンダーセキュリティ評価プログラム | Medium | コンプライアンス担当 | 200万円 | 計画中 |

### Phase 3: 最適化（13〜24ヶ月）

| 施策 | 優先度 | オーナー | 概算コスト | ステータス |
|-----|--------|---------|----------|----------|
| セキュリティ自動化（SOAR） | Medium | セキュリティリード | 1,200万円 | 計画中 |
| レッドチーム・侵入テスト | High | 外部ベンダー | 800万円 | 計画中 |
| ISO 27001 / SOC 2認証取得 | High | コンプライアンス担当 | 1,500万円 | 計画中 |
| AI活用型脅威検知 | Medium | セキュリティリード | 1,000万円 | 計画中 |
| セキュリティチャンピオンプログラム | Medium | 全チーム | 300万円 | 計画中 |

---

Section 4：Metrics & Reporting（メトリクスと報告体制）

4つ目のセクションでは、セキュリティの改善状況を定量化する指標と報告サイクルを定義する。

メトリクスがなければ、施策の効果を経営層に証明できない。KPIを設定することで、セキュリティ投資のROIを数字で示せるようになる。

セキュリティKPIの書き方

KPI	英語表現	測定方法
平均検知時間	MTTD (Mean Time to Detect)	SIEMログ分析
平均対応時間	MTTR (Mean Time to Respond)	インシデントチケット
パッチ適用率	Patch compliance rate	脆弱性スキャン
フィッシング失敗率	Phishing failure rate	社内訓練結果
MFA適用率	MFA coverage rate	IAMダッシュボード
重大インシデント件数	Critical incidents per quarter	インシデントログ

英語テンプレート：

## Metrics & Reporting

### Security KPIs

| KPI | Baseline | Target (6M) | Target (12M) | Measurement |
|-----|---------|------------|-------------|-------------|
| MTTD (Mean Time to Detect) | 72 hours | 48 hours | 24 hours | SIEM dashboard |
| MTTR (Mean Time to Respond) | 8 hours | 4 hours | 2 hours | Incident tickets |
| Patch compliance rate | 65% | 85% | 95% | Vulnerability scan |
| Phishing failure rate | 30% | 15% | 5% | Phishing simulation |
| MFA coverage rate | 40% | 80% | 100% | IAM dashboard |
| Critical incidents per quarter | 4 | 2 | 0 | Incident log |

### Reporting Cadence

| Report | Audience | Frequency | Format |
|--------|---------|-----------|--------|
| Security Operations Dashboard | Security Team | Daily | Dashboard |
| Incident Summary | CISO, Security Lead | Weekly | Email |
| Risk & KPI Report | CISO, CTO | Monthly | Slide deck |
| Executive Security Briefing | Board, CEO, CFO | Quarterly | Presentation |
| Annual Security Review | All Stakeholders | Annually | Report |

日本語テンプレート：

## メトリクスと報告体制

### セキュリティKPI

| KPI | 現在値 | 目標（6ヶ月後） | 目標（12ヶ月後） | 測定方法 |
|-----|--------|--------------|--------------|--------|
| 平均検知時間（MTTD） | 72時間 | 48時間 | 24時間 | SIEMダッシュボード |
| 平均対応時間（MTTR） | 8時間 | 4時間 | 2時間 | インシデントチケット |
| パッチ適用率 | 65% | 85% | 95% | 脆弱性スキャン |
| フィッシング失敗率 | 30% | 15% | 5% | 社内訓練 |
| MFA適用率 | 40% | 80% | 100% | IAMダッシュボード |
| 重大インシデント件数（四半期） | 4件 | 2件 | 0件 | インシデントログ |

### 報告サイクル

| レポート | 対象者 | 頻度 | 形式 |
|---------|--------|------|------|
| セキュリティ運用ダッシュボード | セキュリティチーム | 日次 | ダッシュボード |
| インシデントサマリー | CISO・セキュリティリード | 週次 | メール |
| リスク・KPIレポート | CISO・CTO | 月次 | スライド |
| 経営幹部向けセキュリティ報告 | 取締役会・CEO・CFO | 四半期 | プレゼン |
| 年次セキュリティレビュー | 全ステークホルダー | 年次 | レポート |

インナーソース開発環境でのセキュリティポリシー整備には、英語インナーソース計画書の書き方と組み合わせることで、開発・運用・セキュリティの方針を一体的に管理できる。

---

テンプレートをダウンロード（Word）

以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。

📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)

日本語版テンプレート（コピペOK）

【英語セキュリティロードマップ計画書】

組織名：
作成日：
作成者：
計画期間：
対象フレームワーク：

■ 1. スコープとガバナンス
対象システム：
対象データ：
セキュリティフレームワーク：

役割 | 担当者 | 責任
----|--------|----
CISO |  | セキュリティ戦略の最終責任者
Security Lead |  | 施策の設計・実行管理
Risk Owner |  | 各部門のリスク管理
Compliance Officer |  | 規制対応・監査窓口
Incident Response Team |  | 検知・封じ込め・回復

■ 2. 現状評価
ドメイン | 現在の成熟度 | 目標成熟度 | ギャップ
--------|------------|----------|--------
ID・アクセス管理 |  |  |
ネットワークセキュリティ |  |  |
データ保護 |  |  |
エンドポイントセキュリティ |  |  |
インシデント対応 |  |  |
クラウドセキュリティ |  |  |

リスク | 発生可能性 | 影響度 | レベル | オーナー
------|----------|--------|------|------
      |           |        |      |

■ 3. ロードマップ（フェーズ別施策）
Phase 1（1〜6ヶ月）：基盤整備とQuick Wins
施策 | 優先度 | オーナー | 概算コスト | ステータス
----|--------|---------|----------|----------

Phase 2（7〜12ヶ月）：基盤強化
施策 | 優先度 | オーナー | 概算コスト | ステータス
----|--------|---------|----------|----------

Phase 3（13〜24ヶ月）：最適化
施策 | 優先度 | オーナー | 概算コスト | ステータス
----|--------|---------|----------|----------

■ 4. メトリクスと報告体制
KPI | 現在値 | 目標（6ヶ月後） | 目標（12ヶ月後） | 測定方法
----|--------|--------------|--------------|--------
平均検知時間（MTTD）|  |  |  |
平均対応時間（MTTR）|  |  |  |
パッチ適用率|  |  |  |
MFA適用率|  |  |  |

報告 | 対象者 | 頻度
----|--------|----
セキュリティ運用ダッシュボード | セキュリティチーム | 日次
インシデントサマリー | CISO・セキュリティリード | 週次
リスク・KPIレポート | CISO・CTO | 月次
経営幹部向けセキュリティ報告 | 取締役会・CEO・CFO | 四半期

---

英語版テンプレート（コピペOK）

[Security Roadmap Plan]

Organization:
Date:
Author:
Planning Horizon:
Security Framework:

■ 1. Scope & Governance
Systems in Scope:
Data in Scope:
Security Framework:

Role | Assignee | Responsibility
-----|----------|---------------
CISO |  | Overall security strategy
Security Lead |  | Design and execute initiatives
Risk Owner |  | Manage risks by business unit
Compliance Officer |  | Regulatory compliance
Incident Response Team |  | Detect, contain, recover

■ 2. Current State Assessment
Domain | Current | Target | Gap
-------|---------|--------|----
Identity & Access Management |  |  |
Network Security |  |  |
Data Protection |  |  |
Endpoint Security |  |  |
Incident Response |  |  |
Cloud Security |  |  |

Risk | Likelihood | Impact | Level | Owner
-----|-----------|--------|-------|------
     |           |        |       |

■ 3. Roadmap (Phased Initiatives)
Phase 1 (Months 1–6): Foundation & Quick Wins
Initiative | Priority | Owner | Cost | Status
----------|---------|-------|------|-------

Phase 2 (Months 7–12): Consolidation
Initiative | Priority | Owner | Cost | Status
----------|---------|-------|------|-------

Phase 3 (Months 13–24): Optimization
Initiative | Priority | Owner | Cost | Status
----------|---------|-------|------|-------

■ 4. Metrics & Reporting
KPI | Baseline | Target (6M) | Target (12M) | Measurement
----|---------|------------|-------------|------------
MTTD |  |  |  |
MTTR |  |  |  |
Patch compliance |  |  |  |
MFA coverage |  |  |  |

Report | Audience | Frequency
-------|---------|----------
Security Ops Dashboard | Security Team | Daily
Incident Summary | CISO, Security Lead | Weekly
Risk & KPI Report | CISO, CTO | Monthly
Executive Briefing | Board, CEO, CFO | Quarterly

---

プロダクトロードマップにセキュリティ要件を組み込む際は、英語プロダクトエンジニアリング計画書の書き方と組み合わせることで、開発とセキュリティの優先度を一体で管理できる。

セキュリティロードマップの実行フェーズでは、英語クラウドセキュリティ設計書の書き方を参照することで、クラウド環境の具体的な設計方針と連動した施策を立案できる。

まとめ：英語セキュリティロードマップ計画書は4つのセクションで完成する

英語セキュリティロードマップ計画書は、以下の4セクションで構成する。

1. Scope & Governance：対象システムと役割を定義する
2. Current State Assessment：成熟度ギャップとトップリスクを可視化する
3. Roadmap & Initiatives：フェーズ別の施策と優先度を整理する
4. Metrics & Reporting：KPIと報告サイクルで進捗を管理する

この構成で英語計画書を作成することで、CISO・CTO・経営層への報告が一本化される。セキュリティ投資の根拠を数字で示せるようになり、予算承認のスピードが上がる。