1. ビジネスまたはミッションの分析プロセス
   • 組織のビジネスやミッションの課題を分析し、サイバーレジリエンスの目標に優先順位を付ける。同時に、攻撃者の能力を想定してリストアップする。組織のリスク管理戦略に基づき、サイバーレジリエンスの手法に関する制約や制限を分析する。目標の達成度合いを評価する手法も分析対象に含まれる。
2. 利害関係者のニーズおよび要件の定義プロセス
   • このプロセスでは、まずサイバーレジリエンスの目標を実現する方法を特定する。利害関係者の要件は、資産が標的型攻撃をどの程度受けやすいかを判断するのに役立つ。要件を明確化することで、組織のリスク管理戦略に沿った戦略的なサイバーレジリエンス設計原則を明確化できる。
3. システム要件の定義プロセス
   • サイバーレジリエンスの設計上の制約を踏まえた上で、利害関係者の要件に基づいてサイバーレジリエンスのシステム要件を特定する。このプロセスでは、システムの種類や技術に対する既存の投資、技術の成熟度などを考慮する。この分析は、適用可能なサイバーレジリエンス手法の判断と、サイバーレジリエンスのパフォーマンス評価基準の定義に役立つ。
4. アーキテクチャの定義プロセス
   • このプロセスではサイバーレジリエンスの視点から、システムアーキテクチャの代替手段を検討したり、脆弱（ぜいじゃく）性が攻撃された場合の影響を特定したりする。システムに侵入し続ける攻撃者に関連した、利害関係者の懸念事項に対処する。
5. 設計の定義プロセス
   • サイバーレジリエンス設計とセキュリティ設計の双方の特徴を考慮する。システム要件における制約も考慮の対象に入れる。このプロセスでは、サイバーレジリエンス設計の適用を支援する技術を特定する。
6. システムの分析プロセス
   • 攻撃者がシステム内に継続的な攻撃の足掛かりを得る方法を精査し、特定の脅威イベントに関するサイバーレジリエンス製品／サービスを分析する。
7. 実装プロセス
   • サイバーレジリエンスの目標を実現したり、サイバーレジリエンスのニーズを満たしたりする上で、その実現の制約となる点をセキュリティの観点から特定する。
8. 統合プロセス
   • 組織内にサイバーレジリエンス製品／サービスを安全に導入する方法を特定、定義する。
9. 検証プロセス
   • サイバーレジリエンス製品／サービスがシステム要件を満たすかどうかを検証する。
10. 移行プロセス
    • このプロセスは、全ての利害関係者に脅威や標的型攻撃に関するトレーニングを提供すると同時に、サイバーレジリエンスの目的と目標を策定するために利用する。脅威情報に関するツールを採用し、システムのサイバーレジリエンスに関する妥当性の確認に必要なデータを集める。
11. 妥当性確認プロセス
    • 利害関係者の要件を満たすことで、システムでビジネスとミッションの目標を果たせるかどうかを確認する。サイバーレジリエンスの妥当性確認のために必要な製品／サービスを利用できるようにする。
12. 運用プロセス
    • サイバーレジリエンスの運用面に注目する。ビジネスやミッションのタスクを実行することと、セキュリティ、安全性、プライバシーといった信頼性に関する側面とのトレードオフが、さまざまな条件下の運用環境でどのように発生するかについても考慮する。
13. 保守プロセス
    • このプロセスは、システムズエンジニアリングを通じたサイバーレジリエンスの目的と成果を示す。
14. 処分プロセス
    • システムやシステム要素の廃止が、サイバーレジリエンスの低下にどのように影響する可能性があるかを分析する。その上で、こうしたリスクに対する利害関係者の理解を促す。

　情報セキュリティの専門家はシステムズエンジニアリングの観点から、NISTのガイドラインに記載された14種類のサイバーレジリエンス手法を理解すべきだ。その上で、組織のリスク管理戦略に合わせて、それらの手法を調整することが求められる。リスクの軽減にサイバーレジリエンス製品／サービスを生かすには、その利用方法に関して深く議論する必要がある。