株式会社スタイル・エッジ様 – 顧客事例 –

1年間お付き合いができると思い、LRMに依頼しました
（システム事業部 セクションマネージャー・長田唯世氏）

— ISMS認証を取得した理由をお話下さい。

弊社がISMS認証を取得した目的は、社内の業務環境を整備するためです。事業が成長し組織も拡大する中、それに相応しいセキュリティ体制を整える必要が生まれていました。
経営企画室として、何とかしなければという話をしていた時に、グループ内で使用していた顧客管理システムを外販する計画が持ち上がり、そのためには外部向けにISMS認証が必要という話になりました。経営企画室の中で話が出た時は認証ありきの話ではありませんでしたが、ISMSのフレームワークを使えば、セキュリティ体制を整備することにもつながると考え、グループ全体で取得することになりました。

— 御社の事業は、セキュリティ事故が起きるリスクは高いのですか。

高いという認識を持っています。お客様の士業事務所では非常にクリティカルな情報を扱っています。例えば弁護士事務所の場合、借金の返済に困って相談に来られている方々がデータベース化されています。それは違法な貸金業者などにとっては有用な顧客リストとなり得るものです。
特にスタイル・エッジCAREERのコンサルタントは、クライアント先に常駐し、現場と一体となった支援をしていますので、取り扱いを間違えば流出してしまうリスクがあります。

こういったリスクに対処するため、個人情報の取り扱いルールを作り、リスク管理委員会を組織して、弊社なりの取り組みはしていましたが、それでは実態と見合った対策が取れなくなっていました。

— リスク管理委員会とはどのような役割を担う組織ですか。

リスク管理委員会は、個人情報漏洩事故を防ぐための啓蒙活動を主目的とする組織です。個人情報の取り扱いルールを作成したのと同時期に組織されました。

— それはいつ頃ですか。

2015年です。弊社は2013年から急激に組織が拡大し始めました。そこでそろそろ統一ルールを作った方が良いだろうということになり、Pマーク取得の話が出ました。ただ当時はPマーク取得が出来る体制が整っていないという判断のもと、ひとまずはルール作りだけしようということになりました。そこで自分達なりのルールを構築し、リスク管理委員会を立ち上げ、グループウェアやチャットなどを使用し、「業務でLINEを使ってはダメ」といった注意喚起や、ウイルスメールが来た時はアラートを出すなどの活動は行っていました。

ただ、ルールを徹底させる仕組み作りには至らず、そのうち事業規模もどんどん大きくなってきたため追いつかなくなっていました。

— 今回取得したのがPマークではなくISMS認証だった理由をお話し下さい。

Pマークは守る対象が個人情報に限定されていますので、全体的にセキュリティを強化するならISMSが相応しいと考えました。またISMSは、基本的には自分達でルールを決めてPDCAを回しながら改善し続けることが前提のマネジメントシステムなので、社内状況や社会環境の変化に応じて見直すということがしやすいため、変化の激しい今の時代に合致していると考えました。

— ISMS認証取得の期限は定めていましたか。

厳密な期限はありませんでしたが、最長約1年間の取り組みで考えていました。構想に上がっていた顧客管理システムのリリースを2019年夏に予定していましたので、それまでに間に合えば良いと思っていたのです。

ただ、ISMSに関しては知識がありませんし、コストもかかることなので取得できなかったでは済みません。確実に取得したいと考え、コンサルティング会社の選定からスタートしました。

いかにリスクを受容するかを決めることも大切だとLRMに教えていただきました
（システム事業部 エンジニア・
手塚奈々絵氏）

— 今回、情報セキュリティのルールを構築したことで、現場の運用が変わったところはありましたか。

ありました。今回のISMS認証取得に向けた取り組みの中では、現場の運用を変えることでミスがなくなるのであれば変えるべきだという考えでルール構築を行っています。

例えばスタイル・エッジCAREERの業務ではショートメールを頻繁に使っているのですが、誤送信を防ぐために必ずダブルチェックをすることにしました。また、仮に誤送信があったとしても影響を最小限にとどめるため、本文中に個人情報を含めないルールにしました。

— グループウェアやチャットをご利用されているとのことでしたが、クラウドサービスのご利用に関する制限などは設けましたか。

クラウドサービスの利用に関する検討はしましたが、現段階ではアカウント管理表を作成したのみです。これからルールを検討するということになっています。

クラウドサービスは、お客様がご利用になられているツールを使うという形で、どんどん増えて来たという経緯があります。例えばコミュミケーションツールはLINE、Skype、Chatwork、Slackなどを使っていますし、ストレージはGoogleDrive、OneDrive、Box、Dropboxなどを使っており、グループ内で統一が出来ていない状況です。

今回、LRMからツールをバラバラにしていると管理が煩雑になるため良くないというご指摘をいただきましたが、統一するとクライアントにも影響が及びますので、現実問題として難しい状況です。そこで本来どうあるべきかを考え直して、使う上でのルールを決めていこうということになりました。

— アカウント管理表はなぜ必要なのですか。

どの部署がどのようなツールを使っているかを把握して管理するためです。これまで他の部署で使っていることを知らずに新規で契約してしまうということが起きていましたが、それを防ぐことも出来ます。また、今使用しているものだけではなく、過去にどこかの部署が使ったことがあるツールの履歴も残しています。履歴が残っていれば、仮に別の部署で導入を検討することになった際の参考にすることが出来ます。もしそのツールの使い勝手が悪くて解約したという話なら、導入をやめるという判断も出来ます。そうすることで失敗する可能性を小さくできますし、少しずつでも統一していけるのではないかと考えています。

— そうなると、これが使いたいという場合は申請しなければいけなくなるわけですか。

そうですね。ただ現状では申請するというルールはまだ運用段階に至っていません。申請制にするには許可するか否かの判断基準を明確にする必要がありますので、現在検討中です。

— そのような申請フローを、現場の方々は受け入れてくれるのですか。

使用するツールの申請に限らずルールの浸透は根気強く取り組むべき課題です。今回の取り組みでは、スタイル・エッジグループとしてのルールを明文化できたことはもちろんですが、その作ったルールをグループ全体に浸透させる体制作りが出来たということが重要だったと考えています。

リスク管理委員へのレビューにも出席していただきルール作りが前に進みました
（経営企画室 マネージャー・
西川絵里嘉氏）

— そういったルール作り、体制作りは、どのような経緯で行われたのでしょうか。

LRMのリードに従い、サポートを受けながら作業を進めて行きました。

まずルール作りは、情報資産管理台帳の作成からスタートしましたが、そもそも何をしなければいけないのか、どのようなフォーマットでやるべきなのかといったところから、実行段階まで適宜LRMに質問しながら進めて行きました。同時にリスクアセスメントを実施し、LRMにマニュアルの叩き台を作ってもらい、それを読み合わせしながら弊社の実態に合うよう修正を加えて行きました。

— そのルール作り、マニュアル作りはISMS事務局だけで行ったのですか。

まずISMS事務局がLRMのサポートを受けて何回か修正しながら草案を作りました。そしてリスク管理委員を招集してレビューを行い、各部門の声を聞きながら完成させました。

システム事業部と経営企画室の4名だけで決めてしまえば反発が生まれます。弊社には様々な部門がありますので、現場の意見や実用性を考慮する必要がありました。従って草案をレビューして、実際にこれで皆さんの現場は回りますか、回らなければどうすれば回るようになりますか、という話は丁寧にしていきました。そこは最も苦労したところです。

— やはり異論は出ましたか。

異論は出ましたし、強い抵抗もありました。レビューの場には何度かLRMのお2人にも来ていただいて交通整理していただきました。そもそもこの活動を何のためにやっているのかをご説明いただいて、「出来ないと言うだけではなく、出来る方法を考えましょう」と促してもらって、結果的にリスク管理委員に納得してもらうシーンもありました。
LRMのサポートがあったおかげで、ルール作りが前に進んだだけではなく、取り組みに対するリスク管理委員の理解が深まりました。そしてそれが、ISMS事務局とリスク管理委員の連携体制が築かれる要因にもなりました。

— 内部監査はいかがでしたか。

内部監査はISMS事務局向けと現場向け、ともにLRMに内部監査員を代行していただいて実施しました。福岡支社も大谷さんに行っていただきました。

— ISMS事務局向けの内部監査ではどのような点が監査の対象になるのですか。

審査に必要な書類が揃っているかどうかと、構築したルールについて審査員から規格の言葉で質問された時に、それが何に該当するのかを探せるかどうかをチェックしていただきました。

今回構築したルールは、ISMSの規格を意識せずに回せるようになっています。構築段階でも規格はほとんど意識していません。ISMSの規格は、専門用語がちりばめられていて、非常に難解です。それを理解して1から作るより、一旦規格を読み込んで理解した人が作ったものを吸収した方が、スピード感は良いですし、大きくはずれることはないと思いました。ただ、実際の審査では「第何条のここはどうなっていますか」といった、マニュアルに書かれたルールと規格の関連性を理解していないと答えられない質問もされます。その規格とルールの対照関係を、内部監査を通じて教えていただきました。

— 現場向けの内部監査はどんなところをチェックするのですか。

各現場で、そもそも決めたルールを理解しているか、きちんと守られているかをチェックしてもらいました。この段階で問題点を洗い出して、改善することが出来ましたので、それが審査を迎える準備にもなりました。

— 目的としていた体制整備の他、副次的に得られた成果などはございましたか。

ISMS事務局メンバーのセキュリティに対する興味が以前よりさらに強くなりました。ウイルスなどITシステム上のセキュリティだけではなく、リスク全体に対する関心が強まりました。例えば契約書に目を通した際にこの項目がなければ困るのではないかなど法務に対する興味も芽生えています。

また、LRMのコンサルティングを通して、ISMSは洗い出したリスクの1つ1つに必ず対応しなければいけないものではない、という気付きを得ることも出来ました。リスクは認識していてもすぐに対応出来ないこともあります。クラウドツールの統一が良い例です。リスクをどのように受容していくのかを明確にし、できる範囲で対応すれば良いということがわかりました。自分達で決めたルールを、自分達で運用する。ガチガチにルールを固めて行くことが決して良いとは限らない。それがISMSであるとLRMに教えていただきました。