グローバルITプロジェクトでセキュリティをどう管理するか、英語で文書化できているだろうか。
「セキュリティはインフラチームに任せている」という状況では、プロジェクト全体のセキュリティリスクが見えなくなる。英語圏のプロジェクトでは、セキュリティ計画書(Security Management Plan)がプロジェクト開始前に必須のドキュメントとして機能する。
この記事では、セキュリティ計画書に必要な4つのセクションを日英テンプレート付きで解説する。Word形式のテンプレートをダウンロードしてそのまま使えるので、初めて英語でセキュリティ計画書を作る人にも役立つ。
セキュリティ計画書に必要な4つの構成要素
英語のセキュリティ計画書は、次の4セクションで構成する。
- セキュリティ方針(Security Policy & Objectives):プロジェクトのセキュリティ目標と適用範囲を定義する
- リスクアセスメント(Risk Assessment):セキュリティリスクを識別・評価する
- セキュリティ統制(Security Controls):技術的・運用的・物理的な対策を定める
- モニタリングとインシデント対応(Monitoring & Incident Response):継続的な監視とインシデント対応手順を定める
各セクションを順番に埋めていけば、英語のセキュリティ計画書が完成する。
テンプレートをダウンロード(Word)
日本語版・英語版のWordテンプレートをそれぞれ用意した。ダウンロードしてプロジェクト情報を入力するだけで使える。
日本語版テンプレート(コピペOK)
基本情報
| 項目 | 内容 |
|---|---|
| プロジェクト名 | |
| 作成者 | |
| 作成日 | |
| バージョン | v1.0 |
| 機密分類 | 社外秘 / 機密 |
セクション1:セキュリティ方針と目標
目的(Purpose)
本セキュリティ計画書は、プロジェクト期間中の情報資産を保護し、機密性・完全性・可用性(CIA)を確保するための方針と対策を定めるものである。
適用範囲(Scope)
| 対象 | 含む / 含まない |
|---|---|
| プロジェクトシステム | 含む |
| 開発・テスト環境 | 含む |
| 本番環境 | 含む |
| 外部ベンダーシステム | 含む(契約に明記) |
| 社内既存システム | 含まない |
セキュリティ目標
| 目標 | KPI | 目標値 |
|---|---|---|
| セキュリティインシデントの最小化 | 重大インシデント件数 | 0件/年 |
| 脆弱性の早期対応 | 高リスク脆弱性の対応期間 | 7日以内 |
| アクセス管理の徹底 | 不正アクセス検知率 | 99%以上 |
| コンプライアンス準拠 | 監査指摘事項 | 0件 |
準拠する規格・法令
- ISO/IEC 27001
- GDPR(個人データを扱う場合)
- 個人情報保護法
- その他(プロジェクト固有の規制):
セクション2:リスクアセスメント
情報資産一覧
| # | 資産名 | 機密分類 | 資産オーナー | 保管場所 |
|---|---|---|---|---|
| 1 | 顧客個人情報 | 機密 | ||
| 2 | システム設計書 | 社外秘 | ||
| 3 | ソースコード | 社外秘 | ||
| 4 | 認証情報・APIキー | 機密 | ||
| 5 | プロジェクト契約書 | 機密 |
セキュリティリスク評価
| # | リスク | 脅威 | 脆弱性 | 発生可能性 | 影響度 | リスクレベル | 対応方針 |
|---|---|---|---|---|---|---|---|
| 1 | 不正アクセス | 外部攻撃者 | 弱いパスワード | 高 | 高 | 重大 | 軽減 |
| 2 | データ漏洩 | 内部不正 | アクセス権限過剰 | 中 | 高 | 高 | 軽減 |
| 3 | マルウェア感染 | フィッシング | セキュリティ教育不足 | 中 | 高 | 高 | 軽減 |
| 4 | サービス停止 | DDoS攻撃 | 冗長構成なし | 低 | 高 | 中 | 軽減 |
| 5 | 設定ミス | 人的ミス | レビュープロセス不足 | 中 | 中 | 中 | 軽減 |
セクション3:セキュリティ統制
技術的統制
| 統制項目 | 対策内容 | 担当 | 実施時期 |
|---|---|---|---|
| アクセス管理 | MFA必須、最小権限の原則適用 | インフラ | プロジェクト開始前 |
| 暗号化 | 通信はTLS1.2以上、保存データはAES-256 | インフラ | 設計フェーズ |
| 脆弱性管理 | SAST/DAST、依存パッケージの定期スキャン | DevSecOps | 開発フェーズ〜 |
| ログ・監査 | 全アクセスログを180日間保持・SIEM連携 | インフラ | 構築フェーズ |
| セキュリティテスト | ペネトレーションテスト(リリース前) | 外部ベンダー | テストフェーズ |
運用的統制
| 統制項目 | 対策内容 | 担当 | 頻度 |
|---|---|---|---|
| セキュリティ教育 | 年1回の必須受講 | PM | 年1回 |
| アクセス権限レビュー | 四半期ごとに権限棚卸し | セキュリティ担当 | 四半期 |
| パッチ管理 | 重大パッチは7日以内に適用 | インフラ | 随時 |
| サードパーティ評価 | ベンダーセキュリティ評価の実施 | 調達 | 契約時 |
物理的統制
| 統制項目 | 対策内容 |
|---|---|
| データセンターアクセス | 入退室管理システム・監視カメラ |
| 端末管理 | MDM導入・フルディスク暗号化 |
| 廃棄 | 記録媒体の安全な廃棄(証明書取得) |
セクション4:モニタリングとインシデント対応
モニタリング計画
| 監視項目 | ツール | 担当 | 頻度 |
|---|---|---|---|
| ネットワーク異常 | インフラ | リアルタイム | |
| ログ異常 | SIEM | セキュリティ | リアルタイム |
| 脆弱性スキャン | DevSecOps | 週次 | |
| 設定変更監視 | インフラ | リアルタイム |
インシデント対応手順
| フェーズ | アクション | 担当 | 目標時間 |
|---|---|---|---|
| 検知 | アラート確認・初期トリアージ | SOC / インフラ | 15分以内 |
| 封じ込め | 影響システムの隔離 | インフラ | 1時間以内 |
| 根絶 | 原因除去・パッチ適用 | 開発・インフラ | 24時間以内 |
| 復旧 | サービス再開・動作確認 | 開発・インフラ | 48時間以内 |
| 事後対応 | インシデントレポート作成・再発防止策実施 | PM・セキュリティ | 5営業日以内 |
英語版テンプレート(コピペOK)
Basic Information
| Item | Details |
|---|---|
| Project Name | |
| Prepared By | |
| Date | |
| Version | v1.0 |
| Classification | Confidential / Internal Use Only |
Section 1: Security Policy & Objectives
Purpose
This Security Management Plan defines the security policies, controls, and procedures to protect information assets throughout the project lifecycle and ensure Confidentiality, Integrity, and Availability (CIA).
Scope
| Target | Included / Excluded |
|---|---|
| Project systems | Included |
| Development & test environments | Included |
| Production environment | Included |
| Third-party vendor systems | Included (specified in contracts) |
| Existing internal systems | Excluded |
Security Objectives
| Objective | KPI | Target |
|---|---|---|
| Minimize security incidents | Critical incidents | 0 per year |
| Rapid vulnerability remediation | Time to resolve high-risk vulnerabilities | Within 7 days |
| Enforce access controls | Unauthorized access detection rate | ≥ 99% |
| Compliance adherence | Audit findings | 0 |
Applicable Standards & Regulations
- ISO/IEC 27001
- GDPR (where personal data is processed)
- Applicable data protection laws
- Other (project-specific regulations):
Section 2: Risk Assessment
Information Asset Register
| # | Asset | Classification | Asset Owner | Storage Location |
|---|---|---|---|---|
| 1 | Customer personal data | Confidential | ||
| 2 | System design documents | Internal | ||
| 3 | Source code | Internal | ||
| 4 | Credentials & API keys | Confidential | ||
| 5 | Project contracts | Confidential |
Security Risk Assessment
| # | Risk | Threat | Vulnerability | Likelihood | Impact | Risk Level | Treatment |
|---|---|---|---|---|---|---|---|
| 1 | Unauthorized access | External attacker | Weak passwords | High | High | Critical | Mitigate |
| 2 | Data breach | Insider threat | Excessive access | Medium | High | High | Mitigate |
| 3 | Malware infection | Phishing | Insufficient training | Medium | High | High | Mitigate |
| 4 | Service disruption | DDoS attack | No redundancy | Low | High | Medium | Mitigate |
| 5 | Misconfiguration | Human error | No review process | Medium | Medium | Medium | Mitigate |
Section 3: Security Controls
Technical Controls
| Control | Measure | Owner | Timing |
|---|---|---|---|
| Access management | Enforce MFA; apply least privilege | Infrastructure | Pre-project |
| Encryption | TLS 1.2+ in transit; AES-256 at rest | Infrastructure | Design phase |
| Vulnerability management | SAST/DAST; dependency scanning | DevSecOps | Dev phase onward |
| Logging & audit | Retain all access logs 180 days; SIEM integration | Infrastructure | Build phase |
| Security testing | Penetration testing before release | External vendor | Test phase |
Operational Controls
| Control | Measure | Owner | Frequency |
|---|---|---|---|
| Security training | Mandatory annual training | PM | Annually |
| Access review | Quarterly access rights review | Security lead | Quarterly |
| Patch management | Apply critical patches within 7 days | Infrastructure | As needed |
| Third-party assessment | Vendor security assessment | Procurement | At contract |
Physical Controls
| Control | Measure |
|---|---|
| Data center access | Access control system & CCTV |
| Device management | MDM deployment; full-disk encryption |
| Disposal | Secure media disposal with certificate |
Section 4: Monitoring & Incident Response
Monitoring Plan
| Monitor Item | Tool | Owner | Frequency |
|---|---|---|---|
| Network anomalies | Infrastructure | Real-time | |
| Log anomalies | SIEM | Security | Real-time |
| Vulnerability scans | DevSecOps | Weekly | |
| Configuration change monitoring | Infrastructure | Real-time |
Incident Response Procedure
| Phase | Action | Owner | Target Time |
|---|---|---|---|
| Detection | Alert review & initial triage | SOC / Infra | Within 15 min |
| Containment | Isolate affected systems | Infrastructure | Within 1 hour |
| Eradication | Remove root cause; apply patches | Dev & Infra | Within 24 hours |
| Recovery | Restore service; verify operations | Dev & Infra | Within 48 hours |
| Post-incident | Write incident report; implement preventive measures | PM & Security | Within 5 business days |
各セクションの書き方と例文
セクション1:セキュリティ方針の書き方
セキュリティ方針では「何を守るか」「なぜ守るか」を明示する。英語ではCIAトライアドを軸に記述するのが標準的。
方針を説明する英文例:
- This plan establishes the minimum security requirements that all project members and vendors must comply with.
(本計画書は、すべてのプロジェクトメンバーおよびベンダーが準拠すべき最低限のセキュリティ要件を定める)
- Security requirements will be incorporated into all phases of the project lifecycle, from design through decommissioning.
(セキュリティ要件は、設計から廃棄まで、プロジェクトライフサイクルの全フェーズに組み込まれる)
セクション2:リスクアセスメントの書き方
リスクレベルの算出方法を明示すると、評価の根拠が明確になる。
リスク評価の英文例:
- Risk level is calculated as the product of Likelihood and Impact, rated on a 1–5 scale.
(リスクレベルは、発生可能性と影響度の積として算出し、1〜5のスケールで評価する)
- Risks rated as Critical or High require immediate mitigation actions.
(重大または高リスクに評価されたリスクは、即座の軽減アクションが必要となる)
セクション3:セキュリティ統制の書き方
統制ごとに「誰が・いつ・何をするか」を明記すると、実施漏れを防げる。
統制を説明する英文例:
- All privileged access must be granted on a need-to-know and least-privilege basis and reviewed quarterly.
(すべての特権アクセスはneed-to-knowおよび最小権限の原則に基づいて付与し、四半期ごとにレビューする)
- All data transmitted between systems must be encrypted using TLS 1.2 or higher.
(システム間で送信されるすべてのデータは、TLS 1.2以上を使用して暗号化しなければならない)
セクション4:インシデント対応の書き方
インシデントの重大度区分を明示しておくと、対応優先度の判断がスムーズになる。
インシデント対応の英文例:
- A P1 (Critical) incident must be escalated to the Security Lead within 15 minutes of detection.
(P1(重大)インシデントは、検知から15分以内にセキュリティリードにエスカレーションしなければならない)
- All security incidents must be documented in the incident log, regardless of severity.
(すべてのセキュリティインシデントは、重大度にかかわらずインシデントログに記録しなければならない)
セキュリティ計画書でよく使う英語表現
英語のセキュリティ計画書で頻出する表現をまとめた。
| シーン | 英語表現 | 日本語訳 |
|---|---|---|
| 方針 | enforce security controls | セキュリティ統制を実施する |
| アクセス管理 | grant/revoke access | アクセスを付与/削除する |
| リスク対応 | mitigate / transfer / accept / avoid | 軽減/転嫁/受容/回避する |
| 脆弱性 | remediate a vulnerability | 脆弱性を修正する |
| 監査 | conduct a security audit | セキュリティ監査を実施する |
| インシデント | contain the incident | インシデントを封じ込める |
| 報告 | submit an incident report | インシデントレポートを提出する |
| 準拠 | comply with regulations | 規制に準拠する |
まとめ:英語セキュリティ計画書は4つのセクションで完成する
英語セキュリティ計画書の4セクションをおさらいする。
- セキュリティ方針(Security Policy & Objectives):目標・適用範囲・準拠規格を定義する
- リスクアセスメント(Risk Assessment):資産を識別しリスクを評価する
- セキュリティ統制(Security Controls):技術的・運用的・物理的対策を定める
- モニタリングとインシデント対応(Monitoring & Incident Response):継続監視と初動手順を定める
セキュリティ計画書で定めた方針は、セキュリティポリシーと整合している必要がある。英語セキュリティポリシーの書き方と合わせて整備することで、組織全体のセキュリティ方針とプロジェクト固有の統制がつながる。
また、インシデント発生時に備えたセキュリティインシデント対応書も不可欠だ。英語セキュリティインシデント対応の書き方と組み合わせることで、計画から対応までの一貫したセキュリティ管理体制が整う。


コメント