監査に強い“証跡”の残し方
（ログ/決裁/版管理）
OEM監査や脆弱性照会で本当に見られているのは、「ちゃんとやっています」という説明ではなく、それを裏づける証跡（エビデンス）です。
PSIRT運用では、判断が正しかったか以前に、次の点が問われます。
- いつ受け付けたのか
- 誰が何を確認したのか
- どの版数を対象に判断したのか
- 誰が承認して外部に出したのか
- 後から同じ結論を再現できるのか
現場でありがちな失敗は、「口頭で決めたことが残っていない」「証跡ファイルはあるが探せない」「回答書と根拠資料がつながっていない」という状態です。これでは監査で差し戻されます。
先に結論：証跡は「ログ・決裁・版管理」の3層で残す
監査に強い証跡は、単にファイルを保存することではありません。
最低限、次の3層で残すと再現性が上がります。
1. ログ
いつ、誰が、何を受け取り、何を確認したか。
例：案件受付日、一次回答日、次回更新日、調査メモ、提出履歴
2. 決裁
どの結論を、誰が承認したか。
例：影響あり/なし/調査中の判断、外部送付の承認、例外運用の承認
3. 版管理
どの製品版数・どのSBOM・どの回答書版を根拠にしたか。
例：製品版数、SBOMスナップショットID、回答書v1/v2、提出版ID
この3つが揃って初めて、「運用していたこと」が説明できます。
なぜ監査で証跡が弱くなるのか
原因はだいたい次の4つです。
証跡が弱いのは、セキュリティ知識の不足ではなく、残し方のルール不足です。
手順：監査に強い証跡を作る（6ステップ）
証明したい主張を先に書く
いきなりファイルを集めないことです。まず「何を証明したいか」を一文で書きます。
例：一次回答はSLA内に実施した
例：修正版 v2.3.2 を承認のうえ配布した
証跡は、この主張に紐づけて集めます。
案件IDを軸にする
証跡は必ず案件IDで束ねます。おすすめの最小構成はこれです。
- 案件ID
- 対象製品名
- 対象版数
- 状態（受付／調査中／回答済み／クローズ）
- 証跡リンク/ID
これがあるだけで、監査時に「この案件の根拠はどこか」をたどれます。
ログを残す
最低限、次を残してください。
- 受領日時
- 依頼元
- 一次回答日時
- 次回更新日
- 提出日時
- 差し戻し日時と内容
ログは長文不要です。「時刻・担当者・行為」 が残っていれば十分です。
決裁を残す
外部へ出す結論は、必ず承認痕跡を残します。
- 影響あり/なし/調査中の承認
- 回答書の承認
- 例外的な期限延長の承認
- 修正版配布の承認
メール、ワークフロー、チケットコメントなど形式は問いません。大切なのは 「誰が承認したか」 が追えることです。
版管理を残す
監査では「どの版を見たか」が非常に重要です。最低限、次を明記します。
- 対象製品版数
- 参照したSBOM/構成表の版
- 回答書の版（v1, v2…）
- 提出版の版と提出日
“最新版を見ました”では弱いです。「版数で言えること」が証跡の強さです。
回答書と証跡をつなぐ
最後に、回答書の中に証跡IDや参照先を入れます。
例：CFG-045
例：TEST-009
例：RESP-v2
これで、結論と根拠が一本の線になります。
そのまま使える：証跡台帳の最小テンプレ（TSV）
以下の列があれば、監査でかなり強くなります。
下の枠内をコピーして、ExcelのA1セルに貼り付けてください。
OEM調査依頼・監査対応の進め方や、証跡管理の仕組みを自社向けに整理したい方はご相談ください。
【無料】オンライン相談を予約するよくあるNG例（監査で刺されるポイント）
- NG1：スクリーンショットだけ残す
版数や対象範囲が分からず、後から証拠として弱くなります。 - NG2：承認が口頭だけ
誰が判断したか追えず、監査で止まります。 - NG3：回答書と証跡が別管理
結論と根拠がつながらず、再現できません。 - NG4：クローズ条件が無い
終わったのか、放置なのか分からなくなります。
FAQ：証跡の残し方について
単独の文書より、ログ・決裁・版管理が案件IDでつながっていること が一番強いです。監査は“運用の再現性”を見ています。
必ずしも不要です。重要なのは、回答書から証跡IDや保存場所をたどれることです。
OEM照会も監査も「どの版数に対する判断か」を見ます。版が言えないと、結論の強さが落ちます。
エビデンス集めを、システムで自動化しませんか？
Auto PSIRT Cloudなら、案件のチケット化、影響判定の履歴、SBOMの参照先、OEM回答書の出力履歴がすべて1つのシステム上で紐づいて保存されます。監査の際に探し回る必要はありません。