レポートの基本項目
対象サイト、対象期間、担当者、現在の主要バージョン、更新履歴、監視結果、バックアップ、脆弱性の該当確認を記載します。セキュリティ確認は、確認した製品と情報源を示し、未検査の独自コードまで安全と表現しないようにします。
更新記録の例
| 項目 | 記載内容 |
|---|---|
| 対象 | 製品名、変更前後の版 |
| 作業 | 実施日時、作業者、バックアップ |
| 検証 | フォーム到達、代表画面、管理画面保存 |
| 結果 | 正常、暫定復旧、保留 |
| 次の対応 | 担当、理由、期限 |
件数よりも影響を伝える
攻撃検知が多い月でも、不正侵入の成否とは別です。「検知・遮断・調査・侵害確認」を区別します。監視の停止時間も、計画停止と障害を分け、計測方法を記載すると比較しやすくなります。
翌月へ残す課題を明確にする
ライセンス更新、非対応PHP、不要アカウント、未実施の復元試験などは、承認が必要な内容と対応案を付けます。報告するだけでなく、誰がいつ判断するかを決めることで保守の改善につながります。
発注側が報告で判断すること
未対応の更新がある場合は、理由が互換性、ライセンス、作業承認、調査不足のどれかを確認します。「今月は更新なし」でも、更新情報を調べた結果なのか、作業しなかっただけなのかでは意味が異なります。対象と確認日を記載してもらいます。障害報告では、発生・検知・一次応答・復旧の各時刻、業務影響、実施した暫定策、恒久対応を分けます。数値を並べるだけでなく、次月までに何を判断すべきかが分かるレポートにします。
よくある質問
全てのログを添付する必要がありますか？
通常は必要な要約と証跡の保管場所を示します。詳細ログには個人情報が含まれる場合があるため、共有範囲とマスキングを確認します。調査用原本は別に保存します。
毎月同じ内容でもよいですか？
安定していれば似た結果になることはあります。ただし確認日時、実際の版、未解決事項の進捗、バックアップと監視の結果は更新し、前月資料の複製だけで済ませないようにします。