災害復旧、事業継続およびインシデント対応

ProcessMindの災害復旧、事業継続およびインシデント対応

発効日：2026年9月14日

本書は、ProcessMind B.V.がそのクラウドサービスについて実施する災害復旧（「DR」）、事業継続（「BCP」）およびセキュリティインシデント対応手順の概要を説明するものです。本書は、セキュリティ対策、SaaSホスティングポリシー、サービスレベル契約およびデータ処理付属書を補足します。

本書は当社の現在の方針を説明するものであり、適用される契約、DPAまたはSLAに明示的に定められている内容を超えて、独立した契約上の目標復旧時間、目標復旧時点、データ耐久性の保証、通知期限、サービスレベルまたは責任基準を定めるものではありません。

1. 目的および適用範囲

ProcessMindは、以下の目的で本手順を維持しています。

障害事象の発生中における顧客データの機密性、完全性および可用性の保護
ProcessMindが管理するシステムの障害発生後における重要な本番サービスコンポーネントの復旧
サービス中断中におけるインシデント管理、顧客との連絡および運用上の意思決定の継続
文書化された手順およびソース管理されたインフラストラクチャ定義を使用した、インフラストラクチャ、デプロイ、アプリケーションまたはデータ層の障害からの復旧
セキュリティインシデントの特定および評価、脅威の封じ込め、根本原因の除去、影響を受けたシステムの復旧、必要な連絡、および教訓の記録

本手順は、本番環境のProcessMindクラウドサービス、およびサービスに影響を及ぼし、ProcessMindが合理的に調査および管理できる範囲における、サブプロセッサーまたはクラウドサービスに関わるセキュリティ事象に適用されます。開発環境およびテスト環境は分離されており、顧客向けの本番環境に関するコミットメントの復旧対象とはみなされません。

2. レジリエンス戦略

**2.1 地域構成。**本番サービスはAWS EU（ドイツ、フランクフルト、eu-central-1）でホストされています。このアーキテクチャでは、AWSが複数のアベイラビリティーゾーンにわたって運用する当該リージョン内のAWSマネージドサービスを利用します。Auroraクラスターは現在、単一のライターインスタンスで稼働しているため、データベースの復旧は、同一リージョン内のスタンバイではなく、自動バックアップおよび特定時点への復旧に依存します。ProcessMindは現在、顧客データを扱う第2のアクティブリージョンを運用していません。

**2.2 マネージドサービスおよびサーバーレスサービス。**ProcessMindは、AWS Lambda、Amazon API Gateway、Amazon CloudFront、Amazon Aurora PostgreSQL、Amazon S3、Amazon SQS、Amazon SNSおよびAmazon CloudWatchを利用します。これにより、顧客が管理する長期間稼働のサーバーへの依存が軽減され、アプリケーションおよび静的コンポーネントをソースから再構築して復旧できます。

**2.3 環境の分離。**本番環境と開発環境は、別々のAWSアカウントで、それぞれ独立したデータベースおよびインフラストラクチャスタックを使用して稼働します。これにより、開発作業が本番環境の復旧作業に影響を及ぼすリスクが軽減されます。

**2.4 監視および検出。**CloudWatchアラーム、ダッシュボード、デッドレターキューのアラート、集中ログ管理および合成サービス監視により、インシデントの検出、トリアージおよびエスカレーションを支援します。潜在的なインシデントは、サポート窓口への連絡、従業員からの報告、ベンダーからの通知、またはその他の調査開始の契機を通じて特定されることもあります。

3. 復旧の優先順位

重大なインシデントが発生した場合、ProcessMindは通常、以下の順に復旧を優先します。

顧客データの完全性を保護し、さらなる損害を防止します。
インシデントを封じ込め、影響を受けたシステムを安定化します。
本番環境への主要なアクセス経路および重要なワークフローを復旧します。
復旧完了を宣言する前に、サービスの動作、データの完全性および監視機能を検証します。
状況の更新、顧客への影響およびフォローアップ措置を連絡します。

具体的な順序は、データの完全性、顧客アクセス、非同期処理またはサポートインフラストラクチャへの影響の有無など、インシデントの性質に応じて異なる場合があります。

4. 災害復旧手順

**4.1 インシデントの宣言および調整。**重大なサービス中断およびセキュリティインシデントは、インシデント対応手順に従ってトリアージされます。ProcessMindはインシデント責任者を指名し、対応への参加を権限のある担当者に限定し、重大度および範囲を評価し、技術対応者を調整し、インシデントが解決または格下げされるまで復旧措置を追跡します。

**4.2 封じ込め。**ProcessMindは、より広範な復旧を開始する前に、継続中の影響を停止または軽減するため、商業上合理的な努力を行います。障害の種類に応じて、封じ込め措置には、直近の変更のロールバック、影響を受けた経路の無効化、故障しているコンポーネントの隔離、完全性の確認中のバックグラウンド処理の一時停止、認証情報の失効またはローテーション、あるいは不正な活動の遮断が含まれることがあります。

**4.3 根絶。**直ちに生じている影響が安定した後、ProcessMindは根本原因または寄与要因の除去に取り組みます。これには、コードまたは構成の修正の適用、悪意ある成果物の削除、シークレットのローテーション、信頼できる構成の復元、または露出したアクセス経路の閉鎖が含まれることがあります。

**4.4 データベースの復旧。**Aurora PostgreSQLは、7日間の保持期間を設けた継続的な自動バックアップを実行し、特定時点への復旧をサポートします。データベースレベルの障害、破損事象または誤った破壊的変更により復元が必要となった場合、ProcessMindは、適切な最新のバックアップまたは選択した時点から復元し、復元された環境を検証したうえで、アプリケーショントラフィックを復旧済みのデータベース経路に戻すことがあります。

**4.5 オブジェクトおよび成果物の復旧。**顧客がアップロードしたファイルおよび運用上の成果物はAmazon S3に保存されます。誤削除または上書きが発生した場合の復旧を支援するため、アップロード用バケットおよびリソース用バケットではバージョニングが有効になっています。ウェブサイトおよびフロントエンドのデプロイ用バケットは再生成可能な成果物として扱われ、バックアップから復元するのではなく、ソースから再構築されることがあります。

**4.6 非同期ワークロードの復旧。**非同期処理経路では、失敗したイベントを調査のために保持するデッドレターキューを使用します。復旧には、失敗したメッセージの再試行、処理ロジックの再実行、または基盤となるワークフローが安全な再処理をサポートする場合の作業の再実行が含まれることがあります。

**4.7 アプリケーションおよびインフラストラクチャの再構築。**インフラストラクチャは、ソース管理されたInfrastructure as Codeの定義を通じて管理されます。アプリケーションインフラストラクチャまたは静的アセットの再作成が必要な場合、ProcessMindは、バージョン管理された定義およびビルド成果物から影響を受けたコンポーネントを再構築し、再デプロイできます。

**4.8 サービス再開前の検証。**インシデントを終了する前に、ProcessMindは、利用可能な監視機能、ログ、合成チェックおよび対象を絞った機能検証を用いてサービスの健全性を検証し、検証済みのデプロイ、復旧およびインフラストラクチャ手順を用いて影響を受けた機能を復元します。インシデントにデータの復元またはデータ完全性のリスクが関係していた場合、追加のレビューが行われることがあります。

5. 事業継続措置

**5.1 運用の継続。**ProcessMindは、障害事象の発生中もインシデント対応、顧客サポートの受付、エンジニアリング対応および意思決定を継続できるよう、文書化された運用手順を維持しています。

**5.2 連絡。**本番環境で重大なインシデントが発生した場合、ProcessMindは、顧客サポート窓口を通じて、また適切な場合は公開ステータスページprocessmind.com/statusで更新情報を提供するため、商業上合理的な努力を行います。

**5.3 管理された変更管理。**回避可能な停止を減らし、継続性を継続的に向上させるため、複数の独立した自動検証レイヤーを備えた多層防御型のソフトウェア開発ライフサイクル、管理されたデプロイ、集中監視およびインシデント後のレビューを実施しています。

5.4 復旧中のセキュリティ。 復旧措置は、最小権限アクセス、可能な場合の運用活動の記録、本番システムおよびデータへのアクセス制御など、通常の運用中に適用されるものと同じ一般的なセキュリティ原則に従って実施されます。

6. バックアップおよびデータ保護の概要

6.1 データベースのバックアップ。 Auroraの自動バックアップは暗号化され、7日間保持されます。また、その保持期間内であれば、特定時点への復旧が可能です。

6.2 S3の保護。 Amazon S3は、保存されたオブジェクトに高い耐久性を提供します。変更可能な顧客データ用バケットは、プライマリリージョン内の耐久性およびバージョニングに依存しています。ProcessMindは現在、これらのバケットについてリージョン間S3レプリケーションを有効にしていません。

6.3 ログおよび診断。 集中管理されたログ、アラームおよびテレメトリは、障害の調査および復旧の検証を支援します。これらの仕組みは事業継続の運用を支援するものですが、それ自体が独立したバックアップ製品として提供されるものではありません。

7. インシデントの特定およびトリアージ

7.1 初期評価。 報告された事象について、セキュリティインシデントの定義に該当するか、影響を受ける可能性のあるシステムまたはデータ、想定される範囲および重大度、ならびに直ちに封じ込める必要があるかを判断するため、トリアージを行います。証拠の保全は、インシデントの性質および関係するシステムに応じた方法で取り扱います。

7.2 オンコール対応およびエスカレーション。 ProcessMindは、本番環境のインシデントに対するオンコール体制を維持しており、サービスレベル契約で定義される重大なインシデントについては24時間365日の対応を含みます。これにより、いつでもインシデントを受領確認し、トリアージできるようにしています。

7.3 文書化。 ProcessMindは、重要な調査結果、対応措置および復旧に関する判断を文書化し、事後にインシデントの経過およびその結果として講じられた是正措置を確認できるようにします。

8. コミュニケーションおよび通知

8.1 社内コミュニケーション。 ProcessMindは、インシデントの全期間を通じて技術的な対応と顧客への連絡の整合性が保たれるよう、対応担当者、意思決定者およびサポート窓口を調整します。

8.2 顧客への通知。 DPAまたは適用法令に基づく通知が必要なセキュリティインシデントが発生した場合、ProcessMindは、不当な遅延なく、また可能な場合にはインシデントを認識してから72時間以内に、影響を受ける顧客に通知します。通知には通常、インシデントの性質および範囲、判明している場合は影響を受けたデータのカテゴリー、インシデントの封じ込めおよび是正のために講じた措置、ならびに関連する場合は推奨される顧客の対応が含まれます。

8.3 継続的な更新。 インシデントが継続中である場合、または重要な事実に変更があった場合、ProcessMindは、追加の確認済み情報が得られ次第、続報を提供します。より広範な本番サービスの中断については、ProcessMindは顧客サポート窓口を利用することがあり、適切な場合には公開ステータスページprocessmind.com/statusも利用することがあります。

9. テスト、見直しおよび保守

ProcessMindは、これらの手順を少なくとも年1回、ならびに重大なインシデントまたは重要なアーキテクチャ変更の後に見直し、対応および復旧の取り組みの関連要素（バックアップの復元、デプロイメントの再構築、監視、アラートおよびインシデントに関する連絡など）を定期的に演習し、得られた教訓をセキュリティ、信頼性および事業継続の手順に反映します。

10. 制限および契約上の境界

本書は概要を示すものであり、すべての内部ランブック、エスカレーション経路、調査方法または証拠の取扱手順を運用上の詳細まで記載するものではありません。また、適用される契約または注文書に明示的に定められている場合を除き、リージョン間フェイルオーバー設計、すべての変更可能なバケットに対する変更不能なストレージ保持、または独立したRTO/RPO保証をProcessMindに義務付けるものではありません。

本書と、適用される顧客契約、データ処理付属書、サービスレベル契約または強行法規との間に矛盾がある場合は、それらの規定が優先します。