PCI DSS là gì: Mục tiêu, vai trò, ứng dụng trong marketing

PCI DSS là gì?

PCI DSS do PCI Security Standards Council – PCI SSC phát triển và duy trì. Hội đồng được thành lập bởi các thương hiệu thanh toán quốc tế gồm American Express, Discover, JCB, Mastercard và Visa.

Tiêu chuẩn không chỉ dành cho ngân hàng. Phạm vi có thể bao gồm:

• Website thương mại điện tử nhận thanh toán thẻ.
• Cửa hàng dùng thiết bị POS.
• Cổng thanh toán và đơn vị xử lý giao dịch.
• Call center nhận thông tin thẻ qua điện thoại.
• Nhà cung cấp hosting hoặc managed service có thể ảnh hưởng đến môi trường dữ liệu thẻ.
• Đơn vị phát triển, vận hành hoặc hỗ trợ hệ thống thanh toán.
• Merchant thuê bên thứ ba xử lý thanh toán nhưng vẫn kiểm soát một phần trang thanh toán hoặc luồng dữ liệu.

Mục tiêu của PCI DSS là tạo một baseline bảo mật nhất quán. Tiêu chuẩn không thể ngăn mọi cuộc tấn công và không thay thế quản trị rủi ro toàn diện, pháp luật bảo vệ dữ liệu hoặc quy định riêng của từng ngành.

PCI DSS có liên quan chỉ số PCI cấp tỉnh không?

Không. Hai thuật ngữ có chữ viết tắt gần giống nhưng thuộc hai lĩnh vực hoàn toàn khác nhau.

Bài viết này chỉ đề cập Payment Card Industry Data Security Standard. Không sử dụng dữ liệu khảo sát năng lực cạnh tranh cấp tỉnh để giải thích PCI DSS.

Phiên bản PCI DSS hiện hành

PCI SSC công bố PCI DSS v4.0.1 vào tháng 6/2024 như một bản sửa đổi giới hạn của v4.0. Phiên bản này làm rõ câu chữ và mục đích một số yêu cầu, không thêm hoặc xóa yêu cầu.

Các mốc quan trọng:

• PCI DSS v4.0 được công bố tháng 3/2022.
• PCI DSS v3.2.1 ngừng hiệu lực ngày 31/3/2024.
• PCI DSS v4.0.1 được công bố tháng 6/2024.
• PCI DSS v4.0 ngừng hiệu lực ngày 31/12/2024.
• Các yêu cầu được ghi là best practice đến một ngày tương lai đã có hiệu lực từ 31/3/2025.

PCI DSS áp dụng cho ai?

PCI DSS hướng đến mọi tổ chức:

• Lưu trữ Cardholder Data hoặc Sensitive Authentication Data.
• Xử lý dữ liệu thẻ trong giao dịch.
• Truyền dữ liệu thẻ qua mạng hoặc hệ thống.
• Có thể ảnh hưởng đến an ninh của Cardholder Data Environment.

Đối tượng gồm merchant, processor, acquirer, issuer và service provider. Quy mô nhỏ hoặc số giao dịch thấp không tự động làm doanh nghiệp nằm ngoài phạm vi.

Số lượng giao dịch thường ảnh hưởng cách xác nhận và báo cáo tuân thủ theo chương trình của tổ chức thẻ hoặc ngân hàng thanh toán. Nó không phải căn cứ để bỏ qua các yêu cầu bảo vệ dữ liệu đang áp dụng.

PCI DSS có bắt buộc không?

PCI DSS không phải một đạo luật do PCI SSC ban hành. PCI SSC phát triển tiêu chuẩn nhưng không trực tiếp phạt merchant hoặc quyết định phương thức báo cáo của từng doanh nghiệp.

Trong thực tế, việc tuân thủ được yêu cầu thông qua:

• Quy định của các thương hiệu thẻ.
• Hợp đồng với ngân hàng thanh toán hoặc acquirer.
• Hợp đồng với processor, payment gateway hoặc đối tác.
• Yêu cầu quản trị rủi ro của tổ chức.

Không tuân thủ có thể dẫn đến yêu cầu khắc phục, tăng phí, hạn chế xử lý giao dịch, trách nhiệm hợp đồng hoặc những hậu quả khác theo chương trình áp dụng. Mức độ và quy trình không giống nhau giữa các thương hiệu thẻ, acquirer và thị trường.

Doanh nghiệp nên hỏi trực tiếp acquirer hoặc compliance-accepting entity để xác định phương thức xác nhận, loại SAQ, yêu cầu ROC, tần suất nộp tài liệu và yêu cầu ASV scan.

PCI DSS bảo vệ loại dữ liệu nào?

PCI DSS phân biệt Cardholder Data – CHD và Sensitive Authentication Data – SAD.

PAN – Primary Account Number – là thành phần quyết định dữ liệu có được xem là Cardholder Data hay không. Nếu tên chủ thẻ hoặc ngày hết hạn không đi cùng PAN, việc phân loại theo PCI DSS có thể khác nhưng dữ liệu vẫn có thể chịu quy định bảo vệ dữ liệu khác.

PAN, CVV và dữ liệu thẻ khác nhau thế nào?

• PAN: số tài khoản chính hiển thị trên thẻ hoặc tokenized representation tùy hệ thống.
• Cardholder name: tên chủ thẻ.
• Expiration date: ngày hết hạn.
• Service code: dữ liệu xác định điều kiện sử dụng thẻ trong một số luồng.
• CVV/CVC/CID: mã xác minh thẻ.
• Full track data: dữ liệu đầy đủ từ dải từ hoặc chip tương đương.
• PIN/PIN block: dữ liệu xác thực mã PIN.

CVV, full track data và PIN/PIN block thuộc Sensitive Authentication Data. Sau khi authorization hoàn tất, việc lưu các dữ liệu này bị cấm ngay cả khi doanh nghiệp cho rằng đã mã hóa an toàn.

Cardholder Data Environment là gì?

Cardholder Data Environment – CDE – gồm con người, quy trình và công nghệ lưu trữ, xử lý hoặc truyền dữ liệu tài khoản thẻ, cùng những hệ thống có thể ảnh hưởng đến an ninh của môi trường đó.

Phạm vi có thể bao gồm máy chủ ứng dụng, cơ sở dữ liệu, trang thanh toán, script trên trình duyệt, firewall, tài khoản quản trị, logging, bản sao lưu, nhà cung cấp dịch vụ và nhân sự có quyền truy cập.

Scope sai là một trong những nguyên nhân làm chương trình PCI DSS thất bại. Doanh nghiệp không thể chỉ đánh giá trang checkout mà bỏ qua tài khoản cloud, pipeline triển khai hoặc hệ thống hỗ trợ có thể thay đổi trang đó.

Tokenization có loại bỏ phạm vi không?

Tokenization thay PAN bằng một giá trị thay thế để giảm việc dữ liệu thẻ xuất hiện trong hệ thống kinh doanh. Đây là biện pháp hữu ích nhưng không tự động loại bỏ toàn bộ phạm vi.

Cần đánh giá hệ thống có nhìn thấy PAN trước khi token hóa hay không, token có thể đảo ngược ở đâu, ai kiểm soát vault, nhà cung cấp có AOC phù hợp hay không và merchant còn trách nhiệm nào.

Giảm scope không có nghĩa chuyển toàn bộ trách nhiệm. Merchant vẫn phải quản lý tích hợp, bên thứ ba, quyền truy cập và những yêu cầu còn áp dụng.

Outsource thanh toán có hết trách nhiệm không?

Không. Thuê payment gateway hoặc service provider có thể giảm phạm vi kỹ thuật nhưng không loại bỏ trách nhiệm quản trị.

• Lập danh sách nhà cung cấp dịch vụ.
• Xác định yêu cầu PCI DSS mà mỗi bên thực hiện.
• Kiểm tra tài liệu xác nhận phù hợp.
• Giám sát tình trạng tuân thủ định kỳ.
• Quản lý hợp đồng và thông báo sự cố.
• Bảo vệ tài khoản tích hợp và API key.
• Kiểm soát script hoặc iframe trên website.
• Duy trì quy trình incident response.

Nếu website bị chèn script độc hại trước khi dữ liệu được gửi đến cổng thanh toán, merchant vẫn có thể chịu rủi ro dù không lưu PAN trên máy chủ của mình.

Sáu mục tiêu và 12 yêu cầu PCI DSS

PCI DSS v4.0.1 tổ chức các kiểm soát thành sáu mục tiêu và 12 yêu cầu. Tên gọi hiện hành nhấn mạnh quản trị mạng, cấu hình an toàn, dữ liệu tài khoản, phần mềm, danh tính và chương trình bảo mật liên tục.

Yêu cầu 1: Kiểm soát an ninh mạng

Doanh nghiệp phải cài đặt và duy trì Network Security Controls để bảo vệ Cardholder Data Environment.

Công việc thường gồm:

• Lập sơ đồ luồng dữ liệu và sơ đồ mạng.
• Chỉ cho phép kết nối cần thiết.
• Chặn lưu lượng không được phê duyệt.
• Kiểm soát kết nối giữa CDE và mạng không tin cậy.
• Rà soát rule định kỳ.
• Ghi nhận mục đích và người phê duyệt thay đổi.
• Bảo vệ thiết bị di động hoặc hệ thống kết nối từ xa.

Khái niệm Network Security Controls rộng hơn firewall truyền thống. Nó có thể bao gồm firewall, cloud security group, network ACL, virtual appliance và các cơ chế phân đoạn phù hợp.

Yêu cầu 2: Cấu hình an toàn

Mọi system component trong phạm vi phải được áp dụng secure configuration. Doanh nghiệp không được giữ tài khoản, mật khẩu hoặc tham số mặc định của nhà cung cấp khi chúng tạo rủi ro.

• Duy trì chuẩn cấu hình.
• Tắt dịch vụ và giao thức không cần thiết.
• Thay đổi credential mặc định.
• Giới hạn chức năng trên mỗi hệ thống theo nhu cầu.
• Mã hóa truy cập quản trị.
• Quản lý cấu hình cloud, container và nền tảng ảo hóa.
• Kiểm tra drift so với baseline.

Cài đặt hệ thống an toàn là hoạt động liên tục. Một server đúng chuẩn tại thời điểm triển khai có thể lệch cấu hình sau nhiều lần thay đổi.

Yêu cầu 3: Bảo vệ dữ liệu lưu trữ

Doanh nghiệp phải giảm lượng dữ liệu tài khoản lưu trữ và bảo vệ PAN bằng những cơ chế phù hợp.

• Có chính sách retention và secure deletion.
• Không lưu SAD sau authorization.
• Làm PAN không thể đọc được khi lưu bằng phương pháp được chấp nhận.
• Giới hạn người có quyền xem PAN đầy đủ.
• Che PAN khi hiển thị nếu không có nhu cầu nghiệp vụ.
• Quản lý khóa mật mã trong suốt vòng đời.
• Kiểm tra bản sao lưu, log, file export và môi trường thử nghiệm.

Mã hóa dữ liệu nhưng để khóa cùng nơi, quyền truy cập quá rộng hoặc không có quy trình đổi khóa không đáp ứng mục tiêu bảo vệ.

Yêu cầu 4: Mã hóa khi truyền dữ liệu

Cardholder Data phải được bảo vệ bằng strong cryptography khi truyền qua mạng mở hoặc công cộng.

Cần kiểm soát:

• Giao thức và cipher suite được phép.
• Certificate hợp lệ và quản lý thời hạn.
• Cấu hình TLS của website, API và kết nối dịch vụ.
• Truyền dữ liệu qua email, chat hoặc công cụ cộng tác.
• Mạng không dây và kết nối từ xa.
• Endpoint tích hợp với nhà cung cấp.

HTTPS trên trang checkout là cần thiết nhưng chưa đủ. Luồng dữ liệu còn có API, webhook, log, backup, file transfer và kênh hỗ trợ khách hàng.

Yêu cầu 5: Bảo vệ khỏi malware

PCI DSS yêu cầu bảo vệ hệ thống và mạng khỏi malicious software. Cách tiếp cận không còn giới hạn ở việc cài một phần mềm antivirus.

• Triển khai cơ chế anti-malware trên hệ thống có nguy cơ.
• Đánh giá định kỳ hệ thống được xem là ít bị malware tác động.
• Cập nhật engine và signature hoặc cơ chế phát hiện tương đương.
• Thực hiện quét định kỳ và theo sự kiện.
• Ngăn người dùng vô hiệu hóa bảo vệ trái phép.
• Phát hiện phishing và đào tạo người dùng.
• Giám sát cảnh báo và xử lý sự kiện.

Máy chủ Linux, container hoặc cloud workload không được miễn tự động. Doanh nghiệp cần đánh giá rủi ro và khả năng bị malware tác động theo môi trường thực tế.

Yêu cầu 6: Phát triển hệ thống và phần mềm an toàn

Yêu cầu 6 bao gồm quản lý lỗ hổng, vá lỗi, secure development, thay đổi hệ thống và bảo vệ ứng dụng web công khai.

• Tiếp nhận thông tin lỗ hổng từ nguồn đáng tin.
• Xếp hạng rủi ro và vá theo thời hạn.
• Áp dụng secure software development lifecycle.
• Review code và kiểm thử trước phát hành.
• Phân tách development, test và production.
• Kiểm soát change, rollback và phê duyệt.
• Bảo vệ ứng dụng web khỏi tấn công.
• Quản lý payment-page script.

Với website thương mại điện tử, PCI DSS v4.0.1 yêu cầu quản lý script trên trang thanh toán, xác minh script được ủy quyền, bảo đảm tính toàn vẹn và có cơ chế phát hiện thay đổi trái phép hoặc tampering.

Một Audit website có thể hỗ trợ rà soát tài sản, plugin, script và cấu hình bề mặt web, nhưng không thay thế một cuộc đánh giá PCI DSS theo biểu mẫu chính thức.

Yêu cầu 7: Phân quyền theo nhu cầu công việc

Quyền truy cập vào system component và Cardholder Data phải dựa trên business need to know và nguyên tắc least privilege.

• Xác định vai trò công việc.
• Chỉ cấp quyền cần thiết.
• Có quy trình yêu cầu và phê duyệt.
• Rà soát quyền định kỳ.
• Gỡ quyền khi nhân sự chuyển việc hoặc nghỉ việc.
• Kiểm soát tài khoản đặc quyền.
• Áp dụng default deny khi phù hợp.

Không dùng một tài khoản quản trị chung cho nhiều người. Khi không thể xác định ai đã thực hiện thao tác, logging và điều tra sự cố mất giá trị.

Yêu cầu 8: Danh tính và xác thực

Mỗi người dùng phải có danh tính riêng và được xác thực trước khi truy cập system component.

Kiểm soát gồm:

• User ID riêng.
• Quản lý vòng đời tài khoản.
• Password hoặc passphrase theo yêu cầu hiện hành.
• Multi-factor authentication trong các trường hợp áp dụng.
• Khóa hoặc xử lý tài khoản không hoạt động.
• Kiểm soát service account và application account.
• Quản lý credential của bên thứ ba.
• Chống brute force và credential abuse.

MFA không chỉ là gửi OTP qua SMS trong mọi trường hợp. Thiết kế cần xem xét tính độc lập của các yếu tố, phishing resistance, recovery và quy trình hỗ trợ.

Yêu cầu 9: Truy cập vật lý

Doanh nghiệp phải hạn chế truy cập vật lý vào Cardholder Data và thiết bị trong phạm vi.

• Kiểm soát khu vực nhạy cảm.
• Nhận diện nhân viên và khách.
• Lưu log khách ra vào.
• Bảo vệ media và bản sao lưu.
• Tiêu hủy media an toàn.
• Kiểm tra thiết bị POS để phát hiện thay đổi hoặc skimming.
• Đào tạo nhân viên nhận biết hành vi giả mạo kỹ thuật viên.

Cloud không làm yêu cầu vật lý biến mất; một phần trách nhiệm có thể thuộc cloud provider và phải được thể hiện trong mô hình shared responsibility.

Yêu cầu 10: Logging và monitoring

Doanh nghiệp phải log và theo dõi quyền truy cập vào system component cùng Cardholder Data.

• Ghi nhận user, thời gian, sự kiện và kết quả.
• Bảo vệ log khỏi thay đổi trái phép.
• Đồng bộ thời gian hệ thống.
• Review log và cảnh báo theo tần suất phù hợp.
• Duy trì thời gian lưu theo yêu cầu.
• Điều tra bất thường.
• Giám sát hệ thống bảo mật trọng yếu.

Thu thập log mà không có người xem, cảnh báo hoặc quy trình phản hồi không đáp ứng mục tiêu giám sát.

Yêu cầu 11: Kiểm thử bảo mật

Hệ thống và mạng phải được kiểm thử thường xuyên để phát hiện lỗ hổng, thay đổi trái phép và điểm yếu phân đoạn.

• Quét lỗ hổng nội bộ.
• Quét bên ngoài bởi ASV khi áp dụng.
• Penetration testing.
• Kiểm tra segmentation.
• Phát hiện access point không dây trái phép.
• Intrusion detection hoặc prevention.
• File integrity hoặc change-detection theo phạm vi.
• Phát hiện thay đổi trên payment page.

ASV scan và penetration test là hai hoạt động khác nhau. Báo cáo quét đạt không chứng minh toàn bộ môi trường đã tuân thủ PCI DSS.

Yêu cầu 12: Chính sách và chương trình bảo mật

Yêu cầu cuối cùng kết nối con người, quản trị, rủi ro và hoạt động liên tục.

• Chính sách an ninh thông tin.
• Vai trò và trách nhiệm.
• Targeted risk analysis.
• Đào tạo nhận thức.
• Quản lý nhân sự.
• Quản lý third-party service provider.
• Incident response plan.
• Diễn tập và cải tiến.
• Quản lý phạm vi PCI DSS.
• Đánh giá và xác nhận hoạt động kiểm soát.

PCI DSS v4.x nhấn mạnh việc duy trì an ninh như một hoạt động liên tục, không phải dự án chuẩn bị hồ sơ một lần mỗi năm.

Customized Approach là gì?

PCI DSS v4.x cho phép hai phương pháp triển khai và xác nhận một số yêu cầu:

• Defined Approach: thực hiện kiểm soát theo yêu cầu và testing procedure được mô tả.
• Customized Approach: thiết kế kiểm soát khác nhưng phải đạt customized approach objective và chứng minh bằng tài liệu, risk analysis cùng kiểm thử.

Customized Approach không phải cách bỏ qua yêu cầu. Nó đòi hỏi năng lực thiết kế, chứng minh và đánh giá cao hơn, đồng thời không phải mọi SAQ hoặc chương trình xác nhận đều phù hợp để sử dụng.

SAQ là gì?

Self-Assessment Questionnaire – SAQ – là công cụ để merchant hoặc service provider đủ điều kiện tự đánh giá và báo cáo kết quả PCI DSS.

Không có một SAQ duy nhất cho mọi doanh nghiệp. Mỗi loại SAQ có tiêu chí đủ điều kiện riêng theo kênh thanh toán và kiến trúc hệ thống.

Quy trình thường gồm:

1. Xác định SAQ phù hợp với acquirer hoặc tổ chức thẻ.
2. Xác nhận môi trường đáp ứng toàn bộ tiêu chí đủ điều kiện.
3. Xác định scope.
4. Thực hiện testing theo SAQ.
5. Ghi câu trả lời và bằng chứng.
6. Hoàn thiện Attestation of Compliance.
7. Thực hiện ASV scan nếu áp dụng.
8. Nộp tài liệu cho bên yêu cầu.

SAQ A không có nghĩa website hoàn toàn nằm ngoài PCI DSS. Merchant e-commerce vẫn phải quản lý trang có redirect hoặc embedded payment form, script, nhà cung cấp và những yêu cầu được nêu trong phiên bản SAQ hiện hành.

ROC và QSA là gì?

Report on Compliance – ROC – là báo cáo đánh giá chi tiết theo mẫu chính thức. Qualified Security Assessor – QSA – là tổ chức và chuyên gia được PCI SSC công nhận để thực hiện hoạt động đánh giá PCI DSS theo chương trình QSA.

ROC thường được yêu cầu với tổ chức có quy mô hoặc mức rủi ro cao theo chương trình của payment brand hoặc acquirer. Merchant không nên tự kết luận chỉ dựa trên số lượng giao dịch vì tiêu chí có thể thay đổi theo bên chấp nhận tuân thủ.

QSA đánh giá:

• Scope và luồng dữ liệu.
• Thiết kế cùng vận hành kiểm soát.
• Bằng chứng.
• Tính áp dụng của yêu cầu.
• Kết quả testing.
• Nội dung ROC và AOC.

QSA không phải bên cấp một “con dấu bảo mật vĩnh viễn”. Trách nhiệm duy trì kiểm soát vẫn thuộc tổ chức được đánh giá.

AOC là gì?

Attestation of Compliance – AOC – là biểu mẫu chính thức xác nhận kết quả đánh giá được báo cáo theo PCI DSS. AOC có phiên bản tương ứng với merchant, service provider, SAQ hoặc ROC.

Khi đánh giá nhà cung cấp, doanh nghiệp cần đọc:

• Tên pháp nhân.
• Phiên bản PCI DSS.
• Ngày hoàn thành đánh giá.
• Loại dịch vụ và phạm vi được đánh giá.
• Địa điểm hoặc môi trường được bao phủ.
• Yêu cầu do nhà cung cấp thực hiện.
• Yêu cầu vẫn thuộc trách nhiệm khách hàng.

Một AOC của công ty mẹ hoặc một sản phẩm khác không tự động bao phủ dịch vụ doanh nghiệp đang dùng.

ASV scan là gì?

Approved Scanning Vendor – ASV – là đơn vị được PCI SSC công nhận để thực hiện external vulnerability scan theo yêu cầu PCI DSS áp dụng.

ASV scan:

• Kiểm tra tài sản Internet-facing trong phạm vi.
• Sử dụng quy trình và tiêu chí của chương trình ASV.
• Có thể cần thực hiện theo quý và sau thay đổi đáng kể tùy yêu cầu.
• Phải xử lý lỗ hổng và đạt kết quả passing khi chương trình yêu cầu.

ASV không thay thế internal scan, penetration test, code review hoặc đánh giá cấu hình cloud.

PCI SSC có cấp chứng chỉ không?

PCI SSC không công nhận “compliance certificate” do một đơn vị tự thiết kế như bằng chứng xác nhận PCI DSS.

Các biểu mẫu được công nhận gồm:

• Report on Compliance – ROC.
• Attestation of Compliance – AOC.
• Self-Assessment Questionnaire – SAQ.
• Attestation of Scan Compliance và báo cáo ASV khi áp dụng.

Doanh nghiệp có thể nhận một tờ chứng nhận mang tính trình bày từ nhà tư vấn, nhưng không nên dùng nó thay cho tài liệu chính thức khi làm việc với acquirer, khách hàng hoặc nhà cung cấp.

Tuân thủ có hiệu lực một năm không?

Cách nói “chứng chỉ PCI DSS có hiệu lực một năm” chưa chính xác.

PCI DSS yêu cầu nhiều hoạt động theo ngày, quý, sáu tháng, năm hoặc sau thay đổi. SAQ, ROC và AOC ghi nhận kết quả tại một thời điểm cùng một giai đoạn kiểm thử; bên chấp nhận tuân thủ thường yêu cầu nộp lại theo chu kỳ.

Vì vậy:

• Không có trạng thái an toàn cố định trong 12 tháng.
• Control bị vô hiệu hóa sau đánh giá có thể làm môi trường không còn tuân thủ.
• Sự cố hoặc thay đổi kiến trúc có thể dẫn đến yêu cầu đánh giá lại.
• Tần suất báo cáo do acquirer hoặc payment brand quyết định.

Doanh nghiệp nên dùng ngày hoàn thành AOC và phạm vi được ghi trong tài liệu, không chỉ hỏi “chứng chỉ hết hạn khi nào?”.

Merchant level là gì?

Merchant level thường là cách payment brand hoặc acquirer phân loại doanh nghiệp theo số giao dịch, kênh thanh toán và rủi ro để quyết định phương thức xác nhận.

Không có một bảng merchant level duy nhất do PCI SSC áp dụng cho mọi thương hiệu. Doanh nghiệp không nên sao chép ngưỡng giao dịch từ một bài viết và mặc định nó đúng với hợp đồng của mình.

Hãy xác nhận trực tiếp:

• Merchant level hiện tại.
• Loại SAQ hoặc ROC.
• Yêu cầu QSA.
• ASV scan.
• Penetration test.
• Thời hạn nộp tài liệu.

Website dùng cổng thanh toán cần làm gì?

Đối với website thương mại điện tử, phạm vi phụ thuộc cách trang thanh toán được tích hợp.

Các mô hình thường gặp:

• Redirect hoàn toàn sang trang của payment provider.
• Iframe hoặc embedded form do nhà cung cấp phục vụ.
• JavaScript tokenization chạy trên trang merchant.
• Form thẻ được host trực tiếp trên website merchant.
• API server-to-server xử lý dữ liệu thẻ.

Doanh nghiệp phải xác định:

• Dữ liệu thẻ đi qua trình duyệt và server nào.
• Ai kiểm soát HTML, script và deployment.
• Script bên thứ ba nào chạy trên payment page.
• Log hoặc analytics có vô tình thu PAN hay không.
• SAQ nào đáp ứng tiêu chí.
• Trách nhiệm của payment provider được ghi trong AOC.

Quản trị website cần phối hợp với đội bảo mật để kiểm soát plugin, script, tài khoản và thay đổi trên trang thanh toán; không tự tuyên bố website PCI DSS compliant nếu chưa có đánh giá phù hợp.

Yêu cầu mới đáng chú ý với e-commerce

Từ 31/3/2025, những yêu cầu future-dated của PCI DSS v4.x đã trở thành yêu cầu áp dụng khi nằm trong scope.

Đối với payment page, doanh nghiệp cần đặc biệt chú ý:

• Lập danh mục script và lý do sử dụng.
• Xác nhận script được ủy quyền.
• Bảo đảm tính toàn vẹn của script.
• Phát hiện thay đổi trái phép đối với header và nội dung trang thanh toán.
• Đánh giá third-party script như tag manager, chat, analytics và A/B testing.
• Quản lý quy trình change và rollback.

Đây là phản ứng trước rủi ro e-skimming, trong đó mã độc được chèn vào trang thanh toán để đánh cắp dữ liệu ngay trên trình duyệt người dùng.

MFA trong PCI DSS v4.0.1

Multi-factor authentication là kiểm soát trọng yếu cho truy cập vào CDE và các trường hợp được yêu cầu.

MFA cần:

• Dùng ít nhất hai yếu tố thuộc các nhóm độc lập.
• Không cho phép một yếu tố thất bại làm lộ yếu tố còn lại.
• Chống bypass.
• Quản lý enrollment và recovery.
• Kiểm soát tài khoản đặc quyền và truy cập từ xa.
• Ghi log sự kiện xác thực.

MFA không sửa được mật khẩu dùng chung, tài khoản không được quản lý hoặc quy trình recovery yếu.

Targeted Risk Analysis là gì?

Targeted Risk Analysis – TRA – được dùng khi PCI DSS cho phép tổ chức xác định tần suất hoặc cách tiếp cận của một hoạt động dựa trên rủi ro.

TRA phải mô tả:

• Tài sản và mối đe dọa.
• Yếu tố ảnh hưởng khả năng và tác động.
• Lý do chọn tần suất.
• Biện pháp kiểm soát.
• Phê duyệt và ngày rà soát.

TRA không phải một câu “rủi ro thấp nên không cần làm”. Nó cần bằng chứng, phương pháp và được cập nhật khi môi trường thay đổi.

Quy trình triển khai PCI DSS

Cách giảm phạm vi PCI DSS

Giảm scope đúng cách giúp tập trung kiểm soát vào môi trường cần thiết.

• Không lưu dữ liệu thẻ nếu không có nhu cầu.
• Dùng hosted payment page hoặc giải pháp phù hợp.
• Tokenize PAN.
• Tách mạng và tài khoản quản trị.
• Loại analytics, chat và plugin không cần khỏi payment page.
• Không cho dữ liệu thẻ đi vào CRM, ticket hoặc email.
• Giới hạn quyền support.
• Dùng thiết bị và quy trình riêng cho call center nếu cần.

Segmentation phải được kiểm thử. Một VLAN được đặt tên “PCI” không tự chứng minh hệ thống ngoài vùng không thể ảnh hưởng đến CDE.

Bằng chứng cần chuẩn bị

Bằng chứng phải phản ánh control đang vận hành, không chỉ là policy được viết trước ngày đánh giá.

PCI DSS trong Marketing

PCI DSS có thể hỗ trợ niềm tin khi doanh nghiệp chấp nhận thanh toán thẻ, nhưng Marketing phải truyền đạt chính xác phạm vi và tình trạng xác nhận.

Có thể truyền thông:

• Quy trình thanh toán được vận hành theo yêu cầu bảo mật áp dụng.
• Cổng thanh toán hoặc nhà cung cấp được sử dụng.
• Doanh nghiệp không lưu CVV sau authorization.
• Kênh hỗ trợ chính thức khi khách phát hiện giao dịch bất thường.
• Cách nhận biết trang thanh toán và domain chính thức.
• Hướng dẫn chống phishing.

Không nên dùng:

• “Website an toàn tuyệt đối vì có PCI DSS”.
• “PCI SSC đã chứng nhận toàn bộ doanh nghiệp” khi chỉ có một AOC phạm vi hẹp.
• Logo hoặc huy hiệu không được phép sử dụng.
• Tài liệu đã quá chu kỳ hoặc không đúng pháp nhân.
• Claim “không thể bị hack”.

Mô hình phòng Marketing thuê ngoài cần phối hợp với pháp chế, bảo mật và vận hành trước khi công bố claim về PCI DSS trên website, proposal hoặc quảng cáo.

Có nên ghi “đạt chứng chỉ PCI DSS”?

Cách diễn đạt này dễ làm người đọc hiểu rằng PCI SSC đã cấp một chứng chỉ chung cho toàn doanh nghiệp.

Nên mô tả cụ thể hơn:

• Đã hoàn tất đánh giá PCI DSS v4.0.1 theo SAQ nào.
• Có AOC hoặc ROC hoàn thành vào ngày nào.
• Phạm vi gồm dịch vụ, môi trường hoặc pháp nhân nào.
• Bên nào thực hiện đánh giá.
• Tài liệu được cung cấp cho ai và theo điều kiện nào.

Nếu doanh nghiệp dùng nhà cung cấp thanh toán compliant, không nên biến trạng thái của nhà cung cấp thành claim rằng toàn bộ website hoặc hệ thống nội bộ đã compliant.

PCI DSS có bảo vệ mọi dữ liệu khách hàng không?

Không. PCI DSS tập trung vào payment account data và môi trường liên quan.

Các dữ liệu khác như:

• Địa chỉ giao hàng.
• Số điện thoại.
• Email.
• Lịch sử mua hàng.
• Dữ liệu hành vi Marketing.
• Thông tin định danh.

vẫn cần được bảo vệ theo pháp luật, hợp đồng và chương trình an ninh thông tin phù hợp. PCI DSS không thay thế toàn bộ yêu cầu bảo vệ dữ liệu cá nhân.

PCI DSS khác ISO 27001 thế nào?

Một tổ chức có ISO 27001 vẫn cần thực hiện PCI DSS nếu nằm trong phạm vi. Các control ISO có thể hỗ trợ nhưng phải được kiểm tra theo yêu cầu PCI DSS cụ thể.

PCI DSS khác SOC 2 thế nào?

SOC 2 là báo cáo kiểm toán kiểm soát tại service organization theo Trust Services Criteria. PCI DSS là tiêu chuẩn chuyên biệt cho dữ liệu thanh toán thẻ.

QSA không thể chỉ dựa vào SOC 2 để kết luận một yêu cầu PCI DSS đã được đáp ứng. Bằng chứng từ cuộc kiểm toán khác có thể hỗ trợ, nhưng QSA vẫn chịu trách nhiệm đánh giá tính liên quan, phạm vi và thời điểm của bằng chứng.

Rủi ro khi chỉ làm PCI trước ngày đánh giá

• Log không có đủ lịch sử.
• Scan và review không được thực hiện đúng chu kỳ.
• Nhân sự không hiểu quy trình.
• Control bị tắt sau khi lấy bằng chứng.
• Scope thay đổi nhưng tài liệu không cập nhật.
• AOC nhà cung cấp hết chu kỳ.
• Script mới được thêm mà không phê duyệt.
• Incident response chưa từng diễn tập.

PCI DSS v4.x hướng doanh nghiệp đến business-as-usual. Control phải được gắn vào change management, onboarding, offboarding, procurement và vận hành hằng ngày.

Những sai lầm thường gặp

“PCI DSS không phải chiếc huy hiệu để đặt lên trang thanh toán rồi xem như hoàn tất. Doanh nghiệp phải biết dữ liệu thẻ đi đâu, ai có thể tác động đến môi trường, bên thứ ba chịu trách nhiệm phần nào và kiểm soát có còn hoạt động sau ngày đánh giá hay không.”

Anh Thắng Giấu Tên – CEO Xuyên Việt Media

Checklist PCI DSS cho doanh nghiệp

Câu hỏi thường gặp

Kết luận

PCI DSS là tiêu chuẩn bảo mật dữ liệu tài khoản thanh toán, không phải chỉ số năng lực cạnh tranh cấp tỉnh và cũng không phải một chứng chỉ chung cho mọi website. Phiên bản hiện hành là PCI DSS v4.0.1; toàn bộ yêu cầu future-dated đã có hiệu lực từ ngày 31/3/2025.

Doanh nghiệp phải bắt đầu từ data flow và scope, sau đó triển khai 12 yêu cầu theo môi trường thực tế. Việc thuê cổng thanh toán, tokenization hoặc cloud có thể giảm phạm vi nhưng không loại bỏ trách nhiệm quản trị bên thứ ba.

Tuân thủ cần được chứng minh bằng SAQ, ROC, AOC và tài liệu liên quan theo chương trình áp dụng. Giá trị thực sự không nằm ở một tờ giấy, mà ở khả năng duy trì kiểm soát trước, trong và sau kỳ đánh giá.