ISMS文書体系｜何をどこまで作るか

ISMSの構築で最初に聞かれる質問のひとつが「規程は何本必要ですか」です。答えは「決まっていません」なのですが、これは不親切に聞こえます。実際には規格が明示的に要求している文書は限られており、残りは組織が必要と判断して決めるという構造になっています。この区別を押さえないまま着手すると、二通りの失敗が起こります。

ひとつは作りすぎです。他社の体系を参考に規程を20本、手順書を50本そろえたものの、実務はそのとおりに動いておらず、改訂も止まっている。2次審査で現場に確認すると文書と実態が食い違い、指摘を受けます。もうひとつは足りないです。方針とSoAだけがあって、日々の判断を支える手順がないため、担当者が変わると運用が変質します。

本記事は、規格が求める文書化した情報の範囲を整理し、方針・規程・手順・記録の4階層をどう設計するか、そして「どこで止めるか」の判断基準を扱います。文書化の要求そのものは 箇条7 支援｜力量・認識・文書化した情報、規格全体は ISMS（ISO/IEC 27001）とは をご覧ください。

免責：本記事は一般的な情報提供です。規格の要求事項の解釈、認定・認証の取扱いは、ISO/IEC 27001（JIS Q 27001）の規格本文および認定機関・審査機関の公表資料が正本です。実際の対応はそれらに基づいて行ってください。

なぜここでつまずくのか

「規格が要求する文書の一覧」が規格本文に一覧として載っていない

2013年版まであった「文書管理」「記録管理」という独立した章立てが、2022年版では文書化した情報という一つの概念に統合されています。要求は箇条4から箇条10までの各所に分散して置かれており、規格を通読しないと全体像がつかめません。結果として、コンサルティング会社のひな形一式が「規格が要求する文書」だと誤解されがちです。ひな形の大半は、規格の要求ではなく提供者の設計です。

「組織が必要と判断したもの」の判断を放棄している

規格は、明示的に要求する文書に加えて、ISMSの有効性のために組織が必要と決定した文書化した情報を求めています。これは裁量の余地であると同時に、裁量を行使した説明責任でもあります。「何を作らないと決めたのか、なぜか」を説明できる状態が理想です。ところが実務では、ひな形を全部採用することで判断そのものを回避してしまう。これが作りすぎの主因です。

文書と記録の役割を混同している

規程は「これからこう運用する」という取り決め、記録は「実際にこう運用した」という証拠です。両者は更新の頻度も承認者も違います。規程の中に実績の表が埋め込まれていると、実績が変わるたびに規程の改訂・承認が必要になり、運用が止まります。変わるものと変わらないものを同じ文書に入れないのが基本です。

階層が深すぎる

方針 → 基本規程 → 個別規程 → 実施手順 → 作業標準 → 様式、と6階層に分けた体系を見ることがあります。大企業の文書管理を模したものですが、50名規模の組織では同じ内容が3回書かれるだけになり、改訂のたびに整合を取る作業が発生します。階層は、組織の規模と承認権限の段数に合わせて決めるものです。

改訂が止まることを前提にしていない

文書は必ず古くなります。体系を設計する段階で「年1回、誰が、どの範囲を見直すか」を決めていないと、2年目のサーベイランス審査で「最終改訂日が取得時のまま」という状態になります。サーベイランス審査（維持審査）の準備 でも、文書の鮮度は繰り返し確認される観点です。

何を決めるのか

まず、規格が明示的に文書化した情報として求めているものを押さえます。これは「必ず作る」側の境界線です。

加えて、附属書Aで採用した管理策のうち、手順が定まっていないと運用できないものについて、組織の判断で文書を作ります。SoAで「適用する」とした管理策が、実務上どう運用されるのかを説明できる状態が必要だからです。SoAの書き方は 適用宣言書（SoA）の書き方 にまとめています。

次に、4階層の役割分担を決めます。

第2層と第3層の境界を、承認者の違いで引くのが実務的です。経営判断が必要な取り決めは規程、現場の運用変更で済むものは手順。こう分けておくと、手順の改訂に経営層の承認が要らなくなり、文書が動くようになります。

最後に、作らないと決めたものを記録することをおすすめします。「クリアデスクの運用は規程に1条項を置くにとどめ、独立した手順書は作らない」といった判断を文書体系一覧の備考欄に残しておくと、審査で「なぜこの手順書がないのか」と問われたときに、判断の結果であって漏れではないことを示せます。

実務の手順

ステップ1：規格が明示的に要求する文書から着手する

上表の14項目は、どの組織でも必要です。まずこれを埋めます。この段階では他社のひな形を参照して構いませんが、次のステップで必ず自社化します。ひな形の扱い方は 規程のひな形を自社化するコツ で詳しく扱います。

ステップ2：SoAから、文書が必要な管理策を洗い出す

適用すると決めた管理策を一覧し、それぞれについて「これは既存の規程の一条項で足りるか／独立した手順書が要るか／記録の様式だけあればよいか」を判定します。判定の基準は次の3点です。

• 手順を誤ると影響が大きいか（例：アクセス権の付与・削除、インシデントの初動）
• 複数の人が同じ作業をするか（属人化していると改訂されない）
• 審査や顧客監査で手順の提示を求められるか（委託先管理、バックアップなど）

3つとも「いいえ」なら、独立した文書は不要です。規程の一条項に収めます。

ステップ3：規程の本数を領域で決める

管理策単位で規程を作ると93本になります。領域単位でまとめるのが実務です。たとえば次のような構成であれば、50名規模でも管理できます。

管理策テーマごとの読み方は 組織的管理策37項目の読み方、人的管理策8項目の読み方、物理的管理策14項目の読み方 にまとめています。

ステップ4：文書管理のルールを最初に決める

版番号の付け方、改訂履歴の残し方、保管場所、アクセス権、保存期間、廃止版の扱い。これらを最初に決めておかないと、後から全文書を直すことになります。保管場所は1か所に統一し、「正本はどこか」を全員が答えられる状態にします。共有ドライブとファイルサーバに同じ文書が散在している状態は、審査で必ず問題になります。

ステップ5：様式（フォーム）を先に作る

手順書より様式を先に作ると、体系が現実的になります。様式は「実際に何を記録するのか」を決める行為であり、ここで記録不可能な項目が見つかることがよくあります。たとえば「承認者」の欄を作ったときに、承認する権限を持つ人が不在だと分かる、といった具合です。

ステップ6：レビューの周期と担当を決める

文書一覧表に「次回見直し予定日」と「見直し担当」の列を作ります。全文書を一度に見直すのではなく、四半期ごとに一部ずつ回すと負荷が平準化します。内部監査で文書の鮮度を確認項目に入れておくと、見直し漏れが発見できます。進め方は 内部監査の進め方｜計画・チェックリスト・報告 をご覧ください。

よくある失敗

ひな形一式をそのまま採用する

最も多い失敗です。他社向けに作られた規程には、自社に存在しない部署名、実施していない管理、使っていないツールが書かれています。2次審査では文書の記載どおりに運用されているかが確認されるため、書いてあるのにやっていない状態は不適合の温床になります。詳しくは 規程のひな形を自社化するコツ を参照してください。

規程に固有名詞と数値を書き込みすぎる

「Microsoft 365のテナント管理者は情報システム課長とする」と規程に書くと、ツールを変えるたび、組織名が変わるたびに規程の改訂と承認が必要になります。固有名詞と可変の数値は、第3層の手順か別表に置くのが定石です。規程には「クラウドサービスの管理者権限は、情報システムを所管する部門の長が保有する」のように、役割で書きます。

同じことが複数の文書に書かれている

方針にも管理規程にも利用規程にも「パスワードは定期的に変更する」と書かれている状態です。ひとつを直したときに他が残り、文書間で矛盾が生じます。実務では、同じ事項は1か所にだけ書き、他からは参照する形にします。

記録の保存期間が決まっていない

保存期間の定めがないと、記録が無限に増えるか、誰かの判断で消えます。審査では「前回の内部監査記録を見せてください」と言われるため、最低でも1認証サイクル（3年）は保持できる設計にしておきます。医療情報を扱う場合は、契約や法令で別途保存期間が定まっていることがあるため、そちらを優先します。

電子と紙が混在し、正本が分からない

押印が必要な様式だけ紙で運用し、それがキャビネットに入っているが一覧がない、という状態です。紙で残すなら、電子の文書一覧表に「紙・保管場所」を明記します。

文書を増やすことが目的化する

「規程が20本ある」ことはISMSの成熟度を示しません。示すのは、文書に書かれたとおりに運用されており、その証拠が記録として残っていることです。分量の多い体系は、少人数の組織では維持できません。少人数組織のISMS で触れているとおり、規模に合った体系に絞ることが適切な判断です。

改訂したが周知していない

規程を改訂したのに、現場は旧版の手順で動いている。文書管理の要求には、必要な人が必要なときに利用できる状態にすることが含まれます。改訂時の周知方法（メール通知、朝礼、教育への組み込み）を文書管理のルールに書いておきます。周知と教育の設計は 従業者教育の設計｜受講率100%の運用 で扱います。

ヘルスケア企業の例

医療SaaS事業者

一般的な体系に加えて、本番環境の患者データを扱う作業の手順書が必要になります。障害調査、データ修正依頼への対応、移行作業。いずれも「誰が申請し、誰が承認し、何を記録するか」を定めておかないと、医療機関から手順の提示を求められたときに答えられません。この手順書は、顧客監査でそのまま提示する前提で作ると無駄がありません。

また、顧客ごとの個別要求を規程本体に取り込まないことも重要です。医療機関Aとの契約で求められた条件を全社規程に書くと、他の顧客にも適用されてしまいます。個別要求は契約管理台帳と、必要なら顧客別の付属文書で管理します。責任分界の考え方は AI電子カルテのセキュリティ設計｜責任共有モデル が参考になります。

PHR事業者

同意管理の手順が独立した文書として必要です。取得・変更・撤回のそれぞれについて、画面上の導線、記録される項目、撤回後のデータ取扱いを定めます。個人情報保護法上の要求と重なるため、プライバシーポリシーと社内規程の記載が矛盾しないように、両者を同じレビューに載せます。詳細は PHR事業者のISMS｜個人情報保護法との関係 をご覧ください。

SaMDを開発する企業

QMS（ISO 13485）の文書体系がすでに存在するため、ISMS文書をどう接続するかの設計が先になります。文書管理・教育・内部監査・是正処置は共通化できる一方、リスクマネジメントは目的が異なるため分けます。共通化した文書には、どちらのマネジメントシステムの要求に対応しているかを明記しておくと、両方の審査で使えます。関係の整理は SaMDとISMS・QMS（ISO 13485）の関係 にあります。

医療機関向けのシステムを提供する企業全般

3省2ガイドラインへの対応文書を、ISMSと別体系で持つと二重管理になります。同じ規程の中に、ガイドラインの要求に対応する条項を置き、対応表で紐づけるのが現実的です。統合の考え方は ISMS文書と3省2ガイドライン対応文書の統合、ガイドライン側の全体像は 3省2ガイドラインとは にまとめています。

まとめ

1. 規格が明示的に文書化を要求しているのは限られた項目（適用範囲、方針、リスク関連のプロセスとSoA、目的、力量の証拠、監視結果、内部監査、マネジメントレビュー、不適合と是正処置ほか）。残りは組織の判断
2. 「組織が必要と決定した文書」は裁量であると同時に説明責任。作らないと決めたことも記録に残す
3. 階層は方針・規程・手順・記録の4層で足りる。第2層と第3層の境界は承認者の違いで引く
4. 規程は管理策単位ではなく領域単位でまとめる。50名規模なら8本程度で管理できる
5. 固有名詞と可変の数値を規程に書かない。ツールや組織が変わるたびに改訂が必要になる
6. 文書管理のルール（版数・正本の場所・保存期間・周知方法）は体系を作る前に決める。後から全文書を直す羽目になる

ポテックは、ヘルスケア領域に特化してISMSの構築を支援しています。文書体系は、規模と実務に合わせて「どこで止めるか」を決められるかどうかで、その後の運用負荷が大きく変わる領域です。支援内容と料金は ISMS認証取得支援サービス、個別のご相談は お問い合わせ から承ります。

参考・出典

• 情報マネジメントシステム認定センター（ISMS-AC）
• ISO/IEC 27001 Information security management systems｜ISO
• 日本産業標準調査会（JISC）
• 医療情報システムの安全管理に関するガイドライン｜厚生労働省
• 個人情報保護委員会

※規格の要求事項の解釈、認定および認証の取扱いは、規格本文および認定機関・審査機関の公表資料をご確認ください。改定や運用の見直しにより取扱いが変わる場合があります。