ISMS構築の実務では、規程をゼロから書くことはほとんどありません。コンサルティング会社や書籍、認証機関の解説資料が提供するひな形を土台にします。これ自体は合理的で、規格の要求の抜け漏れを防ぐという意味で有効です。
問題は、ひな形をそのまま採用したときに何が起きるかです。1次審査（文書審査）は通ります。文書としては整っているからです。しかし2次審査では、審査員が現場の担当者に「この規程では月次で棚卸しを行うとありますが、直近3か月分の記録を見せてください」と尋ねます。記録がなければ、規格への不適合ではなく「自社で定めたルールを守っていない」という不適合になります。これは説明が難しく、是正にも時間がかかります。
本記事は、ひな形を自社の実態に合わせる作業を手順化します。どこが露見するのか、何を基準に条項を削るのか、そして「守れないルールを書かない」という原則をどう適用するのかを扱います。文書体系全体の設計は ISMS文書体系｜何をどこまで作るか、規格全体は ISMS（ISO/IEC 27001）とは をご覧ください。
免責：本記事は一般的な情報提供です。規格の要求事項の解釈、認定・認証の取扱いは、ISO/IEC 27001（JIS Q 27001）の規格本文および認定機関・審査機関の公表資料が正本です。実際の対応はそれらに基づいて行ってください。
なぜここでつまずくのか
ひな形は「最大公約数」かつ「安全側」に振られている
ひな形の作り手は、どの組織に使われるか分かりません。したがって、情報システム部門がある、サーバ室がある、開発部門がある、入退室記録がある——といった前提を広くカバーする書き方になります。さらに、審査で不足を指摘されるリスクを避けるため、要求より厳しい水準で書かれていることが少なくありません。「四半期ごと」で十分な点検が「毎月」と書かれている、といった具合です。
この安全側の振れは、ひな形としては正しい設計です。削るのは利用者の仕事という前提で作られています。ところが、削る作業には規格の知識が要るため、多くの組織が削れないまま採用してしまいます。
「削ると審査に落ちるのでは」という恐れ
これが最大の心理的な障壁です。しかし実際には逆で、書いてあってやっていないほうが、書いていないより重いというのが審査の基本的な見方です。規格が求めていない管理を規程に書き、それを守っていない状態は、自社のマネジメントシステムが機能していないことの証明になってしまいます。
自社の実務を書き出す前にひな形を読んでしまう
ひな形を先に読むと、その枠組みに引きずられて「うちもこうすべきかもしれない」という発想になります。順序を逆にして、先に自社が実際にやっていることを書き出し、その後でひな形と突き合わせると、差分が明確になり、判断がしやすくなります。
語尾の意味が意識されていない
日本語のひな形では、「〜する」「〜しなければならない」「〜するものとする」「〜することが望ましい」「〜してもよい」が混在していることがあります。審査では、義務として書かれた条項は義務として確認されます。「望ましい」であれば実施していなくても直ちに不適合にはなりませんが、「しなければならない」と書けば記録の提示を求められます。この違いを意識せずに採用すると、意図せず義務を背負うことになります。
固有名詞と数値がそのまま残っている
ひな形に例示として書かれた部署名、システム名、頻度、保存年数がそのまま残っているケースは非常に多く、審査員が最初に探すポイントでもあります。自社に存在しない「情報システム部」が規程に出てきた時点で、文書が自社化されていないことが分かります。
何を決めるのか
ひな形の各条項について、そのまま使う／書き換える／削るの3分類に振り分けます。判断の基準は次のとおりです。
| 分類 | 条件 | 例 |
|---|---|---|
| そのまま使う | 規格が明示的に要求しており、かつ自社の実務と一致している | 「情報セキュリティ方針はトップマネジメントが承認する」 |
| 書き換える | 趣旨は必要だが、頻度・役割・対象・手段が自社と違う | 「毎月」→「四半期ごと」、「情報システム部長」→「管理部門の長」 |
| 削る | 自社に該当する事象・資産・業務が存在しない | 自社開発をしない組織の「セキュアコーディング基準」の詳細条項 |
削る判断は、必ずSoAと突き合わせます。 ある管理策を適用すると決めているのに、対応する条項を規程から削ると、実装を示す文書がなくなります。逆に、SoAで適用除外とした管理策に関する条項は、規程に残しておく理由がありません。SoAの書き方は 適用宣言書（SoA）の書き方 を参照してください。
原則：守れないルールを書かない。
これを判断の軸に据えます。具体的には、条項ごとに次の3つを自問します。
- 来週から実施できるか。できないなら、実施できる水準に書き換えるか、実施できる時期までは書かない
- 実施した証拠が残るか。記録が残らない条項は、審査で実施を示せない。記録の様式まで設計してから書く
- 担当者が交代しても続くか。特定の個人の習慣に依存する条項は、その人がいなくなった時点で不適合になる
書きたいが今は守れない事項は、規程ではなくリスク対応計画や情報セキュリティ目的に置くのが正しい処理です。「2027年度中にログの自動監視を導入する」は目的として管理し、導入後に規程へ昇格させます。目的の立て方は 情報セキュリティ目的とKPIの立て方 にまとめています。
語尾のルールを決めます。 規程内では「〜する」（義務）と「〜することができる」（裁量）の2種類に統一し、「〜が望ましい」は使わないのが管理しやすい設計です。望ましい程度のことであれば、規程に書かず手順書やガイドに置きます。
実務の手順
ステップ1：自社の実務をAs-Isで書き出す
ひな形を開く前に、現在やっていることを箇条書きにします。入退社時の手続き、アカウントの発行と削除、バックアップ、端末の配布、委託先との契約、インシデントが起きたときの連絡先。すでにやっていることのほうが、これから始めることより多いのが普通です。ここで書き出したものは、ほぼそのまま規程の素材になります。
ステップ2：ひな形の条項を1つずつ3分類する
ひな形に通し番号を振り、各条項に「そのまま／書換／削除」の印と、削除・書換の理由を記入します。この一覧は、審査で「なぜこの条項がないのか」と問われたときの回答資料になります。捨てずに残します。
ステップ3：頻度・役割・対象を自社化する
| ひな形の典型的な記述 | 起きること | 書き換えの方向 |
|---|---|---|
| 「情報システム部長は毎月アクセス権限の棚卸しを行う」 | 該当部署がなく、毎月は実施していない | 「情報システムを所管する部門の長は、四半期ごとにアクセス権限の棚卸しを行う」 |
| 「サーバ室の入退室記録を保管する」 | 自社サーバ室がない（全てクラウド） | 削除。クラウド事業者の管理として委託先管理規程に移す |
| 「全ての情報資産に機密区分ラベルを貼付する」 | 電子ファイルに物理ラベルは貼れない | 「情報資産台帳に機密区分を記録し、文書には区分を明記する」 |
| 「パスワードは90日ごとに変更する」 | 実際は強制変更していない | 実態に合わせる。変更を強制しないなら、その旨と補完する管理（多要素認証等）を書く |
| 「年2回、外部の専門家による脆弱性診断を実施する」 | 予算がなく実施していない | 頻度を実施可能な水準にするか、目的に移して達成後に規程化 |
| 「教育は集合研修により実施する」 | 実際はeラーニングと動画 | 「教育は集合研修またはeラーニング等の方法により実施する」 |
| 「秘密情報は施錠可能なキャビネットに保管する」 | 紙の秘密情報を持たない | 紙を持たない旨を明記したうえで条項を簡素化、または削除 |
ステップ4：固有名詞を役割名に置き換える
「Microsoft 365」「情報システム部」「山田部長」といった記述は、役割で書き直します。ツール名や個人名が必要な場合は、規程本体ではなく別表または手順書に置き、規程からは「別表1に定める」と参照します。これにより、ツール変更時の改訂が別表だけで済みます。
ステップ5：実際にやる人に読ませる
規程を書いたISMS事務局ではなく、その条項を日々実行する担当者にレビューさせます。「これ、うちはやってないですよ」という指摘が最も価値のあるフィードバックです。この工程を飛ばした規程は、ほぼ確実に実態と乖離します。
ステップ6：記録の様式まで一緒に用意する
条項を残すと決めたら、その実施記録をどの様式に残すかを同時に決めます。様式のない条項は、実施しても証拠が残りません。 逆に、様式を設計してみて「これは記録が重すぎる」と分かれば、条項自体を見直す材料になります。
ステップ7：差分の記録を残す
ひな形からの変更点を一覧にしておくと、翌年以降の見直しで「なぜこうなっているか」をたどれます。人が入れ替わると、この背景が失われて元のひな形に戻ってしまうことがあります。
よくある失敗
露見する経路を知らない
ひな形のままであることは、次のような経路で表面化します。審査員は文書と実態の突合を仕事にしているため、経路は定型的です。
| 審査員の行動 | ひな形のままだと起きること |
|---|---|
| 規程に書かれた頻度の記録を求める | 「毎月」の記録が1〜2回分しかない |
| 規程に出てくる部署名の担当者を呼ぶ | その部署が存在しない |
| 規程の用語を現場の担当者に尋ねる | 担当者が用語を知らない／規程を読んだことがない |
| 規程の様式と実際の記録を突き合わせる | 様式が使われておらず、別のExcelで運用されている |
| 適用除外とした管理策の条項を探す | 削除されておらず、SoAと規程が矛盾している |
| 改訂履歴を見る | 初版のまま、日付が取得準備期間で止まっている |
| 複数の規程で同じ事項を比較する | 記述が食い違っている（頻度、保存年数、責任者） |
規程を厳しく書いておけば安全だと考える
逆です。規程は自社が自分に課したルールであり、守れていなければマネジメントシステムが機能していない証拠として扱われます。審査でよくある指摘の類型は 審査でよくある不適合と対策 にまとめています。
削除した条項の理由を残していない
「なぜこの規程にはクリアデスクの条項がないのですか」と問われて、「ひな形から削りました」としか言えないと、判断があったのか漏れたのか区別がつきません。削除理由を一覧に残すだけで、この問いに答えられます。
複数のひな形を混ぜている
コンサルティング会社のひな形、書籍の例文、他社から譲り受けた規程を継ぎ接ぎすると、用語が揃わなくなります。「情報資産」「情報システム」「重要情報」が定義なしに混在し、どれがどれを指すか分からない状態が生まれます。用語定義を1か所に置き、全規程で同じ語を使うことが必要です。
ひな形の前提とする組織規模が違う
大企業向けのひな形には、委員会、分科会、事務局、部門推進責任者といった階層が出てきます。20名の組織でこれを採用すると、一人が4つの役職を兼ねる構造になり、内部監査の独立性が確保できなくなります。少人数組織での設計は 少人数組織のISMS を参照してください。
自社の強みが規程から消えている
見落とされがちな点ですが、ひな形をそのまま使うと、自社が実際に行っている優れた管理が規程に現れません。たとえば、コードレビューで必ずセキュリティ観点のチェックをしている、本番データへのアクセスを全件Slackで通知している、といった運用は、ひな形には書かれていません。これらは規程に書き、記録を残すことで、審査でも顧客への説明でも資産になります。
「後で直す」と言って直さない
取得前は時間がないためひな形のまま提出し、取得後に見直す——という計画は、ほぼ実行されません。1次審査までに自社化を終えるのが現実的です。取得までの工程は ISMS取得にかかる期間｜6か月スケジュールの実際 にまとめています。
ヘルスケア企業の例
医療SaaS事業者
一般的なひな形には、本番環境の患者データを扱う際の統制が書かれていません。障害調査のための参照、データ修正、移行作業。これらは自社で条項を追加する必要があります。逆に、ひな形の「サーバ室」「入退室管理」「media handling」に関する詳細条項は、フルクラウドであれば大半が該当せず、クラウド事業者の管理として委託先管理に移すのが適切です。クラウド利用時の考え方は 医療機関のクラウドセキュリティ も参考になります。
もう一点、顧客である医療機関からの要求を規程に全部取り込まないという判断が重要です。個別の契約条件を全社規程に書くと、他の全顧客に対して同じ義務を負います。個別要求は契約管理で扱います。
PHR事業者
同意の取得・撤回に関する条項はひな形に存在しません。自社で書き起こす領域です。一方、ひな形の個人情報保護に関する条項は、個人情報保護法の条文をなぞったものが多く、自社の実際のデータフローに合わせて具体化しないと機能しません。詳細は PHR事業者のISMS｜個人情報保護法との関係 をご覧ください。
SaMDを開発する企業
QMS（ISO 13485）の文書がすでにあるため、ひな形の規程をそのまま追加すると、同じ事項が2つの体系で別の書き方をされるという最悪の状態になります。教育、文書管理、内部監査、是正処置については、既存のQMS文書に情報セキュリティの要求を追記する方向で自社化するほうが、維持が容易です。関係の整理は SaMDとISMS・QMS（ISO 13485）の関係 にあります。
医療機関向けの開発・保守を受託する企業
3省2ガイドラインが求める安全管理措置は、一般的なISMSひな形には含まれていません。リモート保守の接続手順、作業記録、責任分界に関する条項は追加が必要です。ガイドラインの全体像は 3省2ガイドラインとは、ISMS文書との統合は ISMS文書と3省2ガイドライン対応文書の統合 をご覧ください。
まとめ
- ひな形は最大公約数かつ安全側に書かれている。削るのは利用者の仕事という前提で設計されている
- 書いてあってやっていないほうが、書いていないより重い。厳しく書いて守れないのは、マネジメントシステムが機能していない証拠になる
- 条項はそのまま／書換／削除の3分類に振り分け、削除・書換の理由を一覧に残す。これが審査での回答資料になる
- 原則は守れないルールを書かない。来週から実施でき、記録が残り、担当者が替わっても続くかを自問する
- 今は守れないが実施したい事項は、規程ではなくリスク対応計画または情報セキュリティ目的に置き、達成後に規程へ昇格させる
- 固有名詞と可変の数値は別表か手順書へ。規程は役割で書き、実際にやる担当者にレビューさせる
ポテックは、ヘルスケア領域に特化してISMSの構築を支援しています。弊社の支援では雛形を提供していますが、価値があるのは雛形そのものではなく、どの条項を残し、どこを自社の実務に合わせるかの判断です。支援内容と料金は ISMS認証取得支援サービス、個別のご相談は お問い合わせ から承ります。
参考・出典
- 情報マネジメントシステム認定センター（ISMS-AC）
- ISO/IEC 27001 Information security management systems｜ISO
- 日本産業標準調査会（JISC）
- 医療情報システムの安全管理に関するガイドライン｜厚生労働省
- 個人情報保護委員会
※規格の要求事項の解釈、認定および認証の取扱いは、規格本文および認定機関・審査機関の公表資料をご確認ください。改定や運用の見直しにより取扱いが変わる場合があります。