監査で求められるエビデンス一覧
（提出物の作り方と差し戻されない型）
OEM監査で一番困るのは、「何を出せば合格に近づくかが分からない」ことです。
現場で起きがちな失敗はだいたい次の通りです。
- とりあえず資料を大量に集めるが、何の証明になっているか分からない
- 文書はあるが、対象版数や改訂日が曖昧で差し戻される
- 口頭運用は回っているのに、証跡として残っていない
- 担当者しか場所を知らず、提出直前に探し物が始まる
- 監査で求められた提出物の“粒度”と、こちらの資料の粒度が合わない
結論から言うと、監査エビデンスは 「量」ではなく「紐づけ」 です。
相手が見たいのは、大量のPDFではなく、
「どの要求に対して」「どの文書で」「どの版数・時点を」「どう証明するか」が一目で分かることです。
先に結論：監査エビデンスは「5分類」で整理すると崩れない
まず、エビデンスを種類で分けます。
最初から文書名で考えると迷うので、「何を証明するか」で分類します。
1. 体制を示すエビデンス
- 役割分担表
- 窓口情報
- 承認ルール
- エスカレーションフロー
2. 運用を示すエビデンス
- チケット/案件台帳
- 一次回答履歴
- 次回更新日を含む進捗管理
- 定例会議の議事メモ
3. 技術的根拠を示すエビデンス
- SBOM/部品表
- 構成表
- 設定値
- 仕様書 ／ 試験結果
4. 対外対応を示すエビデンス
- OEM回答書
- 提出履歴
- 差し戻し対応履歴
- 是正計画（必要時）
5. 更新・配布を示すエビデンス
- リリースノート ／ 更新履歴
- 配布手順 ／ 完了確認ログ
この5分類で揃えると、監査で「何の証明か」が説明しやすくなります。
監査でよく求められる提出物一覧（最小セット）
すべての監査で同じではありませんが、サプライヤー実務で頻出なのは次のようなものです。
体制・運用系
- PSIRT窓口/連絡先
- 役割分担表（受付、技術評価、対外回答、承認）
- SLAや期限運用のルール
- 調査依頼の社内エスカレーション手順
- 監査/照会の案件管理台帳
技術系
- 対象製品の版数一覧
- SBOMまたは簡易部品表
- 構成図/IF一覧
- 設定値や機能有効・無効の根拠
- 試験結果、確認メモ、検証ログ
対外対応系
- OEM/顧客向け回答書
- 影響あり/なしの判断根拠
- 調査中の中間回答（次回更新日付き）
- 是正計画や恒久対策の提出物
更新/配布系
- 修正版リリース計画
- 配布方式（工場/現地/OTA）
- 更新完了の確認方法
- 更新履歴
この一覧を見て分かる通り、監査は「セキュリティツールのスクリーンショット」を見たいわけではありません。
運用が本当に回っていることを証明する材料が必要です。
手順：提出物を作る時の進め方（5ステップ）
ここからは“やり方”です。兼務でも破綻しないよう、最小の順番で整理します。
監査要求を“証明すべき主張”に分解する
まず、監査項目をそのまま受け取らず、次のように翻訳します。
つまり、監査要求 → 証明したい主張 → 必要文書 に変換します。
エビデンス一覧表を先に作る
いきなりファイルを集めないこと。先に “一覧表” を作ると、足りないものが見えます。
- ・監査項目
- ・証明したい主張
- ・文書名
- ・文書ID/保存場所
- ・版数/改訂日
- ・所有者（誰の管理か）
- ・提出可否（社内のみ/提出可）
- ・備考（どこを見せるか）
提出版と社内版を分ける
ここが非常に重要です。監査で使う証跡は、すべてをそのまま出す必要はありません。
- 社内版（正本）： 詳細情報、設定値、内部コメントまで含む
- 提出版： 必要範囲だけ抜粋した版
- 参照版： 存在は示すが、現物は監査当日に提示する版
この切り分けがないと、出しすぎるか、逆に何も出せなくなります。
提出物に「版数」と「時点」を付ける
監査で差し戻される最大要因の1つが、どの時点の文書なのか分からないことです。最低限、各提出物には次を入れます。
- ・版数（v1.0 等）
- ・改訂日
- ・対象製品/対象版数
- ・作成者/承認者
“最新版です”という説明だけでは弱いです。いつ、誰が、どの製品版に対して作ったか が必要です。
提出前に“ストーリー”として読めるか確認する
最後に重要なのが、提出物同士がつながっているかです。
この一本の線があると、監査側から見て “運用が本当に回っている” と伝わります。
そのまま使える：エビデンス一覧テンプレ（TSV）
以下は、そのままExcelやスプレッドシートへ貼れる形の雛形です。（タブ区切りになっています）
OEM調査依頼・監査対応の進め方を、自社の現状に合わせて整理したい方はご相談ください。
【無料】オンライン相談を予約するよくあるNG例（監査で刺されるポイント）
- ファイルを集めるだけで一覧表が無い
→ 監査項目との対応が説明できない - 文書に版数/改訂日が無い
→ “いつの情報か”が不明で差し戻される - 社内版と提出版が混ざる
→ 情報を出しすぎる／逆に説明できなくなる - 案件IDでつながっていない
→ 運用している証拠が一本の線にならない - OTAや更新関連の証跡が抜ける
→ 修正版をどう届けるか説明できない
FAQ：監査エビデンスの作り方
単体で最重要な1枚というより、台帳・回答書・根拠資料・更新記録が「案件ID等でつながっていること」が重要です。監査は“運用の再現性”を見ています。
いいえ。提出版と社内版を分け、必要な範囲だけ提出するのが現実的です。重要なのは、必要時に参照できる状態になっていることです。
必須です。監査で「どの時点の文書か」が曖昧だと、運用している証拠として弱くなります。
影響ありの案件では、最終的に「どう修正版を届けるか」が問われるためです。更新経路を説明できると、監査でもOEM照会でも強くなります。
「エビデンス集め」をシステムで自動化しませんか？
Auto PSIRT Cloudなら、案件のチケット化、影響判定の履歴、SBOMの参照先、OEM回答書の出力履歴がすべて1つのシステム上で紐づいて保存されます。監査の際に探し回る必要はありません。