北京の外資系保険会社オフィスのITサポート：証拠という試験

要点: 外資系保険グループの北京拠点は、日常の「ITは動いているか」というテストにはすべて合格しながら、監査で本当に問われる唯一の質問――保険契約者データへのアクセス権を誰が持っていたか、何がいつパッチ適用されたか、データが実際どこに存在するか――には答えられないことがある。規制対象となる中国拠点のITサポートは、稼働率ではなく証拠によって評価される。

外資系保険グループの北京オフィスを思い浮かべてほしい。おおよそ九十人、引受サポート、保険金請求処理、販売網、経理にまたがるスタッフが、英語と中国語が併用されるバイリンガルの環境で働いている。ノートパソコンは起動し、メールは動き、リージョナルのシステムに接続する業務アプリケーションもほとんどの日は問題なく動作する。目に見える指標だけで見れば、ITは仕事をきちんとこなしている。ところがグループのコンプライアンスチームが年次レビューを予定したり、データ保護に関する規制当局の照会が中国カントリーマネージャーの机に届いたりすると、問いの性質はまったく変わる。誰もWi-Fiが速いかどうかは聞かない。過去十二カ月間、誰が保険金請求データベースにアクセスできたか、保険契約者記録を保持するサーバーは予定どおりパッチ適用されていたか、そのデータが物理的にも論理的にもどこに存在するのかを聞かれる。これらはまったく別種の問いであり、稼働維持だけを目的に組まれたサポート体制には、すぐに出せる答えがないことが多い。

本稿は、こうした拠点の中国担当IT・オペレーション責任者に向けて書いている。外資系保険グループまたは金融機関が北京に置く認可法人で、リージョナルオフィスとグループのITまたはリスク機能の両方に報告し、多くの場合、コンプライアンス要件から意図的に設計されたのではなく、自然に育ってきたIT環境を引き継いでいる。これは架空の複合シナリオであり、特定の実在企業ではないが、Brocentが外資系金融機関の中国事業を支援する中で繰り返し出会ってきたパターンである。Brocentは2007年に北京で設立され、2021年以降シンガポールに本社を置き、2016年以降香港にオフィスを構えている――つまり中国向けの業務は、PIPLやMLPSが現在の形で存在するより前から、常に現地の運営上の現実と、海外グループが期待する「きちんと運営されている」水準の両方を満たさなければならなかった。

外資系保険グループの北京拠点が、他とは異なる種類のIT案件である理由

外資系保険グループや金融機関が北京に置く認可法人は、一般的な中小企業のIT案件ではない。それを一般的な案件として扱うことこそ、多くのサポート体制が静かに崩れていく原因である。認可を受けた保険法人は、貿易や製造業の駐在員事務所には存在しない規制の境界の内側にある。取り扱う個人情報は、性質上明確にセンシティブなものが多い――引受や保険金請求に紐づく健康情報、財務履歴、身分証明書情報――そして通常、要求があれば証拠を提示することを求めるグループコンプライアンスの枠組みの下で運営されている。単に統制が存在すると主張するだけでは足りない。Brocentは、単一の報告系統の下で複数のアジア拠点にわたりITを調整する企業を含め、外資系金融機関の中国事業をグループ規模で支援してきたが、そこから得られる教訓は毎回同じだ。このセグメントに合うIT関係とは、記録の生成をサービスの通常の成果物として扱うものであり、チケットを最速で閉じるものではないということである。速度は依然として重要だが、それはもはやこの案件が評価される軸ではない。

九十人規模の外資系保険北京オフィスの内側

複合シナリオはこうだ。約九十人のスタッフが北京の単一拠点に集中し、引受サポート、保険金請求処理、販売・営業支援、経理、そして北京の経営陣とリージョナルまたはグループのコンプライアンス責任者の両方に答える小規模な現地コンプライアンス機能に分かれている。IT環境は、まったくありふれていながらほとんど誰も検証したことのない混合構成だ――保単管理コンポーネントを稼働させるために何年も前に導入された数台の老朽化したオンプレミスサーバー、ローカルのファイル共有と印刷・スキャン環境が、より新しいクラウドワークロードと並存している。メールと協働のためのMicrosoft 365、クラウドホスト型のCRMまたは販売支援ツール、そしてリージョナルまたはグローバルのシステムとWAN経由で通信する保険金請求または引受モジュールが増えつつある。

このスタッフ層は必然的にバイリンガルである――グループへの報告とリージョナルとの調整には英語、現地の運営、販売パートナー、そして保険金請求や引受に関する日常的なやり取りの大半には中国語――そしてITの関係は両方の言語で快適に機能しなければならない。構造的に厄介なのは報告関係だ。現地のカントリーマネージャーは、九十人の生産性を保つITを望む。リージョナルオフィスは、本来標準化されているはずのITフットプリントの中で中国事業が例外にならないことを望む。そして通常は中国国外に拠点を置くグループのITまたはリスク機能は、中国拠点が他と同じ統制基準を満たしているという保証を、アクセスレビュー、パッチ適用サイクル、データ所在地といった言葉で――現地のITサポート業者がこれまで一度も語ることを求められたことのない言葉で――求める。三者いずれも間違っているわけではない。それぞれ異なるものを最適化しているだけであり、その板挟みになる拠点自身が、三者を調整しなければならない。

実際の問題その一：保険契約者データがPIPLの利害を駐在員事務所よりはるかに高く押し上げる

北京の貿易会社の駐在員事務所が扱うのは、従業員の記録と業務上の通信――実質的な義務はあるが、扱うデータ量は管理しやすい範囲にとどまる。一方、保険法人が扱うのは保険契約者の個人情報であり、しばしばPIPL（個人情報保護法）が定義するセンシティブ個人情報に該当する。引受判断や保険金請求評価に紐づく健康・医療データ、財務・身分情報、時には家族や受益者の情報も含まれる。センシティブ個人情報は、PIPLの下で通常の個人情報より明らかに高いコンプライアンスの基準を課される――より狭い正当な目的の根拠、より厳格な同意と必要性の要件、そしてアクセス制御、暗号化、影響評価に対するより高い期待――そしてその量とセンシティブさは、同規模の一般的なオフィスを支援することに慣れた汎用型ITプロバイダーが、これまで設計上想定したことのない水準であることが多い。

この露出は抽象的なものではない。実際には次のような形で現れる。保険金請求処理システムのアクセス権限が、設定した本人が退職して以来一度もレビューされていない。ノートパソコンに保険金請求書類のローカルキャッシュが残っているが、デバイスレベルの暗号化やデータ漏洩防止ポリシーの対象になったことがない。共有ドライブでは「誰が引受ファイルを見られるか」という問いに、文書化されたアクセスモデルではなく、数年前に誰かが設定したフォルダ権限が答えを出している。これらはいずれも悪意はもちろん、不注意すら必要としない。必要なのは、ITサポートの範囲が、そのシステムが保持するデータではなく、システムを稼働させ続けることを中心に設計されていたという事実だけであり、この範囲設定は、データ保護に関する照会や保険契約者からの苦情がその問いを表面化させるまで、目に見えない。

実際の問題その二：老朽化したオンプレミス環境は、調達上の脚注ではなく、現在進行形の運用リスクである

オンプレミスサーバーとクラウドワークロードが並存する混合環境は、この規模と年数の拠点にとってまったく普通のことだ。普通でなく、むしろ危険なのは、大きな障害なく長年動いてきたという理由だけで、オンプレミス側を解決済みの問題として扱ってしまうことである。ハードウェアは自ら劣化を告げない。六、七年稼働してきたサーバーは、五年保証のステッカーが示唆するよりも故障に近く、当該モデルの予備部品はすでに製造中止になっている可能性があり、この環境をもともとサイジングした担当者はすでに異動していることが多く、中核の保単管理サーバーがある火曜日の午後に故障したら何が起きるのかを、自信をもって説明できる人が誰もいなくなっている。

たいていの企業にとって、これは許容できる程度の不便にすぎない。しかし保険法人にとって、保険金請求処理や引受サポートを一日止めるハードウェア障害は、単なるIT内部の頭痛の種ではなく、規制および顧客対応の側面を伴う事業継続イベントである。ハードウェア保守を現在進行形の運用リスクとして扱う――実際の予備部品戦略、文書化された更新計画、障害になる前に劣化を検知する監視を備える――ことは、予算が許すときに見直せばよい項目として扱うこととはまったく別の仕事である。一般的なオフィス向けに組まれたほとんどのサポート体制は、後者をデフォルトにしている。一般的なオフィスにとっては、たいていそれで十分だからだ。

実際の問題その三：グループのITポリシーと現地の義務は、別々の人間によって書かれている

グローバルまたはリージョナルのグループITポリシーは、ほぼ構造的に、中国を specifically に念頭に置いて書かれたものではない。パスワードの複雑性、パッチ適用サイクル、エンドポイント標準、利用規約といった基準線を設定するが、それはどこでも妥当でありながら、どこか特定の場所にとっては十分ではない。中国の現地における義務は、主にPIPLと、ネットワークおよびデータセキュリティのための等級保護制度（MLPS）の枠組みの下で、データ取り扱い、越境移転、システムのセキュリティ等級づけについて独自の要件を課すが、これらはグループポリシーの起草者が対応を求められたことのない要件である。起草者は別の法域の別の問題を解決していたからだ。

この二つの文書は、あからさまに矛盾するわけではない。単に完全には重ならないだけであり、リスクはまさにその隙間に集中する。グループポリシーがクラウドバックアップの対象を指定していても、そのデータが物理的にどこに存在するかまでは指定していないことがある――この詳細は、グループポリシーが起草された際に想定されていた大半の法域よりも、中国においてはるかに重い意味を持つ。グループポリシーの文言に忠実に従う現地のIT機能は、グループ自身の基準には準拠していながら、現地のデータ取り扱いに関する単純な問いには答えられない、という状態に同時に陥り得る。理由は、その二つを調整する役割が誰にも正式に割り当てられなかったというだけである。北京拠点の誰かが、この調整を能動的に担わなければならない――グループポリシーを、その上に積み上げていく土台として扱い、すでに現地の義務をカバーしていると思い込む天井としては扱わない――そして実務上、この役割は、正式に割り当てられたかどうかにかかわらず、現地のITサポート関係を握る側にデフォルトで落ちてくることが多い。

実際の問題その四：監査人が受け入れるだろう証拠を、誰も取りまとめていない

これは他の三つの問題をつなぐ問題であり、最悪のタイミングで表面化する問題でもある。アクセスログは技術的にはどこかに存在しているかもしれない。パッチ記録は、誰かが数日かけて再構築すれば、管理コンソールから推測できるかもしれない。データの所在地も、誰かがすべてのワークロードをそのホスティング先までたどれば判明するかもしれない。しかし「圧力の下で技術的に再構築可能」であることと、「要求されればすぐに提示できる」ことはまったく別物であり、グループの監査チームや規制当局がデータ保護に関する質問をしてきたとき、本来すでに存在しているべき全体像をITが取りまとめるのを一週間も待ってはくれない。

この隙間は、統制が欠けていることが原因であることはめったにない。この立場にある拠点の多くは、実際には妥当なアクセス権限を設定しており、妥当な速さでパッチを適用しており、データの所在地についても筋の通った答えを持っている――問題は、それらのすべてが、要求されればそのまま渡せる形に取りまとめられたことが一度もない、という点にある。誰が何にアクセスできるか、何がいつパッチ適用されたか、データがどこにあるかを毎月あるいは四半期ごとに記録する責任を、誰も負っていない。そもそもその責任がITサポート関係に割り当てられたことがなかったからだ。それは「ITが動いている」と「ITがそれを証明できる」の間の隙間に存在し、規制対象の金融法人にとって、その隙間こそが監査指摘の生まれる場所である。

たいてい何がこの問題を議題に押し上げるのか

このような拠点が、ITが「壊れている」と感じて自発的にレビューを発注することはめったにない――実際壊れていないからだ。何か具体的な出来事が、この問いを議題に押し上げる。最も多いのは、拠点が手元にすぐ取りまとめられる記録を持っていない状態で求められる、定例のグループコンプライアンスまたは内部監査のサイクルである。時には、保険契約者からの苦情や、業界全体に及ぶより広範な規制調査によって引き起こされるデータ保護に関する照会で、「見せてほしい」という誠実な要求に応えるのに、本来かかるべき以上の時間がかかることもある。時には経営陣の交代――新しいカントリーマネージャーや新しいグループリスク責任者――が、前任者が思いつかなかった質問を投げかけることもある。そして時には、単に、すべてがどこにあり誰がどんな権限を持っているかを常に把握していた人物が退職しようとしていて、その知識が監査人や後任者が見つけられる形でどこにも書き残されていなかったことに、拠点が気づくだけのこともある。

Brocentの見解：規制対象の法人にとって、ITサポートと監査証拠は同じ仕事である

外資系保険グループが北京に置く認可法人にとって、誠実な立場はこうだ。ITサポートと監査証拠は、二つの別々の成果物ではない。同じ仕事を、二つの異なる視点から見ているにすぎない。システムを動かし続けながら、監査人が受け入れるものを何も提示できないサポート体制は、たとえ一年を通してすべての従業員のノートパソコンが完璧に動作していたとしても、仕事の半分しか終えていない。グループ監査や規制当局が問うのは、決して「ITは動いているか」ではない。「見せてほしい」だ――誰がアクセス権を持っていたか、見せてほしい。何がパッチ適用されたか、見せてほしい。データがどこにあったか、見せてほしい。最初の問いにしか答えられないプロバイダーは、間違った軸の上にサービスを組み立てている。

Brocentの見解は、外資系金融機関の中国事業を支援してきた経験と、2007年に北京で設立されて以来、中国の規制環境の内側で運営してきた経験に基づいている。それは、報告と記録が、サービスの設計された成果物でなければならない――誰かに求められたかどうかにかかわらず、毎月当たり前のこととして生成される――というものであり、要求が届いてから圧力の下で再構築されるものであってはならない、という考え方だ。この転換は、このセグメントにとって「良いITサポート」の意味を変える。それはもはや応答性と稼働率だけではない。応答性、稼働率、そして規制対象の法人が実際に問われる三つの問い――誰がアクセス権を持っているか、何がパッチ適用されたか、データはどこにあるか――に対する、常に最新の答えが加わる。

この規模の北京拠点にとって、適切なカバレッジとは実際どのようなものか

同じ人数の一般的な北京オフィス向けに組まれたサポート体制と、規制対象の外資系保険法人向けに組まれたサポート体制を分ける要素は四つある。

現地時間で稼働するバイリンガルサービスデスク。 英語と中国語の両方で働く九十人のスタッフには、緊急時に中国語話者を通訳役に回したり、英語のみのエスカレーション経路に切り替えたりするのではなく、両方の言語を流暢に扱えるサービスデスクが必要である。保険金請求と引受の業務はタイムゾーンの引き継ぎのために止まることはないため、現地時間でのカバレッジは言語能力と同じくらい重要である。

リモートのみではなく、常駐またはスケジュールされたオンサイト対応。 老朽化したオンプレミスハードウェアを含む混合環境と、このスタッフ規模は、実質的で継続的な手作業の量を生み出す――リモート優先のモデルではトリアージはできても、完全な解決には至らないことが多い種類の仕事だ。フルタイムのオンサイトITサポートは、常駐であれスケジュールされたものであれ、「チケットに対応した」ことと「実際にサーバーを修理した」ことの間のギャップを埋める。

オンプレミス環境に本物の予備部品体制を伴うハードウェア保守。 年に一度見直す保証更新ではなく、能動的な計画――オンプレミスで稼働し続けるシステムのために特定された予備部品または待機ハードウェア、「壊れたら交換する」というデフォルトではなく監視された更新スケジュール、そしてオンプレミスとクラウドのバランスを、受け継いだ偶然ではなく能動的に管理すべき決定として扱うマネージドクラウドサービスの計画――が必要だ。

要求に応じて再構築するのではなく、毎月生成されるアクセス・パッチ・データ所在地の記録。 これは、グループ監査や規制当局が実際に問う質問に答える部分である。保険契約者データを保持するシステムへのアクセス権を誰が持っているか、そのアクセスが最後にいつレビューされたか、環境全体で何がいつパッチ適用されたか、データが物理的・論理的にどこに存在するかをカバーしなければならない。慌てて集めるのではなく、常設の記録として取りまとめる。これはまさに、規制対象の法人向けに設計されたマネージドITセキュリティサービスが埋めるために存在する具体的な隙間であり、監査を乗り切るサポート体制と乗り切れないサポート体制を分ける、単一で最大の違いである。

これら四つのどれも、特別に高度な技術ではない。それらが珍しいものになっている理由は、一般的な北京オフィス向けに価格設定・範囲設定された汎用サポート契約には、デフォルトでこれらのいずれも含まれないことが多いからだ。標準的な中小企業向けサポートパッケージを提供するプロバイダーは、顧客から求められない限り、毎月更新されるアクセス・パッチ記録を自発的に提供することはない。

一般的な選択肢を実際に比較すると

リージョナルオフィスからのリモートサポートと現地管理者の組み合わせ vs 現地の修理業者 vs オンサイト対応と文書化された証拠の連鎖を備えたマネージドIT（Brocentのモデル）

• リージョナルオフィスからのリモートサポートと現地管理者の組み合わせ — より小規模な体制から成長してきた拠点にとって、しばしばデフォルトの体制である。リージョナルのIT機能がポリシー、ツール、エスカレーションをリモートで処理し、一人の現地採用または兼任の管理者がリモートでは対応できない部分を処理する。日常的な稼働維持には十分機能するが、その現地管理者は、グループ監査が期待するアクセス・パッチ・データ所在地の記録を取りまとめる能力や権限をほとんど持たず、リージョナル機能が依拠するポリシーも、PIPLやMLPSに合わせて specifically に調整されたことは通常ない。
• 現地の修理業者 — 物理的な故障が起きたときの対応は速く、その限られた範囲においてはしばしば安価である。構造的な隙間は、修理そのもの以外のすべてに及ぶ。常設のセキュリティ態勢がなく、月次報告がなく、正式なパッチやアクセスのレビューサイクルがなく、グループポリシーと現地の義務を調整する能力もない。設計上、選択によってではなく構造的に受動的である――小規模な貿易オフィスにとってはそれで問題ないかもしれないが、規制対象の保険法人にとっては現実の負債である。
• オンサイト対応と文書化された証拠の連鎖を備えたマネージドIT（Brocentのモデル） — 現地時間で稼働するバイリンガルサービスデスク、老朽化した環境が生み出す手作業のためのスケジュールされたまたは常駐のオンサイトカバレッジ、本物の予備部品計画を伴うハードウェア保守、そして監査圧力の下で急いで組み立てるのではなく、サービスの常設の成果物として構築される毎月のアクセス・パッチ・データ所在地の記録。誠実なトレードオフとして、これは他の二つの選択肢より費用がかかる――一般的なオフィスが必要とするものではなく、規制対象の法人が実際に必要とするものに合わせて価格設定されているからだ。

よくある質問

北京拠点のITサポートは、上海や深圳とどう違うのか

PIPLとMLPSの下での規制上の義務は全国一律に適用されるため、コンプライアンスの基準線は都市によって変わらない。変わるのは運営上の文脈である。外資系保険会社や金融機関の中国本部および規制対応機能は、不釣り合いなほど多く北京に置かれているため、北京拠点はリージョナルまたはグループの監査が最初に注目する拠点になりやすく、現地とグループ両方のコンプライアンス構造に同時に報告している可能性も高い。人材の確保しやすさ、オフィスの密度、ベンダー間の競争も都市によって異なるが、核心的なサポート要件――稼働率だけでなく証拠であること――は北京でも上海でも深圳でも変わらない。

データが保険契約者の個人情報である場合、PIPLは何を求めるのか

PIPLは、保険に関連するいくつかのカテゴリー――健康・医療情報、財務口座の詳細、使用される場合は生体情報――をセンシティブ個人情報として扱い、通常の個人情報よりも厳しい基準を課す。より狭い正当な目的の根拠、より明示的な同意と必要性の要件、そしてアクセス制御と影響評価に対するより高い期待である。本稿は、保険業界特有の申告期限や罰則額を意図的に引用していない。それらの具体的な事項は、資格を持つ法律顧問と、法人自身の規制当局への申告から得られるべきものであり、ITサポートプロバイダーが提供すべきものではないからだ。ITサポートができること、そしてすべきことは、アクセス制限、暗号化、ログ記録、保持期間といった技術的な統制が整備され、文書化されていることを確実にし、法人自身の顧問が出す法的・コンプライアンス上の結論を裏付けることである。

グループのグローバルITポリシーだけで、現地の義務を満たせるのか

たいてい完全には満たせず、満たせると思い込むことが、本稿で説明した最も一般的な隙間の一つである。グループポリシーは、複数の法域にまたがって同時に合理的な基準線を設定するために書かれており、それはつまり、PIPLの同意・必要性要件やMLPSのシステム等級づけ義務を specifically に念頭に置いて書かれていることはめったにない、ということを意味する。より安全な考え方は、グループポリシーを、現地法人がその上に積み上げていく土台として扱い、グループポリシーがカバーする範囲と中国法が specifically に求める範囲との隙間を特定し埋める責任を、現地の誰かに明確に負わせることである。両者が自動的に一致していると思い込むのではなく。

オンサイトのITスタッフは必要か、それとも九十人にはリモートサポートで十分か

真にクラウドのみで構成された現代的な環境の法人であれば、リモート優先のサポートはうまく機能し得る。しかし、老朽化したオンプレミスハードウェアを含む混合環境を抱える法人――このプロファイルの北京オフィスに典型的なケース――では、リモートのみのサポートは、業務の手作業の半分を十分に解決できないことが多い。ハードウェアの診断、物理的な保守、予備部品の交換、そしてリモートのエンジニアがトリアージはできても完了させられない種類の現場でのトラブルシューティングである。デフォルトで想定するのではなく、実際の手作業の量に合わせてサイジングされた常駐またはスケジュールされたオンサイト対応が、このプロファイルにとってはたいてい、より誠実な答えとなる。

老朽化したオンプレミスサーバー環境はどうすべきか――交換、保守、それとも移行か

単一の明快な答えがあることはめったにない。明確なクラウドネイティブの代替手段があるワークロード――ファイルストレージ、メール、一般的な協働の大半――は、通常は移行計画に組み込むべきであり、それは老朽化したハードウェアに紐づく運用リスクも軽減する。遅延、ライセンス、システム固有の制約が実際にあるワークロード――多くの場合、保単管理や保険金請求システムの中核部分――は、より長くオンプレミスにとどまる必要があるかもしれない。その場合、優先事項は保守へと移る。本物の予備部品体制、監視されたハードウェアの健全性、そして「壊れたら交換する」というデフォルトではなく文書化された更新スケジュールである。正しい答えは、ワークロードごとの能動的な計画であり、一律のどちらか一方の決定ではない。

この状況で、ITプロバイダーから毎月何を報告してもらうべきか

最低限、三つのことが必要だ。保険契約者データを保持するシステムに誰がアクセスできるか、そのアクセスが最後にいつレビューされたかを示す最新のアクセス記録。オンプレミスとクラウドの両方の環境で、何に対して、何が、いつ適用されたかを示すパッチ記録。そして、越境での取り扱いを含め、データが物理的・論理的にどこに存在するかを示すデータ所在地の記録である。これら三つを、何週間も前の通知を必要とせずに常設の月次成果物として提示できるプロバイダーは、記録管理が単なる約束ではなく、そのアカウントを運営する方法に組み込まれていることを示している。

証拠を提示できるITサポートを手に入れる

外資系保険グループの北京拠点が必要としているのは、一般的なオフィスITのより難しいバージョンではない。証拠を後付けではなく設計された成果物として扱うITサポートである。候補に残す価値のあるプロバイダーは、見積もりの前に、アクセスレビューが現在どのように記録されているか、オンプレミスとクラウド全体の実際のパッチ適用サイクルはどうなっているか、法人のデータが物理的にどこにあるかを尋ね、そのうえで、監査人に聞かれたら取りまとめられると約束するのではなく、まさにその記録を生み出すことを中心に月次報告のリズムを構築するプロバイダーである。

Brocentは2007年に北京で設立されて以来、外資系金融機関の中国事業を支援してきた。2016年からの香港オフィス、2021年からのシンガポール本社を含め、この地域で長く運営してきた経験から、規制対象の法人にとって、金融サービス分野のIT関係は、何を稼働させ続けているかだけでなく、何を提示できるかによって評価されることを理解している。北京オフィスが現在、そうした証拠を求められたことのない体制で支えられているなら、有益な次の一歩は、明日それを求められたら実際に何を提示する必要があるのかについて話し合うことだ。お問い合わせから、その対話を始めてほしい。