取引先から★3の取得を打診された。あるいは社内で対応の検討が始まった。最初にやることは決まっています。何を求められているのかを項目単位で把握することです。

ところが、ここで多くの担当者がつまずきます。解説記事を3本読むと、項目数が3通り出てくるからです。「★3は25項目」と書く記事があり、「評価基準は83件」と書く記事があり、「★4は44項目」と書く記事もあります。どれを社内資料に転記すればいいのか、判断がつきません。

この記事では、IPAが公開している要求事項・評価基準のファイルを直接集計した実測値を示します。★3の要求事項は26、評価基準は81。★4の要求事項は43、評価基準は153。大分類7・中分類16の構造に沿って、26と43の中身を項目名まで一覧化しました。

あわせて、要求事項と評価基準という2つの言葉の違いも最初に整理します。この2つが混ざったまま話を進めると、社内の合意形成が必ずどこかで止まります。制度の全体像から確認したい場合はSCS評価制度とはを先に読むと、この記事の位置づけがつかみやすくなります。

SCS評価制度の要求事項とは｜評価基準との違い

SCS評価制度の要求事項とは、企業が実施すべきセキュリティ対策を項目として定めたものです。

一方の評価基準は、その要求事項が満たされているかを確認するための判断基準にあたります。1つの要求事項に対して、評価基準は1件のこともあれば8件に分かれることもあります。要求事項が「何をするか」、評価基準が「どこまでできていれば達成とみなすか」を担当している、と考えると整理しやすくなります。

「26項目」と「81項目」はどちらも正しい

記事によって数字が割れて見える原因の一つが、この2語の混同です。

★3の場合、要求事項は26、評価基準は81。「★3は26項目です」と説明しても「★3は81項目あります」と説明しても、数えている対象が違うだけで、どちらも誤りではありません。困るのは、どちらを数えているのか明示せずに数字だけが流通することです。

社内の説明資料を作るときは、冒頭で「要求事項ベースで26」「評価基準ベースで81」と定義を書いてから本題に入ると、以降のやり取りが速くなります。取引先から項目数を聞かれたときも、どちらの数え方かを確認してから答えるのが確実です。

この区別は、対応状況の管理表を作る段階で効いてきます。要求事項の単位で「対応済み」「未対応」を管理すると、26行の軽い表で済みます。ただし1つの要求事項に評価基準が8件ぶら下がっているケースでは、8件のうち5件しか満たしていない状態も「対応済み」に丸められてしまう。逆に評価基準の単位で管理すると81行になり、粒度は正確ですが全体像が見えにくくなります。要求事項を親、評価基準を子として二段で持つのが実務では扱いやすい形になります。

番号は4階層で振られている

要求事項と評価基準には、階層構造に沿った番号が振られています。大分類から評価基準まで4つの階層があり、それぞれの段で数が増えていきます。★3と★4は別々の体系ではなく、同じ4階層のなかで★3が求める範囲と★4が求める範囲が区別されている構造です。

たとえば「4-1-2」という番号は、大分類4の中分類1にある2番目の要求事項を指します。その下にぶら下がる評価基準は「4-1-2-1」から始まる4桁の番号になります。

この構造を理解しておくと、評価基準を1件ずつ追いかけるのではなく、大分類や中分類の単位でまとめて担当部門に割り振れるようになります。26や81という数字は、一覧で眺めると多く感じます。構造で切ると、実務としては扱える大きさに収まります。

参考：IPA サプライチェーン強化に向けたセキュリティ対策評価制度

どの件数が正しいのか｜★3は26と81、★4は43と153

社内資料に転記する前に、どの数字が正しいのかを先に決めておきます。IPAが公開している要求事項・評価基準のファイルを直接集計すると、★3と★4の件数は次のようになります。評価の方法と有効期間もあわせて置きました。この4つの数字の関係を最初に押さえておくと、以降の章の読み方が決まります。

★4の43は★3の26を含んだ数です。★3の26に加えて43があるのではありません。評価基準も同じで、153のうち81が★3から求められ、残る72が★4で追加されます。この包含関係を読み違えると、社内に「合計69項目」といった存在しない数字が流通します。

流通している83件・157件は実測と一致しない

検索で上位に出る解説記事のなかには、★3の評価基準を83件、★4を157件と書いているものがあります。要求事項を25や44としている記事もあります。

いずれも、公開ファイルを集計した結果とは一致しません。どこで生まれた数字なのかは追えませんでしたが、初期の報道や資料から転記が重なった可能性があります。数え方の違いではなく、実数として異なります。

社内資料や取引先への回答にこれらの数字が入っていると、後から差し替えが必要になります。転記する前に、いま自社が参照している数字の出どころを確認しておくのが安全です。

いつ取得したデータかを添えて使う

この記事の件数は、IPAが公開している「★3・★4 要求事項及び評価基準」のExcelを2026年9月14日に取得し、集計したものです。

制度は運用開始前の段階にあり、評価機関や評価用ガイド等の公表は2026年度下期に予定されています。それに伴って要求事項・評価基準が改訂される可能性があります。社内資料に転記するときは、件数だけでなく「いつ時点のデータか」を必ず添えてください。改訂が入ったときに、どの資料を直せばよいかが一目で分かります。

参考：IPA SCS評価制度 要求事項・評価基準

参考：IPA ★3・★4 要求事項及び評価基準（Excel・2026年4月21日版）

大分類7と中分類16｜要求事項はどこに集まっているか

この章で使う大分類7と中分類16は、IPAが公開している要求事項・評価基準そのものに置かれた区分です。ジョーシスが独自に整理したものではありません。後半で扱う証跡の取り方による3分類とは出どころが違うので、社内資料では分けて扱ってください。

要求事項と評価基準は、この7つの大分類と16の中分類に配分されています。以下の件数は、公開ファイルを本記事で集計した値です。

大分類7つの内訳

大分類は、ガバナンスの整備から始まり、取引先管理、リスクの特定、攻撃等の防御、検知、対応、復旧へと並びます。守る前の準備から、守り、気づき、復旧するまでの流れに沿った並びです。★3と★4それぞれの要求事項数と評価基準数を、この順に置きました。

★3の81件のうち48件、全体の59%が「攻撃等の防御」に入ります。★4でも153件中82件が同じ分類です。要求事項ベースで見ても、★3の26件のうち13件が防御に属します。ちょうど半分です。

ここが、事前の想像と実測がずれやすいところです。「セキュリティ評価制度への対応」と聞くと、規程を整え、体制図を描き、方針を承認する作業を思い浮かべがちです。実際にはガバナンスの整備は★3で8件にとどまり、全体の1割を切ります。準備の重心は技術的な実装の側にあります。

要求事項ベースと評価基準ベースで、見える景色が変わる点にも触れておきます。要求事項で数えると、インシデントへの対応は★3でわずか1件です。ところが評価基準に降りると6件になります。逆に取引先管理は要求事項3件に対して評価基準4件で、ほぼ1対1に近い。要求事項の数だけを見て工数を見積もると、インシデント対応のような項目で足りなくなります。担当を割り当てるときは大分類の単位で、工数を見積もるときは評価基準の件数で、と使い分けるのが実務的です。

なお、ここでいう大分類はSCS評価制度が定めた区分です。NIST CSFの6機能（統治・識別・防御・検知・対応・復旧）とは別の軸なので、名称が似ていても対応づけないでください。NIST CSFで社内の対策状況をすでに整理している場合は、NIST CSFの機能別に見た評価基準の偏りから読み替えるほうが早く把握できます。

中分類16の内訳

大分類をもう一段割ると、偏りはさらにはっきりします。16の中分類のうち、どこに件数が積み上がり、どこが★3では空欄のままなのかが見えるからです。番号は大分類に対応しており、たとえば4-1は大分類4「攻撃等の防御」の1番目の中分類を指します。

最大の塊は「4-1 アイデンティティ管理、認証、アクセス制御」です。★3では要求事項7・評価基準27で、81件のうち33%を1つの中分類が占めます。★4では40件に増えます。

2番目は「3-1 資産管理」の11件（★4では24件）、3番目が「4-4 プラットフォームセキュリティ」の8件（★4では18件）です。上位3つで★3の81件のうち46件、全体の57%に達します。

逆に、★3ではまったく問われない中分類が4つあります。組織の状況、監督、リスクアセスメント、有害事象の分析です。これらは★4から追加されます。★3の準備段階では、この4つに時間を割く必要はありません。

参考：IPA SCS評価制度 詳細情報

★3の要求事項26一覧｜大分類別に全項目

ここからが本題です。★3で求められる26の要求事項を、大分類の順に並べます。各行の右端は、その要求事項にぶら下がる★3の評価基準の件数です。

件数が多い要求事項ほど、確認される観点が細かく分かれていると読めます。「対応済み」と一言で答えられる項目ではない、という目安になります。

ガバナンスの整備（要求事項3・評価基準8）

推進する体制と、守るべき方針を定める領域です。★3では3件で、内訳は役割・責任・権限が2件、ポリシーが1件になります。

3件だけです。推進部門を決め、守秘義務のルールを整え、対応方針を策定する。ISMSやプライバシーマークを運用している企業であれば、既存の文書がそのまま出発点になります。

ただし、既存文書が「ある」ことと、評価基準の条文に「対応している」ことは別です。方針・規程・手順・記録の4階層がつながっているか、条文ごとにどの文書のどこが該当するかを示せるかが問われます。

取引先管理（要求事項3・評価基準4）

取引先との関係と、そこでやり取りする情報の扱いを定める領域です。★3の3件はいずれもサイバーセキュリティサプライチェーンリスクマネジメントという1つの中分類に属します。

制度の名称にサプライチェーンとある割に、★3では4件と少なめです。取引先そのものの対策状況を確認する要求事項は★4から追加されます。

とはいえ、最初の「取引先とのビジネス又はシステム上の関係」は軽い項目ではありません。どの取引先と、どのシステムでつながっているかを把握している状態が求められます。SaaSや外部サービス経由の接続まで含めて洗い出すと、想定よりも数が出てくるのが通例です。

リスクの特定（要求事項4・評価基準11）

何を守る必要があるのかを把握する領域です。★3の4件は資産管理に集中し、対象は端末とソフトウェア、ネットワーク、外部サービス、情報そのものの4つに分かれます。

4件すべてが資産管理です。端末とソフトウェア、ネットワーク、外部サービス、そして情報そのもの。何がどこにあるかを把握できている状態が、★3の土台になります。

かつては年に一度の棚卸しで台帳を更新し、その間の変更は差分で追いかける運用が一般的でした。現在は各システムのAPI経由で利用実態を自動取得し、台帳を常に最新に保てます。評価基準が求めるのは申請ベースの一覧ではなく、実態を反映した把握です。台帳の項目設計から見直したい場合は、IT資産台帳の作り方と運用ルールで具体的に扱っています。

攻撃等の防御（要求事項13・評価基準48）

実際に攻撃を防ぐための実装を問う領域です。★3の半分がここに集まり、要求事項も評価基準も7つの大分類のなかで最大になります。中分類は認証とアクセス制御、教育、データ、プラットフォーム、ネットワークの5つにまたがります。

単独で最多なのは「管理者IDの管理手続」の8件です。ユーザIDの4件と比べて倍の観点が置かれています。委託先や運用ベンダーに渡している管理者IDが棚卸しできているか、権限が業務上必要な範囲に絞られているか、といった点が細かく確認されます。

次に多いのが「ネットワーク境界防護」の7件と「パスワード設定ルール」の5件です。パスワードのルールが5件に分解されている点は、社内説明で誤解が生まれやすいところになります。「パスワードポリシーは策定済みです」と答えるだけでは、5つの観点のどれが記述されていてどれが抜けているかを示せません。

認証まわりは、隣り合う要求事項をまとめて見ると意図が読み取りやすくなります。認証の強度・実装方法の決定が4件、アカウントロック制御が2件、パスワード設定ルールが5件、パスワード管理ルールが3件。合わせて14件が「どうやって本人を確認するか」に集まっています。多要素認証を入れるか、一定回数の失敗でロックするか、といった選択肢のいずれかを実装し、その設定状態を示せるかが問われる構造です。ポリシー文書と実際の設定値が食い違っていると、どちらを出しても証跡になりません。

一方で「アクセス権の管理ルール」は★3では1件だけです。ただし★4では6件に増えます。ここは差が大きい項目なので、後段で改めて触れます。アクセス権の棚卸しを実務としてどう回すかは、アクセス権レビューの進め方と自動化にまとめています。

攻撃等の検知（要求事項1・評価基準3）

攻撃の兆候に気づくための監視を問う領域です。★3では継続的監視という中分類の1件だけで、7つの大分類のなかでも下から2番目の少なさになります。監視の対象がネットワークに限定されている点が、★4との最も大きな差になります。

★3の要求事項は1件、その下の評価基準が3件です。情報機器やソフトウェアの挙動監視、いわゆるEDR的な領域は★4から追加されます。★3の段階では、ネットワークの接続とデータの監視に絞られています。

インシデントへの対応（要求事項1・評価基準6）

実際に起きたあとの動き方を問う領域です。要求事項は1件ですが、その下の評価基準は6件と多くなります。要求事項の数と評価基準の数がここまで離れるのは、7つの大分類のなかでこの領域だけです。

要求事項は1つですが、評価基準は6件に分かれます。しかもこの6件は★3と★4で同数です。インシデント対応手順については、★4に上がっても追加の要求がありません。★3の時点で求められる水準が、そのまま★4でも通用します。

裏を返すと、★3の6件は相応に細かいということです。検知から報告、初動、復旧、事後の見直しまで、手順として文書化され、役割と責任が明示されている状態が求められます。

インシデントからの復旧（要求事項1・評価基準1）

事業をどう戻すかを問う領域です。★3では要求事項も評価基準も1件ずつにとどまり、7つの大分類のなかで最も件数が少なくなります。中分類はインシデント復旧計画の実行の1つだけです。

★3では1件のみ、★4でも2件です。7つの大分類のなかで最も件数が少ない領域になります。

件数が少ないことと重要度が低いことは別ですが、準備の順序という意味では後回しにできる領域だと読めます。

SCS評価制度の準備をどこから機械化できるか整理したい場合は、IT資産とアカウントの一元管理の考え方をまとめた資料が参考になります。

5分でわかるジョーシスの資料をダウンロードする

★4で追加される17要求事項と72評価基準

★4の43要求事項のうち、★3に含まれない新規は17件です。評価基準は72件増えます。この17件と72件が何を求めているかを見ると、★4が★3の延長ではないことがはっきりします。★3を目指す企業にとっても、どこまでを今回の範囲にするかを決める材料になる部分です。

新しく追加される17要求事項

★4で新設される17件を、大分類と中分類を添えて並べます。右端はその要求事項にぶら下がる★4の評価基準の件数です。★3では0件だった中分類、つまり組織の状況・監督・リスクアセスメント・有害事象の分析の4つは、すべてここに登場します。

追加される17件を眺めると、★4が何を見ているかが分かります。脆弱性の管理体制、ログの取得、挙動の監視、インシデントのレベル定義。つまり、攻撃を受けている最中に気づいて判断できる体制です。★3が「守りを固めているか」を問うのに対し、★4は「守りを破られたときに検知して動けるか」まで踏み込みます。

サーバ設置エリアの入退室管理や可搬媒体の制限といった物理面の項目が★4から入る点も、実地審査が加わることと整合します。★3は専門家の確認と署名を前提とした自己評価ですが、★4は第三者評価に実地審査と技術検証が加わります。現地で見て確認できる対象が要求事項に含まれるのは、評価の方法が変わることの裏返しです。

教育・研修の扱いも分かれます。★3で求められるのはインシデント発生時の教育・訓練3件のみで、日常的な意識向上の研修は★4から5件が追加されます。★3の段階では、全社員向けのセキュリティ研修プログラムを一から設計する必要はありません。インシデント時に誰がどう動くかの訓練と、その実施記録があれば足ります。

追加72件の内訳は42件と30件に分かれる

ここが見落とされやすいところです。★4で増える評価基準72件のうち、新しい17要求事項から来るのは42件。残る30件は、★3にもある26の要求事項が深掘りされることで増えます。

深掘りの幅が大きい要求事項は次のとおりです。

とくにアクセス権の管理ルールは1件から6件へ、6倍に増えます。★3では最小限の確認だった領域が、★4では主要項目のひとつになります。

この構造を知っていると、準備の順序が変わります。将来的に★4を視野に入れているなら、★3の段階で「アクセス権の管理」と「機密区分に応じた情報の管理」だけは★4の水準を意識して作り込んでおくほうが、やり直しが減ります。逆に、その2つ以外は★3の水準で進めてよい、という判断もできます。

なお、★3を取得していなくても★4を取得できるとIPAは明記しています。★3から順番に積み上げる必要はありません。どちらを目指すかの判断材料は、★3と★4の違いを要件・評価方法・有効期間で比較した記事にまとめています。

26の要求事項は証跡の取り方で3つに分かれる（ジョーシス独自の整理）

この3つの分け方は、制度が定めたものではありません。IPAが公開している評価基準を、証跡をどう集めるかという観点でジョーシスが独自に整理したものです。

要求事項の一覧を手にしても、次に「で、何をすればいいのか」で止まります。ここを動かすには、項目を内容ではなく証跡の取り方で分けるのが有効です。

★3の81評価基準を、達成をどう示すかという軸で分け直すと3つに割れます。

この3分類は、IPAが公開している要求事項・評価基準の各基準に、想定される証跡の取得手段をジョーシスが割り当てて集計したものです。制度が定めた区分ではありません。

重要なのは、どれか1つでは終わらない点です。システムを入れれば文書が不要になるわけでも、規程を整えれば運用が免除されるわけでもありません。3つすべてに担当と期限を置かないと、どこかが空白のまま評価の時期を迎えます。

文書で示す25件は、種類ではなく粒度が壁になる

25件はパスワードのルール、インシデント対応、推進体制と方針、情報の取扱い、IDとアクセス権の5領域に集まります。ここに守秘義務や資産の把握などが加わっても、作る文書そのものは11種類ほどにとどまります。数としては多くありません。

難しいのは粒度と整合性です。パスワード関連の評価基準は設定ルール5件と管理ルール3件に分かれており、規程に「パスワードポリシーを定める」と1行書いてあるだけでは対応を示せません。評価基準の条文ごとに、どの文書のどこが該当するかを対応づける作業が発生します。

ISMSやプライバシーマークを取得していれば通る、という見立ても実態と合いません。免除規定は2026年9月15日時点で確認できず、ISMSとの関係についての公式な整理も公表されていません。既存文書は出発点として使えますが、そのまま流用できる前提で計画を立てると期間の見積もりを誤ります。

この内訳も、ジョーシスが割り当てて集計したものであり、制度が定めた区分ではありません。

人手で回す16件は、実施ではなく記録が評価される

16件の中身は、全社への周知、年1回の点検、申請と承認の運用、権限の限定、アラートの判断に分かれます。周知が最も多く、次が点検です。作業そのものは難しくありません。効いてくるのは条件のほうです。

周知の対象には役員も派遣社員も受入出向者も含まれます。人の出入りがあるたびに説明の機会が要り、異動のタイミングで漏れが出ます。また★3の有効期間は1年なので、周知も点検も毎年やり直しになります。去年実施したから今年は省略、が通用しません。

そして最も見落とされるのが、評価されるのは実施したことではなく実施を示す記録だという点です。日付・対象者・内容がそろって初めて証跡になります。実施はしていたのに様式がばらばらで証跡として使えない、という結末が最も惜しいところです。どの領域にどんな記録が要るかは、★3の自己評価で求められる証跡で具体的に扱っています。

この内訳も、ジョーシスが割り当てて集計したものであり、制度が定めた区分ではありません。

要求事項一覧を社内でどう使うか

一覧を眺めるだけでは進みません。2026年9月時点で申請はできませんが、準備として動けることは明確にあります。ここまでに整理した件数と偏りを、担当の割り当て・着手の順番・仕組み化の優先度という3つの判断に変換します。いずれも制度の開始を待たずに着手できる範囲です。

大分類ごとに担当部門を割り当てる

26の要求事項を1件ずつ担当者に割り振ると、管理そのものが負担になります。大分類の単位で当てるほうが現実的です。

ガバナンスの整備3件と取引先管理3件は、規程や契約を扱う部門。リスクの特定4件と攻撃等の防御13件は、情報システム部門。攻撃等の検知1件、インシデントへの対応1件、インシデントからの復旧1件は、インシデント対応の体制を持つ担当。この分け方なら、7分類を3つの窓口に集約できます。

評価基準の件数で見ると情報システム部門が59件と突出しますが、そこは実態に合っています。準備の重心は技術側にある、と先に整理したとおりです。

件数の多い要求事項から手をつける

優先順位に迷ったら、評価基準の件数が多い順に並べるのが単純で有効です。★3であれば、管理者IDの管理手続8件、ネットワーク境界防護7件、インシデント対応手順6件、パスワード設定ルール5件。この4つで81件のうち26件、全体の3割を占めます。

とくに管理者IDの管理手続は、委託先や運用ベンダーに渡しているIDまで含めた棚卸しが前提になるため、着手から完了までの期間が読みにくい項目です。早めに始めておくほうが安全です。

逆に、件数が1件の要求事項は最初の1周では深追いしなくてかまいません。ただし「アクセス権の管理ルール」だけは例外です。★3では1件でも★4では6件になるため、★4を視野に入れているなら扱いが変わります。件数順のリストに、将来の増分という列を1つ足しておくと判断がぶれません。

常時対応が必要な項目を先に仕組み化する

評価基準のなかには、実施の頻度が条文に書かれているものがあります。年に一度でよいものと、日常の運用として回し続ける必要があるものが混在しており、後者は着手から定着までに時間がかかります。頻度の指定がある項目を先に洗い出しておくと、仕組み化の優先度が決まります。

このうち常時対応が求められる退職IDの削除は、手作業の運用だと必ず遅れが出ます。人事からの連絡を受けてから1件ずつ止めていく流れでは、在職中と同じ権限が数日から数週間そのまま残ります。そして、その空白期間は削除日時のログに残ります。実施したかどうかではなく、いつ実施したかで見られる項目だと考えてください。手順の設計は退職者アカウントの削除手順で具体的に扱っています。

年1回の項目は、始めた時点からしか記録が積み上がりません。申請の直前にまとめて作れる性質の作業ではないため、様式だけでも先に決めておくと後が楽になります。

参考：IPA SCS評価制度 よくある質問

よくある質問

件数と一覧に関して問い合わせの多い4点をまとめます。いずれも2026年9月15日時点の公開情報にもとづく内容です。

要求事項の一覧はどこで確認できますか

IPAのサイトで公開されています。要求事項・評価基準のページにExcelファイルが掲載されており、大分類・中分類・要求事項・評価基準の全体を確認できます。★3から求められるものと★4で追加されるものは、ファイル内で区分されています。運用開始前の段階のため改訂の可能性があり、参照した日付を控えておくことをおすすめします。

★3の要求事項は26と81のどちらが正しいですか

どちらも正しく、数えている対象が違います。要求事項という単位で数えると26、その達成を確認する評価基準という単位で数えると81になります。社内資料では「要求事項26・評価基準81」と両方を併記し、以降どちらを基準に話すかを最初に決めておくと混乱を避けられます。

★3の26要求事項をすべて満たさないと取得できませんか

26の要求事項はいずれも★3で求められるものです。一部だけを選んで対応する性質のものではありません。ただし要求事項ごとに評価基準の件数は1件から8件まで幅があり、確認される観点の細かさは大きく異なります。件数の多い項目から着手すると、全体の進捗が早く動きます。

★4を目指す場合、★3の準備は無駄になりますか

無駄にはなりません。★4の43要求事項は★3の26を包括しており、評価基準153件のうち81件は★3と同じものです。ただし★3にもある26要求事項のうち一部は★4で評価基準が増えるため、アクセス権の管理と機密区分に応じた情報の管理については、★3の段階から★4の水準を意識して整備しておくとやり直しが減ります。

まとめ

SCS評価制度の要求事項について、2026年9月15日時点で押さえておきたい点は3つです。

1つ目は件数です。★3は要求事項26・評価基準81、★4は要求事項43・評価基準153。★4は★3を包括する関係にあります。流通している83件や157件、25項目や44項目という数字は、公開データの集計値と一致しません。

2つ目は偏りです。★3の81評価基準のうち48件が「攻撃等の防御」に入り、中分類で見ると「アイデンティティ管理、認証、アクセス制御」だけで27件を占めます。制度対応を文書整備の話として捉えると、準備の見積もりを大きく外します。

3つ目は差分の構造です。★4で増える評価基準72件のうち、42件は新設の17要求事項から、30件は★3にもある要求事項の深掘りから来ています。将来★4を視野に入れるなら、深掘り幅の大きい項目だけを先に作り込んでおく判断ができます。

一覧を手に入れたあとの作業は、項目を証跡へ変えていくことです。システムで取る40件、文書で示す25件、人手で回す16件。3つのどれも欠けたままでは、評価の時期に空白が残ります。

なお、ここで触れた3分類と内容別の分類は、いずれも制度が定めた区分ではありません。ジョーシスが独自に整理したものです。

ジョーシスが提供するJosysは、ITデバイスとSaaS、アカウント情報を一元管理し、評価のときに出せる証跡として蓄積します。自社の現状をどこまで機械的に把握できるか確認したい場合は、資料をご覧ください。

5分でわかるジョーシスの資料をダウンロードする

関連記事：ITコンプライアンスとは｜関連法規と50項目チェックリスト

関連記事：セキュリティリスクアセスメントの手法とISMS対応手順