SECURITY FIELD LAB / APPLICANT DATA

先に結論：フォルダではなく、データの状態を管理する

履歴書を一つのクラウドへ集めても、全員が閲覧・編集でき、期限なく残るなら管理は完成していません。収集、選考中、確定、削除待ちの四状態を定義し、状態が変わるたびに閲覧者、編集権限、保管期限を見直します。

仮説「保存場所の統一」だけでは漏えい・誤共有・削除漏れを防げない。検証四状態×四操作のマトリクスをダミーデータで再現する。

応募者データを四状態へ分ける

応募者データを収集、選考中、確定、削除待ちの四状態に分ける図
状態の変更を、フォルダ移動ではなく責任者の確認として記録します。
状態 主な目的 閲覧者 次の確認
収集 応募受付・重複確認 受付担当 目的外項目がないか
選考中 面接・評価 採用担当・面接官 共有範囲を絞ったか
確定 内定・不採用処理 責任者 必要な記録だけ残すか
削除待ち 期限到来・例外確認 削除承認者 削除証拠を残したか

権限は役職ではなく操作で分ける

採用担当、面接官、管理者と閲覧、編集、共有、削除を交差させる権限図
「採用チームだから全員編集」ではなく、作業に必要な操作だけを付与します。

クラウドストレージには権限、版管理、ログなどの機能がありますが、設定だけで安全が保証されるわけではありません。共有リンクの有効期限、外部共有、端末ダウンロード、退職・異動時の権限解除までを一つのチェックリストで確認します。

削除は最後の作業ではなく、設計項目

期限通知、承認、削除、記録を順に行う監査証拠の図
保管期限は一律に決めず、目的・社内規程・法的義務を確認して設定します。
  1. 期限通知 対象ファイル、理由、責任者を一覧化。
  2. 例外承認 継続保管が必要なら目的と次回期限を記録。
  3. 削除 原本、複製、共有リンク、端末保存を確認。
  4. 証拠 実施日時、担当者、対象範囲を監査ログへ残す。

10件のダミー応募で導入判断する

  • 誤共有せず、必要な担当者だけが閲覧できたか。
  • 版の上書きや重複ファイルを追跡できたか。
  • 期限到来から削除・例外承認まで再現できたか。
  • 管理者不在でも手順書から同じ操作ができたか。

ファイル名よりメタデータをそろえる

氏名だけをファイル名にすると、同姓同名、再応募、選考ポジション変更で識別が崩れます。応募ID、募集ID、受付日、状態、次回期限を管理表に持ち、ファイル名へ個人情報を過剰に埋め込まない設計にします。メール添付を保存した時点で原本の場所と複製数を記録し、どの版が最新かを一つの項目で示します。

共有リンクは便利ですが、転送後の閲覧者を追えない設定なら採用データには向きません。リンク期限、ダウンロード可否、外部共有、端末保存をダミーファイルで試し、受信側の端末でも確認します。退職・異動のテストアカウントを無効化し、既存リンクや同期済み端末から閲覧できないことも検証します。

出典と確認上の注意

個人情報の利用目的、安全管理、委託先管理は個人情報保護委員会の資料を確認しています。保管期間や削除義務はデータの性質・社内規程・法的義務で異なるため、専門家へ確認してください。サービス条件は申込時の公式表示が優先されます。