PCI DSS v4.0.1で問われるBAU運用の本質とは？
PCI DSS v4.0.1への移行が完了し、いよいよ本格的な「運用」のフェーズに入りました。
本記事では、新規格で特に重要視されるBAU（通常業務）の運用について、審査の視点を踏まえた実務的なポイントを、実際の事例を交えながらご紹介します。
1. BAUって何？
タイトルにあるBAUという言葉は、Business As Usualの略で、「いつも通りの業務」「日常業務」という意味です。
PCI DSSだけの専門用語ではなく、ビジネス全般で使われますが、セキュリティの観点から見ると、「日常的かつ継続的にセキュリティ管理を業務に組み込む」ことだと考えてください。
PCI DSSにおいては「365日いつでも、常に準拠した状態を保つこと」だと理解してもらえると良いでしょう。
2. v4.0.1でBAUが厳しくなった理由
2.1 準拠を続けるためにBAUが強化
BAUは以前のバージョンでも触れられていましたが、v4.0.1ではその重要性がぐっと増しています。
従来のバージョンに比べて、v4.0.1では日常的で継続的なセキュリティ管理が求められるようになりました。
これは、マルウェアやスクリプト型攻撃など、セキュリティを取り巻く環境が常に変化しているためです。
一度だけの対応では追いつかなくなっているんですね。
PCI DSSの審査では、「いつもBAUがきちんと運用されている」ことを、証拠を見せて証明する必要があります。
2.2 v4.0.1でBAUの時間枠がもっと厳格に
v4.0.1では、「即座に」「迅速に」といった表現も加わり、セキュリティインシデントなどが発生した際にすぐに対応できる体制が求められるようになりました。
ただ決められたスケジュール通りに作業するだけでなく、現場での判断力や素早い対応も重視されるようになったということです。
また、「定期的に」という言葉も、ただ漠然と行うのではなく、リスク分析に基づいてその頻度を文書化し、その根拠をきちんと説明できるようになりました。
会社に合ったセキュリティの頻度を設計し、それを裏付ける記録や文書が必要になります。
「365日、毎日チェックしています」と言える状態が理想です。
これによって、形だけではない、本当に意味のあるセキュリティ運用が期待されることになります。
3. v3.2.1とv4.0.1、BAUの時間枠はどう違う？
3.1 「大幅な変更」の定義がハッキリ
企業がBAUを日々運用しているかどうかは、要件ごとに定められた頻度で確認されます。
下の【表1】の左側がv3.2.1の頻度表現です。「毎日」「毎月」「3カ月に1回（四半期）」など、一見するとしっかりしていそうですが、実は少しあいまいでした。
例えば、四半期に1回のケース。1回目を2月1日、2回目を7月31日に行っても、「四半期に1回」と解釈できてしまう余地があり、最大で6カ月近く期間が空いてしまうこともあり得ました。これでは、本来3カ月ごとにリスクを確認する意味が薄れてしまいますよね。
この問題を解決するため、v4.0.1では「90日～92日に1回以上、または3カ月目のn日に1回以上」と、時間ベースで明確に定義されました。
また、「毎日」の場合も、v3.2.1では休日や祝日が含まれるかどうかの明確な基準がありませんでしたが、v4.0.1では「営業日に限らず」と明記され、解釈で悩むことがなくなりました。
3.2 v4.0.1における「大幅な変更」の定義
v3.2.1では「大幅な変更」という言葉があっても解釈が曖昧で、審査員ごとに判断が分かれることもありました。
しかし、v4.0.1では以下のように具体的な例が示され、この曖昧さが解消されています。
・カード会員データ環境に追加される新しいハードウェア、ソフトウェア、またはネットワーク機器
・カード会員データ環境内のハードウェアおよびソフトウェアの交換または主要なアップグレード
・アカウントデータのフローまたは保存におけるすべての変更
・カード会員データ環境の境界やPCI DSS評価範囲に対するあらゆる変更
・カード会員データ環境の基礎となるサポートインフラへのあらゆる変更（ディレクトリサービス、タイムサーバ、ロギング、監視への変更を含むが、これに限定されない）
・カード会員データ環境をサポートする、または事業体に代わってPCI DSS要件を満たすサードパーティベンダー/サービスプロバイダ（または提供されるサービス）に対するすべての変更
これらの変更が発生した場合は、必ず脆弱性の評価を行い、必要に応じてアプリケーションの再評価、ASVスキャン、ペネトレーションテストなどの検証を実施しなければなりません。
これを怠ると「非準拠」と見なされてしまうので、十分に注意してください。
4. 日々の運用で困ること＆うまく進める方法
実際の現場でBAUを進めるうえで、よくある課題とその対策を見ていきましょう。
4.1 BAU運用でよくある課題と解決策
担当者がいなかったり、運用が漏れたりする
事象: 急な人事異動や忙しい時期にチェックが漏れてしまう。
対策: 複数名で交代で担当したり、バックアップ担当者を明確にしたり、チェックリストとスケジュールでしっかり管理しましょう。
記録が残っていなかったり、実施履歴がバラバラ
事象: 証拠となる記録をうっかり残し忘れてしまう。
対策: 自動で記録を集める仕組みを導入したり、フォーマットを統一したり、承認を徹底したりしましょう。
形だけのチェックになってしまう
事象: 「チェックするためのチェック」になり、本来のセキュリティ目的が果たされない。
対策: 定期的にレビュー会を開いて、何のためにチェックしているのか、その効果を再確認し、インシデントや脅威に合わせた改善を続けましょう。
4.2 効果的な運用のためのヒント
・スケジュール管理
・ツールを導入(Jiraなどでタスクとリマインダーを管理。)
・カレンダーと連動(チェック要件ごとにアラートを設定。)
・内部レビュー会を定期開催(各コントロールの実施結果や課題を共有し、見える化。)
・運用チェックリストをきちんと整備
・コントロール要件（例：要件10.x ログレビュー、6.x パッチ管理）に対応したチェックリストの作成。
・頻度、責任者、関連する証拠、レビュー方法などを統一されたフォーマットで記録。
・専門家（QSA）に相談。
QSAにスケジュール管理やチェックリストの整備、BAU運用の進捗管理などを依頼するのも良い方法です。
5. 実際の事例
ここでは、準拠維持コンサルティングや審査で実際に起こったケースをご紹介します。
【ケース1】 決済代行サービスプロバイダ
事象: ASVスキャンを1回分忘れてしまった。
原因: ASVレポートの受け取りを怠り、有効期限が切れてしまった。
影響: 非準拠と判断され、追加のスキャン後に再審査が必要に。
【ケース2】BPOサービスプロバイダ
事象: 大幅な変更に伴うスキャンやテストを忘れてしまった。
原因: 新しい拠点を追加した際の、ネットワーク機器やサーバーのリリース遅延、それに伴うスケジュール調整の遅れ。
影響: 非準拠と判断され、数カ月後に再審査が必要に。
【ケース3】アプリケーション保守サービスプロバイダ
事象: 運用停止したはずのサーバーが、実はまだ動いていた。
原因: サーバー停止の確認や承認、変更管理の手順に漏れがあった。
影響: 定期的な確認コンサルで発見されたため、すぐにサーバーを停止し、手順を見直すことができました。
これらのケースはどれも、「ちょっとした油断」「計画の甘さ」「手順を飛ばしてしまう」といった運用ミスが原因です。事前の計画や管理体制、そして記録を徹底することがいかに大切か、よくわかりますよね。
6. レオンテクノロジーの準拠維持コンサルティングについて
弊社のQSAは、ギャップ分析、BAUの運用設計から、書類の整備、証拠の管理、さらには審査前のリハーサルまで、トータルでサポートいたします。
実務に寄り添った視点で、現場の業務とうまくなじむような無理のない運用フローを一緒に考え、設計していきます。
また、「大幅な変更」が発生した際のリスク評価や変更管理体制の構築もお任せください。
PCI DSSの準拠は一度対応したら終わり、ではありません。継続的な対応が必要です。
準拠維持を自社だけで行うことに不安を感じたら、お気軽にご相談くださいね。
PCI DSSがテーマのセミナーも近日実施予定です。
SNSでもご案内いたしますので、ぜひフォローをよろしくお願いします！
▼サービスページはこちら
>>>PCI DSS準拠支援
>>>PCI DSS審査
