ISMSを自社の仕事に合わせて運用する

当社がISMSの認証取得に取り組み始めた頃は、コンサルティング会社の支援を受けていました。用意された雛形に自社の情報を記入し、文書や台帳はWordとExcelで管理する。まずは規格が求めるものを一通りそろえるところからのスタートでした。

認証を取得するうえでは、この方法が助けになりました。一方で、運用を続けるうちに、自社の仕事の進め方とは合わない部分も見えてきました。

文書を改訂するたびに、本文だけでなく改訂履歴も更新する。誰が確認し、どの版を承認したのかを別の記録に残す。内部監査で指摘があれば、さらに別の台帳で対応状況を追う。少人数のISMS運用チームにとって、こうした管理は徐々に重い作業になっていきました。

規格は手順書ではなかった

運用を見直すきっかけになったのは、ISO/IEC 27001（JIS Q 27001）が具体的な手順を定めたものではないと捉え直したことでした。

ISMSは、Information Security Management System（情報セキュリティマネジメントシステム）の略称です。ISO/IEC 27001は、組織が満たすべき要求事項を示しています。しかし、文書をWordで作ることも、台帳をExcelで管理することも求めていません。要求事項をどのような仕組みで満たすかは、それぞれの組織が決められます。

ISMSに取り組むと、確認することや記録することは増えます。リスクを洗い出し、責任者を決め、変更の経緯を残し、定期的に見直す。規格に沿って運用する以上、一定の手間はかかります。

一方で、規格が求めているのは、現場から離れた特別な作業ではありません。アクセス権限を適切に設定する、バックアップを取る、問題が起きたら原因と対応を確認する。多くは、当社でも日常業務の中ですでに行っていたことでした。

見直す余地があったのは、その残し方です。必要な対応はしていても、判断の理由が会話の中にしか残っていない。定期的に確認していても、いつ、誰が、何を確認したのかまでは記録していない。業務は回っていても、後から経緯をたどれない場面がありました。

要求事項に沿って一つずつ確認すると、すでにできていることと、記録や運用を補うべきことを整理できます。新しいサービスや仕組みを導入するときには、検討すべき項目を確認するためのチェックリストにもなります。ISO/IEC 27001の要求事項は、日常業務を確認できる形にし、次の改善点を見つけるための枠組みとしても使えます。 そう捉え直したことで、認証を目的とした管理から、自社の業務に合う仕組みへ変える方向が見えてきました。

自社で扱う情報や利用するサービスが変われば、必要な対策も変わります。一度作った文書を維持するだけでは、現在の業務に合っているかを確認できません。そこで当社は、要求事項を普段の仕事へ組み込み、日常の中で記録と見直しを続けられる運用を作ることにしました。

日常業務と同じ場所で管理する

当社が最初に見直したのは、実際の作業と記録を分けていた点です。作業後に内容を思い出して台帳へ転記する運用では、記録すること自体が仕事になります。転記を忘れれば、実施した作業と記録にもずれが生じます。

そこで、ISMS運用チームが日常的に使っていたGitLabを管理基盤にしました。文書はMarkdownで作成してGitで管理し、対応が必要な事項はGitLabのイシューで追跡します。自己点検や教育後の理解度確認にはGoogleフォームを使い、対応が必要な回答だけをイシューへつなぎます。

すべてを一度に置き換えたわけではありません。数年かけて少しずつ対象を広げ、現在は次のように使い分けています。

管理するもの 使用する仕組み 記録できること
ISMS関連文書 Git 変更内容、変更者、変更日時
文書の承認 GitLabのマージリクエスト 承認者、承認日時
監査指摘や是正処置 GitLabのイシュー 担当者、期限、対応の経緯
自己点検や教育 Googleフォーム 回答内容、回答日時
情報資産 データベースへ移行中 資産、管理責任者、関連情報

Gitを使えば、コミット履歴が文書の改訂履歴になります。マージリクエストを通してからメインブランチへ反映することで、承認された文書を正本として管理できます。監査指摘をイシューにすれば、規程を改訂した理由と対応の経緯もリンクでたどれます。

ツールを一つに統一することが目的ではありません。変更履歴が重要な文書にはGit、回答を集める点検にはフォームというように、用途に合う仕組みを選んでいます。対応が必要な事項をGitLabへ集めることで、担当者や期限を普段の業務と同じ場所で確認できるようにしました。

作業の履歴をそのまま証跡にする

運用を作り直したことで、審査のために記録を整える作業は以前より少なくなりました。文書を更新する、変更を承認する、イシューに対応を記録する。普段の作業で残る履歴を、そのままISMSの証跡として使えるためです。

特定の担当者しか状況を把握できない場面も減りました。イシューを確認すれば、未対応の課題やこれまでの経緯が分かります。担当者が不在でも、別のメンバーが対応を引き継ぎやすくなりました。

ISMSを自分たちの仕事として考える

運用を自分たちで作るには、規格の文言を確認するだけでは足りません。なぜこの記録が必要なのか、どのようなリスクに備えるのかを、実際の業務に照らして考える必要があります。

その過程で、チームとISMSとの関わり方も変わりました。メンバーがセキュリティ関連のニュースや脆弱性情報を自発的に確認し、気になった情報を定例会や日常の会話で共有するようになりました。

自分たちで仕組みを設計し、試し、改善する機会が増えたことで、ISMSを認証維持のための作業ではなく、自分たちの業務を守る活動として考えるようになりました。

セキュリティの話題を日常的に共有するうちに、その関心はISMS運用チームからほかのメンバーへも少しずつ広がりました。仕組みを自分たちで作る過程が、チームの外でもセキュリティについて話すきっかけになりました。

現在も運用を見直している

現在の運用も完成形ではありません。情報資産の目録は、スプレッドシートからデータベースへの移行を進めています。台帳の規模が大きくなり、セル単位の変更や資産同士の関係をスプレッドシートでは追いにくくなったためです。

脆弱性情報の確認についても、手作業を補うアプリケーションを開発し、試験運用しています。検知した情報は週1回の定例会で確認します。担当者が定期的に手作業で確認する運用から、継続的に情報を集めて判断する運用へ移しているところです。

こうした変更でも、先にツールを決めることはしません。現状の作業を整理し、どこで情報が滞るのか、誰が何を判断するのかを確認してから、運用フローとそれを支える仕組みを設計します。当社では、文書の変更、承認、課題への対応を互いにリンクできるため、GitLabを運用の中心にしています。

小さな範囲から自社の運用へ変える

ISMSの運用に負担を感じていても、文書や台帳を一度に移行する必要はありません。当社も、一つの文書をGitで管理するところから対象を広げてきました。

これから見直す場合は、日常の作業とISMSの記録がどこで分かれているかを確認します。文書の改訂、承認、点検、是正処置のうち、転記や二重管理が発生しているものから試すと変化を確かめやすくなります。

運用を集約するときは、バックアップとエクスポートの方針も必要です。監査に備えて、変更者と変更日時を識別できること、差分を確認できること、承認済みの版を保護できることも、自社の手順として説明できるようにしています。

規格は、多くの組織に適用できるように作られたフレームワークです。だからこそ、雛形を埋めるだけでは、自社の業務に合わない運用が残ることがあります。要求事項を理解し、普段の仕事に組み込める流れを設計する。当社では、その見直しを重ねることで、ISMSを認証維持のための作業ではなく、日常の業務を改善する機会として捉えられるようになりました。