雇用状態と入社・退職の管理

Drataは、要員ごとの雇用状態をもとに、誰をコンプライアンスの確認の対象にするか、入社時と退職時にどの作業を求めるかを決めます。雇用状態は人事システムやIDプロバイダーから自動で決まり、必要なときは手作業で変えられます。このページでは、要員の雇用状態の管理として、在籍中、退職、入社予定などの区分、入社時と退職時に確認される項目、退職する人の担当を引き継ぐときの注意を説明します。

雇用状態の区分

雇用状態は、PersonnelページのPersonnel statusの列に表示されます。

雇用状態	意味	コンプライアンスの確認
Current employee	在籍中の従業員	対象
Current contractor	在籍中の業務委託者	対象
Former employee	退職した従業員	退職時の作業が済んだかを確かめる対象
Former contractor	契約を終えた業務委託者	退職時の作業が済んだかを確かめる対象
Future hire	入社予定者。入社日が未来の日付	入社日まで対象外と同じく扱われる
Out of scope (ignore)	監査の範囲に含めない要員	対象外
Out of scope (service account)	人ではないサービスアカウント	対象外
Unknown	人事システムの記録をIDプロバイダーの記録に確実に対応付けられなかった	原因を直して解消する

対象外の2つの区分は、対象外の要員とサービスアカウントで説明します。

雇用状態の決まり方

つないでいるもの	決まり方
IDプロバイダーだけ	人ではない別名のアドレスを除き、在籍中の従業員として取り込まれる。アカウントを有効にした日が入社日、無効にした日が退職日になる。業務委託者かどうかは推定されない
人事システムもつないだ場合	人事システムの入社日と退職日から、在籍中か退職済みかが決まる
手作業で変えた場合	監査に関係する例外を記録するために、意図して設定する

人事システムは、雇用状態、入社日、退職日の正となる情報源です。値は、できるだけ人事システムの側で直します。Unknownや、在籍中なのに退職済みと表示される場合の直し方は、人事システムとの連携で説明しています。

雇用状態を手作業で変える

1. Governance → Personnelで、要員を1人以上選びます。
2. Change employment statusを選び、新しい雇用状態を選んで確定します。

1人だけなら、一覧のPersonnel statusの列の選択肢から変えることもできます。選べる雇用状態は、Current employee、Former employee、Current contractor、Former contractor、Out of scope (ignore)、Out of scope (service account)です。

【注意】 手作業で雇用状態を変えると、その要員のIDプロバイダーと人事システムとの同期が止まり、連携先の変更が反映されなくなります。従業員から業務委託者への切り替えなども、できるだけ人事システムで変えて、次の同期を待ちます。手作業で変えた後に同期を再開すると、手作業の値は連携先の値で上書きされます。Future hire、手作業で追加した退職者（Former employee (manually added)、Former contractor (manually added)）の雇用状態は、直接は変えられません。

入社予定者の扱い

入社日が未来の日付の要員は、自動でFuture hireになります。入社予定者は、確認項目とモニタリングテストの対象にならず、入社日までは対象外の要員と同じく扱われます。入社前の人を把握しながら、入社前にテストを失敗させずに済みます。

場面	操作
人事システムで管理している場合	人事システムに未来の入社日があれば、毎日の同期で自動でFuture hireになる
Drataで入社日を入れる場合	要員を開き、Detailsの欄のEditで未来の入社日を入れ、Submitを選ぶ。数分でFuture hireになる
入社予定者を確かめる場合	PersonnelページのEmployment statusでFuture hireを選ぶ

入社予定者を在籍中にするには、入社日を今日か過去の日付に直してから、必要に応じて雇用状態を変えます。入社日が未来の間は、雇用状態を変えられません。Drataで入社日を手作業で変えると、その要員の人事システムからの入社日の同期が止まります。

入社時に確認される項目

入社した要員には、ポリシーへの同意、セキュリティー研修、バックグラウンドチェック、端末の設定などの作業が求められます。要員はこれらをMy Drataで済ませ、Drataが確認項目として確かめます。

確認項目	説明しているページ
ポリシーへの同意	社員への割り当てと同意
セキュリティー研修（HIPAA研修、AI研修）	セキュリティー研修
バックグラウンドチェック	バックグラウンドチェック
IDプロバイダーの多要素認証	IDプロバイダーとの連携
端末の設定（画面ロック、ディスクの暗号化など）	端末の確認項目と是正

入社時の作業の猶予

入社の初日に全ての作業が済むことはまれです。Drataでは、ポリシーのSLA（対応の期限）で、入社時の作業の猶予を決めます。猶予の間は、要員はDrataで確認され、タスクと催促も表示されますが、関係するテストは成功のままです。猶予を過ぎても済んでいない作業は、テストとコントロールの準備状況に影響し始めます。

1. Governance → Policiesを開き、ActiveタブでInformation Security Policyを開きます。
2. OverviewタブのDetailsの欄でEditを選びます。
3. Service level agreementsの欄で、作業を済ませるまでの期間を入れ、Saveを選びます。

猶予は、人事システムの入社日から数えます。監査人は、入社時の作業が決まった期間内に済むことを期待するため、期間は社内の手続きに合わせて決めます。作業が済んでいない要員には、PersonnelページからSend reminder emailで催促のメールを送れます。要員がMy Drataで行う作業は、My Drataで社員が行うことで説明します。

退職時に確認される項目

監査人は、退職した要員について、アクセスの削除などの退職時の作業が速やかに済んだことを、日時の分かる記録で確かめます。ヘルプセンターでは、次のことを示す記録（チケットやチェックリストなど）が求められるとしています。

確かめられること	内容
アクセスの期限内の無効化	システムやアプリへのアクセスを、System Access Control Policyなどで決めた期限内に外した
高リスクのシステムの優先	VPN、メール、GitHub、管理画面など、外部に公開されたシステムやクラウドのシステムを先に外した
アクセスレビューとの突き合わせ	アクセスレビューの記録と照らし、その人がアクセスできた全てのシステムを対象にした
会社の資産の返却	IT機器や入館証などの資産が返却された

Drataでは、Former Personnel Offboardingのテストが、全ての退職者に退職時の証跡があるかを確かめます。このテストは、アクセスの削除（DCF-70）と資産の返却（DCF-688）のコントロールにマッピングされています。退職者のアクセスを外す期限は、System Access Control PolicyのSLAで決め、設定を変えると次のモニタリングの周期から新しい期限で評価されます。

退職時の証跡の状況を確かめる

Governance → Personnelで、Employment statusをFormer employeeに絞ると、Offboarding evidenceの列で証跡の有無を確かめられます。Complianceの絞り込みでOffboarding evidence missingを選ぶと、証跡のない退職者だけに絞れます。

証跡を手作業で付ける

退職時の証跡を付けられるのは、Adminのロールのユーザーで、対象は退職済みの雇用状態の要員だけです。

1. Governance → Personnelで、退職した要員を開きます。
2. Requirementsの表で、Offboarding evidenceを選びます。
3. ファイルはUpload file、JiraのチケットはUpload ticketを選び、URLを貼り付けます。

退職した要員のOffboarding evidenceの画面。ファイルかJiraのチケットを証跡として付ける

証跡には、IDプロバイダーでアカウントが無効になったことを示す画面や書き出し、人事システムで退職の日付が分かる画面、アクセスを外したシステムと日付を記録したチェックリスト、退職時の作業のチケットなどを使います。その要員に当てはまらない場合は、同じ画面から除外を作れます。

Jiraのチケットを自動で集める

退職時の作業をJiraで管理している場合は、Settings → Personnel complianceのHuman Resourcesタブで、Automate offboarding evidence collectionを有効にし、Configureを選びます。

Human ResourcesタブのAutomate offboarding evidence collectionの欄。有効にして、検索するJiraのチケットを設定する

1. 探すチケットのJQL（例：project = "Offboarding" AND type = "Task"）を入れます。プロジェクトと課題の種類は、1つずつ指定します。
2. 要員との照合を、名前かメールアドレスで行うかを選び、Jiraの項目に対応付けます。
3. 照合の例を5件確かめて、Finishを選びます。

【注意】 監査に含まれるのは、Jiraの解決日（Resolution date）がある、完了したチケットだけです。チームが管理するプロジェクト（team-managed）のチケットや、解決日のないチケットには、DrataAcceptのラベルを付けます。チケットの説明やコメントには、アクセスを外したシステムを書いておきます。

Jiraを使わない場合は、Drata APIで要員の記録に証跡をアップロードすることもできます（Drata APIとMCP）。

退職する人の担当を引き継ぐ

退職する人がコントロールオーナー、証跡のオーナー、ポリシーオーナー、承認者などを担当している場合は、退職の手続きの前に後任に引き継ぎます。ヘルプセンターでは、次の動きが示されています。

担当	引き継がなかった場合
ポリシーオーナー	Drataへのアクセスが外れると、ポリシーは最初のAdminに自動で割り当て直され、そのAdminにメールが届く
コントロールの承認者	承認者がいなくなると、承認者が必要であることを示すバナーが表示される

コントロールオーナーと承認者の引き継ぎの手順は、コントロールオーナーと承認で説明しています。管理者が退職する場合は、管理者が交代するときの引き継ぎも確かめてください。