概要設計の段階では、以下のようなことに注意してレビューを行う。
1）各機能、使用するデータの機密性、可用性について適切な評価を行っているか？
既に組織でISMSを取り入れている場合は、それに準じた評価を行う必要がある。もし、組織がISMSを取り入れていない場合、たとえば以下のようにレベル分けを行う。
| 機密性 |
|---|
| 低：公開情報や誰でも使用できる機能（たとえば、商品の価格情報、商品検索機能など） 中：漏えい、不正利用されても、多大な影響は出ないが特定のユーザーにしかアクセスできない情報や機能（たとえば、登録ユーザのみに提供する情報、買い物カゴ機能など） 高：漏えい、不正利用されると多大な影響が出る情報や機能（たとえば、ユーザの個人情報、管理者用メンテナンスメニューなど） |
| 可用性 |
| 低：常時必要としない情報や機能 たとえば、管理者用メンテナンスメニューなど 高：常時必要とする情報や機能 たとえば、ユーザーのログイン情報、各種ユーザーへ提供する機能など |
完全性については、ウェブプリケーションではほとんどの場合、高いレベルで必要となるので除外している。
2）各機能、使用するデータに対するリスクの洗い出しを適切に行っているか？
リスクの洗い出しが不十分な場合、対策しなければならないリスクが見過ごされ、脆弱性が残ることがある。リスクには、例えば、通信内容が暗号化されていないために盗聴される、商品検索機能のバグにより個人情報が漏えいするなどがある。
3）すべてのリスクに対して、評価を行い、対策を行っているか？
すべてのリスクを、ゼロにすることはアプリケーションを作らないこと以外にはない。被害が受容できないリスクは、何らかの対策でリスクを軽減して、受容できるようにしたり、他のサービスで代用してリスクを転嫁する必要がある。
対策すべきリスクの軽減は、次のとおり。
| リスクの軽減を適切に実施しているか？ |
|---|
| ・使用するツール、言語が実装する機能に対して適正か？ ・入力データの生成元は信頼できるのか？ 信頼できないのであれば信頼できるようにする対策をとっているか？ ・出力データで気をつけなければならないことはなにか明確になっているか？ ・誰がいつ何を行ったか記録に残るか？ ・バックアップ／リストア計画は設計されているか？ |
| リスクの回避を適切に実施しているか？ |
| ・脆弱性となりうる不要な機能、不要なデータはないかを確認する。 |
| リスクの転嫁を適切に実施しているか？ |
| ・外部サービス、既存のツールなどの利用ができないかを確認する。 |
| 受容するリスクはすべて容認できるか？ |
| ・必要だが、脅威が存在する機能は被害が容認できるレベルになっているかを確認する。 |
この段階でのレビュー結果が後の詳細設計やコーディングでの対策に影響を与えるので、十分な検討が必要となる。また、必要に応じてセキュリティ対策となる機能を追加する。
