CREX｜Security

CREX｜Security

PCI DSSとは？12の要件や対象事業者をわかりやすく解説

更新日：

PCI DSSとは？、12の要件や対象事業者をわかりやすく解説

現代のビジネスにおいて、クレジットカード決済は不可欠なインフラとなっています。しかし、その利便性の裏側には、常にカード情報の漏洩という重大なリスクが潜んでいます。顧客の貴重な情報を守り、安全な決済環境を提供することは、事業者の社会的責務であり、信頼の礎です。

そこで重要となるのが、クレジットカード業界のグローバルセキュリティ基準である「PCI DSS（Payment Card Industry Data Security Standard）」です。

本記事では、PCI DSSとは何かという基本的な定義から、その目的、対象となる事業者、準拠するために満たすべき12の要件、そして準拠することのメリットや準拠しない場合のリスクまで、網羅的かつ分かりやすく解説します。最新バージョンである「v4.0」の変更点にも触れながら、PCI DSS準拠を目指すすべての事業者にとって有益な情報を提供します。

PCI DSSとは

PCI DSSとは

PCI DSSは、クレジットカード決済に関わる事業者にとって、避けては通れない重要なセキュリティ基準です。この章では、PCI DSSがどのようなもので、なぜ策定されたのか、その基本的な概念と背景を詳しく掘り下げていきます。

国際カードブランド5社が策定したセキュリティ基準

PCI DSSは、その正式名称を「Payment Card Industry Data Security Standard」といいます。日本語に訳すと「ペイメントカード業界データセキュリティ基準」となり、その名の通り、クレジットカード情報の保護を目的として策定された、国際的なセキュリティ基準です。

この基準は、以下の国際カードブランド5社によって共同で設立された「PCI SSC（Payment Card Industry Security Standards Council）」という団体によって策ていされ、維持・管理されています。

  • VISA
  • MasterCard
  • JCB
  • American Express
  • Discover

これらのカードブランドは、世界中のクレジットカード決済ネットワークの根幹をなしており、その安全性を確保することは業界全体の最重要課題でした。そこで、各社が独自に定めていたセキュリティ基準を統一し、グローバルで一貫したアプローチを取るためにPCI DSSが生まれました。

PCI DSSが保護の対象とするのは、「カード会員データ」と「機密認証データ」です。具体的には、以下のような情報が含まれます。

データ種別 具体的な情報 PCI DSSでの取り扱い
カード会員データ ・カード会員名
・カード番号（PAN: Primary Account Number）
・有効期限
・サービスコード		 保存する場合は、読めない状態（暗号化、マスキングなど）にする必要があります。
機密認証データ ・磁気ストライプの完全なデータ
・CAV2/CVC2/CVV2/CID（カード裏面の3～4桁の番号）
・PIN/PINブロック（暗証番号）		 いかなる場合でも保存することは固く禁止されています（発行会社による特定の業務を除く）。

事業者は、これらの情報を扱う際に、PCI DSSが定める厳格なルールに従う必要があります。この基準は、単なる技術的な要件の羅列ではなく、技術、運用、管理の各側面から多層的な防御を求める包括的なフレームワークであることが特徴です。

PCI DSSが策定された背景と目的

PCI DSSがなぜ必要とされ、どのような目的で策定されたのかを理解することは、その重要性を深く認識する上で不可欠です。

【背景】
2000年代初頭、インターネットの急速な普及に伴い、Eコマース（電子商取引）が世界的に拡大しました。これにより、消費者はオンラインで手軽に買い物ができるようになった一方で、事業者は大量のクレジットカード情報を自社のシステムで処理・保存するようになりました。

この変化は、サイバー犯罪者にとって新たな攻撃の標的を生み出しました。ECサイトの脆弱性を突いてデータベースに侵入し、カード情報を大量に盗み出すといった事件が世界中で頻発するようになったのです。

当時、各カードブランドはそれぞれ独自のセキュリティプログラム（例: VISAのAIS、MasterCardのSDPなど）を運用していましたが、加盟店（事業者）にとっては、取引のある複数のカードブランドごとに異なる基準への対応を求められ、非常に大きな負担となっていました。また、基準が乱立していることで、業界全体としてのセキュリティレベルの足並みが揃わないという課題もありました。

このような状況を打開し、深刻化するカード情報漏洩の脅威に業界全体で立ち向かうため、国際カードブランド5社が結集し、統一されたグローバル基準として2004年にPCI DSSが策定されました。

【目的】
PCI DSSの根源的な目的は、以下の3つに集約されます。

  1. カード会員データの保護:
    これが最も重要かつ直接的な目的です。クレジットカードの番号や有効期限、セキュリティコードといった機密情報を、漏洩、盗難、不正利用といったあらゆる脅威から保護することを目指します。そのために、データの保存、処理、伝送の各段階における具体的なセキュリティ要件を定めています。
  2. セキュリティレベルの統一と加盟店の負担軽減:
    前述の通り、乱立していたセキュリティ基準を一本化することで、加盟店はPCI DSSという単一の基準に準拠すればよくなりました。これにより、準拠活動の効率化と負担軽減が図られ、事業者がセキュリティ対策に集中しやすい環境が整いました。
  3. カード決済市場の健全な発展と信頼の維持:
    消費者が「このお店なら安心してクレジットカードを使える」と感じられる環境を構築することは、カード決済市場全体の持続的な成長に不可欠です。PCI DSSは、業界全体で高いセキュリティレベルを維持・証明するための枠組みを提供し、消費者からの信頼を確保することで、市場の健全な発展を促進するという大きな目的も担っています。

PCI DSSは、単なる罰則を避けるための義務ではなく、顧客の信頼を得てビジネスを成長させるための重要な経営課題であると認識することが、準拠への第一歩と言えるでしょう。

PCI DSSの対象となる事業者

PCI DSSがどのような事業者を対象としているのかを正しく理解することは、自社に準拠義務があるかどうかを判断する上で極めて重要です。この章では、対象事業者の範囲と、取引件数によって分けられる事業者レベルについて詳しく解説します。

カード情報を扱うすべての事業者

結論から言えば、PCI DSSの対象となるのは、「カード会員データを保存、処理、または伝送するすべての事業者」です。これには、事業の規模や業種、年間の取引件数は一切関係ありません。たとえ個人事業主が運営する小規模なオンラインショップであっても、顧客のクレジットカード情報を自社のシステムで扱っている限り、PCI DSSの準拠対象となります。

具体的には、以下のような事業者が典型的な対象となります。

  • 加盟店（Merchant）:
    • ECサイト運営事業者: 自社のサーバーで顧客のカード情報を入力させ、決済処理を行っている場合。
    • 実店舗を持つ事業者: POS（Point of Sale）レジや決済端末でカード決済を受け付けている小売店、飲食店など。
    • コールセンターを運営する事業者: 電話口で顧客からカード番号を聞き取り、システムに入力している通販会社やサービス事業者。
  • サービスプロバイダ（Service Provider）:
    • 決済代行会社（PSP: Payment Service Provider）: 加盟店に代わって、カード会社とのデータ連携や決済処理を行う事業者。
    • データセンター、ホスティング事業者: 加盟店のサーバーやシステムを預かり、物理的なインフラやネットワーク環境を提供している事業者。
    • システム開発・運用会社: 決済システムやECサイトの構築、保守、運用を請け負っている事業者。
    • セキュリティベンダー: ファイアウォール管理や脆弱性スキャンなど、PCI DSS準拠に関連するサービスを提供している事業者。

ここで重要なポイントは、「自社でカード情報を直接保持していなくても対象になるケースがある」という点です。例えば、決済代行会社が提供する決済画面（トークン決済やリダイレクト型決済）を利用しているECサイトの場合、自社のサーバーにカード情報は保存されません。しかし、顧客がカード情報を入力する決済ページが自社のウェブサイトの一部として提供されている場合、そのウェブサイトのサーバーや関連するシステムもPCI DSSの準拠範囲（スコープ）に含まれる可能性があります。

自社がPCI DSSの対象かどうかを判断する最も確実な方法は、契約しているカード会社やアクワイアラー（加盟店契約会社）に確認することです。多くの場合、加盟店契約の中にPCI DSSへの準拠が義務として盛り込まれています。

取引件数で決まる4つの事業者レベル

PCI DSSの対象となるすべての事業者は、その準拠を証明する必要があります。しかし、その証明方法は、年間のカード取引件数によって定義される「事業者レベル」に応じて異なります。取引件数が多ければ多いほど、漏洩事故が発生した際の影響が甚大になるため、より厳格な審査が求められます。

一般的に、VISAやMasterCardが定める基準が広く用いられており、加盟店は以下の4つのレベルに分類されます。

レベル 年間取引件数（VISA/MasterCard） 主な準拠証明方法
レベル1 年間600万件以上
（または過去に情報漏洩事故を起こした事業者、カードブランドが指定した事業者）		 ・ROC（準拠報告書）：QSAによる年1回の訪問審査
・AOC（準拠証明書）の提出
・ASVスキャン：ASVによる四半期ごとのネットワークスキャン
レベル2 年間100万件～600万件 ・SAQ（自己問診票）とそれに対応するAOC（準拠証明書）の提出
・ASVスキャン：ASVによる四半期ごとのネットワークスキャン
レベル3 年間2万件～100万件（Eコマース事業者は100万件未満すべて） ・SAQ（自己問診票）とそれに対応するAOC（準拠証明書）の提出
・ASVスキャンが必要な場合がある
レベル4 年間2万件未満 ・SAQ（自己問診票）とそれに対応するAOC（準拠証明書）の提出
・ASVスキャンが必要な場合がある

【用語解説】

  • QSA (Qualified Security Assessor): PCI SSCに認定された、PCI DSSの訪問審査を実施できる資格を持つ審査員。
  • ASV (Approved Scanning Vendor): PCI SSCに認定された、外部ネットワークの脆弱性スキャンを実施できるベンダー。
  • ROC (Report on Compliance): QSAが審査結果を詳細に記述した報告書。
  • AOC (Attestation of Compliance): 事業者がPCI DSSに準拠していることを証明する書類。
  • SAQ (Self-Assessment Questionnaire): 事業者が自社の準拠状況を自己評価するための質問票。

レベル1の事業者は、最も厳格な審査が求められます。QSAによる客観的で詳細な訪問審査を受け、その結果をまとめたROCを提出しなければなりません。これは、準拠にかかるコストも時間も最も大きくなります。

一方、レベル2から4の事業者は、主にSAQ（自己問診票）による自己評価が求められます。SAQには、カード情報の取り扱い方法に応じて複数の種類があり、自社の状況に合った正しいSAQを選択して回答する必要があります。ただし、「自己問診」とはいえ、各要件を満たしていることを示す客観的な証拠（ログ、設定ファイル、手順書など）を整理・保管しておくことが求められます。

注意点として、これらのレベル分けや要件は、契約するアクワイアラーやカードブランドの方針によって若干異なる場合があります。最終的には、自社がどのレベルに該当し、何をすべきかについては、必ず契約先のアクワイアラーに確認する必要があります。

PCI DSSが定める12の要件

PCI DSSの中核をなすのが、カード会員データを保護するために遵守すべき「12の要件」です。これらの要件は、6つの「目標」に分類されており、技術的な対策から組織的な管理体制の構築まで、多岐にわたるセキュリティ対策を網羅しています。ここでは、各要件が何を求めているのかを具体的に解説します。

① 要件1：ファイアウォールを導入・維持する

目標：安全なネットワークとシステムの構築・維持

この要件の目的は、信頼できない外部ネットワーク（インターネットなど）と、カード会員データを扱う内部ネットワークとの境界に「壁」を設けることで、不正なアクセスをブロックすることです。

  • 具体的な対策:
    • ファイアウォールやルーターを設置し、送受信されるすべての通信（トラフィック）を検査・制御します。
    • 「カード会員データ環境（CDE）」を、その他の社内ネットワーク（例：一般業務用のLAN）から分離（セグメンテーション）することが強く推奨されます。これにより、万が一社内の別セグメントがマルウェアに感染しても、CDEへの影響を最小限に抑えられます。
    • ファイアウォールの設定ルールは、「すべてを拒否」を基本とし、業務上明確に必要な通信のみを許可する「最小権限の原則」で運用します。
    • ネットワーク構成図を常に最新の状態に保ち、少なくとも半年に一度はファイアウォールの設定ルールを見直すことが求められます。

② 要件2：システムの初期設定を安全なものに変更する

目標：安全なネットワークとシステムの構築・維持

サーバーやネットワーク機器、ソフトウェアなどは、製造元（ベンダー）から出荷された時点では、利便性を優先した共通のパスワードや設定（デフォルト設定）になっていることが多く、これらは広く知られているため、サイバー攻撃の格好の標的となります。この要件は、そうした初期設定の脆弱性を排除することを目的としています。

  • 具体的な対策:
    • 「admin」「password」といった安易な初期パスワードは、システム導入後、運用を開始する前に必ず独自の複雑なものに変更します。
    • 業務に不要な機能やサービス、ポートはすべて無効化します。
    • システムのセキュリティを強化するための設定（ハードニング）を業界標準やベストプラクティスに基づいて実施します。
    • CDE内に設置するすべての機器について、こうしたセキュリティ強化の手順を文書化し、徹底することが重要です。

③ 要件3：保存しているカード会員データを保護する

目標：カード会員データの保護

万が一、攻撃者によってシステム内に侵入されたとしても、盗み出されたデータが意味のない文字列であれば、被害を最小限に食い止められます。この要件は、保存するカード会員データを読み取り不可能な状態にして保護することを目的としています。

  • 具体的な対策:
    • まず大前提として、法規制や業務上の理由で明確な必要性がない限り、カード会員データを保存してはいけません。
    • カード番号（PAN）を保存する必要がある場合は、暗号化、トークン化（意味のない別の文字列に置き換える技術）、または一方向ハッシュ化といった強力な技術を用いて、復元不可能な状態または厳格な管理下でしか復元できない状態にします。
    • 画面表示や印刷物では、カード番号の最初の6桁と最後の4桁以外を「*」などで隠す「マスキング」を行う必要があります（例: 411111******1111）。
    • データを暗号化するための「鍵」は、データとは別の安全な場所に、厳格なアクセス制御のもとで管理することが極めて重要です。

④ 要件4：公共ネットワークでカード会員データを伝送する際は暗号化する

目標：カード会員データの保護

インターネットや公衆無線LANといったオープンな公共ネットワーク上でカード会員データを送受信する際、データが暗号化されていなければ、通信経路上で第三者に盗聴（パケットキャプチャ）されるリスクがあります。この要件は、伝送中のデータを保護することを目的としています。

  • 具体的な対策:
    • ECサイトの決済ページや、システム間のデータ連携など、公共ネットワークを介してカード会員データを伝送する際は、TLS（Transport Layer Security）v1.2以上といった、現時点で安全とされる強力な暗号化プロトコルを使用します。
    • SSLやTLS v1.0/v1.1といった、既知の脆弱性が存在する古いバージョンのプロトコルは使用してはいけません。
    • エンドユーザーが使用するブラウザやデバイスとの通信だけでなく、サービスプロバイダとの通信など、すべての外部通信が対象となります。

⑤ 要件5：マルウェアからすべてのシステムを保護し、定期的に更新する

目標：脆弱性管理プログラムの維持

ウイルス、ワーム、スパイウェア、ランサムウェアといった「マルウェア」は、システムに侵入し、情報を盗み出したり、システムを破壊したりする悪意のあるソフトウェアの総称です。この要件は、マルウェアの感染を未然に防ぎ、検知・駆除する体制を維持することを目的としています。

  • 具体的な対策:
    • カード会員データ環境（CDE）内のすべてのサーバー、PCにアンチウイルスソフトウェアを導入します。
    • アンチウイルスソフトは、常に稼働させ、定義ファイル（パターンファイル）を自動で最新の状態に更新する設定にします。
    • 定期的にシステム全体のスキャンを実行し、結果のログを保管します。
    • マルウェアに感染しやすいとされるシステム（例: WindowsベースのPCなど）だけでなく、一般的に安全と見なされがちなシステム（例: Linuxサーバー）も対象となります。

⑥ 要件6：安全性の高いシステムとアプリケーションを開発・維持する

目標：脆弱性管理プログラムの維持

自社で開発したWebアプリケーションやシステムのプログラムに不備（脆弱性）があると、SQLインジェクションやクロスサイトスクリプティング（XSS）といった攻撃手法によって、データベース内の情報を不正に窃取される可能性があります。この要件は、開発段階からセキュリティを考慮し、運用開始後も脆弱性を迅速に修正する体制を求めるものです。

  • 具体的な対策:
    • OWASP（Open Web Application Security Project）などが公開しているガイドラインに基づき、セキュアコーディング（安全なプログラミング）の規約を定めて開発者に遵守させます。
    • 公開されているOSやミドルウェアのセキュリティパッチは、リスクを評価した上で、リリースから原則1ヶ月以内に適用します。
    • アプリケーションを公開する前に、専門家による脆弱性診断（Webアプリケーション診断）やコードレビューを実施します。
    • 特に決済処理に関わるアプリケーションには、より厳格なチェックが求められます。

⑦ 要件7：カード会員データへのアクセスを業務上必要な範囲に制限する

目標：強力なアクセス制御措置の実施

情報セキュリティの基本原則の一つに「知る必要性（Need-to-Know）」があります。これは、従業員であっても、その業務を遂行する上で本当に必要な情報にしかアクセスできないように制限すべき、という考え方です。この要件は、この原則をカード会員データへのアクセスに適用することを求めています。

  • 具体的な対策:
    • デフォルト（初期設定）ですべてのアクセスを拒否し、個々のユーザーや役割に対して、業務上最低限必要なデータへのアクセス権限のみを明示的に付与します。
    • 役割ベースのアクセスコントロール（RBAC: Role-Based Access Control）を導入し、「経理担当者」「顧客サポート担当者」といった役割ごとにアクセス権限を定義・管理します。
    • アクセス制御の仕組みを文書化し、適切に運用されていることを定期的に確認します。

⑧ 要件8：システムへのアクセスを識別・認証する

目標：強力なアクセス制御措置の実施

システムにアクセスする人物が「誰であるか（識別）」を特定し、その人物が「本人であること（認証）」を確認できなければ、不正なアクセスを防ぐことはできません。この要件は、システム利用者の一意な識別と、強固な認証メカニズムの導入を求めています。

  • 具体的な対策:
    • すべての利用者に、他者と重複しない一意のユーザーIDを割り当てます。複数人で共有するアカウント（例: admin, support）の使用は原則として禁止です。
    • パスワードは、最低文字数、複雑さ（英数字・記号の混在）、定期的な変更（例: 90日ごと）などを定めた厳格なポリシーに従って設定させます。
    • 多要素認証（MFA）を導入します。特に、CDEへのリモートアクセスや、管理者権限でのアクセスにはMFAが必須です。PCI DSS v4.0では、このMFAの適用範囲がさらに拡大・強化されています。

⑨ 要件9：カード会員データへの物理的なアクセスを制限する

目標：強力なアクセス制御措置の実施

サイバー攻撃だけでなく、物理的な不正侵入による情報窃取も大きなリスクです。カード会員データが保存されているサーバーや、バックアップテープ、関連書類などが保管されている場所への物理的なアクセスを厳しく管理することが求められます。

  • 具体的な対策:
    • サーバーラックが設置されているデータセンターやサーバルームは、施錠管理されたエリアとします。
    • ICカードや生体認証などによる入退室管理システムを導入し、誰がいつ入退室したかを記録します。
    • 監視カメラを設置して、機密性の高いエリアを常時モニタリングします。
    • 業務で不要になったカード情報が記載された書類は、シュレッダーで復元不可能な状態にして廃棄します。

⑩ 要件10：ネットワークやカード会員データへのアクセスをすべて追跡・監視する

目標：ネットワークの定期的な監視・テスト

万が一セキュリティインシデントが発生した際に、「いつ、誰が、何をしたのか」を追跡できなければ、原因究明や被害範囲の特定が困難になります。この要件は、システムへのアクセスや操作に関するログをすべて記録し、定期的に監視することを求めています。

  • 具体的な対策:
    • CDE内のすべてのサーバー、ネットワーク機器、アプリケーションでログ機能を有効にし、ユーザーの操作、管理者権限の操作、認証試行などを記録します。
    • 取得したログは、改ざんされないように保護し、最低1年間は保管します（うち直近3ヶ月はすぐに分析できる状態で保管）。
    • 記録されたログは、自動化ツールや担当者によって毎日レビューし、不審なアクティビティや異常がないかを確認します。

⑪ 要件11：セキュリティシステムとプロセスを定期的にテストする

目標：ネットワークの定期的な監視・テスト

導入したセキュリティ対策が、実際に有効に機能しているかを継続的に検証しなければ、新たな脅威に対応できません。この要件は、定期的なテストを通じて、セキュリティ体制の有効性を確認し、脆弱性を発見・修正するプロセスを確立することを求めています。

  • 具体的な対策:
    • 外部脆弱性スキャン: ASV（認定スキャンベンダー）によって、少なくとも四半期に一度、インターネットに公開されているシステムの脆弱性スキャンを実施します。
    • 内部脆弱性スキャン: 同様に、四半期に一度、内部ネットワークの脆弱性スキャンを実施します。
    • ペネトレーションテスト（侵入テスト）: 少なくとも年に一度、およびシステムに大きな変更があった際に、専門家が擬似的な攻撃を行ってシステムの脆弱性を洗い出すテストを実施します。
    • ファイル改ざん検知メカニズムを導入し、重要なシステムファイルの変更を週に一度はチェックします。

⑫ 要件12：情報セキュリティに関するポリシーを維持する

目標：情報セキュリティポリシーの維持

これまでに挙げた11の要件を場当たり的に実施するのではなく、組織全体として情報セキュリティに取り組むための「憲法」となるポリシー（方針・規程）を定め、全従業員がそれを理解し、遵守する文化を醸成することが求められます。

  • 具体的な対策:
    • 網羅的な情報セキュリティポリシーを文書化し、経営層の承認を得ます。
    • このポリシーを、正社員、契約社員、業務委託先のスタッフなど、関係者全員に周知徹底します。
    • 年に一度以上のセキュリティ意識向上トレーニングを実施し、従業員の知識を最新の状態に保ちます。
    • 情報漏洩などのインシデントが発生した際の対応手順を定めた「インシデントレスポンス計画」を策定し、定期的に訓練を実施します。

これら12の要件は相互に関連し合っており、一つでも欠けるとセキュリティチェーンに穴が開いてしまいます。PCI DSS準拠とは、これらすべての要件を継続的に満たし続けることを意味します。

PCI DSSに準拠する3つのメリット

情報セキュリティレベルが向上する、企業の信頼性やブランドイメージが向上する、ビジネスチャンスの拡大につながる

PCI DSSへの準拠は、決して簡単な道のりではなく、相応のコストとリソースを必要とします。しかし、その労力に見合う、あるいはそれ以上の大きなメリットを企業にもたらします。ここでは、準拠によって得られる3つの主要なメリットを解説します。

① 情報セキュリティレベルが向上する

PCI DSS準拠に取り組む最大のメリットは、組織全体の情報セキュリティレベルが体系的かつ飛躍的に向上することです。これは、準拠が単なるチェックリストの消化作業ではないからです。

PCI DSSが定める12の要件は、技術的な対策（ファイアウォール、暗号化、脆弱性管理など）から、物理的な対策（入退室管理など）、そして組織的な対策（ポリシー策定、従業員教育、インシデント対応計画など）まで、セキュリティにおける重要な側面を網羅しています。準拠プロセスを進める中で、自社のセキュリティ体制をこれらの要件に照らし合わせて総点検することになります。

この過程で、これまで見過ごされてきた脆弱性や、管理プロセスの不備が明らかになります。例えば、

  • 「とりあえず動いているから」と放置されていたサーバーの古いソフトウェア
  • 退職した従業員のアカウントの消し忘れ
  • 曖昧なルールで運用されていた管理者権限
  • 文書化されていなかったインシデント発生時の連絡体制

といった課題が洗い出され、具体的な改善策が講じられます。

重要なのは、これらの強化されたセキュリティ対策は、クレジットカード情報だけでなく、企業が保有する他の重要な情報資産（個人情報、顧客データ、営業秘密、技術情報など）の保護にも直接的に寄与するという点です。結果として、ランサムウェア攻撃や標的型攻撃といった、カード情報漏洩以外のサイバー脅威に対する耐性も同時に高まります。PCI DSS準拠は、企業全体のセキュリティガバナンスを確立し、デジタル社会における事業継続性を確保するための強力な基盤となるのです。

② 企業の信頼性やブランドイメージが向上する

今日の消費者は、自らの個人情報がどのように扱われるかについて非常に敏感です。特に、クレジットカード情報のような機密性の高い情報を提供することには、少なからず不安を感じています。このような状況において、PCI DSSに準拠しているという事実は、「私たちは、お客様の情報を国際的な基準に則って厳格に保護しています」という明確で客観的なメッセージとなります。

  • 顧客へのアピール:
    PCI DSSの準拠認定を受けると、多くの場合、ウェブサイトや店舗に準拠を示すロゴマークを掲示できます。これを見た顧客は、その企業がセキュリティに真摯に取り組んでいることを認識し、安心して商品やサービスを購入できます。これは、特に新規顧客を獲得する際の大きなアドバンテージとなり得ます。
  • 取引先からの信頼獲得:
    BtoBの取引においても、PCI DSS準拠は極めて重要です。近年、サプライチェーン全体でのセキュリティ確保が重視されており、取引先を選定する際に、その企業のセキュリティ体制を評価する動きが活発になっています。特に、決済システムを連携させる場合や、顧客データを共有するようなビジネスでは、取引の前提条件としてPCI DSS準拠を求められるケースが増加しています。準拠していることで、ビジネス交渉を有利に進め、信頼できるパートナーとしての地位を確立できます。

情報漏洩事故を起こした企業が、顧客や取引先からの信頼を失い、長期にわたってブランドイメージの低下に苦しむ例は後を絶ちません。PCI DSSへの準拠は、こうしたレピュテーションリスクを未然に防ぎ、企業の社会的信用とブランド価値を維持・向上させるための、攻めと守りを兼ね備えた投資と言えるでしょう。

③ ビジネスチャンスの拡大につながる

情報セキュリティレベルと企業信頼性の向上は、最終的に具体的なビジネスチャンスの拡大へと繋がります。

  • 新規市場・顧客層の開拓:
    セキュリティ意識の高い大企業や公的機関は、取引先に高いレベルのセキュリティを要求します。PCI DSSに準拠していなければ、そもそも入札に参加できなかったり、商談のテーブルにつくことさえできなかったりする場合があります。逆に、準拠していることが、これまでアプローチできなかった市場への参入障壁をクリアする鍵となり得ます。
  • グローバル展開の促進:
    PCI DSSは、国際カードブランド5社が策定した世界共通の基準です。そのため、海外の顧客やパートナー企業との取引においても、その有効性が広く認められています。海外進出を目指す企業にとって、PCI DSS準拠は「グローバルスタンダードのセキュリティレベルを満たしている」ことの証明となり、国境を越えたビジネスを円滑に進めるためのパスポートのような役割を果たします。
  • カードブランドとの良好な関係構築:
    PCI DSSに準拠し、カード情報の安全な取り扱いに努めることは、カードブランドやアクワイアラーとの信頼関係を深めることにも繋がります。これにより、将来的に新しい決済手段やサービスを導入する際に、スムーズな連携や支援を受けやすくなる可能性があります。

このように、PCI DSS準拠は、単なるコンプライアンス対応という守りの側面だけでなく、企業の競争力を高め、新たな成長機会を創出する攻めの戦略としても非常に大きな価値を持つのです。

PCI DSSに準拠しない場合のリスク・罰則

カードブランドからの罰金、カード取引ライセンスの停止・剥奪、損害賠償請求と社会的信用の失墜

PCI DSS準拠のメリットを理解する一方で、準拠しない場合にどのようなリスクや罰則が待ち受けているのかを正しく認識することも同様に重要です。コンプライアンス違反は、企業の存続を揺るがしかねない深刻な事態を引き起こす可能性があります。

カードブランドからの罰金

PCI DSSに準拠していない状態でカード情報の漏洩事故を起こした場合、カードブランドから加盟店契約会社（アクワイアラー）を通じて、高額な罰金（ペナルティ）が科される可能性があります。

この罰金は、直接的な契約関係のないカードブランドから加盟店へ直接請求されるわけではなく、カードブランドがアクワイアラーに請求し、そのアクワイアラーが加盟店契約に基づき、加盟店へ請求するという流れが一般的です。

罰金の額は、漏洩したカード会員データの件数、被害の規模、事業者の対応の悪質性などによって変動しますが、ケースによっては数千万円から数億円に上ることもあります。さらに、情報漏洩によって不正利用された被害額の補填（チャージバック）も求められるため、金銭的な負担は計り知れません。

これらの費用は、中小企業にとっては経営を直接圧迫する致命的な金額になり得ます。「うちは規模が小さいから大丈夫だろう」という安易な考えは非常に危険です。

カード取引ライセンスの停止・剥奪

金銭的なペナルティ以上に、事業者にとって深刻な影響を及ぼすのが、クレジットカード取引ライセンス（加盟店契約）の停止、あるいは剥奪です。

情報漏洩事故の規模や内容が悪質であるとカードブランドやアクワイアラーに判断された場合、一時的または永久的にクレジットカード決済の取り扱いを禁じられることがあります。

特に、ECサイトやサブスクリプションサービスなど、売上の大部分をクレジットカード決済に依存している事業者にとって、これは事実上の死刑宣告に等しい措置です。決済手段を失うことで、事業の継続そのものが不可能になるリスクがあります。

一度ライセンスを剥奪されてしまうと、同じ事業者名で再契約することは極めて困難です。これは、単に一つのアクワイアラーとの契約が終了するだけでなく、カード業界全体のブラックリストに載ることを意味するため、他のアクワイアラーとの新規契約も絶望的になります。

損害賠償請求と社会的信用の失墜

カードブランドからの罰則に加えて、事業者にはさらなる三重苦が待ち受けています。

  1. 顧客からの損害賠償請求:
    カード情報を漏洩させてしまった顧客から、プライバシー侵害などを理由に集団訴訟を起こされ、多額の損害賠償を請求されるリスクがあります。訴訟に対応するための弁護士費用や、和解金・賠償金の支払いなど、さらなる金銭的負担が発生します。
  2. インシデント対応コスト:
    情報漏洩が発覚した場合、原因究明のためのフォレンジック調査費用、顧客への通知・お詫びのための通信費やコールセンター設置費用、広報・PR対応費用など、事故の収束までに莫大なコストと時間、人員を要します。
  3. 社会的信用の失墜と顧客離れ:
    これが最も回復が困難なダメージかもしれません。情報漏洩事故を起こしたという事実はニュースなどで広く報道され、「セキュリティ意識の低い会社」「顧客情報をぞんざいに扱う会社」というネガティブな評判が定着してしまいます。一度失った顧客の信頼を取り戻すのは容易ではなく、長期的な顧客離れや売上減少に繋がります。ブランドイメージの回復には、事故対応費用の何倍ものコストと長い年月が必要となるでしょう。

これらのリスクを総合的に勘案すると、PCI DSS準拠のために先行投資を行うことは、将来発生しうる天文学的な損失を回避するための、極めて合理的な経営判断であると言えます。

PCI DSS準拠を達成するまでの5ステップ

準拠対象範囲（スコープ）の特定、現状と要件とのギャップ分析、セキュリティ対策の実施、準拠状況の審査、準拠報告と証明書の取得

PCI DSS準拠は、一夜にして達成できるものではありません。計画的かつ体系的なアプローチが不可欠です。ここでは、準拠を達成するための標準的な5つのステップを解説します。

① 準拠対象範囲（スコープ）の特定

これは、PCI DSS準拠プロジェクトにおける最も重要かつ最初のステップです。スコープとは、PCI DSSの12の要件が適用される範囲のことで、具体的には「カード会員データを保存、処理、伝送する、あるいはそのセキュリティに影響を与えうるすべてのシステムコンポーネント、プロセス、および人員」を指します。

  • なぜスコープの特定が重要か？
    スコープが広ければ広いほど、準拠のために保護・管理しなければならない対象が増え、対策にかかるコスト、工数、時間が膨れ上がります。逆に、スコープを可能な限り限定（最小化）できれば、準拠の負担を大幅に軽減できます。
  • スコープの特定方法:
    1. データフローの可視化: 顧客がカード情報を入力してから、決済処理が完了するまでの全工程で、データが「どこで」「どのように」流れ、「どこに」保存されるのかを正確に図示します（データフロー図の作成）。
    2. 関連コンポーネントの洗い出し: データフローに関わるすべてのシステムコンポーネント（サーバー、ネットワーク機器、PC、アプリケーション、データベースなど）をリストアップします。
    3. スコープの最小化: ネットワークセグメンテーション（分離）が最も効果的な手法です。ファイアウォールを用いて、カード会員データ環境（CDE）を他の社内ネットワーク（一般業務LANなど）から完全に分離します。これにより、PCI DSSの要件は厳格に管理されたCDE内にのみ適用され、一般業務LANはスコープ外とすることができます。

このステップを曖昧なまま進めると、後工程ですべての作業が手戻りになる可能性があります。必要であれば、QSAなどの専門家の支援を受けて、正確にスコープを定義することが成功の鍵です。

② 現状と要件とのギャップ分析

スコープが明確になったら、次にそのスコープ内の現状のセキュリティ対策（As-Is）と、PCI DSSが求める要件（To-Be）との間にどれくらいの差（ギャップ）があるのかを分析します。

  • ギャップ分析の進め方:
    PCI DSSの12の要件と、それに付随する約400のサブ要件一つひとつに対して、自社の現状を照らし合わせていきます。

    • 満たしている（Compliant）: 要件を完全に満たしており、それを証明する証拠（ドキュメント、ログなど）も揃っている。
    • 満たしていない（Not Compliant）: 要件を満たしていない、または部分的にしか満たしていない。
    • 適用除外（Not Applicable）: 自社の環境では該当しない要件（例: 無線LANを使用していない場合の無線LAN関連要件）。

この作業は専門知識を要するため、多くの企業がQSAによる「予備審査」や「ギャップ分析サービス」を利用します。専門家は、単にギャップを指摘するだけでなく、そのギャップを埋めるための具体的な改善策も提案してくれます。この分析結果が、次のステップである「セキュリティ対策の実施」の具体的なロードマップとなります。

③ セキュリティ対策の実施

ギャップ分析によって明らかになった課題を、一つずつ解決していくフェーズです。これは、準拠プロジェクトの中で最も多くのリソースと時間を要する段階です。

  • 実施内容の例:
    • 技術的対策:
      • ファイアウォールのルール見直しと再設定
      • サーバーやOSのセキュリティパッチ適用
      • カードデータの暗号化ソリューション導入
      • 多要素認証（MFA）システムの導入
      • ログ収集・監視ツールの導入
    • 運用的・管理的対策:
      • 情報セキュリティポリシーや各種手順書の作成・改訂
      • 従業員へのセキュリティ教育の実施
      • インシデント対応計画の策定と訓練
      • アクセス権限の棚卸しと再設定

これらの対策は、優先順位をつけ、計画的に実行していく必要があります。リスクの高い項目から着手するのが一般的です。プロジェクト管理の手法を用いて、進捗、課題、コストを適切に管理することが重要です。

④ 準拠状況の審査

すべての対策が完了したら、その結果がPCI DSSの要件を正式に満たしているかどうかを評価する「審査」のフェーズに移ります。審査方法は、前述の「事業者レベル」によって異なります。

  • レベル1事業者の場合（訪問審査）:
    QSA（認定審査員）が現地を訪れ、数日から数週間にわたって審査を実施します。

    • ドキュメントレビュー: ポリシーや手順書が要件を満たしているかを確認。
    • ヒアリング: 担当者に運用状況について質問。
    • 実機確認: サーバーやネットワーク機器の設定が適切か、ログが取得されているかなどを実際に確認。
    • サンプリングテスト: 複数の対象からサンプルを抽出し、ルール通りに運用されているかを検証。
  • レベル2～4事業者の場合（自己問診）:
    自社のカード情報取り扱い形態に合ったSAQ（自己問診票）を選択し、すべての質問に「はい」「いいえ」「該当なし」などで回答します。「はい」と回答した項目については、その根拠となる証拠を提示できる必要があります。SAQの作成は自社で行いますが、内容の正確性を担保するためにQSAの支援を受ける企業も少なくありません。

また、多くのレベルでASV（認定スキャンベンダー）による四半期ごとの外部ネットワークスキャンも必須となります。スキャンで脆弱性が発見された場合は、修正して再スキャンを行い、合格する必要があります。

⑤ 準拠報告と証明書の取得

審査の結果、すべての要件を満たしていることが確認されると、準拠を証明する書類が発行されます。

  • QSAによる訪問審査の場合:
    • ROC（Report on Compliance; 準拠報告書）: 審査内容と結果を詳細に記述した、数百ページに及ぶ報告書。
    • AOC（Attestation of Compliance; 準拠証明書）: ROCの要約版で、事業者がPCI DSSに準拠していることを公式に証明するエグゼクティブサマリー。
  • SAQによる自己問診の場合:
    • 完成したSAQと、その結果に基づいて作成されたAOC（準拠証明書）。

これらの証明書類を、契約しているアクワイアラーやカードブランドに提出することで、年次の準拠報告が完了します。

重要なのは、PCI DSS準拠は一度達成すれば終わりではないという点です。これは、毎年更新が必要な継続的なプロセスです。年次審査だけでなく、日々の運用の中でセキュリティポリシーを遵守し、ログを監視し、新たな脆弱性に対応し続ける「Business as Usual（BAU）」の体制を構築することが、真の準拠状態を維持する上で不可欠です。

最新バージョン「PCI DSS v4.0」の主な変更点

PCI DSSは、変化し続けるサイバー攻撃の脅威に対応するため、数年ごとに改訂されます。2022年3月には、最新メジャーバージョンである「PCI DSS v4.0」がリリースされました。v3.2.1からの移行期間を経て、現在ではv4.0への準拠が求められています。ここでは、v4.0の主な変更点について解説します。

v4.0への移行スケジュール

PCI SSCは、事業者が新しいバージョンへ円滑に移行できるよう、十分な移行期間を設けています。v4.0への移行スケジュールは以下の通りです。

日付 内容
2022年3月31日 PCI DSS v4.0 リリース
2024年3月31日 PCI DSS v3.2.1 引退（この日以降、年次審査はv4.0で実施）
2025年3月31日 v4.0で新たに追加された要件が「ベストプラクティス（推奨）」から「必須」へ移行

このスケジュールからわかるように、2024年4月1日以降の審査は、すべてPCI DSS v4.0に基づいて行われる必要があります。さらに、2025年3月31日までは猶予期間が設けられている一部の「将来の日付指定の新しい要件」も、それ以降は完全に必須化されます。これから準拠を目指す事業者はもちろん、すでに準拠している事業者も、v4.0への対応が急務となっています。
（参照：PCI Security Standards Council 公式サイト）

「カスタマイズアプローチ」の導入

PCI DSS v4.0における最も大きな概念的変更点が、「カスタマイズアプローチ（Customized Approach）」の導入です。

  • 従来の「定義済みアプローチ（Defined Approach）」:
    これは、v3.2.1まで採用されていた唯一のアプローチです。PCI DSSの各要件に書かれている通りの方法で、セキュリティ対策を実装・テストすることが求められます。非常に明確で分かりやすい一方、新しい技術や独自のセキュリティ対策を導入している企業にとっては、柔軟性に欠けるという側面がありました。
  • 新しい「カスタマイズアプローチ」:
    v4.0では、この定義済みアプローチに加えて、カスタマイズアプローチが選択できるようになりました。これは、各要件が目指す「目的（Intent）」を満たすのであれば、事業者は要件に書かれている方法とは異なる、独自のセキュリティ管理策を設計・実装できるというものです。
    例えば、AIを活用した異常検知システムなど、先進的な技術を導入している企業が、その技術の有効性を証明することで、定義済みアプローチの代替策として認められる可能性があります。

ただし、このアプローチは自由度が高い分、その管理策が要件の目的を十分に満たしていることを、客観的かつ厳格なリスク分析とテストを通じて証明する責任を事業者が負います。そのため、高度なセキュリティ専門知識と文書化能力が求められ、すべての企業に適した選択肢というわけではありません。基本的には、従来通りの「定義済みアプローチ」が標準的な選択肢となります。

新たな要件の追加と既存要件の強化

v4.0では、近年のサイバー攻撃のトレンドや技術の変化を反映し、多くの要件が追加・強化されました。ここでは、特に重要な変更点をいくつか紹介します。

  1. 多要素認証（MFA）の全面的な適用拡大:
    v3.2.1では、CDEへのリモートアクセスなどにMFAが求められていましたが、v4.0ではその適用範囲が大幅に拡大されました。CDEへのすべてのアクセス（コンソールアクセス含む）に対してMFAが必須となり、パスワードと他の認証要素（スマートカード、生体認証、ワンタイムパスワードなど）の組み合わせが標準となります。
  2. パスワード要件の強化:
    従来のパスワード要件（最低7文字、90日ごとの変更など）に加えて、より強力なパスワードポリシーが求められるようになりました。システムが対応している場合、最低12文字（管理者アカウントは15文字）の長さ、および15分間のロックアウトなどの要件が追加されました。
  3. フィッシング対策の強化:
    従業員を標的としたフィッシング攻撃による情報漏洩が増加していることを受け、v4.0ではフィッシング攻撃に対するセキュリティ意識向上トレーニングをシミュレーション形式で実施することが求められるようになりました。
  4. ECサイトの決済ページ保護の強化:
    ECサイトの決済ページに不正なスクリプトを埋め込み、入力されたカード情報を窃取する「eコマーススキミング（フォームジャッキング）」攻撃への対策として、新たな要件が追加されました。決済ページで実行されるすべてのスクリプトの正当性を確認し、不正な変更や追加を検知する仕組みの導入が求められます。

これらの変更は、PCI DSSが静的な基準ではなく、脅威の進化に合わせて進化し続ける動的なフレームワークであることを示しています。事業者は、これらの新しい要求事項を正確に理解し、自社のセキュリティ体制に組み込んでいく必要があります。

PCI DSS準拠に関するよくある質問

PCI DSSの準拠プロセスには、多くの専門用語や独自の概念が登場します。ここでは、初心者が特につまずきやすい用語や疑問について、Q&A形式で分かりやすく解説します。

QSA・ASVとは何ですか？

A. QSAとASVは、どちらもPCI DSSの準拠を評価・支援する上で重要な役割を担う、PCI SSC（PCIセキュリティ基準協議会）から正式な認定を受けた第三者機関です。

  • QSA (Qualified Security Assessor; 認定セキュリティ評価人)
    QSAは、PCI DSSの準拠状況を評価するための専門的な知識とスキルを持つと認定された審査員または企業です。主な役割は、事業者レベル1の企業に対する訪問審査（オンサイト評価）を実施し、その結果をROC（準拠報告書）としてまとめることです。また、レベルを問わず、ギャップ分析や準拠コンサルティングといった支援サービスも提供しており、多くの企業が準拠プロセスでQSAの助言を仰ぎます。QSAは、PCI DSSに関する深い知見を持つ、準拠活動における最も頼れるパートナーの一人です。
  • ASV (Approved Scanning Vendor; 認定スキャンベンダー)
    ASVは、PCI DSS要件11.2で定められている「外部脆弱性スキャン」を実施することを認定されたベンダーです。このスキャンは、インターネット側から事業者のシステム（Webサーバー、ファイアウォールなど）を調査し、攻撃の足がかりとなりうるセキュリティ上の脆弱性がないかを確認するものです。ASVによるスキャンは、少なくとも四半期（3ヶ月）に一度実施し、合格（Passing Scan）の結果を得る必要があります。もし脆弱性が発見された場合は、それを修正した上で再度スキャンを行い、合格するまで繰り返さなければなりません。

SAQ（自己問診票）とは何ですか？

A. SAQ (Self-Assessment Questionnaire; 自己問診票)は、主に事業者レベル2から4の加盟店や、特定の条件を満たすサービスプロバイダが、自社のPCI DSS準拠状況を自己評価するために使用する質問票です。

SAQは、PCI DSSのすべての要件を網羅した質問リスト形式になっており、各質問に対して「はい」「いいえ」「該当なし」などで回答していきます。重要なのは、SAQにはカード情報の取り扱い方法によって複数の種類（タイプ）があるという点です。

SAQタイプ（例） 対象となる事業者の概要
SAQ A カード情報を一切処理・伝送・保存せず、すべての処理をPCI DSSに準拠した第三者（決済代行会社など）に完全に委託しているECサイトなど。
SAQ A-EP ECサイトで、決済処理自体は第三者に委託しているが、顧客がカード情報を入力する決済ページを自社サイトで提供している場合。
SAQ B-IP 実店舗で、インターネット経由で決済情報を送信するスタンドアロンの決済端末（IP接続）のみを使用している場合。
SAQ C 実店舗で、決済アプリケーションがインターネットに接続されたPCなどにインストールされているが、カード情報を電子的に保存していない場合。
SAQ D 上記のいずれにも当てはまらない、すべての加盟店およびサービスプロバイダ。最も要件数が多く、審査が厳しいタイプ。

自社のビジネスモデルやシステム構成に合致した、正しいタイプのSAQを選択することが極めて重要です。間違ったSAQを選択すると、準拠報告が無効と見なされる可能性があります。どのSAQが自社に該当するか不明な場合は、契約しているアクワイアラーやQSAに相談することをおすすめします。

ROC（準拠報告書）とAOC（準拠証明書）の違いは何ですか？

A. ROCとAOCは、どちらもPCI DSS準拠審査の結果として作成される重要なドキュメントですが、その目的と内容が異なります。

  • ROC (Report on Compliance; 準拠報告書)
    ROCは、QSAが実施した訪問審査の全内容を詳細に記述した、包括的な報告書です。これには、審査の対象となった範囲（スコープ）、審査方法、各要件に対する評価、確認された証拠、担当者へのヒアリング内容などが、すべて記録されています。そのため、非常に分厚い（数百ページに及ぶことも珍しくない）文書となり、主に事業者とQSAが審査内容の詳細を共有・保管するために使用されます。ROCは、準拠を証明するための詳細な根拠資料と位置づけられます。
  • AOC (Attestation of Compliance; 準拠証明書)
    AOCは、その名の通り、事業者がPCI DSSに準拠していることを公式に証明するための書類です。ROCが詳細な報告書であるのに対し、AOCは審査結果の要約（エグゼクティブサマリー）であり、数ページ程度の簡潔な文書です。ここには、事業者の情報、審査を実施したQSAの情報、準拠したPCI DSSのバージョン、そして最終的な審査結果（準拠しているか否か）が明記されています。事業者は、このAOCをアクワイアラーやカードブランドに提出することで、年次の準拠報告を行います。

簡単に言えば、「ROCは審査内容のすべてを記録した詳細レポート」であり、「AOCはその結果をまとめた公式な証明書」と理解すると分かりやすいでしょう。SAQによる自己評価の場合も、ROCはありませんが、AOCは作成・提出する必要があります。

PCI DSS準拠を支援するコンサルティング会社5選

PCI DSS準拠は専門性が高く、自社のリソースだけでは達成が困難な場合が少なくありません。多くの企業が、専門のコンサルティング会社の支援を活用しています。ここでは、日本国内でPCI DSS準拠支援サービスを提供している代表的な企業を5社紹介します。

① NRIセキュアテクノロジーズ株式会社

NRIセキュアテクノロジーズは、野村総合研究所（NRI）グループのセキュリティ専門企業です。日本国内で最初にQSA（認定セキュリティ評価人）資格を取得した企業の一つであり、長年にわたる豊富な実績と高い専門性を誇ります。PCI DSS準拠の初期段階であるギャップ分析から、コンサルティング、審査、そして準拠維持のための運用支援まで、一貫したワンストップサービスを提供しているのが大きな強みです。金融機関をはじめとする大規模で複雑なシステムへの対応実績も豊富で、信頼性の高い支援を求める企業に適しています。
（参照：NRIセキュアテクノロジーズ株式会社 公式サイト）

② TIS株式会社

TISは、金融・決済領域に強みを持つ国内有数の大手システムインテグレーター（SIer）です。PCI DSS準拠支援コンサルティングや審査サービスはもちろんのこと、セキュアな決済システムの設計・構築から運用までを手がけることができます。単に基準への準拠を支援するだけでなく、企業のビジネスモデルに合わせた最適な決済インフラの実現をサポートできる点が特徴です。幅広い業種・業態への対応実績があり、システム構築とコンプライアンス対応を同時に進めたい企業にとって心強いパートナーとなります。
（参照：TIS株式会社 公式サイト）

③ 株式会社B-EN-G

株式会社B-EN-G（ビジネスエンジニアリング）は、特に製造業や流通業向けのERP（統合基幹業務システム）導入に強みを持つコンサルティングファームです。その知見を活かし、ERPシステムと連携する決済システムのPCI DSS準拠支援に特色があります。グローバルに事業を展開する企業への支援実績も多く、海外拠点を含めたグループ全体の準拠体制構築をサポートできる点が強みです。基幹システムとの連携を考慮した、現実的で効率的な準拠プランの提案が期待できます。
（参照：株式会社B-EN-G 公式サイト）

④ 株式会社GRCS

株式会社GRCSは、GRC（ガバナンス・リスク・コンプライアンス）領域に特化したコンサルティングサービスを提供する専門企業です。PCI DSS準拠を、単なるセキュリティ基準への対応としてではなく、企業全体のセキュリティガバナンスやリスクマネジメント体制の一環として捉え、統合的に強化していくアプローチを得意としています。経営層の視点に立ったリスク評価や、持続可能なコンプライアンス体制の構築を重視する企業に適したサービスを提供しています。
（参照：株式会社GRCS 公式サイト）

⑤ 株式会社リンク

株式会社リンクは、クラウドホスティングサービス「ベアメタルクラウド」などを提供する事業者であり、特にAWS（Amazon Web Services）やGCP（Google Cloud Platform）といったパブリッククラウド環境におけるPCI DSS準拠に豊富な知見と実績を持っています。クラウドの特性を最大限に活かした効率的な準拠アーキテクチャの設計・構築から、運用監視、審査対応までをトータルで支援します。クラウドネイティブな環境でサービスを展開するスタートアップやWebサービス事業者にとって、非常に頼りになる存在です。
（参照：株式会社リンク 公式サイト）