QCプラネッツ

カテゴリー: 情報セキュリティ

  • 【提言】CIAリスクアセスメントの評価は2段階がよい

    【提言】CIAリスクアセスメントの評価は2段階がよい

    ★ 本記事のテーマ

    【提言】CIAリスクアセスメントの評価は2段階がよい

    CIAのリスクアセスメントの点数付けを細かくして運用するより、
    リスクを本当に除去・回避する活動に集中しませんか？。

    • ① CIAとは
    • ② CIAの細かい点数付けの良さと課題点
    • ③ 【提言】CIAリスクアセスメントの評価は2段階がよい

    ① CIAとは

    CIAは情報セキュリティで最も大事な概念で、最初に覚える用語ですよね！

    CIAとは

    1. C（Confidentiality）＝機密性
      情報が漏れたらどれだけ影響があるか
    2. I（Integrity）＝完全性
      改ざんされたらどれだけ影響があるか
    3. A（Availability）＝可用性
      利用できなくなったらどれだけ影響があるか

    情報セキュリティの【基本のキ】ですね。

    CIAの影響度合いを点数付け

    CIAが重要な理由は

    1. リスクアセスメントの項目
    2. 情報セキュリティ計画や目標
    3. 内部監査、外部審査での評価対象
    4. マネジメントレビューでのフォロー対象
    5. 事業継続計画を考える上での重要な変数
    6. 情報資産台帳での個々の資産のCIA評価に必須

    など、CIAが出てくる場面がたくさんあります。

    ② CIAの細かい点数付けの良さと課題点

    あなたの組織でのCIA評価はどうなっていますか？

    3段階、5段階評価が一般的

    おそらく、3段階または5段階が一般的です。

    ★5段階の場合

    影響度 内容
    1 影響ほぼなし
    2 小さい影響
    3 中程度の影響
    4 大きな影響
    5 重大な影響
    (業務停止レベル)

    ★3段階の場合

    影響度 内容
    1 影響ほぼなし
    2 中程度の影響
    3 重大な影響
    (業務停止レベル)

    よくあるパターンですよね！

    リスク値の評価方法

    説明できる理由でれば、
    どの計算式でリスク値を求めてもOK

    よくあるのが、

    リスク値= C × I × A
    ●5段階の場合は　リスク値の値域：1～125(=\(5^3\))
    ●3段階の場合は　リスク値の値域：1～275(=\(3^3\))

    となります。

    リスクのしきい値でリスク評価

    計算したリスク値から
    しきい値を設定して
    リスクの高低を決めます。

    例えば５段階の場合

    ●リスク値が80以上なら「高」
    ●リスク値が20～79までなら「中」
    ●リスク値が19以下なら「低」
    とし
    「高」「中」についてリスク管理を実施していく。
    とよく考えますよね。

    3段階、5段階評価の良さ

    段階数がある程度あると、

    1. 細分され、柔軟な評価ができ、多くの人から賛同が得られやすい
    2. 事業特性に反映した評価ができる
    3. リスク分布が滑らかで、分析しやすい

    などが挙げられますが、

    一番のメリットは
    「安心感」ではないでしょうか。

    3段階、5段階評価の課題

    一方、課題や問題点もあります。

    1. 区分が多いと評価基準が複雑になる
    2. 評価・分析に手間・時間がかかる
    3. 点数の値の吟味や、項目の洗い出しなどで意見一致が大変

    などが挙げられますが、

    一番のデメリットは
    手間がかかりすぎて、手段が目的化しがちになる。

    CIAによるリスク評価の目的は、

    リスクを見つけて、それを除去すること

    あいまいにリスク高いものを、
    それなりのリスクに低減しても
    リスクが残っている以上、リスクであり、
    リスク対処したとは言えません。

    ③ 【提言】CIAリスクアセスメントの評価は2段階がよい

    本記事で、はっきり言います。

    2段階評価にしてはどうか？
    そしてリスク対応は「リスクを無くす」ことだけに集中するはどうか？

    ちょっと大胆であり、組織のメンバーやISMS審査官からクレームがあるかもしれません。

    2段階評価でもそれなりに手間

    2段階評価にして
    CIA　リスク値=1～8で評価
    リスク対応は「リスクをなくす」施策とし、すべてとりかかる！

    として、実際組織のリスクアセスメントシートを作ってみました。

    5段階の1～125
    3段階の1～27に比べ はリスク値の値域は大幅に狭くなる！
    でも
    それなりに手間がかかるし、
    2段階くらいにしておかないと
    組織のISMSは機能していないのではないか？
    と思ってしまう。。。

    ISMSの運用ははっきり言って、「大変！」です。

    2段階評価で作ったリスクアセスメント表

    リスクアセスメント表の例を挙げてみます。

    上図の例では、

    1. C,I,Aはそれぞれ2段階で評価した
    2. リスク評価は「高」(4点以上)、「低」(4点未満)の2段階とした
    3. リスク対応は容易ではないが、リスク「高」⇒「低」に下がるまで行動を実施する
    4. 2段階でリスクアセスメントは楽にならず、手間がかかる
    5. 2段階は「有無」の決着がはっきりつくのでわかりやすい

    リスク評価値は
    ●1×1×1=1 (リスク低)
    ●1×1×2=2 (リスク低)
    ●1×2×2=4 (リスク高)
    ●2×2×2=8 (リスク高)
    の５つしかないため、リスク評価も「高」「低」の２段階で十分となります。

    実際に作ってわかりました。

    2段階評価ではデメリットを突く意見もある

    2段階は「シンプル」で「はっきり」する良さもありますが、
    ●中程度のリスク評価が欲しい！
    ●監査で雑な区分と指摘される！
    ●段階的な改善が見れるにしてほしい！
    などの反論も受けやすいです。

    リスク評価と行動を経験した上で、評価段階数を決めよう

    CIAの評価数の決め方に賛否両論がありますが、決める道しるべは、

    ●どこかの組織がやっているからそれを真似る
    ではなく
    ●実際にリスク評価とリスク行動と除去した経験を得た上で、
    あなたの組織に合う評価数を決めてください。

    今回は、「2段階」の良さを提言しました。

    まとめ

    以上、「【提言】CIAリスクアセスメントの評価は2段階がよい」を解説しました。

    • ① CIAとは
    • ② CIAの細かい点数付けの良さと課題点
    • ③ 【提言】CIAリスクアセスメントの評価は2段階がよい
  • 【ISO27001 2022 6.1】 ISMS　計画がわかる

    【ISO27001 2022 6.1】 ISMS　計画がわかる

    ★ 本記事のテーマ

    ISMS　計画がわかる

    ISMS 計画（情報セキュリティ計画）の重要なポイントをわかりやすく解説します。

    • ① 方針(ポリシー)とリスクアセスメントとの関係をおさえる
    • ② ISMS　計画がわかる
    • ③ ISMS　計画の年間活用方法

    ① 方針(ポリシー)とリスクアセスメントとの関係をおさえる

    ISMSには、似たような文書があります。
    相互の関係性、整合性をおさえることが重要です。

    1. 情報セキュリティ方針(ポリシー)
    2. 情報セキュリティリスクアセスメント
    3. ISMS　計画(情報セキュリティ計画)

    互いに整合させると全体感が見えない

    活用方法が異なりますが、違うものとして扱うと、

    ・情報セキュリティ方針(ポリシー)と
    ・情報セキュリティリスクアセスメントと
    ・ISMS　計画(情報セキュリティ計画)
    は何が違うのか？
    互いに整合性をおさえたいが
    どう同じでどう違って、どう扱えばいい？

    と混乱します。

    つまり、

    ・情報セキュリティ方針(ポリシー)と
    ・ISMS　計画(情報セキュリティ計画)
    は整合性が合うように計画書を作る！

    そして、

    ・要求事項6.1.1 ISMS　計画(情報セキュリティ計画)と
    ・要求事項 6.1.2 情報セキュリティリスクアセスメントも
    は整合性が合うように計画書を作る！

    となりますよね。

    すると、

    ・情報セキュリティ方針(ポリシー)と
    ・要求事項 6.1.2 情報セキュリティリスクアセスメントも
    は整合性が合いそうだけど、
    互いにどんな関係？

    となりますよね。ここって、
    あまり解説されていないので迷ってしまいます。

    ここで、注意したいのは、

    ①情報セキュリティ方針(ポリシー)とISMS　計画
    ②情報セキュリティリスクアセスメントとISMS　計画
    とそれぞれ対応を考えていると二度手間で煩雑＆難解になります。

    全体感で考える

    なので、

    ・情報セキュリティ方針(ポリシー)と
    ・情報セキュリティリスクアセスメントと
    ・ISMS　計画(情報セキュリティ計画)
    は１セットで考える

    すると、先の疑問が湧きますので、
    ３つの関係性を解説します。

    まず、

    ・情報セキュリティ方針(ポリシー)と
    ・情報セキュリティリスクアセスメントと
    ・ISMS　計画(情報セキュリティ計画)
    はどれもリスク対策であること

    この共通点は当たり前ですね。

    あえてそれぞれのテーマ、文書としてあるので、何がちがうのでしょうか？

    それは

    情報セキュリティ方針(ポリシー)は
    【対外】、【対内】の両方の内容がある。

    方針の例として、

    1. 社外に対する宣言がある【対外】
    2. 社内で実施する宣言がある(対内)

    がありますね。
    確かに、【対外】、【対内】の両方があります。

    一方、

    情報セキュリティリスクアセスメントは
    【対内】の内容のみである。

    内外の影響から自分たちにとってどんなリスクがあるかを洗い出す性質があるので、
    【対内】のみとなります。

    以上から、下の関係図でまとめることができます。

    この図から、関係性がよくわかりますね。

    ② ISMS　計画がわかる

    具体的に、計画表を作ってみましょう。

    計画へのインプット情報

    「① 方針(ポリシー)とリスクアセスメントとの関係をおさえる」
    で述べた通り、

    情報セキュリティ方針(ポリシー)と
    情報セキュリティリスクアセスメント
    のリスク情報がインプットとなります。

    これは確かにそうですが、

    実際は、
    情報セキュリティ方針(ポリシー)と
    情報セキュリティリスクアセスメント
    情報セキュリティ計画
    の作成を同時に進めながら、インプット情報の精度を高めていきます。

    ISO9001　品質目標のように考えてもよい

    ISMSを取り掛かる人の中で、
    QMS(品質マネジメントシステム)、ISO9001も
    取り掛かる人もいるでしょう。

    QCプラネッツもそうです。

    品質方針(ポリシー)⇔情報セキュリティ方針(ポリシー)
    品質目標⇔情報セキュリティ計画
    QMSリスクアセスメント⇔情報セキュリティリスクアセスメント
    と対応して考えるとわかりやすいです。

    同じ組織、会社でマネジメントシステムを回すならなおさらだと思います。

    計画の例(アウトプット)

    例を出します。

    計画事例を挙げました。
    次に活用のポイントを解説します。

    ③ ISMS計画の年間活用方法

    まず、一番大事なことは

    計画の目的をおさえること

    情報セキュリティ計画を管理する上で、
    管理が目的化するのではなく、
    あなたの組織に襲うリスクがないこと
    である点を忘れずに運営しましょう。

    計画から運営するポイント

    QMS、ISO9001 品質目標と似ていますが、以下のポイントで運営します。

    1. 方針、目標、リスクアセスメントの項目と
      計画の活動施策の内容は整合させること
    2. 項目の中に【対外】【対内】を色分けし、方針、リスクアセスメントと計画との関係性を確認すること
    3. 各活動施策の評価・メトリックは数値化できるものとする
    4. 結果から有効性評価を行い、次年度の計画やマネジメントレビュー報告につなげること

    その他、【社外秘】（文書のセキュリティレベル）や
    変更履歴
    承認回付
    もあります。

    計画の事例を挙げました。
    ISMSはルールが煩雑で
    書類が多くなる傾向があり、
    それぞれの要素感の整合性を合わせる必要がある
    など、運営を難しくなる傾向が強いです。

    だからこそ、ISMSの各要素の整合性を確実にし、
    統合できるところは統合し、簡素化する工夫が重要です。

    計画も簡素化し、計画から実行・評価につなげ、
    ISMSリスクをあなたの組織から排除できることが一番大事です。

    まとめ

    以上、「ISMS　計画がわかる」を解説しました。

    • ① 方針(ポリシー)とリスクアセスメントとの関係をおさえる
    • ② ISMS　計画がわかる
    • ③ ISMS　計画の年間活用方法
  • ISMS,ISO27001　運用する組織に必要な規程が何かがわかる

    ISMS,ISO27001　運用する組織に必要な規程が何かがわかる

    ★ 本記事のテーマ

    ISMS,ISO27001　運用する組織に必要な規程が何かがわかる
    情報セキュリティ(ISMS)を運用する組織に
    必要な規程をあれこれ盛り込むと
    大変です！
    とはいっても、
    要求事項が多い情報セキュリティに
    規程は重要です！

    本ブログは、規程群はシンプルにし、
    組織運営が円滑になるポイントをわかりやすく解説します。

    • ① 規程の数は最小限にとどめる
    • ② QMSと比較するとISMSの規程は作りやすい
    • ③ ISMSの規程群の構成・特徴
    • ④ ISO27001 2022要求事項・管理策に乗せると作りやすい

    ① 規程の数は最小限にとどめる

    ISO27001 2022を例に
    34の要求事項と93 の管理策
    を網羅する規程が必須です。
    –

    でも、
    規程は全部でいくつ必要？

    １つの要求事項に１規程とすると133個になり、

    組織が回りません。。。絶対！　無理ゲーです！

    なので、

    組織が回すために
    最小限の規程数としましょう。

    ② QMSと比較するとISMSの規程は作りやすい

    QCプラネッツはQMSからマネジメントシステムを学んでいますが

    QMSと比較してみると、ISMSの規程の作り方のヒントがわかります。

    組織が必要とするQMSの規程とは

    QMS（品質マネジメントシステム）を運用している組織では、
    大同小異ありますが、下の表の規程群でまとめられていると思います。

    ここで、設計、製造、検査部門の個別の規程は不含とし、
    本社、事業部全体のQMS規程を列挙しました。

    QMSも面倒ですが、
    10数個の規程しかないことがわかります。

    組織が必要とするISMSの規程とは

    QMSを参考にすると、

    ISMSも
    10数個の規程にしぼらないと
    組織運営が厳しいことがわかります。

    ただし、

    QMS： ISO9001 2015　要求事項は30個程度
    ISMS：ISO27001 2022　要求事項＋管理策=130個程度
    と4倍の違いがあります。
    ISMSの規程は
    1つの規程でなるべく多くの
    ISO27001 2022　要求事項、管理策の内容を
    含めておく必要があります。

    それも、

    内容を統体して、
    少ない規程情報でなるべく多くの
    ISO27001 2022　要求事項、管理策の内容を
    含めるよう努力しましょう。

    QMS規程とISMS規程を比較

    組織が円滑に運用できるための、最小限のISMS規程をまとめると下表を考えることができます。

    もちろん

    • QMSとISMSで共通あるいは似通った規程
    • QMS単独の規程
    • ISMS単独の規程

    がそれぞれあります。

    ③ ISMSの規程群の構成・特徴

    ISMSに必要な規程群についてみていきましょう。

    組織が必要とするISMSの規程とは

    ★まず自分で考えてみよう！

    ルールを決めなければいけないものを列挙すると

    • 情報セキュリティポリシー・方針
    • 情報セキュリティ目標
    • 情報セキュリティの年間活動
    • 情報セキュリティマニュアル
    • 組織の責任と権限
    • 力量管理
    • 監査(内部監査、第２者監査、外部審査)
    • アクセス権限の管理
    • 法規制関係
    • セキュリティ事故(インシデント)対応

    が思い浮かぶはずです。これは、情報セキュリティの専門知識が無くても、
    セキュリティ（防御）に必要な項目を考えたらわかるものですね。

    ★ISO27001 2022要求事項を見てみよう

    次に、以下の２つを検討します。

    • 要求事項＋管理策から必要な規程を探すこと
    • それぞれの規程にどの要求事項＋管理策を盛り込むかを考えること

    要求事項＋管理策から必要な規程を探すと

    • 事業継続
      (QMSよりISMSの方が深刻だから)
    • 物理的・環境的管理
      (管理策7にあり、比較的理解しやすい)
    • リスクマネジメント管理
      (リスクアセスメント運営を重視するため)

    についての規程が追加で必要とわかります。

    内容を統体して、
    少ない規程情報でなるべく多くの
    ISO27001 2022　要求事項、管理策の内容を
    含めるよう努力しましょう。
    となります。

    ④ ISO27001 2022要求事項・管理策に乗せると作りやすい

    実際に組織に合うISMS規程群を作ってみましょう。

    ISMSの組織運営のための規程群

    ISMSの組織運営のための規程群は

    • QMSをヒントに最小限の規程群にする
    • 要求事項＋管理策からISMS個別の規程群を盛り込む
    • 規程の内容は少な目であるが、要求事項＋管理策を網羅するように、細かくではなく内容を統体して書く

    とＱＣプラネッツから提唱しました。

    ISMSの規程群の作り方

    下図のように、

    • 必要最低限のISMS規程を一回作る。
    • 個別の「要求事項＋管理策」に合う規程を探し割り当てる。
    • 「要求事項＋管理策」に合わせるが、どうしても個別の規程が必要な場合は、規程を増やす
    • 「要求事項＋管理策」のうち、複数の事項が１つにまとめることができる場合は、なるべくまとめる。まとめるために規程内容が少々抽象化してもよい。
    • 「要求事項＋管理策」が全て入り切るまで何度も見直す

    結構大変で何度もフィードバックや修正が必要な作業になります。

    ISMSの規程群の例（ＱＣプラネッツ）

    QCプラネッツも実際に作ってみた規程群を例に
    「要求事項＋管理策」との関係図も紹介します。

    【リンク】ＱＣプラネッツのISMS規程群

    いかがでしょうか？

    ISMSの規程群を作る裏側はめったに紹介されませんが、
    ここがISMSを有効に組織運営する大事なポイントです！

    実際に規程群を泥臭く作ってみて実感しましたので、解説しました！

    ISMSって結構泥臭い仕事

    情報セキュリティのマネジメントシステムは
    情報セキュリティの専門性の高さより
    組織全体が目的に向かって進むために
    いろいろ泥臭いことです。

    情報セキュリティの専門の高さが高ければISMS,ISO27001が回せると思われがちですが、

    組織の各メンバーが情報セキュリティに求められる行動をキチンと実行するかを監視したり、動機づけたりする方にエネルギーを集中すべきです。

    ISMSを自力で構築（書類群をつくってみて）わかりました。

    逆にいれば、
    ソフトウェアや情報セキュリティが苦手でも、
    組織運営を支える泥臭い仕事が好きであれば
    ISMS,ISO27001は回せると言えます。

    まとめ

    以上、「ISMS,ISO27001　運用する組織に必要な規程が何かがわかる」を解説しました。

    • ① 規程の数は最小限にとどめる
    • ② QMSと比較するとISMSの規程は作りやすい
    • ③ ISMSの規程群の構成・特徴
    • ④ ISO27001 2022要求事項・管理策に乗せると作りやすい
  • 【シンプルがベスト！】 ISMS,ISO27001リスクアセスメントがわかる

    【シンプルがベスト！】 ISMS,ISO27001リスクアセスメントがわかる

    ★ 本記事のテーマ

    ISMS,ISO27001リスクアセスメントがわかる
    リスクアセスメント表を
    「MECE(もれなくかぶれなく)」 かつ「シンプル」
    作らないと目的達成ができません
    リスクアセスメントで疲弊しないためのコツを解説します！

    実際に「リスクアセスメント表」を作成して、わかった重要なポイントを解説します。

    • ① 自分の首をしめがちなリスクアセスメント表
    • ② 【重要】リスクアセスメント表の作り方を解説！
    • ③ リスクアセスメントの目的はシンプルに「リスクを除去」すること

    ① 自分の首をしめがちなリスクアセスメント表

    「リスクアセスメントは疲れる！」となっていませんか？

    ISMSに限らず、マネジメントシステムでは、リスクを特定することが重要で、よくアセスメント表を作ります。

    でも、重要と分かっていても「いいイメージ」ないですよね！

    よくあるISMSリスクアセスメント表

    よくあるISMSリスクアセスメント表を図にしてみます。
    あなたの組織やあなたが担当するリスクアセスメント表も似たものではないでしょうか？

    リスクアセスメント表の問題点

    上図のリスクアセスメント表は

    問題だらけで、
    作り直した方がよいでしょう。

    なぜか？
    理由は簡単です！

    このリスクアセスメント表を活用したいですか？
    「Ｎｏ！」と思いますよね！
    それが理由です！

    ではどこが、いやと思うところかを解説します！

    ★ リスクアセスメント表の課題

    図でまとめましたが、

    1. 脅威やリスクを挙げるとき、
      MECEかつ粒度をそろえないから、
      読み手が「なぜ？」と思いながらの活用      することになる
    2. 項目がMECEかつ粒度がバラバラなため、
      100個近くの項目と拡大しがち      。
      100個もリスク対応はやってられない。
    3. 課題と施策が単に裏返しで終わると、
      根本的な解決にならない。
    4. 点数付けに手間をかけるが、
      その値に意味はそもそもない。
    5. リスク対応として「受容」、「回避」、「低減」など、
      あいまいなレベルを入れがち。
      本来「除去」以外必要か？

    なので、

    「あるべき」リスクアセスメント表とはどういうものかを考える必要があります。

    ② 【重要】リスクアセスメント表の作り方を解説！

    QCプラネッツがおススメな「リスクアセスメント表」の作り方を解説します。

    リスクアセスメントは最もsimpleであれ！

    簡単です！

    ありがちなリスクアセスメント表の課題を解決すればよいのです。
    1. 脅威やリスクの項目化はMECEかつ粒度をそろえる
    2. 項目がMECEかつ粒度を維持しつつ最小限に抑える
    3. 課題を解決する施策を考える
    4. リスクレベルを最小限にする。

    何と言っても

    リスクアセスメントは最もsimpleであれ！

    です。

    よく、リスクレベルは「高」、「中」、「低」と三段階にしますが、
    ＱＣプラネッツからおススメしたいのは

    リスクレベルは「高」、「低」の2段階にしてはいかがでしょうか？

    そもそも、

    リスクは「有無」の2つしかないし、
    リスクが有れば、無くすことが重要だし、それ以外の活動は要らない。

    くらいの割り切りが重要です。

    リスクをMECEかつシンプルに分ける

    情報セキュリティにおけるリスクをMECEかつシンプルに分けてみます。ここは、クリティカルシンキングが得意な人が担当するとベターです。

    チームで決めたとか、上司の顔色伺うと、
    自分の首を絞めるリスクアセスメント表になるので要注意です。

    先ほどの、「よくあるしんどいリスクアセスメント表」では、リスク項目が次の16になっていました。

    1. 自然災害
    2. 火災
    3. 停電
    4. 断水
    5. ハードウェアの故障
    6. ネットワーク構成要素の技術的障害
    7. 操作ミス
    8. 保守的エラー
    9. 資源の誤用
    10. 盗難
    11. 記憶媒体の不正使用
    12. 不正な方法でのソフトウェア使用
    13. 悪意のあるソフトウェア
    14. 不正なユーザによるネットワークへのアクセス
    15. 不正な方法でのネットワーク設備の使用
    16. 違法行為

    いかがでしょうか

    リスクを項目に分けるにしては、
    違和感があります。
    MECE(漏れかぶれ)でないし、粒度もあっていないから

    ＱＣプラネッツも見た瞬間、思考停止になりました。

    この表では表を管理するだけで精一杯で、
    組織の情報セキュリティ対策まで
    効果が出せるとは思えません。

    ★16個の項目の問題点

    1. 「自然災害」、「火災」、「停電」、「断水」とあるが、
      「火災、停電、断水」は自然災害？人災？どちらとも読める。
    2. 「操作ミス」と「保守的エラー」は
      何が違う？同じ？
      同じ場合もあるのでは？

      3. 「記憶媒体の不正使用」、
      「不正な方法でのソフトウェア使用」、
      「悪意のあるソフトウェア」、
      「不正なユーザによるネットワークへのアクセス」
      「不正な方法でのネットワーク設備の使用」は
      その下にある
      「違法行為」と何が違う？同じ？

    3. などなど…

    といろいろツッコミ所があると、リスクアセスメント表は使いたくないとなるはず。

    ★リスクの分け方をＱＣプラネッツが提唱

    リスクを層別していくと、次の項目分けを提唱します。

    いかがでしょうか？

    1. MECEかつシンプルに層別した
    2. 層別すると8種類で済む
    3. 情報セキュリティのリスクは最終的には
      「情報破壊」と「情報漏洩」の２つである
    4. この層別で、「各リスク項目を列挙」しても、
      少ない項目で網羅的にリスク対策ができる
      (100項目にはならないはず)

    リスクアセスメント表を提唱

    先程、提唱したリスクアセスメント表をさらに書くと下表になります。

    さらに、リスク前後は
    3段階ではなく、2段階の
    「高」と「低」だけとしてはいかがでしょうか？

    どうでしょうか？

    シンプルなわりに、網羅性の高いリスクアセスメント表と考えています。

    是非、活用してみてください。

    ③ リスクアセスメントの目的はシンプルに「リスクを除去」すること

    リスク評価・レベルは最小限でいい

    リスク評価は、

    1. リスク受容
    2. リスク回避
    3. リスク低減
    4. リスク除去

    など、いろいろありますが、

    「リスク除去」
    の１本立てでよいと考えますし、
    リスクレベルは「高」と「低」
    の２つでよいでしょう。

    リスクアセスメントの目的を見失うな！

    いろいろな声を聴いて
    たくさんあるリスク評価や
    3以上あるリスクレベル
    になる気持ちは十分わかりますが、

    煩雑になるとISMS,ISO27001を有効に運用できなくなります。

    他のマネジメントシステムより要求が多く、
    煩雑になりがちな情報セキュリティだからこそ
    １つ１つの対応はシンプルを追求しましょう。

    リスクアセスメントですが、

    リスクを除去すること。
    煩雑なリスクアセスメント表に飲まれてはいけない！
    リスク除去できればシンプルなアセスメントで十分！

    手段が目的化するという履き違いがよく発生するところです。

    まとめ

    以上、「ISMS,ISO27001リスクアセスメントがわかる」を解説しました。

    • ① 自分の首をしめがちなリスクアセスメント表
    • ② 【重要】リスクアセスメント表の作り方を解説！
    • ③ リスクアセスメントの目的はシンプルに「リスクを除去」すること
  • 【重要】ISO27001 2022要求事項がわかる

    【重要】ISO27001 2022要求事項がわかる

    ★ 本記事のテーマ

    ISO27001 2022要求事項がわかる！
    ISO9001 2015と比較しながら
    ISO27001 2022の要求事項を学びましょう。
    • ① ISO9001 2015と比較してISO27001 2022を学ぶ
    • ② ISO9001 2015要求事項を復習
    • ③ ISO27001要求事項を学ぶポイント

    ① ISO9001 2015と比較してISO27001 2022を学ぶ

    マネジメントシステムは共通要素が多い

    (JQA引用 https://www.jqa.jp/service_list/management/iso_info/iso_network/vol26/article01/)

    実は、

    どちらもマネジメントシステムなので
    ほとんど内容が同じ

    極端に言えば、ISO9001 2015をマスターしていれば、他のマネジメントシステムもそれなりにできてしまう。

    なので、

    マネジメントシステムのベースである
    ISO9001 2015を軸にISO27001 2022を
    学ぶと、わかりやすいし、
    両方の要求事項が手に入る！

    ISO9001 2015とISO27001 2022の要求事項を比較

    ISO9001 2015とISO27001 2022の要求事項を比較しましょう。下表のとおりです。

    要求事項 ISO9001 2015 ISO27001
    1 – 適用範囲 適用範囲
    2 – 引用規格 引用規格
    3 – 用語及び定義 用語及び定義
    4 – 組織の状況 組織の状況
    – 4.1 組織及びその状況の理解 組織及びその状況の理解
    – 4.2 利害関係者のニーズ及び期待の理解 利害関係者のニーズ及び期待の理解
    – 4.3 品質マネジメントシステムの適用範囲の決定 情報セキュリティマネジメントシステムの適用範囲の決定
    – 4.4 品質マネジメントシステム及びそのプロセス 情報セキュリティマネジメントシステム
    5 – リーダシップ リーダシップ
    – 5.1 リーダシップ及びコミットメント リーダシップ及びコミットメント
    – 5.2 方針 方針
    – 5.3 組織の役割、責任及び権限 組織の役割、責任及び権限
    6 – 計画 計画策定
    – 6.1 リスク及び機会への取組み リスク及び機会に対する活動
    – – – 6.1.2 情報セキュリティリスクアセスメント
    – – – 6.1.3 情報セキュリティリスク対応
    – 6.2 品質目標及びそれを達成するための計画策定 情報セキュリティ目的及びそれを達成するための計画策定
    – 6.3 変更の計画 変更の計画策定
    7 – 支援 支援
    – 7.1 資源 資源
    – 7.2 力量 力量
    – 7.3 認識 認識
    – 7.4 コミュニケーション コミュニケーション
    – 7.5 文書化した情報 文書化した情報
    8 – 運用 運用
    – 8.1 運用の計画及び管理 運用の計画策定及び管理
    – 8.2 製品及びサービスに関する要求事項 情報セキュリティリスクアセスメント
    – 8.3 製品及びサービスの設計・開発 情報セキュリティリスク対応
    – 8.4 外部から提供されるプロセス、製品及びサービスの管理 –
    – 8.5 製造及びサービス提供 –
    – 8.6 製品及びサービスのリリース –
    – 8.7 不適合なアウトプットの管理 –
    9 – パフォーマンス評価 パフォーマンス評価
    – 9.1 監視、測定、分析及び評価 監視、測定、分析及び評価
    – 9.2 内部監査 内部監査
    – 9.3 マネジメントレビュー マネジメントレビュー
    10 – 改善 改善
    – 10.1 一般 継続的改善
    – 10.2 不適合及び是正処置 不適合及び是正処置
    – 10.3 継続的改善 –
    附属書A – 管理策(93個)
    黄色枠がISO9001とISO27001の相違点です。それ以外は同じ要求事項であることがわかりますね。

    ★要求事項の相違点

    1. ISO9001は品質目標、ISO27001はリスクアセスメントが中心である点
    2. ISO9001の「8.運用」はプロセスごとに要求事項が異なるが、ISO27001は全プロセス統合している点
    3. ISO9001は管理策には要求事項はないが、ISO27001は93個の管理策も要求事

    3点だけ違うことがわかれば、ISO9001からISO27001へと習得するのが効率がよいと言えます。

    ISO9001とISO27001のさらなる相違点

    要求事項は大きく３点異なることを解説しました。その他、ISOを組織に運営する中で、気にかけておくべき相違点を解説します。

    ★相違点

    両者の要求事項を運用していくと、以下の違いがあります。

    項目 ISO9001 2015 ISO27001
    原則 リスク低減も機会向上とマイナス面もプラス面も見る リスク低減のみ（マイナス面のみ）
    要求事項 運用（プロセス）によって箇条4～10で除外してよいものがある。 汎用的であり、箇条4～10のいかなる要求事項も除外できない
    中心軸 品質目標が中心 情報セキュリティ目標よりリスクアセスメントが軸
    目標項目 数値目標が立てやすい(顧客満足、教育、品質トラブル、品質コスト） 数値目標が立てにくい(事故件数、教育受講率くらいしかない）

    大事なのは、

    ISO9001 2015も
    ISO27001 2022も
    解決すべき課題・リスクをコントロールして
    あなたの組織のあるべき姿・目標に向かうことです。

    そして、

    ISO9001 2015と
    ISO27001 2022は
    共通要素を最初に理解して、
    個別の個性を知っていくことです。

    ISO9001(QMS)もISO27001(ISMS)も両方マスターしましょう。

    ② ISO9001 2015要求事項を復習

    ISO27001のベースとなるISO9001を先に習得しよう！

    QCプラネッツはソフトウェアが苦手だからかもしれませんが、

    いきなりISO27001に入るより、
    一旦ISO9001から学んだ方がよい。

    その理由は、

    1. ISO9001はISOすべてのマネジメントシステムのベースだから。
    2. ISO9001とISO27001の共通要素は多いから。
    3. ISO14001などの他のマネジメントシステムへの応用が効きやすいから。

    ISO9001ならＱＣプラネッツにおかませください！

    ISO9001 2015についてはＱＣプラネッツの人気ブログがあります。たくさんの方に見ていただいております。是非復習しましょう！

    ISO9001_2015_まとめ 【ISO9001 2015がわかる】
    ISO9001 2015の要求事項を、暗記に走らず、理解して自分の言葉で説明できるように、実務経験から重要ポイントをわかりやすく解説！

    全要求事項をわかりやすく解説しており、さらに、内部監査・外部審査のポイント、内部監査養成へのポイントもＱＣプラネッツのサイトでまとめています。

    マネジメントシステム全体像

    まずは、PDCAサイクルとISOマネジメントシステムとの関連をおさえましょう。

    品質マネジメントシステム

    先ほどのリンクの【ISO9001 2015がわかる】記事にあるとおり、PDCAサイクルをしっかりおさえておきましょう。

    ③ ISO27001要求事項を学ぶポイント

    ここまで、読めば、

    ISO9001から、
    リスクアセスメントを加えて、
    運用の各プロセスを統合すれば
    ISO27001になる

    とわかります。

    ソフトウェア、情報セキュリティの
    知識やノウハウがなくても、
    ISO27001は理解できてしまう。

    ともいえます。

    品質マネジメントシステム

    でも、それだけでは
    ・専門知識やノウハウがないことが相手にばれてしまう。
    ・自信もってISO27001が運用できない。
    ・リスクアセスメント・情報目録が煩雑になりそうで、運用が面倒くさい。
    ・特に煩雑な「管理策」への対策が不十分で困っている。

    あたりが、不安要素になるでしょう。

    ISO27001 2022の初心者が習得すべき方法

    ISO27001を始めることは特に、


    ・ソフトウェア、情報セキュリティを始めたばかり。
    ・管理策への対策。

    の2点が、大きなハードルと思います。
    (その次は「リスクアセスメント」でしょうが、これはやればいいだけと分かってきます。）

    でも、大丈夫です！　１つずつＱＣプラネッツと解決できます！！

    ★ソフトウェアが苦手でも大丈夫！

    情報セキュリティは基本、カタカナが多いソフトウェア領域で、得意な人もいれば、苦手な人もいます。

    情報セキュリティは得意不得意関係なく大事なので、苦手な人はどうやって攻略するか？悩むはずです。

    そこで、ＱＣプラネッツがその攻略法を解説しました。関連記事を読んでください。

    情報セキュリティは重要とわかるけど、ソフトウェア領域が苦手なあなたに、是非読んでほしい攻略法です！

    ★管理策をどうやってものにするか？

    ISO9001にはない、「管理策」。要求事項と同様に要求されますが、数が多く、粒度もばらばらで理解や習得が難しいです。

    QCプラネッツが編み出した攻略法は、

    マネジメントシステムなのだから、メインは要求事項。だったら管理策を無理矢理でも、要求事項に組み込んで、同時に見ていけば習得しやすいはず

    詳しくは、関連記事を読んでください。

    93個もあり、まとめにくい管理策は
    要求事項に組み込めば、マスターできる必殺技を伝授します！

    ★手元に置いておきたい管理策の運用マニュアル

    管理策は暗記不要で、後から見るべきものとわかるはずです。とはいえ、数行しかない管理策から何を注意して要求を満たせばよいかの勘所がわかりませんよね。

    また、確認頻度も高いので、

    手元に置いて、すぐに確認ができ、勘所も書いてあるマニュアルがほしい

    と思い、関連記事を作りました。読んで下さい。

    93個あるISO27001 2022管理策を上手に活用できる方法を伝授します！

    ここまで来れば、
    ISO27001の攻略方法は、
    (1) 要求事項の全体像はISO9001をベースでよく、
    (2) ISO27001学習の初期に悩みやすい、
    ・情報セキュリティの基礎
    ・管理策への対応
    への対処方法がわかり、自信がついたと思います。

    あとは、個別の細かいところを１つずつ習得していけば、ISO9001,ISO27001両方マスターできます。

    細かいところもＱＣプラネッツがわかりやすく解説していきます。

    まとめ

    以上、「ISO27001 2022管理策がわかる！」を解説しました。

    • ① ISO9001 2015と比較してISO27001 2022を学ぶ
    • ② ISO9001 2015要求事項を復習
    • ③ ISO27001要求事項を学ぶポイント
  • 【重要】ISO27001 2022管理策がわかる！

    【重要】ISO27001 2022管理策がわかる！

    ★ 本記事のテーマ

    【重要】ISO27001 2022管理策がわかる！
    ISO27001 2022管理策の
    大事なポイントと
    業務、運用、監査に活かせるポイントを
    まとめた教科書を作りました！

    手元にあるとうれしい本書です。

    • ①管理策の習得が難しくて悩んでいませんか？
    • ②QCプラネッツが【わかる！管理策教科書】を作りました！
    • ③【本書ご購入方法】

    ①管理策の習得が難しくて悩んでいませんか？

    管理策をどう攻略するかがISO27001ではキーとなります。

    理由をいくつか挙げると、

    1. 管理策が93個もあり、多すぎ!
    2. 個々の管理策の要求事項が簡素であり、具体的に何をしたらよいか迷う。
    3. ソフトウェアや情報セキュリティ分野が苦手である。
    4. 運用するために暗記したいが覚えられず困る。
    5. ユーザ－からの問い合わせ、監査対応で自信もって対応できない。

    など、たくさん悩みが出てきます。

    ソフトウェアが苦手な
    QCプラネッツも同意見です。

    とはいっても、

    情報セキュリティの重要性は年々増すばかりで、自分の業務にもかかわるのも時間の問題！

    なので、

    どうすればいいのか？困る！！

    となりますよね！

    ②QCプラネッツが【わかる！管理策教科書】を作りました！

    あなたと同じ悩みをもっていたQCプラネッツから本書を紹介させていただきます。

    4点解説します。

    • (1) 作った思い
    • (2) 本書のポイント・メリット
    • (3) 本書の構成
    • (4) 本書のサンプルをご紹介

    (1) 作った思い

    もともとは、自分用にまとめたものでした。

    教科書なり、自費で受講した資料なり、色々集めて、
    自分にとってわかりやすく、活用しやすく、
    手元に持ってすぐ確認できる教科書    を
    作成しました。

    折角作ったので、

    同じ悩みを抱える多くの方々にも活用していただければと思い、本書を提案させていただきます。

    (2) 本書のポイント・メリット

    わかりやすく、活用しやすく、
    手元に持ってすぐ確認できる教科書    を意識して作りました。

    ★本書のポイント・メリット

    1. できるだけスライドの文字を減らし、ポイントを強調。
    2. 本書を活用しやすく、1管理策に1スライド。
    3. 専門用語や概念ではなく、具体的かつ分かりやすい言葉で解説。
    4. 管理策の暗記は不要で、むしろ組織のリスクとその対策を具体的に考える姿勢を重視。
    5. まず管理策全体を俯瞰し、徐々に個別の管理策の理解を深めること。
    6. すぐに読み返して、何度も読めること。

    いかがでしょうか。

    管理策への苦手意識をあまり気にせず、どなたでもマスターできる本書構成であることがわかると思います。

    そうじゃないと、QCプラネッツ自身も自信もって、ISO27001ができませんから(笑)。

    (3) 本書の構成

    全104ページあります。本書の構成をご紹介します。

    No ページ 内容
    1 1 表紙
    2 2 目次
    3 3 【はじめに】
    4 6 5．組織的管理策
    5 44 6．人的管理策
    6 53 7．物理的管理策
    7 68 8．技術的管理策
    8 103 まとめ

    (4) 本書のサンプルをご紹介

    「(2) 本書のポイント・メリット」 は本書の【はじめに】に記載しております。

    せっかくなので数ページ解説ページサンプルを紹介します。管理策は全部で93あるので、100ページ超となります。

    本当は前頁紹介したいのですが、100ページ超のため、だらだらたくさん図を張り付けても、本書の良さが活かせないので、いくつか紹介とさせていただきます。

    ★その1

    ★その2

    ★その3

    ★各ページのポイント

    1. 朱書きにて重要箇所を強調。
    2. 具体的に何が要求されているかがわかる。
    3. 求められるものやそれが無い場合の対処も解説。
    最初は「なるほど」
    2回目は「全体との関係」
    慣れてきたら「セキュリティ関連の専門用語・概念」への熟知
    ・・・
    と何度も読みながら
    情報セキュリティを究めていきましょう。

    情報セキュリティの習得方法は、

    1. 自組織でのリスク・やるべきことを考える。
    2. ISMSの全体を理解する。
    3. 慣れて自信がついてきたらソフトウェア、情報セキュリティの専門用語・概念への理解を広める。

    です。ありがちなのは、その逆の
    1.ソフトウェア、情報セキュリティの専門用語・概念を暗記
    2. ISMS,ISO27001の内容を暗記
    3.すべて覚えてから活動する
    は、

    初心者は特にくじけます。
    実用的な行動が先で専門性は後です！

    ③【本書ご購入方法】

    本ブログ、メルカリから販売しております。

    本ブログからのご購入

    ご購入いただけます。ご購入後、ＱＣプラネッツからアクセスサイト先（アクセスのみ可）をご案内いたします。データの拡散を防ぐため、ダウンロードと印刷は不可とさせていただきます。

    メルカリからのご購入

    「QCプラネッツ」で検索ください。

    noteからのご購入(近日公開予定)

    note掲載後、ここに記載させていただきます。

    よろしくお願いいたします。

    まとめ

    以上、「ISO27001 2022管理策がわかる！」を解説しました。

    <d

    • ①管理策の習得が難しくて悩んでいませんか？
    • ②QCプラネッツが【わかる！管理策教科書】を作りました！
    • ③【本書ご購入方法】
  • ソフトウェアが苦手でも情報セキュリティがよくわかる

    ソフトウェアが苦手でも情報セキュリティがよくわかる

    ★ 本記事のテーマ

    ソフトウェアが苦手でも情報セキュリティがよくわかる
    • ①情報セキュリティに苦手意識ありませんか？
    • ②ソフトウェアが苦手でも情報セキュリティはすぐ理解できる！
    • ③QCプラネッツが「わかる情報セキュリティ」の本書を作成しました！
    • ➃【本書ご購入方法】

    ①情報セキュリティに苦手意識ありませんか？

    情報セキュリティの重要さが増している

    近年はIT(情報技術)や情報通信が飛躍的に発展しています。QCプラネッツもブログを書いているのもこうした恩恵があるからです。

    しかし、一方でIT基盤を脅かす脅威も深刻化しています。そのため情報セキュリティが重要視されてきています。

    多くの企業がISMSやISO27001認証を取り、情報セキュリティリテラシー強化に向かっています。

    情報セキュリティをマスターしたいけど困っている

    QCプラネッツも然りで、

    情報セキュリティが大事だからマスターしたい!
    でも、難しくて困っている！！

    ではありませんか？

    その理由は、よくわかります。以下が「あるある」だと思います。

    1. ソフトウェアが苦手で、情報セキュリティがよくわからない
    2. 情報セキュリティに出てくる専門用語が理解できず、暗記してもすぐ忘れる
    3. 天才国際ハッカーに襲われる見えない恐怖にかられる

    などが理由でしょう。

    QCプラネッツはハードウェア寄りの思考であり、
    ソフトウェアが苦手で
    SEの仕事など（特に要件定義あたり）は何をやっているのか？
    何が面白いのか？がよくわかりません。

    とはいっても、

    毎日、PC、ネット、システムを活用して仕事している分、情報セキュリティは何とかマスターしたい!

    という気持ちはあります。せっかくの思いを空回りしないようにするにはどうすればよいか？ずっと困っていました。

    でも、解決しました。
    本ブログを読んでいただければ同じ悩みを抱えるあなたへ
    役立てられる！と自信があります。

    ②ソフトウェアが苦手でも情報セキュリティはすぐ理解できる！

    実は、ソフトウェアが苦手でも、情報セキュリティの専門用語が知らなくても、情報セキュリティはマスターできます。不思議に思うでしょう。その理由も解説していきます！

    情報セキュリティは家の防犯対策と同じ

    情報セキュリティが苦手なQCプラネッツでも、情報セキュリティ,ISMS,ISO27001をマスターするにはどんな演習問題があればよいかをいろいろ思考しました。その結果、

    家の防犯対策を考えることができたら
    情報セキュリティ,ISMS,ISO27001が手に入る！

    とわかりました。その理由は、

    家の防犯対策そのものを情報セキュリティ用語に変換すればクリアーできるから。

    なので、

    得意な人は、情報セキュリティ用語から入って良し！
    苦手な人は、防犯対策を思考演習史して良し！

    これはQCプラネッツも意外な結果がわかり、面白い！と実感しています。

    リスクを考え、対策を考える練習すれば大丈夫

    あとで本書を紹介しますが、その中で豪邸の防犯対策をたくさん列挙すると、ISO27001管理策のほとんどが網羅できました。

    となると、

    防犯対策を考える思考さえあれば
    ISMS,ISO27001の中身の暗記は不要。
    だから何も覚えなくても情報セキュリティ対策はできる！

    ③QCプラネッツが「わかる情報セキュリティ」の本書を作成しました！

    パワポ資料形式でわかりやすくまとめました。

    本書を作った思い

    1. 専門家が書く情報セキュリティは、専門用語・概念が難しい！
    2. 情報セキュリティの運用は煩雑でやりたくない！
    3. とはいっても、すべての人に情報セキュリティ対策は必須
    4. 簡単でわかりやすく学べる入門書がほしい！無いなら作ってしまおう！

    という思いで、本書を作りました。

    作ってわかったことは、

    1. 情報セキュリティの用語・概念よりあなたにとってのリスクは何か？を具体的に解ればそれでよい！
    2. 情報セキュリティ事故は、外部攻撃より内部不正・ミスによるものがほとんど。
    3. だから自分ができることだけやるだけでもかなりの情報セキュリティ対策ができる
    4. ISMS,ISO27001の内容（特にISO27001 管理策）は暗記不要。自分で考えた対策に該当するものを後であてはめればよいだけ
    5. 専門用語より自分の言葉で対策した方が周囲も理解でき、情報セキュリティ対策につながる

    本書の構成

    イメージ図です。

    「ソフトウェアが苦手でも情報セキュリティがよくわかる」ために以下の構成を考えて本書を作りました。

    1. 情報セキュリティは何に気を付けたらよいのか？を冷静に理解する。
    2. 情報セキュリティを学ぶ前に、「侵入・盗難」から家の防犯対策を演習する。(侵入・盗難する側と、それを守る側の両方の立場で考える)
    3. 防犯対策を情報セキュリティ対策に置き換える(意外とそのままでよいことがわかる)
    4. ISO27001要求事項・管理策と照らし合わせると割と網羅できることを実感できる
    5. 次は小規模オフィスのあるあるから情報セキュリティ対策を考える
    6. 家の防犯対策と同様に、小規模オフィスも自分で情報セキュリティ対策を考えることができるようになる
    7. ISO27001要求事項・管理策と照らし合わせると割と網羅できることを実感できる
    8. 専門用語・概念より自分でとるべき対策を考えること、考えてから用語・概念を合わせればよいだけ
    9. 自信がついたら、情報セキュリティの専門用語や概念を勉強してもよい

    ➃【本書ご購入方法】

    本ブログから販売しております。

    本ブログからのご購入

    ご購入いただけます。ご購入後、ＱＣプラネッツからアクセスサイト先（アクセスのみ可）をご案内いたします。データの拡散を防ぐため、ダウンロードと印刷は不可とさせていただきます。

    メルカリからのご購入

    「QCプラネッツ」で検索ください。

    noteからのご購入(近日公開予定)

    note掲載後、ここに記載させていただきます。

    よろしくお願いいたします。

    まとめ

    以上、「ソフトウェアが苦手でも情報セキュリティがよくわかる」を解説しました。

    • ①情報セキュリティに苦手意識ありませんか？
    • ②ソフトウェアが苦手でも情報セキュリティはすぐ理解できる！
    • ③QCプラネッツが「わかる情報セキュリティ」の本書を作成しました！
    • ➃【本書ご購入方法】
  • ISO27001 2022管理策は要求事項に組み込もう！

    ISO27001 2022管理策は要求事項に組み込もう！

    ★ 本記事のテーマ

    ISO27001 2022管理策は要求事項に組み込もう！
    • ①管理策への悩み
    • ②管理策は要求事項に組み込めばいい！
    • ③【結論】要求事項と管理策の対応表を活用しよう！

    ①管理策への悩み

    管理策をどう攻略するかがISO27001ではキーとなります。

    管理策への悩みあるある

    ISMS,ISO27001を勉強したり、実務で求められたりすると、絶対悩みことがあります！

    1. 93個もある管理策は覚えられない！しかも要求事項もあるし。。。
    2. 多すぎる管理項目では組織の情報セキュリティ管理が十分できず本末転倒だ！
    3. ISMS内部監査、ISO27001外部審査で、管理策全てはチェック時間的に無理！

    と思いますよね。

    管理策の対応あるある

    実際、ISO27001の審査員の講義でこういう質問すると、

    1. 93個もある管理策は覚えなくていいし、審査員も全部は覚えていない。
    2. 審査の評価の際に、ISOハンドブックをみて管理策番号を照らし合わせている。
    3. 93個のある管理策は、個別の粒度である程度はまとめることができる。それを覚えて審査にのぞんでいる。

    と回答をもらいました。

    でも、

    一瞬わかった感じになるが、
    管理策を習得した気にならない。
    職場で管理策に関する問い合わせが来ると不安だ

    と、完全に納得する感じにはなりません。

    QCプラネッツが解決します！
    秘訣を思いつきました！

    ②管理策は要求事項に組み込めばいい！

    結論のイメージ図を描きます。本記事で最も伝えたいところです。

    発想のきっかけ

    管理策攻略はＱＣプラネッツも困っています。
    とはいえ、ISO27001を学ぶ上でいくつか気づいたことがあります。

    1. 監査は長くても2～3時間。この中ですべての要求事項と管理項目の10近くを質疑するには、1個2,3分しか時間がないこと
    2. ISMS,ISO27001のベースはマネジメントシステム(MS)であり、MSがしっかり管理・運営できていることが要求されること
    3. ISO27001の要求事項4～10はISO9001とほぼ同じで、完成度が高く今後変わる可能性は低い。一方、管理策はISO27001更新のたびに変わるほど完成度が低い。重視すべきは要求事項側であること
    4. 管理策のいくつかは要求事項の内容と重複するものがあるとわかったこと

    監査演習すると、質疑は管理策より要求事項がベースであり、
    日々の情報セキュリティも組織運営が肝であり、要求事項がベースとなります。

    ISO9001をマスターしていれば、
    そこに少し情報セキュリティの内容を追加しただけでも
    それなりの監査や管理ができてしまう。

    この作戦で行けば、管理策への抵抗感はほぼありません（とＱＣプラネッツは実感しています。

    要求事項4～10の流れはISO9001,ISO14001などのマネジメントシステムと同じなのでマスターしましょう。

    ISO9001については関連記事があります。

    ISO9001_2015_まとめ ISO9001 2015の要求事項を、暗記に走らず、理解して自分の言葉で説明できるように、実務経験から重要ポイントをわかりやすく解説！

    個々の管理策に近い要求事項を当てていく

    では、93個の管理策をそれぞれ、最も近い要求事項に当てていきましょう。

    完全に一致しないところもあります。
    考えが変わって該当する要求事項も変わるでしょう。それもOKです。

    ではやってみましょう。ＱＣプラネッツは下表のとおりになりました。これが絶対正解ではありません。一例としてみてください。

    ★管理策と要求事項の対応表

    管理
    策    		 内容 – 要求
    事項    		 内容
    ー ー ⇒ 4.1 組織及びその状況の理解
    5.1 情報セキュリティのための方針群 ⇒ 5.3 責任及び権限
    5.2 情報セキュリティの役割及び責任 ⇒ 5.3 責任及び権限
    5.3 職務の分離 ⇒ 5.3 責任及び権限
    5.4 管理層の責任 ⇒ 5.3 責任及び権限
    5.5 関係当局との連絡 ⇒ 5.3 責任及び権限
    5.6 専門組織との連絡 ⇒ 5.3 責任及び権限
    5.7 脅威インテリジェンス ⇒ 4.1 組織及びその状況の理解
    5.8 プロジェクトマネジメントにおける情報セキュリティ ⇒ 9.1 監視、測定、分析及び評価
    5.9 情報及びその他の関連資産の目録 ⇒ 7.1 資源
    5.10 情報及びその他の関連資産の許容される利用 ⇒ 7.5 文書化した情報
    5.11 資産の返却 ⇒ 7.1 資源
    5.12 情報の分類 ⇒ 7.5 文書化した情報
    5.13 情報のラベル付け ⇒ 7.5 文書化した情報
    5.14 情報の転送 ⇒ 7.1 資源
    5.15 アクセス管理 ⇒ 5.3 責任及び権限
    5.16 識別情報の管理 ⇒ 5.3 責任及び権限
    5.17 認証情報 ⇒ 5.3 責任及び権限
    5.18 アクセス権 ⇒ 5.3 責任及び権限
    5.19 供給者関係における情報セキュリティ ⇒ 4.2 利害関係者のニーズ及び期待の理解
    5.20 供給者との合意における情報セキュリティの取扱い ⇒ 4.2 利害関係者のニーズ及び期待の理解
    5.21 情報通信技術(ICT)サプライチェーンにおける情報セキュリティの管理 ⇒ 4.2 利害関係者のニーズ及び期待の理解
    5.22 供給者のサービス提供の監視、レビュー及び変更管理 ⇒ 4.2 利害関係者のニーズ及び期待の理解
    5.23 クラウドサービスの利用における情報セキュリティ ⇒ 4.2 利害関係者のニーズ及び期待の理解
    5.24 情報セキュリティインシデント管理の計画策定及び準備 ⇒ 8.3 情報セキュリティリスク対応
    5.25 情報セキュリティ事象の評価及び決定 ⇒ 8.3 情報セキュリティリスク対応
    5.26 情報セキュリティインシデントへの対応 ⇒ 8.3 情報セキュリティリスク対応
    5.27 情報セキュリティインシデントからの学習 ⇒ 8.3 情報セキュリティリスク対応
    5.28 証拠の収集 ⇒ 8.3 情報セキュリティリスク対応
    5.29 事業の中断・阻害時の情報セキュリティ ⇒ 8.3 情報セキュリティリスク対応
    5.30 事業継続のためのICTの備え ⇒ 8.3 情報セキュリティリスク対応
    5.31 法令、規制及び契約上の要求事項 ⇒ 9.1 監視、測定、分析及び評価
    5.32 知的財産権 ⇒ 9.1 監視、測定、分析及び評価
    5.33 記録の保護 ⇒ 9.1 監視、測定、分析及び評価
    5.34 プライバシー及び個人識別可能情報(PII)の保護 ⇒ 9.1 監視、測定、分析及び評価
    5.35 情報セキュリティの独立したレビュー ⇒ 9.1 監視、測定、分析及び評価
    5.36 情報セキュリティのための方針群、規則及び標準の遵守 ⇒ 9.1 監視、測定、分析及び評価
    5.37 操作手順書 ⇒ 7.5 文書化した情報
    6.1 選考 ⇒ 7.1 資源
    6.2 雇用条件 ⇒ 7.1 資源
    6.3 情報セキュリティの意識向上、教育及び訓練 ⇒ 7.2 力量
    6.4 懲戒手続 ⇒ 7.1 資源
    6.5 雇用の終了又は変更後の責任 ⇒ 7.1 資源
    6.6 秘密保持契約又は守秘義務契約 ⇒ 7.3 認識
    6.7 リモートワーク ⇒ 7.1 資源
    6.8 情報セキュリティ事象の報告 ⇒ 8.3 情報セキュリティリスク対応
    7.1 物理的セキュリティ境界 ⇒ 7.1 資源
    7.2 物理的入退 ⇒ 7.1 資源
    7.3 オフィス、部屋及び施設のセキュリティ ⇒ 7.1 資源
    7.4 物理的セキュリティの監視 ⇒ 7.1 資源
    7.5 物理的及び環境的脅威からの保護 ⇒ 7.1 資源
    7.6 セキュリティを保つべき領域での作業 ⇒ 7.1 資源
    7.7 クリアデスク・クリアスクリーン ⇒ 7.1 資源
    7.8 装置の設置及び保護 ⇒ 7.1 資源
    7.9 構外にある資産のセキュリティ ⇒ 7.1 資源
    7.10 記憶媒体 ⇒ 7.1 資源
    7.11 サポートユーティリティ ⇒ 7.1 資源
    7.12 ケーブル配線のセキュリティ ⇒ 7.1 資源
    7.13 装置の保守 ⇒ 7.1 資源
    7.14 装置のセキュリティを保った処分又は再利用 ⇒ 7.1 資源
    8.1 利用者エンドポイント機器 ⇒ 5.3 責任及び権限
    8.2 特権的アクセス権 ⇒ 5.3 責任及び権限
    8.3 情報へのアクセス制限 ⇒ 5.3 責任及び権限
    8.4 ソースコードへのアクセス ⇒ 5.3 責任及び権限
    8.5 セキュリティを保った認証 ⇒ 5.3 責任及び権限
    8.6 容量・能力の管理 ⇒ 7.1 資源
    8.7 マルウェアに対する保護 ⇒ 7.1 資源
    8.8 技術的脆弱性の管理 ⇒ 7.1 資源
    8.9 構成管理 ⇒ 7.1 資源
    8.10 情報の削除 ⇒ 8.1 運用の計画策定及び管理
    8.11 データマスキング ⇒ 8.1 運用の計画策定及び管理
    8.12 データ漏洩防止 ⇒ 8.1 運用の計画策定及び管理
    8.13 情報のバックアップ ⇒ 8.1 運用の計画策定及び管理
    8.14 情報処理施設・設備の冗長性 ⇒ 8.1 運用の計画策定及び管理
    8.15 ログ取得 ⇒ 8.1 運用の計画策定及び管理
    8.16 監視活動 ⇒ 8.1 運用の計画策定及び管理
    8.17 クロックの同期 ⇒ 8.1 運用の計画策定及び管理
    8.18 特権的なユーティリティプログラムの使用 ⇒ 8.1 運用の計画策定及び管理
    8.19 運用システムへのソフトウェアの導入 ⇒ 8.1 運用の計画策定及び管理
    8.20 ネットワークセキュリティ ⇒ 8.3 情報セキュリティリスク対応
    8.21 ネットワークサービスのセキュリティ ⇒ 8.3 情報セキュリティリスク対応
    8.22 ネットワークの分離 ⇒ 8.3 情報セキュリティリスク対応
    8.23 ウェブフィルタリング ⇒ 8.3 情報セキュリティリスク対応
    8.24 暗号の利用 ⇒ 8.3 情報セキュリティリスク対応
    8.25 セキュリティに配慮した開発のライフサイクル ⇒ 9.1 監視、測定、分析及び評価
    8.26 アプリケーションセキュリティの要求事項 ⇒ 9.1 監視、測定、分析及び評価
    8.27 セキュリティに配慮したシステムアーキテクチャ及びシステム構築の原則 ⇒ 9.1 監視、測定、分析及び評価
    8.28 セキュリティに配慮したコーディング ⇒ 9.1 監視、測定、分析及び評価
    8.29 開発及び受入れにおけるセキュリティテスト ⇒ 9.1 監視、測定、分析及び評価
    8.30 外部委託による開発 ⇒ 9.1 監視、測定、分析及び評価
    8.31 開発環境、テスト環境及び本番環境の分離 ⇒ 9.1 監視、測定、分析及び評価
    8.32 変更管理 ⇒ 9.1 監視、測定、分析及び評価
    8.33 テスト用情報 ⇒ 9.1 監視、測定、分析及び評価
    8.34 監査におけるテスト中の情報システムの保護 ⇒ 9.1 監視、測定、分析及び評価
    – – ⇒ 5.1 リーダーシップ＆コミットメント
    – – ⇒ 5.2 方針
    – – ⇒ 6.1 計画策定
    – – ⇒ 6.1.2 リスクアセスメント
    – – ⇒ 7.4 コミュニケーション
    – – ⇒ 9.2 内部監査
    – – ⇒ 9.3 マネジメントレビュー
    – – ⇒ 10.1 不適合、是正処置
    – – ⇒ 10.2 継続的改善
    これは一例です。
    大事なのは考え方です。

    そして、

    上表を
    「管理策⇒要求事項」の対応から
    「要求事項⇒管理策」の対応に
    変えてみましょう。

    ③【結論】要求事項と管理策の対応表を活用しよう！

    要求事項と管理策の対応表

    是非活用してみてください。

    上表を
    「管理策⇒要求事項」の対応から
    「要求事項⇒管理策」の対応に
    変えてみましょう。
    要求
    事項    		 内容 – 管理
    策    		 内容
    4.1 組織及びその状況の理解 ⇒ ー ー
    4.1 組織及びその状況の理解 ⇒ 5.7 脅威インテリジェンス
    4.2 利害関係者のニーズ及び期待の理解 ⇒ 5.19 供給者関係における情報セキュリティ
    4.2 利害関係者のニーズ及び期待の理解 ⇒ 5.20 供給者との合意における情報セキュリティの取扱い
    4.2 利害関係者のニーズ及び期待の理解 ⇒ 5.21 情報通信技術(ICT)サプライチェーンにおける情報セキュリティの管理
    4.2 利害関係者のニーズ及び期待の理解 ⇒ 5.22 供給者のサービス提供の監視、レビュー及び変更管理
    4.2 利害関係者のニーズ及び期待の理解 ⇒ 5.23 クラウドサービスの利用における情報セキュリティ
    5.1 リーダーシップ＆コミットメント ⇒ – –
    5.2 方針 ⇒ – –
    5.3 責任及び権限 ⇒ 5.1 情報セキュリティのための方針群
    5.3 責任及び権限 ⇒ 5.2 情報セキュリティの役割及び責任
    5.3 責任及び権限 ⇒ 5.3 職務の分離
    5.3 責任及び権限 ⇒ 5.4 管理層の責任
    5.3 責任及び権限 ⇒ 5.5 関係当局との連絡
    5.3 責任及び権限 ⇒ 5.6 専門組織との連絡
    5.3 責任及び権限 ⇒ 5.15 アクセス管理
    5.3 責任及び権限 ⇒ 5.16 識別情報の管理
    5.3 責任及び権限 ⇒ 5.17 認証情報
    5.3 責任及び権限 ⇒ 5.18 アクセス権
    5.3 責任及び権限 ⇒ 8.1 利用者エンドポイント機器
    5.3 責任及び権限 ⇒ 8.2 特権的アクセス権
    5.3 責任及び権限 ⇒ 8.3 情報へのアクセス制限
    5.3 責任及び権限 ⇒ 8.4 ソースコードへのアクセス
    5.3 責任及び権限 ⇒ 8.5 セキュリティを保った認証
    6.1 計画策定 ⇒ – –
    6.1.2 リスクアセスメント ⇒ – –
    7.1 資源 ⇒ 5.9 情報及びその他の関連資産の目録
    7.1 資源 ⇒ 5.11 資産の返却
    7.1 資源 ⇒ 5.14 情報の転送
    7.1 資源 ⇒ 6.1 選考
    7.1 資源 ⇒ 6.2 雇用条件
    7.1 資源 ⇒ 6.4 懲戒手続
    7.1 資源 ⇒ 6.5 雇用の終了又は変更後の責任
    7.1 資源 ⇒ 6.7 リモートワーク
    7.1 資源 ⇒ 7.1 物理的セキュリティ境界
    7.1 資源 ⇒ 7.2 物理的入退
    7.1 資源 ⇒ 7.3 オフィス、部屋及び施設のセキュリティ
    7.1 資源 ⇒ 7.4 物理的セキュリティの監視
    7.1 資源 ⇒ 7.5 物理的及び環境的脅威からの保護
    7.1 資源 ⇒ 7.6 セキュリティを保つべき領域での作業
    7.1 資源 ⇒ 7.7 クリアデスク・クリアスクリーン
    7.1 資源 ⇒ 7.8 装置の設置及び保護
    7.1 資源 ⇒ 7.9 構外にある資産のセキュリティ
    7.1 資源 ⇒ 7.10 記憶媒体
    7.1 資源 ⇒ 7.11 サポートユーティリティ
    7.1 資源 ⇒ 7.12 ケーブル配線のセキュリティ
    7.1 資源 ⇒ 7.13 装置の保守
    7.1 資源 ⇒ 7.14 装置のセキュリティを保った処分又は再利用
    7.1 資源 ⇒ 8.6 容量・能力の管理
    7.1 資源 ⇒ 8.7 マルウェアに対する保護
    7.1 資源 ⇒ 8.8 技術的脆弱性の管理
    7.1 資源 ⇒ 8.9 構成管理
    7.2 力量 ⇒ 6.3 情報セキュリティの意識向上、教育及び訓練
    7.3 認識 ⇒ 6.6 秘密保持契約又は守秘義務契約
    7.4 コミュニケーション ⇒ – –
    7.5 文書化した情報 ⇒ 5.10 情報及びその他の関連資産の許容される利用
    7.5 文書化した情報 ⇒ 5.12 情報の分類
    7.5 文書化した情報 ⇒ 5.13 情報のラベル付け
    7.5 文書化した情報 ⇒ 5.37 操作手順書
    8.1 運用の計画策定及び管理 ⇒ 8.10 情報の削除
    8.1 運用の計画策定及び管理 ⇒ 8.11 データマスキング
    8.1 運用の計画策定及び管理 ⇒ 8.12 データ漏洩防止
    8.1 運用の計画策定及び管理 ⇒ 8.13 情報のバックアップ
    8.1 運用の計画策定及び管理 ⇒ 8.14 情報処理施設・設備の冗長性
    8.1 運用の計画策定及び管理 ⇒ 8.15 ログ取得
    8.1 運用の計画策定及び管理 ⇒ 8.16 監視活動
    8.1 運用の計画策定及び管理 ⇒ 8.17 クロックの同期
    8.1 運用の計画策定及び管理 ⇒ 8.18 特権的なユーティリティプログラムの使用
    8.1 運用の計画策定及び管理 ⇒ 8.19 運用システムへのソフトウェアの導入
    8.3 情報セキュリティリスク対応 ⇒ 5.24 情報セキュリティインシデント管理の計画策定及び準備
    8.3 情報セキュリティリスク対応 ⇒ 5.25 情報セキュリティ事象の評価及び決定
    8.3 情報セキュリティリスク対応 ⇒ 5.26 情報セキュリティインシデントへの対応
    8.3 情報セキュリティリスク対応 ⇒ 5.27 情報セキュリティインシデントからの学習
    8.3 情報セキュリティリスク対応 ⇒ 5.28 証拠の収集
    8.3 情報セキュリティリスク対応 ⇒ 5.29 事業の中断・阻害時の情報セキュリティ
    8.3 情報セキュリティリスク対応 ⇒ 5.30 事業継続のためのICTの備え
    8.3 情報セキュリティリスク対応 ⇒ 6.8 情報セキュリティ事象の報告
    8.3 情報セキュリティリスク対応 ⇒ 8.20 ネットワークセキュリティ
    8.3 情報セキュリティリスク対応 ⇒ 8.21 ネットワークサービスのセキュリティ
    8.3 情報セキュリティリスク対応 ⇒ 8.22 ネットワークの分離
    8.3 情報セキュリティリスク対応 ⇒ 8.23 ウェブフィルタリング
    8.3 情報セキュリティリスク対応 ⇒ 8.24 暗号の利用
    9.1 監視、測定、分析及び評価 ⇒ 5.8 プロジェクトマネジメントにおける情報セキュリティ
    9.1 監視、測定、分析及び評価 ⇒ 5.31 法令、規制及び契約上の要求事項
    9.1 監視、測定、分析及び評価 ⇒ 5.32 知的財産権
    9.1 監視、測定、分析及び評価 ⇒ 5.33 記録の保護
    9.1 監視、測定、分析及び評価 ⇒ 5.34 プライバシー及び個人識別可能情報(PII)の保護
    9.1 監視、測定、分析及び評価 ⇒ 5.35 情報セキュリティの独立したレビュー
    9.1 監視、測定、分析及び評価 ⇒ 5.36 情報セキュリティのための方針群、規則及び標準の遵守
    9.1 監視、測定、分析及び評価 ⇒ 8.25 セキュリティに配慮した開発のライフサイクル
    9.1 監視、測定、分析及び評価 ⇒ 8.26 アプリケーションセキュリティの要求事項
    9.1 監視、測定、分析及び評価 ⇒ 8.27 セキュリティに配慮したシステムアーキテクチャ及びシステム構築の原則
    9.1 監視、測定、分析及び評価 ⇒ 8.28 セキュリティに配慮したコーディング
    9.1 監視、測定、分析及び評価 ⇒ 8.29 開発及び受入れにおけるセキュリティテスト
    9.1 監視、測定、分析及び評価 ⇒ 8.30 外部委託による開発
    9.1 監視、測定、分析及び評価 ⇒ 8.31 開発環境、テスト環境及び本番環境の分離
    9.1 監視、測定、分析及び評価 ⇒ 8.32 変更管理
    9.1 監視、測定、分析及び評価 ⇒ 8.33 テスト用情報
    9.1 監視、測定、分析及び評価 ⇒ 8.34 監査におけるテスト中の情報システムの保護
    9.2 内部監査 ⇒ – –
    9.3 マネジメントレビュー ⇒ – –
    10.1 不適合、是正処置 ⇒ – –
    10.2 継続的改善 ⇒ – –

    PDFも用意しました。活用ください。

    ★リンク　【ISO27001要求事項と管理策の対応表】

    対応表からわかること

    上表を見ると、例えば

    要求事項「4.2 利害関係者のニーズ及び期待の理解」 において、
    該当する管理策
    ・「5.19 供給者関係における情報セキュリティ」
    ・「5.20 供給者との合意における情報セキュリティの取扱い」
    ・「5.21 情報通信技術(ICT)サプライチェーンにおける情報セキュリティの管理」
    ・「5.22 供給者のサービス提供の監視、レビュー及び変更管理」
    ・「5.23 クラウドサービスの利用における情報セキュリティ」
    の5つを考えて組織運営や、監査対応をすればよいことがわかります。

    基本は、

    要求事項はマネジメントシステムとして確立していることと、わかりやすいことから要求事項をベースにISMS,ISO27001に対応していけばよいです。

    そして、

    要求事項の補佐する役割として数多い管理策があるという関係でみていけば、管理策への抵抗は無くなるはず。

    いかがでしょう。対応表を活用して、管理策を活用していきましょう。

    まとめ

    以上、「ISO27001 2022管理策は要求事項に組み込もう！」を解説しました。

    • ①管理策への悩み
    • ②管理策は要求事項に組み込めばいい！
    • ③【結論】要求事項と管理策の対応表を活用しよう！
    • error: Content is protected !!