SAQ là gì và tại sao nó tồn tại

SAQ (Self-Assessment Questionnaire) là bộ câu hỏi tự đánh giá tuân thủ PCI DSS dành cho merchant và service provider không thuộc Level 1. Theo phân loại của Visa, Level 1 là các tổ chức xử lý hơn 6 triệu giao dịch thẻ mỗi năm. Những tổ chức đó bắt buộc phải thuê QSA (Qualified Security Assessor) thực hiện ROC (Report on Compliance) toàn diện, một quy trình tốn kém và mất nhiều tháng.

Level 2, 3, 4 thường không bắt buộc làm ROC. Thay vào đó, họ có thể tự điền SAQ, ký AOC (Attestation of Compliance) xác nhận kết quả, rồi nộp cho acquiring bank hoặc payment brand theo chu kỳ hằng năm.

Vấn đề là không phải mọi SAQ đều giống nhau. PCI SSC hiện có 9 loại SAQ với số câu hỏi chênh lệch rất lớn: từ khoảng 22 câu (SAQ A) đến 329 câu (SAQ D dành cho service provider). Chọn sai loại SAQ đồng nghĩa với việc bạn đang tự đánh giá theo tiêu chuẩn thấp hơn mức thực tế cần thiết, hoặc làm tốn công sức hơn mức cần thiết.

Nguồn: PCI SSC Document Library (pcisecuritystandards.org/document_library)


Tổng quan 9 loại SAQ

Loại SAQDành choSố câu hỏi (xấp xỉ)Điều kiện chính
SAQ AE-commerce merchant dùng payment hoàn toàn outsourced~22Không lưu, xử lý, truyền CHD trên hệ thống của merchant
SAQ A-EPE-commerce merchant dùng outsourced payment nhưng website ảnh hưởng đến security của payment page~191JavaScript của merchant chạy trên payment page
SAQ BMerchant dùng imprint machine hoặc standalone dial-out terminal~41Không lưu CHD, terminal không kết nối internet
SAQ B-IPMerchant dùng standalone IP-connected terminal~83Không lưu CHD, terminal kết nối IP nhưng tách biệt
SAQ CMerchant dùng payment application kết nối internet~160Không lưu CHD, hệ thống không kết nối với các hệ thống khác trong mạng nội bộ
SAQ C-VTMerchant nhập thủ công qua virtual terminal từ browser~83Không lưu CHD, chỉ dùng một thiết bị tại một thời điểm
SAQ D (Merchant)Tất cả merchant không thuộc các loại trên~285Lưu CHD, hoặc không đáp ứng điều kiện của bất kỳ loại nào khác
SAQ D (Service Provider)Service provider không thuộc các loại trên~329Xử lý, lưu trữ, hoặc truyền CHD thay mặt cho merchant khác
SAQ P2PEMerchant dùng thiết bị P2PE hardware đã được PCI SSC validate~35Thiết bị P2PE phải nằm trong danh sách approved của PCI SSC

CHD là viết tắt của cardholder data, bao gồm số thẻ (PAN), tên chủ thẻ, ngày hết hạn, và service code. CDE (Cardholder Data Environment) là toàn bộ hệ thống, quy trình, và con người có liên quan đến lưu trữ, xử lý, hoặc truyền CHD.


Quy trình chọn SAQ đúng

Câu hỏi đầu tiên là bạn là merchant hay service provider. Merchant là doanh nghiệp chấp nhận thẻ để thanh toán hàng hóa hoặc dịch vụ của mình. Service provider là doanh nghiệp xử lý, lưu trữ, hoặc truyền CHD thay mặt cho merchant khác. Ranh giới này quan trọng vì SAQ D dành cho service provider yêu cầu nhiều hơn SAQ D dành cho merchant, và payment brand có thể phân loại bạn độc lập với cách bạn tự mô tả trong hợp đồng.

Câu hỏi tiếp theo là bạn có lưu CHD không. Nếu có, bạn rơi vào SAQ D (Merchant) hoặc SAQ D (Service Provider) tùy loại tổ chức. Phần lớn các loại SAQ khác đều yêu cầu bạn không lưu CHD sau khi giao dịch hoàn tất.

Nếu không lưu CHD, bước tiếp theo là xác định kênh thanh toán. Merchant bán hàng online và merchant có cửa hàng vật lý sử dụng SAQ khác nhau. Terminal vật lý dẫn đến SAQ B, B-IP, hoặc P2PE tùy loại thiết bị. Kênh online dẫn đến SAQ A, A-EP, hoặc C tùy cách payment page được xây dựng.

Với kênh online, câu hỏi phân biệt là ai kiểm soát payment page. Nếu khách hàng rời khỏi website của bạn để thanh toán trên trang của Stripe, PayPal, hoặc provider khác (redirect hoàn toàn), bạn không tiếp xúc với CHD. Đó là điều kiện cốt lõi của SAQ A. Nếu payment form nằm trên domain của bạn, hoặc bạn dùng thư viện JavaScript như Stripe.js để nhúng form vào trang của mình, bạn cần trả lời thêm một câu hỏi nữa.

Câu hỏi phân biệt SAQ A và SAQ A-EP là: có JavaScript nào từ website của bạn chạy trên payment page không? Nếu trang checkout load bất kỳ JavaScript nào bạn kiểm soát, kể cả analytics, chat widget, hay tag manager, bạn rơi vào SAQ A-EP thay vì SAQ A. PCI SSC lý luận rằng JavaScript bên thứ ba trên payment page tạo ra attack surface tiềm năng, ngay cả khi form thực tế được hosted bởi provider.

Một số ví dụ cụ thể:

SAQ A phù hợp với website Shopify bán lẻ dùng Stripe Checkout hoặc PayPal redirect, trong đó khách hàng được chuyển hoàn toàn sang trang của provider để nhập thông tin thẻ, rồi redirect về trang cảm ơn của bạn. Website của bạn không load bất kỳ JavaScript nào ảnh hưởng đến trang payment đó.

SAQ A-EP phù hợp với trang checkout tự xây dùng Stripe.js hoặc Stripe Elements, trong đó form thanh toán xuất hiện trực tiếp trên domain của bạn. Stripe xử lý CHD trong iframe của họ, nhưng trang chứa iframe đó nằm trên server của bạn và có thể load thêm script từ domain của bạn.

SAQ D (Service Provider) phù hợp với công ty IT Việt Nam xây dựng hệ thống payment processing hoặc hosted payment page cho ngân hàng hoặc merchant Mỹ. Công ty IT đó không phải merchant; họ là service provider và phải đáp ứng ~329 câu hỏi thay vì ~285.


Những lỗi phổ biến khi chọn SAQ

Lỗi phổ biến nhất trong môi trường e-commerce là chọn SAQ A khi thực ra thuộc SAQ A-EP. Nhiều developer hiểu rằng "dùng Stripe nghĩa là SAQ A" nhưng điều này chỉ đúng nếu implementation là redirect hoàn toàn. Stripe Elements, Stripe.js, và các thư viện tương tự giữ CHD trong môi trường của Stripe, nhưng trang chứa chúng vẫn thuộc domain của bạn. Nếu trang đó load Google Tag Manager, Intercom, Hotjar, hoặc bất kỳ script nào khác bạn kiểm soát, SAQ A-EP là loại đúng. Sự chênh lệch không nhỏ: 22 câu so với 191 câu. Chọn sai có thể bị phát hiện trong quá trình audit của acquiring bank và yêu cầu làm lại từ đầu.

Lỗi thứ hai là service provider tự phân loại thành merchant. Các công ty outsource Việt Nam xây dựng payment system hoặc hosted checkout cho khách hàng nước ngoài thường là service provider theo định nghĩa của PCI DSS. Merchant là người bán hàng hóa hoặc dịch vụ và nhận thanh toán qua thẻ. Service provider là người xử lý hoặc lưu trữ CHD thay mặt cho người khác. Payment brand phân loại dựa trên hoạt động thực tế, không dựa trên cách doanh nghiệp tự mô tả, và việc phân loại sai ảnh hưởng đến cả loại SAQ lẫn việc có được dùng SAQ hay phải làm ROC.

Lỗi thứ ba là bỏ qua subcontractor chain. Nếu bạn là Level 2-4 nhưng xử lý payment thay mặt cho Level 1 merchant, acquiring bank hoặc hợp đồng thương mại có thể áp đặt yêu cầu cao hơn mức SAQ thông thường. Một số Level 1 merchant yêu cầu service provider của họ phải có ROC thay vì SAQ, bất kể quy mô của service provider đó. Điều này cần được xem xét trong hợp đồng trước khi bắt đầu dự án.


AOC đi kèm SAQ

Khi hoàn thành SAQ, merchant hoặc service provider ký AOC, tài liệu chính thức xác nhận rằng họ đã hoàn thành SAQ và kết quả phản ánh trạng thái tuân thủ thực tế tại thời điểm đánh giá. AOC là tài liệu acquiring bank hoặc payment brand thu thập để theo dõi tuân thủ.

Quy trình thông thường: điền SAQ, ký AOC, nộp cả hai cho acquiring bank theo chu kỳ hằng năm. Một số acquiring bank còn yêu cầu nộp kết quả quét mạng từ ASV (Approved Scanning Vendor) kèm theo.

AOC không phải chứng chỉ vĩnh viễn. Nó xác nhận trạng thái tại thời điểm đánh giá. Nếu môi trường của bạn thay đổi đáng kể sau khi ký AOC, ví dụ như chuyển sang payment provider khác hoặc thêm kênh thanh toán mới, đánh giá có thể cần được làm lại trước chu kỳ thường niên.


SAQ và ROC: khi nào cần ROC

ROC là báo cáo tuân thủ đầy đủ do QSA thực hiện, bắt buộc với Level 1 merchant. Level 1 với Visa là tổ chức xử lý hơn 6 triệu giao dịch Visa mỗi năm, hoặc bất kỳ tổ chức nào đã từng có sự cố vi phạm dữ liệu thẻ ảnh hưởng đến account data.

Service provider cũng thường cần ROC nếu xử lý lượng giao dịch lớn. Visa phân loại service provider Level 1 là những tổ chức xử lý hơn 300,000 giao dịch mỗi năm hoặc được Visa chỉ định tùy theo rủi ro.

Ngoài quy định của payment brand, acquiring bank hoặc hợp đồng thương mại cụ thể đôi khi yêu cầu ROC ngay cả với tổ chức Level 2. Điều này phổ biến hơn trong các hợp đồng xử lý payment quy mô lớn hoặc khi merchant chính là enterprise.

Nguồn: PCI SSC Document Library (pcisecuritystandards.org/document_library)

Thẻ:
PCI DSSSAQCompliancePayment Security