ECサイトのセキュリティ対策とは、顧客情報や決済情報を守るだけでなく、不正注文、アカウント乗っ取り、サイト改ざん、サービス停止などを防ぎ、事業を継続するための取り組みです。

優先すべき対策は、カード情報をできる限り自社環境で扱わないこと、EMV 3-Dセキュアなどの決済不正対策、管理者の多要素認証、脆弱性と第三者スクリプトの管理、ログ監視、復旧可能なバックアップ、インシデント対応計画です。SSL/TLSやWAFの導入だけで、ECサイト全体の安全が保証されるわけではありません。

2026年3月公表の「クレジットカード・セキュリティガイドライン6.1版」によると、2025年のクレジットカード不正利用被害額は約510.5億円で、その約9割をEC加盟店における「なりすまし」による不正利用が占めています。また、カード情報を非保持化したECサイトでも、Webサイトの脆弱性や設定不備を悪用した情報窃取が発生していると指摘されています。

本記事では、IPA、経済産業省、個人情報保護委員会、クレジット取引セキュリティ対策協議会、PCI Security Standards Council、OWASP、NISTの公開情報をもとに、ECサイトの主なリスクと実務的な対策を解説します。

最終確認日・注意事項： 2026年8月14日。本記事は一般的な情報提供を目的としています。個別の法的義務、PCI DSSの適用範囲、必要な技術対策は、事業内容、決済方式、契約、システム構成によって異なります。必要に応じて、弁護士、契約先のカード会社・決済代行会社、PCI SSC認定評価機関、セキュリティ専門家へ確認してください。

参考：クレジットカード・セキュリティガイドライン6.1版、IPA「ECサイト構築・運用セキュリティガイドライン」

ECサイトでセキュリティ対策が重要な理由

ECサイトは、氏名、住所、電話番号、メールアドレス、購入履歴、ログイン情報など、攻撃者に悪用され得る情報を扱います。決済方法によっては、カード会員データを保存していなくても、購入者のブラウザに表示される決済画面や決済先へのリダイレクトが改ざんされる可能性があります。

事故が発生すると、次のような影響が考えられます。

  • 顧客情報や認証情報の漏えい
  • クレジットカードの不正利用やチャージバック
  • 不正注文、転売、在庫・配送コストの損失
  • サイト停止による売上機会の喪失
  • フォレンジック調査、復旧、顧客対応、再発防止にかかる費用
  • 個人情報保護委員会や契約先への報告、本人への通知
  • ブランドや取引先からの信用低下

IPAは、ECサイトの事故によって長期間のサイト閉鎖、売上減少、原因調査、被害補償などの大きな経済的損失が生じ得るとして、経営者と実務担当者の双方に継続的な対策を求めています。

参考：IPA「ECサイト構築・運用セキュリティガイドライン」

ECサイトが直面する主なセキュリティリスク

1. Webアプリケーションの脆弱性

アクセス制御の不備、セキュリティ設定の誤り、インジェクション、安全でない設計、認証処理の不備などがあると、顧客情報の閲覧、データ改ざん、管理機能の悪用、サーバー侵害につながる可能性があります。

OWASP Top 10:2025では、Broken Access Control（アクセス制御の不備）、Security Misconfiguration（セキュリティ設定の不備）、Software Supply Chain Failures（ソフトウェアサプライチェーンの問題）などが、重要なWebアプリケーションリスクとして整理されています。

参考：OWASP Top 10:2025

2. 既知の脆弱性とアップデート漏れ

OS、Webサーバー、CMS、ECパッケージ、プラグイン、テーマ、JavaScriptライブラリ、管理端末などを古い状態で使い続けると、公開済みの脆弱性を悪用される危険が高まります。

更新作業を制作会社や保守会社へ委託していても、契約範囲、緊急時の対応時間、更新失敗時の復旧方法が明確でなければ、脆弱性が放置される可能性があります。

3. Webスキミングと第三者JavaScriptの改ざん

Webスキミングは、決済ページなどに不正なJavaScriptを挿入し、購入者が入力したカード情報や個人情報を攻撃者へ送信する手口です。正常な決済も完了する場合があり、利用者や運営者が被害に気づきにくい点が問題です。

分析タグ、広告タグ、チャット、レビュー、A/Bテストなどの第三者JavaScriptは、サイト上で実行されるため、提供元やタグ管理アカウントが侵害されると影響を受ける可能性があります。PCI DSS v4.0.1は、対象となる決済ページのスクリプトについて、承認、完全性確認、必要性を記録したインベントリなどを求めています。

参考：PCI SSC「PCI DSS v4.0.1」、OWASP「Third Party JavaScript Management Cheat Sheet」

4. 不正ログインとアカウント乗っ取り

他のサービスから流出したID・パスワードの組み合わせを試す「リスト型攻撃（クレデンシャルスタッフィング）」、総当たり攻撃、フィッシングなどにより、顧客や管理者のアカウントが乗っ取られることがあります。

顧客アカウントが侵害されると、登録済み情報の閲覧、ポイントやクーポンの不正利用、配送先変更、不正注文などにつながります。管理者アカウントが侵害された場合は、商品情報の改ざん、顧客データの取得、不正スクリプトの設置など、より大きな被害が発生する可能性があります。

5. クレジットカードの不正利用とカードテスティング

窃取・生成されたカード番号が使用可能かを確かめるため、少額決済や大量の決済試行が行われることがあります。EMV 3-Dセキュアだけに依存せず、決済前の不正ログイン対策、決済時の本人認証・不正検知、決済後の配送・換金対策を組み合わせる必要があります。

最新のクレジットカード・セキュリティガイドライン6.1版では、EC加盟店に対して、脆弱性対策、適切な不正ログイン対策、EMV 3-Dセキュアの導入などが示されています。

参考：クレジットカード・セキュリティガイドライン6.1版

6. API、プラグイン、委託先を経由した侵害

ECサイトは、決済、在庫、配送、CRM、メール配信、アクセス解析、広告、チャットなど、多くの外部サービスと連携します。APIキーの漏えい、過剰な権限、使われていない連携、脆弱なプラグイン、委託先アカウントの侵害が、攻撃経路になる可能性があります。

個人情報の取扱いを委託する場合、委託元には委託先の選定、契約、取扱状況の把握などを通じた必要かつ適切な監督が求められます。SaaSや制作会社へ運用を任せても、EC事業者側の責任がすべてなくなるわけではありません。

参考：個人情報保護委員会「個人情報保護法ガイドライン（通則編）」

7. DDoS、ランサムウェア、障害によるサービス停止

DDoS攻撃、ランサムウェア、クラウドや外部サービスの障害、設定ミス、誤操作などにより、販売機会が失われる可能性があります。セキュリティは情報漏えいの防止だけでなく、可用性と復旧も含めて考える必要があります。

ECサイトで優先すべき12のセキュリティ対策

1. 守る対象と責任範囲を明確にする

最初に、ECサイトを構成する資産とデータの流れを把握します。

  • ドメイン、DNS、CDN、サーバー、クラウド
  • ECプラットフォーム、CMS、プラグイン、テーマ
  • 決済画面、決済代行会社、カード会社との接続
  • 顧客・管理者アカウントと権限
  • API、タグ管理、広告・解析スクリプト
  • 個人情報、注文情報、ログ、バックアップの保存先
  • 制作会社、保守会社、SaaS、再委託先

「誰が、何を、いつまでに更新・監視・復旧するか」を、社内の担当表と委託契約に落とし込みます。セキュリティ責任者と、事故発生時の意思決定者も決めておきます。

2. カード情報をできる限り自社環境で扱わない

カード情報の入力・処理をPCI DSS準拠の決済代行会社へ委ね、EC事業者の環境をカード情報が通過・保存しない構成にすることで、リスクとPCI DSSの対象範囲を抑えられる場合があります。

ただし、非保持化すればECサイト全体が安全になるわけではありません。決済先へのリダイレクトや埋め込み決済画面が改ざんされるリスクがあり、ECサイト自体の脆弱性対策は引き続き必要です。また、使用できるPCI DSS自己問診（SAQ）の種類や対象範囲は、決済方式とシステム構成によって変わります。自己判断せず、契約先のカード会社・決済代行会社または認定評価機関へ確認してください。

参考：PCI SSC「PCI DSS」、PCI SSC「SAQ Aの対象とスクリプト対策」

3. EMV 3-Dセキュアと多面的な不正利用対策を導入する

EMV 3-Dセキュアは、カード決済時にリスク判定や追加認証を行い、なりすましによる不正利用を抑える仕組みです。2025年3月に公表されたガイドライン6.0版で、EC加盟店における指針対策として追加され、6.1版にも引き継がれています。

ただし、EMV 3-Dセキュアだけですべての不正注文を防げるわけではありません。商材、客単価、配送方法、過去の被害状況に応じて、次の対策を組み合わせます。

  • 不正検知サービスによる取引リスク判定
  • 決済試行回数・頻度の制御
  • 同一端末、IPアドレス、配送先などの異常検知
  • 高リスク注文の保留と目視確認
  • 注文・会員登録・クーポン利用のレート制限
  • 配送先変更や高額注文時の追加確認

具体的な必須要件と例外は、加盟店契約や業種によって異なる可能性があるため、契約先へ確認してください。

参考：日本クレジット協会「関連資料」、経済産業省「クレジットカード・セキュリティガイドライン改訂」

4. 管理者へ多要素認証と最小権限を適用する

EC管理画面、クラウド、サーバー、DNS、ドメイン管理、ソースコード管理、タグ管理、決済管理、メール管理には、多要素認証を設定します。可能であれば、フィッシング耐性の高いパスキーやセキュリティキーも検討します。

さらに、次を徹底します。

  • 共有アカウントを避け、利用者ごとにIDを発行する
  • 業務に必要な最小限の権限だけを与える
  • 退職者、異動者、委託終了者の権限を速やかに削除する
  • 管理画面の接続元制限や条件付きアクセスを検討する
  • 権限変更、設定変更、データ出力をログへ記録する
  • 緊急用アカウントの利用手順と監査方法を決める

5. 顧客アカウントの認証を強化する

顧客向けログインには、長いパスワードを許可し、よく使われるパスワードや漏えい済みパスワードを拒否し、試行回数を制御します。パスワードマネージャーと貼り付けを妨げない実装も重要です。

「英大文字・小文字・数字・記号を必須にする」「定期的に変更させる」といったルールは、現在の代表的なガイドラインでは一律に推奨されていません。NIST SP 800-63B-4は、単一要素として使うパスワードを最低15文字とし、文字種の組み合わせを強制せず、漏えいなどの根拠がない定期変更を要求しない方針を示しています。

ECサイトの対象顧客やリスクに応じて、顧客向け多要素認証、パスキー、異常ログイン通知、重要情報変更時の再認証も検討します。アカウント復旧やMFA再設定が攻撃者の迂回経路にならない設計も必要です。

参考：NIST SP 800-63B-4、OWASP「Authentication Cheat Sheet」

6. ソフトウェアと脆弱性を継続管理する

OS、ミドルウェア、ECパッケージ、CMS、プラグイン、ライブラリ、コンテナ、管理端末を台帳化し、サポート期限と脆弱性情報を追跡します。重大な脆弱性が公表されたときに、対象システム、担当者、緩和策、更新期限をすぐ判断できる状態が理想です。

実務では、次の対策を組み合わせます。

  • セキュリティ更新を速やかに適用する
  • 本番反映前に検証環境で動作確認する
  • 不要なプラグイン、アカウント、サービスを削除する
  • ソースコードレビューと依存関係スキャンを行う
  • 公開前・大規模改修後・定期的に脆弱性診断を行う
  • 高リスクな変更では侵入テストを検討する
  • 修正完了後に再診断し、検出事項の解消を確認する

診断の頻度に、すべてのECサイトへ共通する万能な回数はありません。変更頻度、扱うデータ、攻撃リスク、契約、PCI DSSの対象範囲に基づいて決めます。

7. WAFを多層防御の一部として運用する

WAFは、SQLインジェクションやXSSなど、Webアプリケーションへの不正なリクエストを検知・遮断するのに役立ちます。ただし、WAFは脆弱性そのものを修正するものではなく、認証・権限設計、セキュアコーディング、アップデート、診断の代わりにはなりません。

導入後は、マネージドルールの更新、誤検知の確認、例外ルールの棚卸し、アラートへの対応を継続します。大規模なDDoSへの対策が必要な場合は、WAFとは別にCDNやDDoS防御サービスの機能も確認します。

8. HTTPS、セッション、セキュリティヘッダーを適切に設定する

サイト全体をHTTPS化し、HTTPからHTTPSへ転送します。そのうえで、HSTS、CookieのSecure・HttpOnly・SameSite属性、適切なセッション有効期限、ログイン後のセッションID更新、CSRF対策などを設定します。

外部JavaScriptやCSSをHTTPで読み込む混在コンテンツは避けます。HSTSのincludeSubDomainsやpreloadは影響範囲が大きいため、すべてのサブドメインをHTTPSで運用できることを確認して段階的に導入します。

参考：OWASP「Transport Layer Security Cheat Sheet」、OWASP「Session Management Cheat Sheet」

9. 決済ページと第三者スクリプトを管理する

決済・会員・注文ページで動くJavaScriptを一覧化し、所有者、提供元、目的、読めるデータ、変更方法、必要性を記録します。不要なタグは削除し、タグ管理ツールの公開権限には多要素認証と承認フローを設定します。

システムに応じて、次を検討します。

  • Content Security Policy（CSP）による読み込み元と実行方法の制限
  • Subresource Integrity（SRI）による外部ファイルの完全性確認
  • 決済ページやHTTPヘッダーの改ざん検知
  • スクリプト変更時のレビューと承認
  • 本番環境へ直接タグを公開できる権限の制限
  • 決済ページから不要な広告・計測タグを排除する

CSPやSRIには実装上の制約があり、設定を誤るとサイト機能が停止する場合があります。決済方式とPCI DSSの対象範囲を確認し、専門家や決済代行会社と設計してください。

参考：PCI SSC「ECサイトのスクリプト対策に関するFAQ」、OWASP「Content Security Policy Cheat Sheet」

10. ログを集約し、異常を検知・対応する

ログは保存するだけでは十分ではありません。次のようなイベントを記録し、異常時に担当者へ通知します。

  • ログイン成功・失敗、多要素認証の失敗
  • パスワード・メールアドレス・配送先の変更
  • 管理者権限の変更、商品・価格・決済設定の変更
  • 大量の会員登録、決済試行、クーポン利用
  • 顧客データや注文データの大量出力
  • WAF、マルウェア対策、クラウド監査ログの重要アラート
  • JavaScriptや決済ページの想定外の変更

ログには、カード番号、パスワード、認証トークンなどの秘密情報を記録しない設計が必要です。ログ自体へのアクセス制限、改ざん防止、時刻同期、保存期間、アラート対応手順も定めます。

参考：OWASP「Logging Cheat Sheet」

11. 復旧可能なバックアップを確保する

データベース、画像、設定、ソースコード、インフラ構成、DNS設定、重要なSaaSデータを対象にバックアップ方針を定めます。

  • 本番環境と異なる認証・保管先でバックアップを保護する
  • 暗号化し、アクセス権を限定する
  • 複数世代を保存する
  • ランサムウェア対策として変更・削除されにくいコピーを持つ
  • 目標復旧時間（RTO）と目標復旧時点（RPO）を決める
  • 定期的に復元テストを行い、実際に戻せることを確認する

バックアップは取得成功の表示だけでなく、復元結果で有効性を判断します。

12. インシデント対応計画を作り、訓練する

不正アクセスや情報漏えいの疑いが生じた際に、連絡先や判断基準を調べ始めるのでは対応が遅れます。平時に次を準備します。

  • 社内責任者、経営者、法務、広報、顧客対応の連絡網
  • 制作会社、クラウド、決済代行会社、カード会社、保険会社の緊急連絡先
  • サイト停止、決済停止、アカウント無効化などの判断権限
  • ログ、サーバー、設定を保全する手順
  • 個人情報保護委員会、契約先、本人への報告・通知の確認手順
  • 顧客向け告知文、問い合わせ対応、FAQのひな形
  • 復旧と再公開の判断基準

机上訓練や連絡訓練を行い、担当者不在時にも機能するか確認します。

参考：IPA「中小企業の情報セキュリティ対策ガイドライン第4.0版」

ECサイトの構築方式別に確認すべきこと

SaaS・ASP型EC

プラットフォーム事業者がインフラや共通アプリケーションを管理していても、次の項目はEC事業者側の管理が必要になることがあります。

  • 管理者アカウントと権限
  • アプリ、外部連携、APIキー
  • テーマや追加スクリプト
  • 決済、不正検知、EMV 3-Dセキュアの設定
  • 顧客データの利用・出力・削除
  • 委託先や運用担当者の管理
  • インシデント時の連絡と顧客対応

契約前に、責任分界、データ保管場所、バックアップ、ログ提供、脆弱性対応、障害時の連絡、解約時のデータ返却・削除を確認します。

オープンソース・ECパッケージ

更新情報とセキュリティ情報を継続的に追跡し、コア、プラグイン、テーマ、サーバーを含めて保守します。カスタマイズによって標準アップデートを適用しにくくなる場合があるため、更新手順と検証環境を準備しておく必要があります。

オープンソースであること自体が、直ちに安全または危険という意味ではありません。運用体制、更新状況、設定、拡張機能、コード品質によってリスクは変わります。

フルスクラッチ・ヘッドレスEC

自由度が高い一方、認証、認可、セッション、API、決済、ログ、秘密情報管理、依存関係、クラウド設定などを自社と開発会社が設計・検証する範囲が広がります。開発初期から脅威分析とセキュリティ要件を組み込み、継続的なコードレビュー、セキュリティテスト、監視を行う体制が必要です。

ECサイトのセキュリティチェックリスト

経営・運用体制

  • □ セキュリティ責任者とインシデント時の意思決定者が決まっている
  • □ システム、データ、委託先、外部連携の台帳がある
  • □ 自社・EC基盤・制作会社・決済代行会社の責任分界が明確になっている
  • □ 委託契約にセキュリティ、再委託、事故報告、監査、データ返却・削除の条件がある
  • □ 定期的に、または体制変更時に連絡網と対応計画を見直している

アカウントと権限

  • □ 管理画面、クラウド、DNS、決済、タグ管理で多要素認証を使っている
  • □ 共有アカウントを避け、個人ごとのIDを使っている
  • □ 最小権限を適用し、不要・休眠アカウントを削除している
  • □ 顧客ログインにレート制限と漏えい済みパスワード対策がある
  • □ パスワード再設定とMFA復旧に本人確認と通知がある

システムとアプリケーション

  • □ OS、EC基盤、CMS、プラグイン、ライブラリのバージョンを把握している
  • □ 重大な脆弱性へ緊急対応できる手順がある
  • □ 公開前、大規模改修後、定期的に脆弱性を評価している
  • □ WAFのルールとアラートを継続運用している
  • □ HTTPS、セッションCookie、HSTSなどを適切に設定している
  • □ APIキーや秘密情報をソースコードや公開領域へ保存していない

決済と不正利用

  • □ カード情報を自社環境で保存・処理する必要性を見直している
  • □ 自社に適用されるPCI DSSとSAQの範囲を契約先へ確認している
  • □ EMV 3-Dセキュアが正しく設定・運用されている
  • □ カードテスティングや大量決済試行を検知・制限できる
  • □ 高リスク注文の保留、確認、配送対策がある
  • □ 決済ページのスクリプトとタグを把握している

監視・バックアップ・事故対応

  • □ 認証、管理操作、決済、データ出力のログを記録している
  • □ 重要な異常を担当者へ通知し、対応記録を残している
  • □ ログにカード番号、パスワード、認証トークンを残していない
  • □ バックアップを本番環境と分離し、復元テストをしている
  • □ インシデント時の停止、調査、連絡、報告、復旧手順がある
  • □ 決済代行会社、カード会社、専門業者の緊急連絡先を確認している

IPAは、より詳細な項目を確認できる「ECサイト構築・運用セキュリティガイドライン」とチェックリストを公開しています。本チェックリストだけで十分とせず、自社のシステム構成に合わせて公式資料も利用してください。

情報漏えいが疑われる場合の初動

情報漏えい、不正アクセス、Web改ざんなどが疑われる場合は、被害を広げず、証拠を失わないことが重要です。

  1. 責任者と契約先へ連絡する
  2. 被害拡大を抑えるため、必要に応じて決済・ログイン・サイトの一部または全部を停止する
  3. ログ、サーバー、クラウド監査記録、設定、対象ファイルを保全する
  4. 事実関係、原因、影響範囲、対象データを調査する
  5. パスワード、APIキー、認証情報を安全な端末から失効・更新する
  6. 個人情報保護委員会、カード会社、決済代行会社などへの報告要否を確認する
  7. 対象者への通知、問い合わせ対応、再発防止、復旧を進める

慌ててサーバーを初期化したりログを削除したりすると、原因調査や影響範囲の特定が難しくなる場合があります。攻撃が継続している可能性があるため、侵害された疑いのある端末から重要アカウントの認証情報を変更することも避け、専門家の支援を受けてください。

個人情報保護委員会への報告と本人通知

個人情報保護委員会は、次のような漏えい等またはそのおそれを、民間事業者の報告対象として示しています。

  • 要配慮個人情報を含む
  • 不正利用により財産的被害が生じるおそれがある
  • 不正な目的で行われたおそれがある
  • 対象となる本人が1,000人を超える

ECサイトからカード番号を含む個人データが漏えいした場合や、不正アクセスにより個人データが窃取された場合、Webサイトが改ざんされて入力情報が第三者へ送信された場合などが、公式ページの例として挙げられています。

報告対象事態では、発覚後速やかに速報を行い、目安は概ね3〜5日以内です。確報は原則30日以内、不正な目的で行われたおそれがある場合は60日以内です。本人への通知も、状況に応じて速やかに行う必要があります。適用判断は個別事情によるため、早期に専門家と個人情報保護委員会の公式情報を確認してください。

出典：個人情報保護委員会「漏えい等の対応とお役立ち資料」、個人情報保護法ガイドライン（通則編）

ECサイトのセキュリティに関するよくある質問

SSL/TLS証明書があればECサイトは安全ですか？

いいえ。HTTPSは通信の盗聴や改ざんを防ぐ重要な対策ですが、アプリケーションの脆弱性、管理者アカウントの侵害、不正注文、第三者JavaScriptの改ざん、サーバー内部の情報漏えいまでは防げません。

WAFを導入すれば脆弱性診断は不要ですか？

不要にはなりません。WAFは攻撃の検知・遮断を支援しますが、脆弱性そのものを修正するものではありません。アップデート、セキュアな設計・実装、コードレビュー、脆弱性診断と組み合わせます。

SaaS型ECならセキュリティ対策はすべて事業者任せでよいですか？

いいえ。SaaS事業者が基盤を保護していても、管理者アカウント、権限、外部アプリ、タグ、APIキー、決済設定、顧客データ、委託先の管理などは、利用者側の責任になる場合があります。契約と責任分界を確認してください。

カード情報を保存していなければPCI DSSは関係ありませんか？

必ずしもそうとは限りません。決済ページの提供方法、リダイレクト、埋め込みフォーム、実行するスクリプトなどによって、ECサイトがカード会員データ環境のセキュリティに影響を与える場合があります。適用範囲と使用するSAQは、カード会社・決済代行会社・認定評価機関へ確認してください。

EMV 3-Dセキュアを入れれば不正利用を完全に防げますか？

完全には防げません。EMV 3-Dセキュアは重要な本人認証対策ですが、不正ログイン、カードテスティング、アカウント乗っ取り、決済後の不正配送などには、別の対策も必要です。

パスワードは定期的に変更させるべきですか？

漏えいの兆候がない利用者へ一律に定期変更を求める方法は、現在のNISTガイドラインでは推奨されていません。十分な長さ、よく使われる・漏えい済みパスワードの拒否、試行回数の制御、多要素認証、漏えい時の強制変更を重視します。

脆弱性診断はどのくらいの頻度で行えばよいですか？

すべてのECサイトに共通する回数はありません。少なくとも公開前、大規模な変更後、重大な脆弱性が関係するとき、定期的なタイミングで実施を検討します。PCI DSSの対象となる環境では、外部スキャンなどの具体的な頻度が定められる場合があるため、適用要件を確認してください。

まとめ

ECサイトのセキュリティは、SSL/TLS、WAF、ウイルス対策のような単体製品だけでは実現できません。決済、認証、Webアプリケーション、第三者スクリプト、権限、委託先、監視、バックアップ、インシデント対応を組み合わせた多層防御が必要です。

まずは、管理者の多要素認証、不要アカウントとプラグインの削除、アップデート状況の確認、カード情報の取扱いと決済方式の見直し、EMV 3-Dセキュア、ログ監視、バックアップの復元テストから着手してください。そのうえで、IPAのチェックリストとクレジットカード・セキュリティガイドラインを使い、未対応項目に担当者と期限を設定します。

セキュリティ対策に「一度設定すれば完了」という状態はありません。新機能の追加、外部サービスの変更、担当者の異動、脆弱性の公表に合わせて、継続的に点検・改善することが重要です。