これまで説明した技術的な対策により、電子メールによるウイルス感染はある程度未然に防ぐことはできる。しかし、技術的な対策は完全にはなりえない。システム管理者による正しい運用、利用者による正しい利用が伴ってこそ、技術的な対策を補完し、対策の実効性をより完全なものにすることができる。
そこで、管理者あるいは利用者に対してウイルス対策における方針（ポリシー）を明確にし、運用ルールを定めておく必要がある。以下にウイルス対策におけるポリシーおよび運用ルールとして一般的なものを紹介する。

情報漏洩に関して盛り込むべきセキュリティポリシーの内容として、以下のものがあげられる。

これまで、不正アクセスに対する技術的な対策を記述してきたが、不正アクセスに関する技術は日々進歩している。どんなに堅牢なセキュリティ対策を構じていても、公開しているDMZ上のサーバーは常に脅威にさらされている。そのため、万が一事故が発生した場合の対応についても考慮する必要がある。
インシデントとは、悪意を持った行為や、偶発的な事象により発生したコンピュータセキュリティ上の事象のことである。インシデント対応とは、これらのインシデントが発生した時に企業が取るべき対応のことであり、インシデントへの対応に際しどのような手続きをとるかを事前に決めておく必要がある。

インシデントが発生した場合の対応について、手順を以下に示す。

インシデントの発見はサーバー管理者だけに限らず、社員の場合もあれば社外の関係者や顧客である可能性もある。特に、社内で発見したインシデントについては、連絡先を一本化しておき、連絡が滞ったり、情報が錯綜しないようにしなければならない。通常、システムのインシデント連絡窓口は社内情報システム関連部署である場合が多い。

図表26にインシデント発生時の確認事項を示す。インシデントの連絡を受けた連絡窓口の担当者は、どのようなインシデントが発生したのか、発生日時、影響範囲や程度などをなるべく具体的に聞く。連絡窓口の担当者は、その内容から関係があると思われるサーバーやネットワークの管理者に対し、調査を依頼する。調査依頼を受け取ったサーバーやネットワークの管理者は、システムの状態やログを元に調査を行う。行った確認や調査はすべて証拠となるため、記録しておくことが必要である。また、インシデントの重大性によっては、警察やJPCERTなどの公的機関への連絡も必要である。

システム設定ファイルが改ざんされたり、破壊されたりしている場合は、バックアップから復旧作業を行う。復旧作業を行う場合は、バックアップ作成時点ですでにファイルが改ざんされている可能性があるため、そのようなファイルを復元しないように、ファイルの更新日や内容を確認しながら慎重に復旧する。なお、攻撃されたセキュリティホールによっては、rootkit ³を埋め込まれている可能性があるため、サーバーであれば再インストールしてからシステム設定ファイルを復旧したほうが安全である。

同様なインシデントの再発を防ぐために、その原因を特定して速やかに対策を取らなければならない。対策が取られるまでの間は、再び攻撃される可能性が高いため、サービスは停止しておくことが必要である。また、侵入されていた場合には、パスワードが漏洩していることも考えられるため、パスワードの変更が必要となる可能性がある。