2026.10.19 人事労務

人事管理システムのセキュリティ要件：マイナンバーの区分管理・権限・ログ・委託先の確認項目

人事管理システムには、氏名や住所だけでなく、マイナンバー、健康診断の結果、人事評価といった性質の異なる情報が一つのデータベースに集まります。この記事は、人事管理システムのセキュリティを「製品のどの機能を確かめれば、法令上の安全管理措置を満たせるか」という選定の目線で整理したものです。番号法と個人情報保護法で保護の水準が変わる箇所、権限とログ・暗号化の確認方法、クラウドや保守ベンダーが番号法上の委託に当たる条件、漏えい時の報告基準までを、個人情報保護委員会の資料をもとに説明します。人事管理システム全体の機能と導入形態は人事管理システムとは何かを機能と導入判断から整理した記事で扱っています。

まとめ：人事管理システムのセキュリティはデータの区分と委託関係で決まる

人事管理システムのセキュリティで最初に決めるのは、製品のセキュリティ機能の多さではありません。どの情報を誰に見せるかというデータの区分と、ベンダーがデータに触れるかという委託関係の2つです。マイナンバーは番号法により事務取扱担当者だけが扱う前提で、健康情報は要配慮個人情報、人事評価は社内規程で閲覧者を絞る情報です。この3つを同じ「人事部の権限」でまとめて見せる製品や設定は、選定の段階で外します。

確認の順番は、項目単位で閲覧を切れる権限、閲覧とCSV出力まで残る操作ログ、マイナンバーの暗号化と削除記録、委託先としての統制資料（ISMS認証、SOC2報告書、セキュリティチェックシート）です。保守や不具合調査でベンダーが本番の個人番号を扱う運用になっていると、クラウドでも番号法上の委託に当たり、委託先の監督義務が生じます。従業員100人以下で単一法人なら製品の標準機能と設定で足ります。グループ会社や独自の評価制度で権限の切り方が製品の型に収まらないときに、周辺の追加開発を検討してください。

人事管理システムが扱う情報の区分と、法令ごとに変わる保護の水準

人事管理システムのセキュリティ要件は、扱う情報の種類で決まります。全項目を同じ強さで守る設計は、守りすぎの項目と守り足りない項目を同時に生みます。

マイナンバー・健康情報・評価情報は根拠法も閲覧してよい人も違う

マイナンバー（個人番号）を含む情報は番号法上の特定個人情報で、利用は源泉徴収票や社会保険の届出といった法定の事務に限られ、必要な範囲を超えた収集・保管も禁じられています。健康診断の結果や病歴は個人情報保護法の要配慮個人情報です。厚生労働省の雇用管理分野における健康情報の留意事項（令和5年10月27日最終改正）は、診断名や検査値のような加工前の情報を産業保健業務従事者に扱わせることが望ましいとし、上司などが扱う範囲は社内規程で定めて周知するよう示しています。人事評価は法令上の特別な区分ではないものの、評価者と被評価者の関係から閲覧範囲を社内規程で絞る情報です。

3つは閲覧してよい人がそれぞれ違います。選定では「人事部」という一つの役割で全部が見える構成になっていないかを最初に確かめてください。

番号法の特定個人情報は事務取扱担当者以外に見せない設計が前提になる

個人情報保護委員会の特定個人情報の適正な取扱いに関するガイドライン（事業者編）は、令和7年6月の一部改正版が現行です。別添1の技術的安全管理措置は、アクセス制御、アクセス者の識別と認証、外部からの不正アクセス等の防止、漏えい等の防止の4項目で構成されています。アクセス制御の項では、事務取扱担当者と取り扱う特定個人情報ファイルの範囲を限定するよう求め、手法の例にユーザーIDに付与するアクセス権の限定を挙げています。

人事管理システムに当てはめると、マイナンバーの欄を見られるのは給与・社会保険の手続き担当者だけで、人事異動や評価を担当する人事部員には見えない状態が出発点になります。マイナンバーを人事管理システムとは別の専用サービスに分けて保管する構成も、この区分を守る手段の一つです。

人事管理システムのセキュリティ機能を選定時に確かめる5つの要件

製品比較の表に並ぶ「暗号化」「権限設定」の丸印だけでは、運用で困る箇所が見えません。デモやトライアルで、次の5点を実際の画面と資料で確かめます。

項目単位の閲覧権限でマイナンバー欄と評価欄を部門の権限から切り離す

権限設定には、メニュー単位、部門単位、項目単位という粒度の違いがあります。部門単位までしか切れない製品では、営業部の部長に部下の住所や評価は見せても、マイナンバーと健康情報は見せない、という設定ができません。確認するのは、同じ従業員レコードの中で項目ごとに閲覧・編集を分けられるか、その設定を役割（ロール）にまとめて付与できるかの2点です。

役割に権限をまとめる考え方はRBAC（ロールベースアクセス制御）の仕組みと導入判断で詳しく扱っています。会社・組織・項目の3軸で権限を切る大企業の設計は大企業の人事管理システムの選び方に譲り、ここでは項目単位で切れることを最低条件にします。

SSOと多要素認証の対応範囲と、退職・異動でアカウントが止まる速さ

ログインの強さは、SSO（シングルサインオン）と多要素認証、IPアドレス制限の3つで見ます。SmartHRの公式セキュリティページは、SSO、2要素認証、IPアドレス制限、操作ログの閲覧をアプリケーションの機能として公表しています。製品を比べるときは、SSOが上位プランだけの機能になっていないか、管理者アカウントにも多要素認証を強制できるかを料金表と合わせて確かめてください。

見落としやすいのは退職時の止まり方です。退職日にアカウントが自動で無効になるか、異動で人事部を離れた人の権限がいつ外れるかを確認します。社内のID基盤からアカウントを配る方式はMFA・SSO・IDaaSの違いと選定を参照してください。

操作ログは閲覧とCSV出力まで残るか、保存期間と取り出し方を確認する

番号法ガイドライン別添1は、組織的安全管理措置として特定個人情報ファイルの利用・出力状況やアクセスログ等を記録するよう示しています。人事管理システムで問題になるのは、変更の履歴は残っても、閲覧とCSV出力が残らない製品があることです。従業員の一覧を誰かが丸ごと出力しても、記録が無ければ後から追えません。

デモでは、ある担当者がマイナンバー欄を開いた操作と、従業員一覧をCSVで出力した操作の両方がログに出るかを見てください。あわせて、ログの保存期間、管理者がログを検索・出力できるか、ログ自体を人事部員が消せない作りかも確かめます。

通信と保存の暗号化に加え、マイナンバーをアプリ層で暗号化しているか

通信のTLS暗号化と、データベースやストレージ全体の暗号化は、主要なクラウド型人事管理システムでほぼ標準になっています。差が出るのは、マイナンバーのような特定の項目をアプリケーションの層でも暗号化しているかです。SmartHRは前述の公式ページで、サーバー側の暗号化に加えてマイナンバーとアクセストークンをアプリケーションレベルでも暗号化していると公表しています。

ストレージ全体の暗号化は、ディスクの持ち出しには効きますが、正規のアカウントを乗っ取られた場合には効きません。項目単位の暗号化と、復号できる権限の限定がそろって初めて、乗っ取りに対する防御になります。

保存期間を過ぎたデータの削除と、削除した記録を残す機能があるか

番号法ガイドライン別添1の物理的安全管理措置は、法令の保存期間を過ぎた個人番号をできるだけ速やかに復元できない手段で削除し、削除した記録を保存するよう求めています。手法の例には、保存期間経過後の削除を前提にした情報システムの構築が挙がっています。製品の確認項目は、退職者のマイナンバーを期限で一括削除できるか、削除の実施日と対象件数を記録として出せるかです。

退職者データを長く残すと、漏えい時の被害が在籍者の数倍に膨らみます。退職者データの棚卸しと消去の手順は退職者データを残さない人事システムの設計で、SQLとPythonの例とともに説明しています。

クラウド型人事管理システムと委託先管理、番号法Q&Aで見る線引き

クラウド型の人事管理システムを使うと、ベンダーのサーバーに従業員の個人情報が置かれます。このとき、ベンダーが法律上の委託先になるかどうかで、利用企業が負う義務が変わります。

クラウド事業者が個人番号を取り扱わない契約なら番号法上の委託に当たらない

個人情報保護委員会の番号法ガイドラインに関するQ&AのQ3-12は、クラウドサービスが番号法上の委託に当たるかを、事業者が契約の履行に当たって個人番号を含む電子データを取り扱うかどうかで判断するとしています。契約条項で個人番号を含むデータを取り扱わない旨が定められ、適切にアクセス制御を行っている場合は委託に当たりません。

委託に当たらなくても、義務が消えるわけではありません。Q3-13は、委託先の監督義務は課されないものの、利用企業が自ら果たすべき安全管理措置としてクラウド上のデータを守る必要があると答えています。選定時に利用規約とデータ処理に関する条項を読み、ベンダー社員が個人番号に触れない定めがあるかを確認してください。

保守や不具合調査で本番の個人番号を使うと委託になる開発会社の落とし穴

同じQ&AのQ3-14は、保守サービスの事業者が個人番号を含む電子データを取り扱う場合は委託に当たるとし、典型例に「個人番号を用いて情報システムの不具合を再現させ検証する場合」と「個人番号をキーワードとして情報を抽出する場合」を挙げています。修正パッチの配布だけを行い、作業中に画面へ番号が出ても書き取りや印刷を防ぐ措置がある場合は委託に当たりません。

受託開発の現場で起きやすいのは、不具合の調査のために本番データベースの複製を開発環境へ持ち込む運用です。これを契約に定めないまま行うと、利用企業は委託先の監督義務を果たしていないことになります。保守契約では、本番の個人番号を調査に使わないこと、使う場合は委託として契約と監督を整えることを、最初に決めておくべきです。

ISMS認証・SOC2報告書・ISMAPリストで委託先の統制を書面で確かめる

個人情報保護法25条は、個人データの取扱いを委託するときに委託先を監督するよう求めています。個人情報保護法ガイドライン（通則編）は、その中身を委託先の選定、契約の締結、取扱状況の把握としています。選定の段階で集める書面は次のとおりです。

ISO/IEC 27001（ISMS）の認証範囲に、その人事サービスの運用部門が含まれているか
SOC2 Type2報告書を開示してもらえるか（SmartHRは受領済みで希望者に限定開示と公表）
政府調達向けのISMAPクラウドサービスリストに登録があるか
経済産業省やIPAの基準に沿ったセキュリティチェックシートの最新版

ISMAPは登録監査機関の外部監査を経たサービスだけが載るため、自社で監査をしない企業には有効な目安になります。ただし未登録でも安全でないとは限らないので、民間企業の選定ではISMSとSOC2報告書を主な根拠にし、ISMAPは加点として扱うのが現実的です。

漏えい時の報告義務から逆算する人事管理システムのログと連絡体制

漏えいが起きたとき、報告に必要な事実を集められるかどうかは、選定時のログと契約で決まります。報告の基準は情報の種類で違います。

健康情報は1件、マイナンバーは100人超か不正目的で報告対象になる差

個人情報保護法では、要配慮個人情報の漏えいは1件でも委員会への報告と本人への通知の対象です。不正アクセスのような不正の目的による漏えいと、財産的被害のおそれがある漏えいも人数に関係なく対象で、それ以外は1,000人を超えると対象になります。一方、番号法ガイドライン別添2では、不正の目的による漏えい、不特定多数への閲覧、本人の数が100人を超える事態が主な報告対象として挙がっています。

情報の種類	報告対象になる主な基準	根拠
健康診断の結果など	1件でも対象	個人情報保護法
住所・評価など一般の情報	1,000人超か不正目的	個人情報保護法
マイナンバー	100人超か不正目的など	番号法

健康情報を人事管理システムに入れるかどうかで、漏えい時の報告の重さが変わります。健康診断の結果まで同じシステムで持つ必要があるかは、産業保健の運用と合わせて判断してください。

速報3〜5日と確報30日に間に合わせるログと連絡経路を契約で決めておく

報告は、事態を知ってから概ね3〜5日以内の速報と、30日以内（不正の目的による場合は60日以内）の確報の2段階です。報告の様式と手順は個人情報保護委員会の漏えい等の対応とお役立ち資料にまとまっています。速報までに対象者の範囲と漏えいした項目を絞るには、前述の閲覧・出力ログが要ります。

クラウド型では、ベンダー側で検知した事故が利用企業へ何時間以内に通知されるか、調査のためにどのログを提供してもらえるかを契約で決めておきます。報告の4類型と期限の数え方は個人情報保護委員会への報告義務の実務で、2026年7月公布の令和8年改正で委託先の取扱い範囲が明記された点は個人情報保護法改正の解説で扱っています。

人事管理システムのセキュリティを製品標準で足りるか判断する境界線

最後に、ここまでの要件を製品の標準機能で満たせるか、追加の開発が要るかを判断します。対策を足しすぎる失敗もあるため、両側の条件を示します。

SaaSの標準機能と設定で足りるのは100人以下で単一法人の企業

番号法ガイドラインは、従業員100人以下の事業者を中小規模事業者とし、安全管理措置の手法を簡素化した対応方法を示しています（個人番号を業として扱う委託先や金融分野、扱う個人情報が5,000人分を超える事業者などは除かれます）。この規模で単一法人なら、項目単位の権限、操作ログ、SSOか多要素認証を備えたクラウド型の標準機能と、取扱規程の整備で要件を満たせます。

この層でオンプレミスへ切り替えたり、暗号化を自社で実装したりするのは過剰です。サーバーの更新とパッチの適用を自社で担う負担が、クラウド事業者の統制よりも弱い箇所を生みます。製品の選び方は中小企業が人事管理システムを選ぶ基準を参照してください。

自社開発や周辺の追加開発を入れるべき場面と、見送るべき対策の判断基準

追加の開発を検討するのは、製品の権限の型に自社の閲覧範囲が収まらないときです。たとえば、グループ会社ごとに人事部が分かれ出向者の情報を出向元と出向先で見せ分ける場合や、評価の閲覧を評価者の段階ごとに切り替える場合が当たります。このときも人事管理システム全体を作り直すのではなく、マイナンバーと健康情報は専用の製品に分け、権限の判定や連携だけを開発する範囲に絞るほうが、守る箇所が少なく済みます。

見送るべきなのは、全項目の暗号化や独自の認証方式を自前で作る対策です。運用できる担当者がいなくなった時点で穴になります。権限の切り方や連携の設計を含めた相談は、一創の人事・労務管理システム開発で受け付けています。費用の見積もり方は人事管理システムの費用の内訳と5年総額にまとめました。

よくある質問

人事管理システムのセキュリティについて、選定や運用の相談でよく受ける質問に答えます。

人事管理システムはクラウドとオンプレミスのどちらが安全ですか？

形態だけで安全性は決まりません。クラウド型はベンダーがISMS認証やSOC2報告書で統制を示し、脆弱性への対応も事業者側で進みます。オンプレミス型はデータを社内に置けますが、サーバーの更新、パッチ、ログの保管を自社で担います。専任の情報システム担当者がいない企業では、クラウド型のほうが保てる水準は高くなりやすいです。オンプレミスを選ぶ条件は人事管理システムの比較記事の判断軸を参照してください。

マイナンバーは人事管理システムで管理してよいですか？

管理してかまいません。ただし番号法ガイドラインに沿って、事務取扱担当者だけが閲覧できるよう項目単位で権限を切り、操作ログと削除記録を残せることが条件です。人事管理システムの権限が部門単位までしか切れない場合は、マイナンバーを専用の管理サービスに分け、給与計算や社会保険の手続きとだけ連携する構成のほうが安全です。

人事評価の情報は社内の誰まで見せてよいですか？

法令で一律に決まっているわけではなく、評価制度と社内規程で決めます。一般的には本人、評価者、人事部の評価担当に限り、同じ部署の同僚や他部署の管理職には見せません。人事管理システムでは、評価の項目を住所などの基本情報と別の権限で管理できるか、評価期間中だけ閲覧範囲を変えられるかを確認してください。

退職者の個人情報はいつ消せばよいですか？

労働基準法109条により、労働者名簿などは退職日から5年（経過措置で当分の間は3年）保存します。マイナンバーは源泉徴収票の控えなど法定の保存期間を過ぎたら、できるだけ速やかに削除し、削除の記録を残す運用です。個人情報保護法22条は、利用の必要がなくなった個人データを遅滞なく消去するよう努めることも求めています。

セキュリティチェックシートではベンダーに何を質問すればよいですか？

この記事の要件に沿って、項目単位の権限設定の可否、閲覧とCSV出力のログの有無と保存期間、マイナンバーの暗号化の層、保存期間後の削除機能、ベンダー社員が個人番号に触れるかどうかの契約条項、事故時の通知期限を質問します。回答はISMSの認証範囲やSOC2報告書と突き合わせ、書面と実際の画面が一致しているかをトライアルで確かめてください。