規制のある業界で業務システムを担当していると、取引先（委託元など）によるシステム監査を受けることがある。自分は技術面の担当として対応した。
この記事では、その経験をもとに「この種の監査で一般に聞かれる項目」「事前に揃えておく証拠」「機密で現物を見せられないものの示し方」を整理する。先に結論を書くと、問われるのは技術の優劣ではなく、運用が記録として残っていて、後から示せるかどうかだった。
前提：何を確認する場なのか
監査は、口頭の説明ではなく証拠で確認する行為だ。「権限は適切に管理している」と答えれば、その記録を求められる。「変更管理をしている」と答えれば、手順書と証跡を求められる。
自分が受けた質問も、技術的に難しいものはほとんどなかった。大半は次の2点の確認だった。
- それが文書として定められているか
- 文書どおりに運用され、その記録が残っているか
規制のある業界でシステムが満たすべき状態を制度として定義したものがCSV（コンピュータ化システムバリデーション）で、監査での質問もおおむねこの考え方の上にある。CSVそのものの説明は別記事に譲る。
聞かれる項目と、揃えておく証拠
自分が対応した範囲で聞かれた項目と、それに対して用意しておくとよい証拠を表にまとめる。業界や監査の目的によって項目は変わるはずなので、網羅的な一覧ではなく出発点として見てほしい。
| 項目 | 聞かれること | 揃えておく証拠 |
|---|---|---|
| 開発フロー | どういう手順で開発し、リリースしているか | 手順書（SOP）、実際のマージリクエストとレビュー記録 |
| 変更管理 | 変更時の承認フロー。誰が承認したか | 変更管理台帳とマージリクエストの対応、承認記録、テスト結果 |
| アカウント・権限管理 | 誰がシステムに入れるか。権限の付与と管理の方法 | 権限の一覧（誰が・どの権限を・いつ付与されたか） |
| 外部委託先のアカウント | 開発ベンダーの誰が、どこまでアクセスできるか | 委託先アカウントの一覧とアクセス範囲 |
| 退職・契約終了時の扱い | アクセスを無効化するフローがあるか | 無効化の手順と、実施した記録 |
| 通信の暗号化 | どの通信を、どの方式で暗号化しているか | 構成図上で暗号化区間を説明できる資料 |
| 構成の把握 | システム全体が何とどう繋がっているか | 最新の構成図 |
| 環境の分離 | 本番環境と開発環境が分かれているか | 環境ごとの構成と、アクセスできる人の違い |
| 監査証跡・ログ | 「いつ・誰が・何をしたか」が記録されているか | 証跡の取得対象、保存場所、保持期間 |
| バックアップ | 取得頻度。復元テストを実施しているか | 取得設定、復元テストの実施記録、保存期間 |
| 障害対応 | 障害発生時のエスカレーションフロー | 連絡経路と判断者を定めた手順 |
並べてみると、「技術がどう優れているか」を聞く項目はない。どれも「決めてあるか」「そのとおりやっているか」「記録があるか」のいずれかになっている。
事前準備でやったこと
準備には3週間ほどかけた。やったことは大きく3つある。
1. 監査証跡の確認
「誰が・いつ・何を変えたか」が記録されているかを、テーブル単位で確認した。見るべき点は、記録の有無だけでなく、変更前と変更後の値まで追えるかどうかだ。あわせて、証跡がどこに保存され、どれだけの期間保持されるかを即答できるようにしておく。
2. 変更管理の対応づけ
GitLabのマージリクエストと変更管理台帳を対応づけ、「いつ・誰が・何を変更したか・承認者は誰か」を1本の線で追える状態にした。台帳だけ、あるいはマージリクエストだけでは、変更の承認と実際のコード変更が結びつかない。
リリースフローの各手順がこの追跡のために存在していることは、準備を通じて理解できた。その経緯は引き継いだリリースフローが、監査で初めて意味を持ったに書いている。
3. SOPと実態の突き合わせ
標準作業手順書（SOP）が、実際の運用と食い違っていないかを確認した。古い手順書が残っていると「文書と実態が違う」状態になる。これはコードの問題ではなく運用管理の問題として、重く見られる。
機密で現物を見せられないものの示し方
監査では証拠を求められるが、こちらにも開示できないものがある。システムの内部、具体的な構成の詳細、機密データそのものは、求められてもそのままは出せない。
ここで必要になるのは、「見せられない」で終わらせず、仕組みで担保していることを見せられる形で示すことだ。自分が経験した範囲では、次の形になった。
- 仕組みを説明する：その点をどういう仕組みで担保しているかを、事実として説明する
- 開示範囲を線引きする：どこまでは見せられ、どこからは機密で見せられないかを明確に伝える
そのうえで、一般には次のような形が現物の代わりとして使われることが多いと思う。これは自分の経験の記録ではなく、一般論としての補足である。
- 中身ではなく、手順書と記録の様式を示す（どういう記録を取る決まりになっているか）
- データをマスキングした画面や帳票で、記録が存在することを示す
- 詳細を省いた構成図で、境界と暗号化区間だけを示す
もう一つ重要だったのは役割分担だ。技術担当が答えるのは事実で、どこまで開示するかの判断は別の役割になる。技術担当がその場で開示範囲まで判断すると、出しすぎるか、出さなすぎるかのどちらかに寄りやすい。開示範囲は事前に社内の監査窓口と決めておき、技術担当は事実の説明に集中するのがよい。
事前チェックリスト
次に備えるときの自分用のメモも兼ねて、チェックリストにしておく。
- 構成図が最新で、「今どうなっているか」を1枚で示せる
- 権限の一覧があり、誰が・どの権限を・いつ付与されたかが分かる
- 外部委託先のアカウントとアクセス範囲を説明できる
- 退職・契約終了時のアクセス無効化の手順があり、現在のアカウントと突き合わせてある
- 監査証跡が取得・保存されており、保持期間を即答できる
- 変更手順・承認記録・テスト結果が、変更ごとに紐づいている
- どの通信をどの方式で暗号化しているかを、口頭で説明できる
- バックアップの取得頻度と、復元テストの実施記録がある
- 本番環境と開発環境の分離を説明できる
- 障害時のエスカレーションフローが文書化されている
- SOPが実際の運用と一致している
- 開示できる範囲とできない範囲を、社内の監査窓口と事前に合意している
大事なのは、これらを当日すぐに出せる状態にしておくことだ。その場で探し始めると間に合わない。
うまくいかなかった点・難しかった点
準備をして分かったのは、監査の直前に揃えようとすること自体に無理がある、という点だ。証跡は過去に遡って作れない。記録されていなかった期間の記録は、後から用意できない。
つまり準備の本体は、監査の連絡が来る前の日常の運用にある。普段やっていないことを監査のために取り繕う必要がある状態は、日常の運用と文書の間に乖離があるということだ。逆に、普段から文書どおりに運用して記録を残していれば、当日は自分たちがやっていることをそのまま説明すればよい。自分の担当範囲を事実として答え、範囲外のことは範囲外だと答える。
また、エンジニアとしての感覚とのずれもあった。普段の開発では「動くか」「速いか」「読みやすいか」を気にするが、監査ではそこはほとんど問われない。よくできた設計でも、記録がなければ確認のしようがない。地味な運用でも、証跡が残っていれば確認できる。
まとめ
- この種の監査で問われるのは、技術の優劣ではなく「決めてあるか」「そのとおり運用しているか」「記録が残っているか」
- 聞かれる項目は、開発フロー、変更管理、アカウント・権限、通信の暗号化、構成、監査証跡、バックアップ、障害対応などに集まる
- 機密で現物を出せないものは、仕組みの説明と開示範囲の線引きで示す。開示範囲は事前に社内で決めておく
- 証跡は遡って作れない。準備の本体は日常の運用にある
記録が残っていて後から追えることは、監査のためだけのものではない。障害対応でも、引き継ぎでも、同じ記録が役に立つ。
関連記事: