イベント管理システムのセキュリティ｜来場者名簿を外部SaaSに預ける判断と確認項目

来場者300人分の氏名・会社名・メールアドレス・名刺画像。イベントを1回開くたびに、この塊が社外のクラウドサービスに積み上がっていきます。事故が起きたとき、個人情報保護法上の説明責任を負うのはシステムを売ったベンダーではなく、名簿を集めた自社です。この記事では、イベント管理システムのセキュリティを製品機能のチェックリストではなく、利用企業側に残る責任から整理します。委託先の監督として何をすれば足りるのか、選定時に見る暗号化・権限・ログ、契約書に落とす条項、来場者名簿を外部SaaSに預けてよい条件の線引きまで扱いました。

まとめ：外部SaaSに預けてよい条件と、選定で外せない確認項目

先に結論を示します。無料イベントで、集める情報が氏名・会社名・連絡先にとどまり、決済も会員基盤との連携もない。この範囲なら来場者名簿を外部SaaSに預けて構いません。自社で受付システムを作って守るより、ISMS認証を持つ事業者の基盤に載せたほうが実際の防御力は上がります。

逆に、会員データベースとの突合、カード情報の自社保持、顔認証や属性の取得。いずれかに当てはまるならSaaS単体では収まりません。会員基盤と接続する部分は自社の管理下に置き、SaaSは受付フォームと当日照合に役割を絞ります。

製品選定で外せない確認は5つです。管理者権限を役割ごとに分けられるか、多要素認証を強制できるか、監査ログを90日以上残せるか、暗号化方式と保管国が開示されるか、契約終了時の返還・削除が証明付きか。価格やUIの好みより先に、この5点を見てください。どれだけ良い製品でも、法第25条が定める委託先の監督義務は自社に残ります。

イベント管理システムが抱える情報資産と、漏えいが起きる4つの経路

守る対象を先に確定させないと、対策の過不足を判断できません。

受付・決済・アンケートで集まる情報の種類と、要配慮情報が混ざる場面

申込フォームで集まるのは氏名・所属・役職・メールアドレス・電話番号が中心です。有料イベントの決済が加わるとカード情報が、名刺読み取りを入れると名刺画像が乗ります。見落としやすいのは、参加登録の設問に紛れ込む要配慮個人情報です。食物アレルギーの申告、車椅子利用の有無、宗教上の食事制限。取得には原則として本人の同意が要り、オプトアウトによる第三者提供もできません。

打ち手は単純です。こうした設問を「配慮が必要な事項があればご記入ください」という自由記述に一本化し、イベント終了後72時間以内に削除する運用にします。設問として構造化して保存するほど、管理義務は重くなります。

公開申込ページからの流出経路と、管理画面の権限過多で起きる内部要因

外部からの侵入経路は、不特定多数に開いている申込ページに集中します。入力値の検証不足によるSQLインジェクション、申込確認画面のURLに連番のIDが入っていて他人の登録内容が見えてしまう直接オブジェクト参照の欠陥。この2つが典型です。SaaS製品ならベンダー側で対処されている前提ですが、独自にフォームを埋め込んだ場合は自社の責任範囲になります。

もう一方の経路は内部です。イベント運営は繁忙期に人が増えるため、全員を管理者権限で登録する運用が起きがちです。名簿の一括ダウンロード権限が10人以上に配られた状態は、外部攻撃より現実的なリスクを抱えます。

当日の現地運用で生じる紙とUSBの持ち出しリスクと、外部スタッフの扱い

当日の会場で起きる事故は、システムの外側にあります。通信が不安定な会場に備えて名簿をPDFで印刷し、そのまま回収されずに残る。受付端末が持ち込みのノートPCで、名簿CSVがデスクトップに置かれたまま持ち帰られる。運営を派遣スタッフやイベント会社に任せている場合、その端末は自社の管理外です。

紙の名簿には通し番号を振り、終了時に枚数を突き合わせてその場で裁断するところまでを手順書に書きます。外部スタッフには閲覧のみ可能な当日用アカウントを発行し、終了後に無効化する。この2つで現地の穴はほぼ塞がります。

個人情報保護法が利用企業に課す義務と、委託・第三者提供の切り分け

「ベンダーが対策しているから安心」という説明は、法的には成り立ちません。名簿を集めた事業者に残る義務を条文の単位で確認します。

SaaS利用は委託か第三者提供か｜本人同意の要否が変わる判定の分かれ目

イベント管理SaaSに参加者情報を入れる行為は、通常は法第27条第5項第1号の「委託」に該当します。委託なら第三者提供にあたらず、本人の同意は要りません。ただしSaaS事業者が預かったデータを自社の目的で使わない場合に限られます。

分かれ目は利用規約です。参加者データを匿名化して自社サービスの改善に使う、業界動向レポートの集計母数に含める。こうした条項があると、委託の範囲を超えた提供と評価される余地が生まれます。契約前に「委託された個人データを、委託の目的以外に取り扱わない」旨の明記を確認し、無ければ覚書で補ってください。データが国外のサーバーに保存される場合は、法第28条の外国にある第三者への提供の規律も併せて検討します。共催セミナーで名簿を相手企業へ渡す場合は委託ではなく第三者提供にあたるため、共催セミナーの名簿分配と同意設計で扱った共同利用の要件も確認してください。

委託先の監督として求められる契約・確認・是正の3点と、実務での落とし方

法第25条は、委託元に「必要かつ適切な監督」を課しています。個人情報保護委員会のガイドラインが示す内容は3段階です。委託先を適切に選定すること、安全管理措置を契約に盛り込むこと、そして取扱状況を把握することです。

実務では、選定時にセキュリティチェックシートの回答と第三者認証の写しを提出させ、契約書に安全管理措置と再委託の条件を明記し、年1回は認証の有効期限と重大インシデントの有無を確認する。この3つで足ります。契約書を交わしただけで年次確認をしていない状態は、委託先のミスでも委託元の監督義務違反を問われます。記録はメールのやり取りを含めて残してください。

漏えい発覚から速報・確報・本人通知までの期限と、報告主体になる会社

令和4年4月1日から、個人データの漏えい等で個人の権利利益を害するおそれがある場合、個人情報保護委員会への報告と本人への通知が義務になりました。速報は発覚からおおむね3日から5日以内、確報は30日以内。不正アクセスや内部不正など不正の目的によるおそれがある場合は確報が60日以内に延びます。速報の3日から5日には土日祝日が含まれます。

報告義務を負うのは委託元と委託先の双方ですが、委託先が委託元に通知したときは委託先の義務が免除されます。つまり、SaaS事業者から連絡を受けた自社が委員会への報告主体になります。契約書に「インシデント覚知後◯時間以内に委託元へ通知する」条項を入れておかないと、速報の期限に間に合いません。24時間以内を目安に交渉してください。

製品選定で確認するセキュリティ要件と、第三者認証で裏を取る手順

ここからは選定段階の具体です。営業資料に並ぶ「万全のセキュリティ体制」を、確認可能な項目に翻訳していきます。

アクセス制御と認証で見る項目｜権限粒度・多要素認証・IP制限の実装状況

権限は役割ごとに分けられるかを見ます。名簿の閲覧のみ、受付チェックインのみ、一括出力を含む管理者。この3階層に分離できることが条件です。一括ダウンロード権限だけを切り出せる製品は、外部スタッフを入れる運用に耐えます。

認証では、管理者アカウントへの多要素認証を組織単位で強制できるかを確認してください。個人が任意で設定できるだけの製品は、実際には誰も設定しません。管理画面への接続元IPアドレスを制限できると、認証情報が漏れた場合の被害を止められます。SAMLによるシングルサインオンに対応していれば、退職者のアカウント無効化を人事の手続きに一本化でき、運用の抜けが減ります。

暗号化と保管場所の確認｜通信・保存の方式とデータの所在国を聞く質問文

通信の暗号化はTLS 1.2以上が現在の水準で、満たさない製品は候補から外します。確認が要るのは保存時の暗号化です。「データベースは暗号化しています」という回答には、AES-256などの方式名と鍵の管理主体を聞き返してください。クラウド事業者のマネージドな鍵管理か自社保有かで、事故時の説明が変わります。

保管国も同じです。データの所在国、バックアップの保存先、サポート担当者がどの国から管理画面に入るか。この3つを質問状に入れます。どちらがどこまで守るのかという整理には、クラウドセキュリティの責任共有モデルの考え方をそのまま当てはめられます。

監査ログの保存期間と提供形式｜事故調査に使える粒度かを見分ける基準

ログは、事故が起きてから取得できるものではありません。確認するのは、何が記録されるか、どれだけ残るか、どう取り出せるかの3点です。記録の粒度は、ログイン成否と接続元IPアドレス、名簿の閲覧・検索、CSVの出力操作、権限の変更が最低限になります。特に一括出力の記録が無い製品では、内部不正の調査ができません。

保存期間は90日を下限とし、確報の期限が60日であることを踏まえると180日あると余裕が生まれます。取り出し方は、管理画面での閲覧だけでなくCSVやAPIで外部に出せるかを見てください。画面でしか見られないログは、退会後に手元へ残りません。

ISMSやISO27017などの認証と第三者報告書で確かめられる範囲と限界

ISO/IEC 27001（ISMS）は情報セキュリティ管理の仕組みが回っていることの認証で、クラウドサービス固有の管理策を足したものがISO/IEC 27017です。プライバシーマークは個人情報の取扱いに範囲を絞った国内制度、SOC 2 Type IIは一定期間の統制運用を第三者が検証した米国基準の報告書にあたります。

限界もあります。認証は「そのシステムに脆弱性が無いこと」を保証しません。ISMSの認証範囲が本社の管理部門だけで、開発拠点が範囲外というケースは実在します。取得の有無ではなく、認証書の適用範囲と登録番号で対象サービスが含まれるかを確認してください。SOC 2の報告書は、監査対象期間と例外事項の欄に実態が出ます。

委託契約に落とす条項｜再委託・脆弱性診断の可否・終了時のデータ返還

確認した内容は、契約書の条項にしないと効力を持ちません。標準の利用規約に足りないことが多い3項目を挙げます。

契約書に明記する安全管理措置と再委託の可否｜サブプロセッサ開示の扱い

安全管理措置は、組織的・人的・物理的・技術的の4分類ごとに委託先が講じる措置を契約または付属文書へ書き出します。ガイドラインの枠組みと揃えると確認漏れが減ります。

再委託は事前の書面承諾を要件にするのが原則です。ただしSaaS事業者はインフラをクラウド事業者に、メール配信を別のサービスにと、多層の再委託が前提になっています。個別承諾を求めると契約が進まないため、実務では「サブプロセッサの一覧を公開し、追加時は30日前に通知する。利用企業は異議を申し立てられる」形に落とします。一覧が公開されていない事業者には書面で提出を求めてください。

SaaSへの脆弱性診断が禁止される理由と、自社開発部分で診断する範囲

マルチテナント型のSaaSは、利用企業が独自に脆弱性診断を実施することを規約で禁じている製品が大半です。同じ基盤を他社と共有しており、診断のトラフィックが他社に影響するからです。禁止条項に反して診断をかければ契約違反になります。

取れる手段は2つあります。ベンダーが実施した診断結果のサマリーを提出させること、そして事前申請による診断を認めるプランがあるかを確認することです。一方、自社で開発した申込ページや、SaaSのAPIを叩く連携部分は自社の管理下にあるため、こちらは診断の対象になります。脆弱性診断の種類と費用相場を踏まえ、公開範囲の広い申込ページを優先して実施してください。

契約終了時のデータ返還・削除の証明と、サービス終了に備える持ち出し手順

解約時に何が起きるかを、契約段階で決めておきます。返還の形式はCSVかJSONか、返還後の削除までの猶予は何日か、削除完了を証明する書面が出るか。この3点を条項に入れてください。証明書の発行に対応しない事業者でも、削除完了の通知メールには応じることが多く、交渉の余地があります。

あわせて、事業者側の都合によるサービス終了に備えます。この分野は製品の入れ替わりが速く、買収による統合やプラン廃止が起きます。四半期に1度は名簿と参加履歴をエクスポートし、自社のストレージへ暗号化して保管する。過去の参加履歴は次回の集客資産でもあり、失えば営業側の損失に直結します。

来場者の個人情報を外部SaaSに預ける是非｜預けてよい条件と自社構築の線

ここが判断の核心です。委託は法的に許されていますが、許されることと自社にとって妥当であることは別になります。条件を切って言い切ります。

外部SaaSに預けてよい条件｜無料イベント・氏名と連絡先のみ・年数回の規模

次の条件をすべて満たすなら、外部SaaSに預けてください。集める情報が氏名・会社名・部署・メールアドレス・電話番号にとどまる。参加費が無料で決済情報を扱わない。年間の開催が10回以下で、1回あたり数百人規模。既存の会員データベースと参加者を突合しない。

この範囲で自社構築を選ぶのは費用対効果が合いません。申込フォームの脆弱性対策、TLS証明書の更新、権限管理、ログ保全を自前で維持する工数が、SaaSの月額を上回ります。規模の線引き自体は中小企業のイベント管理システム導入判断で年間開催数と参加者数の2軸から整理しているため、併せて判断してください。

自社構築に倒すべき条件｜会員基盤との接続・決済保持・顔認証や属性の取得

一方、次のいずれかに該当するならSaaS単体で完結させるべきではありません。会員データベースや顧客管理システムと参加者情報を突き合わせる。有料イベントでカード情報を自社側に通す。顔認証やビーコンで行動データを取得する。医療・金融など業法上の追加規律がかかる情報を扱う。

とはいえ、全部を自社で作る必要はありません。現実的な構成は分離です。申込受付と当日チェックインはSaaSに任せ、会員基盤との突合は自社側で行い、SaaSからは参加IDと最小限の項目だけをAPIで受け取る。カード情報は決済代行のトークン方式に寄せ、自社システムへ番号を通さなければPCI DSSの直接の適用範囲を狭められます。この分離設計と公開部分の安全性は、脆弱性診断・セキュリティ診断で実測してから運用に入るのが確実です。

判断を誤る典型｜無料プランでの本番運用と、担当者退職で失う管理者権限

失敗のパターンは2つです。1つは、無料プランや個人向けプランのまま本番運用を続けること。無料プランは監査ログが残らず、権限も分離できず、多くはサポートの対象外です。事故時に調査ができないため、報告書に「経路不明」と書くことになります。有料プランへの切り替えは、参加者が100人を超えた時点で判断してください。

もう1つは、管理者アカウントを担当者の個人メールアドレスで作る運用です。退職や異動で引き継がれず、過去の名簿にアクセスできなくなる。削除依頼を受けても対応できず、法第35条の利用停止・消去の請求に応えられません。管理者は共有メールアドレスで作成し、副管理者を必ず2人以上置きます。

令和8年改正が受付運用に及ぼす影響と、開催前後で回す点検の手順

法制度は動いています。2026年7月に公布された改正法には、イベント受付の運用へ直接効いてくる論点が含まれました。時点を明記したうえで整理します。

令和8年改正の該当論点｜特定生体個人情報と委託先規律の明確化の位置づけ

改正個人情報保護法は2026年7月10日に成立し、同年7月17日に令和8年法律第56号として公布されました。柱は課徴金制度の導入、16歳未満の子どもに関する規律強化、顔認証等の特定生体個人情報の規律強化、統計作成やAI開発向けデータの同意不要化、委託先規律の明確化、漏えい時の本人通知要件の緩和です。罰則関係の一部は2027年1月17日に先行施行、本体部分は公布から2年を超えない範囲で政令が定める日に施行される見込みとされています。2026年8月時点で政令は未確定のため、施行日は個人情報保護委員会の公表を確認してください。

イベント運営に効くのは、顔認証の規律強化と委託先規律の明確化の2点です。改正の全体像と対応の優先順位は令和8年改正の解説で扱っているため、法務側の検討はそちらを起点にしてください。

顔認証受付を入れる場合に追加で要る同意設計と、代替手段を残す運用

顔認証による受付は、待ち行列の解消には効きます。ただし顔の特徴量データは特定生体個人情報として規律が強まる方向にあり、同意取得と利用目的の限定が現在より厳しく運用される可能性があります。導入するなら、施行を待たず次の3点を先に組み込んでください。

1. 申込フォームで顔認証利用の同意を独立したチェック項目にする
2. 顔特徴量の保存期間をイベント終了後7日以内などに限定して明示する
3. 顔認証を使わないQRコード受付の窓口を必ず併設する

3つ目を軽視すると、同意しない参加者を受け付けられなくなります。同意が実質的に強制される設計は、有効性そのものを疑われます。16歳未満が参加する学校向け・親子向けイベントでは法定代理人の同意が要る場面が出るため、顔認証は見送るのが安全です。

開催前・当日・終了後で回す点検項目と、名簿を消し込む期限の決め方

運用は、イベントごとに同じ手順を回します。開催前はアカウント棚卸しと権限確認、当日アカウントの発行、ベンダーのインシデント窓口の確認。当日は受付端末の持ち出し管理と紙名簿の枚数管理。終了後は当日アカウントの無効化、紙名簿の裁断、名簿の消し込みです。

保存期間は利用目的から逆算します。次回の案内に使うなら1年、営業リードなら自社のリード管理ポリシーに合わせる。目的が終わった情報を持ち続けても、漏えい時の被害が増えるだけです。

よくある質問

選定と運用の現場で実際に挙がる質問をまとめました。

イベント管理システムのセキュリティで最初に確認すべき項目は何ですか？

管理者権限の分離と多要素認証の強制、この2つを最初に見てください。暗号化や認証取得は多くの製品が水準を満たす一方、権限設計は差が大きく、事故の実際の入口になりやすい部分です。この2点を満たさない製品は、運用でカバーしようとしても抜けが出ます。次に監査ログの保存期間、その次に暗号化方式とデータ保管国という順で確認します。

来場者の個人情報を外部のクラウドサービスに預けても法律上問題ありませんか？

個人情報保護法上は委託にあたるため、本人の同意なく預けられます。ただし条件が2つあります。1つは、委託先が預かったデータを委託の目的以外に使わないこと。利用規約に自社サービス改善への利用があれば、委託の範囲を超える余地があります。もう1つは、法第25条の監督義務が自社に残ることです。契約に安全管理措置を盛り込み、年1回は取扱状況を確認してください。国外保存なら外国にある第三者への提供の規律も検討します。

SaaS型のイベント管理システムに自社で脆弱性診断をかけられますか？

多くの製品では利用規約で禁止されています。マルチテナント構成のため、診断のトラフィックが同じ基盤を使う他社に影響するからです。代わりに、ベンダーの診断結果サマリーの提出を求めるか、事前申請で診断を認めるプランの有無を確認します。自社で開発した申込ページ、APIの連携部分、独自に埋め込んだフォームは自社の管理範囲なので診断できます。公開範囲が広い申込ページから優先してください。

参加者名簿が漏えいしたとき、いつまでに誰が報告する必要がありますか？

個人の権利利益を害するおそれがある場合、個人情報保護委員会への報告と本人への通知が必要です。速報は発覚からおおむね3日から5日以内、確報は30日以内で、不正アクセスなど不正の目的によるおそれがある場合の確報は60日以内に延びます。速報の期限に土日祝日も含まれる点に注意してください。報告主体は委託元と委託先の双方ですが、委託先が委託元に通知した場合は委託先の義務が免除されるため、実務では名簿を集めた自社が報告します。ベンダーからの通知が遅れると期限に間に合わないので、契約に通知期限を入れておきます。

顔認証やQRコードでの受付にすると、追加で必要になる対応はありますか？

QRコードの受付は、コードに個人情報を埋め込まず参照用のIDだけを持たせる設計にすれば追加対応はほぼ不要です。顔認証は扱いが変わります。顔の特徴量は令和8年改正で特定生体個人情報として規律が強まる方向にあり、同意の取得と利用目的の限定、保存期間の明示が必要になります。代替受付を必ず併設し、同意しない参加者も入場できる形にしてください。16歳未満が参加するイベントでは、顔認証の採用自体を見送る判断が無難です。

関連記事

• イベント管理システムとは？主な機能や特徴：機能の全体像から確認する場合の入口です
• イベント管理とは？業務の全工程と判断基準：受付から事後フォローまでの工程整理です
• 二段階認証とは？多要素認証との違い：管理者の認証方式を決めるときの参照先です
• ISMSクラウドセキュリティ認証（ISO/IEC 27017）：第三者認証を読み解く背景知識です
• WAFとは？IPS・IDSとの違いと選び方：申込ページを自社で公開する場合の防御手段です