TL;DR
- 「対策方針: 早期にパッチ適用を推奨」では現場は動かない。「5/22 14:00 までに山田が本番サーバ A の Apache を 2.4.62 にアップデート」と書いた瞬間に作業が走る
- 現場向け報告の 3 要素: タスク (動詞) / 担当者 (個人名) / 期限 (日時)
- 表形式でまとめれば作業着手率はほぼ 100%
対象読者
- セキュリティコンサルタント 1-3 年目
- 脆弱性対応依頼書・インシデント指示書を書く方
- 「結局誰が、いつまでに、何を?」と問い返された経験がある方
なぜ「対策方針」では動かないのか
セキュリティ担当が「対策方針」を書いた時点で、頭の中には次の情報が揃っている。
- どのサーバが対象か
- 誰が作業するか
- いつまでにやるべきか
- どうやって作業するか
しかし報告書には「対策方針」しか出ない。受け取った現場は次のロスを生む。
- 「どのサーバ?」→ 1 日ロス
- 「うちじゃなくて隣のチームでは?」→ 2 日ロス
- 「いつまで?」→ 1 週間ロス
- 「どう作業?」→ 半日ロス
報告書が「自分の頭の中の情報」を出し切っていないだけ。
Before/After 比較表
| # | 場面 | Before (方針のみ) | After (タスク化) |
|---|---|---|---|
| 1 | 週次脆弱性対応 | 「早期にパッチ適用を推奨」 | 「5/22 14:00 までに山田が web-prod-01 の Apache を 2.4.62 に yum update。完了報告は Slack #infra」 |
| 2 | インシデント初動 | 「不審な通信を検知。詳細調査を行う」 | 「田中: 端末 PC-042 をネット切断、14:30 完了報告。鈴木: 過去 7 日通信ログ抽出、17:00。高橋: 上長報告書、明日 10:00」 |
| 3 | 月次セキュリティ | 「アカウント棚卸を実施」 | 「6/5 佐藤が退職者リスト入手、6/10 山田が AD 無効化、6/15 鈴木が完了報告書作成」 |
After 共通: 誰が・いつまでに・何を が全部埋まっている。
現場向け報告の 3 要素
要素 1: タスク (動詞形・1 アクション)
NG 「対応する」「実施する」「確認する」
OK 「アップデートする」「切断する」「無効化する」
「対応」は範囲が広すぎて作業が始まらない。「アップデートする」なら yum update を打てば終わる。
要素 2: 担当者 (実名・1 人)
NG 「情シス部門で対応」「セキュリティチーム」
OK 「山田が対応」
部署名だと「誰の手に渡るか」が決まらない。実名なら朝礼で確認できる。
要素 3: 期限 (日付 + 時刻)
NG 「速やかに」「至急」「来週中に」
OK 「5/22 (金) 14:00 まで」
時刻まで書くことで、他業務との競合を見える化できる。
実例: Apache 脆弱性対応依頼
Before (対策方針)
件名: Apache HTTP Server の脆弱性対応依頼
JPCERT より深刻度高の脆弱性 (CVE-2026-XXXX、CVSS 9.1) が公開されました。
当社の本番環境に該当があり、悪用された場合 RCE の可能性があります。
つきましては早期にパッチ適用を推奨いたします。
現場: 「どのサーバ?」「うちのチーム?」「いつまで?」「手順は?」 → 3 日経過しても着手なし。
After (タスク + 担当者 + 期限)
件名: 【要対応・5/22 14:00 まで】Apache 脆弱性 対応依頼 (CVE-2026-XXXX)
【対応概要】 本番サーバ 3 台の Apache を 2.4.62 にアップデート
【タスク・担当者・期限】
| # | タスク | 担当 | 期限 | 完了報告先 |
|---|---------------------------------------------------|------|-----------|-------------|
| 1 | web-prod-01 の Apache を 2.4.62 に yum update | 山田 | 5/22 14:00| Slack #infra|
| 2 | web-prod-02 の Apache を 2.4.62 に yum update | 田中 | 5/22 16:00| Slack #infra|
| 3 | web-prod-03 の Apache を 2.4.62 に yum update | 鈴木 | 5/23 10:00| Slack #infra|
| 4 | 3 台の動作確認 (HTTP 200 応答) | 佐藤 | 5/23 11:00| 本依頼に返信|
【作業手順】 別紙 1 (社内 Wiki: /security/CVE-2026-XXXX-apache-update)
【ロールバック手順】 別紙 2
【作業窓口】 ゆうき (内線 1234)
現場: 「了解、5/22 14:00 までやります」 → 13:30 に完了報告。
タスク化 4 チェックリスト
| # | チェック項目 | NG → OK |
|---|---|---|
| 1 | 動詞で書かれているか | 「対応」 → 「アップデート」 |
| 2 | 担当者が個人名 1 人か | 「情シス」 → 「山田」 |
| 3 | 期限が日付 + 時刻か | 「速やかに」 → 「5/22 14:00」 |
| 4 | 完了報告先が明示か | (なし) → 「Slack #infra」 |
4 つ揃った報告書は現場で作業着手率がほぼ 100%。
「分からないから止まる」を防ぐ事前確認依頼
報告書を初めて受ける現場では Apache バージョンや該当サーバが分からないことが多い。本依頼の前に事前確認依頼を出す。
件名: 【事前確認・5/20 まで】本番サーバの Apache バージョンご確認依頼
下記 3 台の Apache バージョンを 5/20 12:00 までに本依頼に返信でご回答ください。
- web-prod-01 / web-prod-02 / web-prod-03
確認コマンド: httpd -v
担当: 各サーバ管理者 (山田 / 田中 / 鈴木)
事前確認で情報を得たら本番の対応依頼書を発出。
担当者が今日からできる 3 アクション
- 次の脆弱性対応依頼を「タスク + 担当者 + 期限」表で書く
- 「速やかに」を全て日時に置換する (過去 1 ヶ月分を grep)
- 完了報告先を必ず明示する (Slack / メール / 対面のいずれか)
まとめ
現場向け報告の肝は「タスク化」。動詞で書く、個人名で書く、日時で書く、完了報告先を書く。この 4 つで作業着手率はほぼ 100%。
シリーズ最終回 (#5) は監査対応報告: 監査人を納得させる Before/After。
関連記事
- Before/After #2 — 経営者向け報告: 売上/コスト/評判への翻訳
- Before/After #3 — 役員会報告: 3 軸 5 分テンプレ
- シリーズ #1 — 「で?」と言われなくなる 3 つの視点
📌 無料テンプレ提供: 「タスク + 担当者 + 期限」表テンプレ、事前確認依頼の雛形、完了報告先一覧フォーマットを PDF 配布。note メンバーシップ で 初月無料。
📣 法人向け: 脆弱性対応依頼書・インシデント指示書のタスク化改善ワークショップ → intect-i.jp
タグ: #Security #セキュリティ #報告書 #BeforeAfter #現場担当 #脆弱性対応 #タスク化