SCS評価制度 ★3/★4 セルフチェック

セキュリティの責任者と担当部署を決め、連絡先を一覧にして年1回見直す。

1. セキュリティを統括する役員（社長・取締役など。CISO の肩書きは不要）を1名決める。
2. 担当部署（総務・情シスなど）と担当者の役割・責任を1枚の体制図と分担表にする。
3. 役員・担当者の緊急連絡先（電話・メール・代理者）をリストにする。
4. 年1回、体制図と連絡先を見直した日付と確認者を記録する。

証拠として残すもの

• セキュリティ体制図（役員名・部署名入り）
• 役割・責任の分担表
• 緊急連絡先リスト
• 年次点検の記録（日付・確認者）

必要になるもの

• 体制図・分担表のテンプレート

補足: 小規模企業なら「社長＝統括役員、総務担当＝担当部署」で構いません。兼務でも役割が文書になっていれば足ります。

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

守秘義務のルールを文書にし、入社時・受け入れ時に説明する。

1. 役員・従業員・派遣社員・出向者を対象にした守秘義務規程（就業規則の秘密保持条項でも可）を用意する。
2. 入社時・社外要員の受け入れ時に説明する手順を決め、説明した記録（チェックリストや署名）を残す。

証拠として残すもの

• 守秘義務規程または就業規則の該当条項
• 入社時説明のチェックリストや受領書

必要になるもの

• 守秘義務規程のテンプレート

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

会社としてのセキュリティ基本方針を定め、いつでも見られる場所に置き、改正時に周知する。

1. A4 1〜2枚の「情報セキュリティ基本方針」を作り、経営者名で承認・日付を入れる。
2. 社内ポータル・共有フォルダ・掲示など、全員が最新版を参照できる場所を決める。
3. 改正したら全員に通知し、通知した日付と方法（メール・朝礼など）を記録する。

証拠として残すもの

• 承認済みの基本方針（版・日付入り）
• 掲示場所または共有フォルダのスクリーンショット
• 改正時の周知記録

必要になるもの

• 基本方針のテンプレート
• 社内共有の場所（ポータル・共有フォルダ）

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

取引先・クラウドなど「社外が管理していて自社がつながっているシステム」を一覧にし、年1回見直す。

1. 顧客・子会社・関係会社・クラウド事業者ごとに、自社の機器やデータが接続しているシステム（EDI・共有ポータル・SaaS・VPN など）を洗い出す。
2. 相手先名・システム名・接続方法・自社側の窓口を1つの台帳にまとめる。
3. 年1回、台帳を見直した日付と確認者を記録する。

証拠として残すもの

• 社外接続システム台帳
• 年次点検の記録

必要になるもの

• 台帳のテンプレート（表計算で可）

補足: 3-1-3（外部情報サービスの管理）の台帳と1つにまとめると運用が楽になります。

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

機密情報を渡す相手と、業務開始前に取扱条件を契約や覚書で取り決める。

1. 機密情報を共有する子会社・取引先を一覧にする。
2. 秘密保持契約（NDA）または基本契約の条項に「機密情報の定義・利用制限・保管方法・複製可否・第三者提供可否・返還または廃棄」の6点が入っているか確認する。
3. 抜けている相手には、覚書または NDA を業務開始前に締結する。

証拠として残すもの

• 締結済み NDA・覚書（6点を含むもの）
• 共有先と契約状況の一覧

必要になるもの

• NDA のひな形（6点を網羅したもの）

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

事故が起きたときの自社と取引先の役割分担を、事前に文書で決めておく。

1. 機密情報を共有する相手ごとに、インシデント発生時の「誰が誰に・いつまでに連絡するか」「調査・費用負担・公表の分担」を決める。
2. NDA や基本契約の条項、または別紙の合意書に落とし込む。

証拠として残すもの

• インシデント時の役割分担が書かれた契約条項または合意書

必要になるもの

• 契約条項のひな形

補足: 2-1-2 の NDA に「インシデント時の連絡・分担」条項を足す形が最も手間が少ないです。

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

パソコン・サーバの台帳を作り、導入や接続のルールを決め、年1回守られているか点検する。

1. パソコン・シンクライアントの製造元・OS・台数を把握できる台帳を作る（資産管理ツールでも表計算でも可）。
2. サーバ・仮想サーバ・ハイパーバイザについても同様に台帳化する。
3. 機器・ソフトの「導入・設置・ネットワーク接続・パッチ適用」のルールを1枚にまとめる。
4. 年1回、台帳と実機、ルールの遵守状況を突き合わせて記録する。

証拠として残すもの

• IT 資産台帳（製造元・OS・台数が分かるもの）
• 機器・ソフト管理ルール
• 年次点検の記録

必要になるもの

• 資産台帳（表計算）または IT 資産管理ツール

補足: 台数が数十台を超えるなら、自動で棚卸しできる資産管理ツールを入れると年次点検が一気に楽になります。

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

ネットワークの構成図と、ルータ・スイッチ等の機器一覧（保守業者入り）を作る。

1. 拠点ごとのネットワーク構成図を作り、各ネットワークの所在地と用途（社内 LAN・ゲスト Wi-Fi・サーバ区画など）を書く。
2. ルータ・FW・スイッチ・無線 AP ごとに、製造元・モデル・保守事業者（契約窓口）を一覧にする。

証拠として残すもの

• ネットワーク構成図（所在地・用途入り）
• ネットワーク機器一覧（製造元・モデル・保守事業者）

必要になるもの

• 構成図の作図ツール（表計算でも可）

補足: 保守事業者の欄が空の機器は、故障時に誰も直せない機器です。ここで洗い出しておくと事故対応も速くなります。

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

クラウド・SaaS を使うときの条件を決め、契約前に確認し、機密情報の扱いについて事業者と合意する。

1. 外部サービス利用時のセキュリティ要件（データ保管場所・多要素認証の有無・ログ・退会時のデータ削除など）をチェックリストにする。
2. 新しいサービスを使う前にチェックリストで確認し、結果を残す。
3. 各サービスの利用規約・データ処理契約で機密情報の取扱いが合意されていることを確認し、規約の版や日付を台帳に記録する。

証拠として残すもの

• 外部サービス利用のセキュリティ要件チェックリスト
• 利用中サービス台帳（規約確認日入り）

必要になるもの

• チェックリストと台帳のテンプレート

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

情報を「機密・社外秘・公開」などに区分するルールを決め、重要な機密情報は管理者と保管場所を台帳にする。

1. 機密区分（例: 極秘・社外秘・社内限り・公開）と、区分ごとの表示方法・取扱方法・取扱エリアをルールにする。
2. 重要な機密情報ごとに、管理者名・部署・保管場所・保管期限・開示先・管理者連絡先を台帳にする。
3. 年1回、ルールと台帳を見直した記録を残す。

証拠として残すもの

• 情報の機密区分ルール
• 重要機密情報台帳
• 年次点検の記録

必要になるもの

• 区分ルールと台帳のテンプレート

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

ユーザ ID の発行・変更・削除を申請と承認で行い、退職者や使っていない ID をすぐ止める。

1. ID の付与・変更・削除の申請書（またはワークフロー）と承認者を決める。
2. 共有 ID は原則禁止にし、やむを得ない場合は「誰がいつ使ったか」を記録する仕組み（利用簿など）を作る。
3. 退職・異動時に ID と権限を止める手順を人事の手続きに組み込み、一定期間未使用の ID を定期的に無効化する。

証拠として残すもの

• ID 申請・承認の記録
• 共有 ID の利用記録
• 退職・異動時の ID 停止記録
• 未使用 ID の棚卸記録

必要になるもの

• 申請フォームまたはワークフロー
• ID を一元管理する仕組み（ディレクトリサービス・ID 管理サービス）

補足: 社内 PC・クラウドの ID をディレクトリサービスや ID 管理サービスで一元化すると、退職時の停止が1か所で済みます。

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

サーバ・ネットワーク機器ごとに管理者を決め、管理者権限を最小限の人に限定し、誰が持っているか一覧にする。

1. すべてのサーバ・ネットワーク機器について、システム管理者と責任者を一覧にする。
2. 管理者権限を持つ人を必要最小限に絞り、管理者 ID の共有をやめる（やむを得ない場合は利用者を特定できる記録を残す）。
3. 各管理者 ID の権限を用途に応じた最小限にし、開発用の管理者権限で本番環境を操作できないよう分離する。
4. 管理者 ID の付与・変更・削除を申請・承認制にし、設定変更できる人を限定する。
5. 退職や未使用の管理者 ID は速やかに削除・無効化する。

証拠として残すもの

• 機器ごとの管理者・責任者一覧
• 管理者 ID 保有者一覧
• 管理者 ID の申請・承認記録
• 権限設定のスクリーンショット

必要になるもの

• 管理者一覧のテンプレート
• 特権 ID を管理できる仕組み

補足: 「全員が Administrator」の状態は最も多い不適合です。日常作業用の一般 ID と管理者 ID を分けるところから始めます。

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

すべての ID をパスワード等で認証し、重要な機密情報を扱うクラウドには必ず多要素認証を使う。

1. パスワードなしでログインできる端末・システムが無いことを確認する。
2. 重要な機密情報を扱うクラウドサービスを特定し、ユーザ・管理者ともに多要素認証を必須に設定する。
3. 多要素認証は知識・所有・生体・その他のうち2種類以上を組み合わせる（認証アプリ・SMS・ハードウェアキーなど）。
4. 多要素認証のパスワードは8文字以上にする。

証拠として残すもの

• 多要素認証が必須になっている管理画面のスクリーンショット
• 対象クラウドサービス一覧と設定日

必要になるもの

• 多要素認証に対応した ID 管理サービスまたは各クラウドの MFA 機能
• 認証アプリまたはセキュリティキー

補足: 主要なクラウドサービスは追加費用なしで多要素認証を有効化できます。まず管理者アカウントから必須化します。

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

PC とスマホのロック解除に 6 文字以上の PIN を必須にし、10 回失敗でロックまたは間隔を延ばす設定にする。

1. PC のログオンとスマートデバイスのロック解除に、6文字以上のパスワードまたは PIN を必須にする。
2. 10回以上の失敗で端末をロックするか、失敗のたびに待ち時間が延びる設定を有効にする。
3. 端末管理ツールがあればポリシーで一括配布し、無ければ設定手順書と設定確認の記録を残す。

証拠として残すもの

• 端末のロックポリシー設定画面
• 設定手順書と設定済み端末の一覧

必要になるもの

• OS のアカウントロックポリシー
• スマートデバイスを一括管理できる仕組み（台数が多い場合）

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

初期パスワードの変更・推測されやすい語の禁止・使い回し禁止・長さの基準を社内ルールにして周知する。

1. パスワードルールを1枚にまとめる: 初期パスワードは必ず変更／推測されやすい単語禁止／機器・サービス間で使い回さない。
2. 長さの基準を決める: 多要素認証または10回失敗ロックがあるなら8文字以上、どちらも無いなら英大小文字・数字を含む10文字以上。
3. 全員に周知し、周知した日付と方法を記録する。

証拠として残すもの

• パスワードルール（版・日付入り）
• 周知記録

必要になるもの

• パスワードルールのテンプレート

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

パスワードの安全な保管方法と、漏えいしたときの変更手順を決めて周知する。

1. 保管方法をルールにする: パスワード管理アプリの利用、または紙に書く場合は施錠保管。付箋・共有ファイルへの平文保存を禁止。
2. 漏えいまたはその疑いがあるときに「誰が・何を・どの順で変更するか」の手順を作る。
3. 全員に周知し、記録を残す。

証拠として残すもの

• パスワード管理ルール
• 漏えい時の変更手順
• 周知記録

必要になるもの

• パスワード管理アプリ（個人用でも法人用でも可）

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

システムや部屋へのアクセス権を申請・承認制にし、範囲を最小限にして、台帳で管理し棚卸しする。

1. システム・PC・機密エリアへのアクセス権の発行・変更・削除を申請・承認制にする。
2. 与える権限・入室許可は業務に必要な範囲に限定する。
3. 申請書または台帳で誰に何を許可したかを管理し、棚卸しの頻度（例: 年1回）を決めて実施する。

証拠として残すもの

• アクセス権管理ルール
• 申請書または権限台帳
• 棚卸し記録

必要になるもの

• 権限台帳のテンプレート

補足: 4-1-1（ユーザ ID）と同じ申請フローに乗せると二重管理になりません。

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

事故が起きたときの対応について、入社時と年1回、e ラーニングか集合教育で訓練し、受講記録を残す。

1. インシデント発生時の対応（発見したら誰に報告するか・端末を切り離す・勝手に再起動しない等）の教育資料を作る。
2. 新規受け入れ時と年1回、e ラーニングまたは集合教育で実施する（資料配布だけでは不可）。
3. 実施内容・方法・時期・受講者を記録して保管する。
4. 年1回、教育内容が現状に合っているか点検して記録する。

証拠として残すもの

• 教育資料
• 受講記録（日付・受講者名）
• 年次点検の記録

必要になるもの

• 教育資料のテンプレート
• e ラーニングまたは標的型メール訓練サービス（任意）

補足: 標的型メール訓練サービスは「訓練＋受講記録」を自動で残せるため、この項目の証拠づくりに向いています。

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

対象・頻度・保管期間を決めてバックアップし、重要データは遠隔地にも置き、復元手順書を作る。

1. バックアップ対象（ファイルサーバ・業務システム・クラウドデータ等）・取得頻度・保管期間を一覧にする。
2. 重要な機密情報は、ローカルのバックアップに加えて遠隔地（別拠点またはクラウド）にも保管する。
3. 対象ごとに復元手順書を作り、実際に復元できることを試して記録する。

証拠として残すもの

• バックアップ方針（対象・頻度・保管期間）
• バックアップ実行記録
• 遠隔地保管の証跡
• 復元手順書と復元テストの記録

必要になるもの

• バックアップソフトまたは NAS のバックアップ機能
• クラウドバックアップまたは別拠点の保管先

補足: ランサムウェア対策として、バックアップ先は通常の共有ドライブから直接書き換えられない構成（別資格情報・世代管理・イミュータブル）にしておくと安心です。

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

許可していないソフトを入れられないようにし、USB の自動実行を止め、サーバ・機器の設定変更を承認制にする。

1. 利用を許可するソフトの一覧を作り、それ以外を削除するか、一般ユーザがインストールできない設定（管理者権限なし）にする。
2. 外部記録媒体を使う端末で自動実行・自動再生を無効化する。
3. サーバ・ネットワーク機器の設定変更を申請・承認制にし、変更記録を残す。

証拠として残すもの

• 許可ソフト一覧
• 一般ユーザに管理者権限が無いことを示す設定
• 自動実行無効化の設定画面
• 設定変更の申請・承認記録

必要になるもの

• OS のポリシー設定または端末管理ツール
• 変更管理の申請フォーム

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

サポート切れの OS・ソフトを使わず、自動更新を有効にし、重大な脆弱性の修正は14日以内に適用する。

1. PC の OS・ブラウザ・Office、サーバの OS・ミドルウェア、スマートデバイスの OS・アプリ、境界のネットワーク機器の OS・ファームウェアを対象に、サポート状況を台帳で確認する。
2. サポート終了品は撤去するか、インターネットから完全に遮断する。
3. 可能なものは自動アップデートを有効にする。
4. 「重大」「高リスク」または CVSS 7.0 以上の修正は、公開から14日以内に適用する運用を決め、適用日を記録する。
5. 期限内に適用できない場合は、機能の無効化・ベンダー推奨の回避策・ネットワーク分離・通信監視のいずれかを行い、その記録を残す。

証拠として残すもの

• サポート状況を含む資産台帳
• 自動更新の設定画面
• パッチ適用記録（公開日と適用日）
• 代替措置の記録

必要になるもの

• パッチ管理ツールまたは端末管理ツール（台数が多い場合）
• ネットワーク機器のファームウェア更新体制（保守契約）

補足: 「14日以内」を守るには、脆弱性情報を誰が見て誰が判断するかを 1-2-1 の体制に組み込んでおく必要があります。

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

ネットワークにつながる全 PC・サーバにマルウェア対策ソフトを入れ、スキャンと定義ファイル更新を運用する。

1. ネットワーク接続しているすべての PC・サーバにマルウェア対策ソフトを導入し、未導入機が無いことを台帳で確認する。
2. 機器ごとにスキャン範囲と頻度を決めて実行する。
3. パターンファイルをベンダー推奨どおり自動更新にし、更新状況を管理画面で確認できるようにする。

証拠として残すもの

• 導入状況が分かる管理コンソールの画面
• スキャン設定と実行記録
• 定義ファイル更新状況

必要になるもの

• 法人向けマルウェア対策ソフト（管理コンソール付き）または EDR

補足: 管理コンソールで全台の状態が見えるものを選ぶと、「全台に入っている」ことを証拠として示せます。

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

ルータ・FW の初期パスワードを変え、不要な受信通信を遮断し、ルールを文書化して不要分を消し、外部からの設定変更は MFA か IP 制限を付ける。

1. すべての FW・ルータの管理パスワードを強固で一意なものに変更するか、リモート管理を無効化する。
2. FW・ルータのパスワード変更手順を文書にし、4-1-5 のパスワールールを満たす設定にする。
3. 認証されていないインバウンド通信をすべて遮断する（初期設定で開いているポートの確認）。
4. インバウンド通信のルール一覧を文書化し、不要になったルールは速やかに削除する。
5. インターネット経由で FW ルールを変更する場合は、多要素認証か信頼できる IP アドレスからの接続に制限する。

証拠として残すもの

• FW・ルータの一覧とパスワード変更記録
• パスワード変更手順書
• インバウンドルール一覧
• ルール棚卸しの記録
• リモート管理の認証設定画面

必要になるもの

• ファイアウォール機能を持つルータまたは UTM
• 設定を保守できる体制（自社または保守事業者）

補足: 家庭用ルータのままだとルール一覧の出力やリモート管理の制限ができないことがあります。その場合は法人向け機器への置き換えが必要です。

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

外から中・中から不正サーバへの通信をリアルタイムに検知・遮断する仕組みを入れ、ログを見て判断し、異常時に通知が来るようにする。

1. ネットワーク境界（UTM・次世代 FW）または端末（EDR）で、インバウンドと不正サーバへのアウトバウンドの双方を検知・遮断する機能を有効にする。
2. ログ・アラートを誰がいつ確認し、インシデントかどうかを誰が判断するかを手順にする。
3. アラートが速やかに発報され、速報レポートが作成・通知される仕組み（メール通知・監視サービス）を整える。

証拠として残すもの

• 検知・遮断機能が有効な管理画面
• ログ確認の手順と確認記録
• アラート通知の設定またはサンプル

必要になるもの

• UTM・次世代ファイアウォールまたは EDR
• 監視・通知の仕組み（機器の通知機能または監視サービス）

補足: 自社で毎日ログを見る人がいない場合は、監視を外部サービスに任せる方が確実です。

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

事故対応の手順（発見報告→初動→調査・対応→復旧→最終報告）と連絡先・報告フォーマットを整え、年1回点検し、事例を社内で共有する。

1. 発見報告・初動・調査対応・復旧・最終報告の5段階を含む対応手順書を作る。
2. 社内外の連絡先（経営層・取引先・警察・所管省庁・個人情報保護委員会・保守事業者など）と報告ルートを一覧にする。
3. インシデント時の統括役員と担当部署の役割・責任を決める（1-2-1 の体制図に追記でも可）。
4. 報告フォーマット（第一報・最終報告）を用意する。
5. 年1回、連絡先と体制を点検し、社内外の重大事例と対策を社内に共有した記録を残す。

証拠として残すもの

• インシデント対応手順書
• 連絡先・報告ルート一覧
• 報告フォーマット
• 年次点検の記録
• 事例共有の記録

必要になるもの

• 対応手順書・報告書のテンプレート

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。

事業に不可欠なシステムについて、サイバー攻撃時の目標復旧レベルを決め、予備手段（待機系や人手運用）を用意する。

1. 止まると事業が回らないシステム（受発注・会計・生産管理など）を特定する。
2. それぞれについて「何時間以内に・どの水準まで」復旧するかの目標を決める。
3. システムによる継続策（予備機・クラウド待機系）と人手による継続策（電話・FAX での業務、取引先連絡先の複数手段）を準備し、文書にする。

証拠として残すもの

• 重要システム一覧と目標復旧レベル
• 復旧対策の文書（待機系構成または人手運用手順）
• 取引先連絡先リスト

必要になるもの

• 予備機またはクラウド待機環境（必要な場合）
• BCP 文書のテンプレート

補足: 4-3-4 の復元手順書と組み合わせると、「バックアップから何時間で戻せるか」が目標復旧レベルの根拠になります。

※ META-MARK の解釈です。IPA の解説書・取得ガイド（2026年10月頃公開予定）が優先されます。