Tóm tắt
SAQ PCI DSS là bộ tự đánh giá tuân thủ cho merchant và service provider được phép không làm ROC; loại SAQ phụ thuộc vào cách bạn nhận và xử lý dữ liệu thẻ.
SAQ PCI DSS (Self-Assessment Questionnaire) là bộ câu hỏi tự đánh giá do PCI SSC ban hành, dùng cho merchant và service provider được acquirer hoặc thương hiệu thẻ cho phép không làm Report on Compliance (ROC). Có 9 loại SAQ; loại đúng phụ thuộc cách bạn nhận và xử lý dữ liệu thẻ, không phụ thuộc quy mô. Kết quả được xác nhận bằng Attestation of Compliance (AOC).
SAQ PCI DSS dùng khi nào?
SAQ dùng khi thương hiệu thẻ và acquirer cho phép tổ chức tự đánh giá thay vì để Qualified Security Assessor (QSA) lập ROC. Merchant level do từng thương hiệu thẻ quy định theo khối lượng giao dịch 12 tháng, không phải PCI SSC; theo cách phân loại phổ biến của Visa, Level 1 (trên 6 triệu giao dịch Visa mỗi năm, hoặc merchant từng bị xâm phạm dữ liệu) cần ROC, còn các level thấp hơn thường được dùng SAQ. Ngưỡng và cách xác nhận cụ thể phải được xác nhận với acquirer, vì acquirer có quyền yêu cầu cao hơn (Visa: security compliance). Xem thêm cách xác định cấp của bạn trong bài cấp độ PCI DSS.
Sau khi điền SAQ, doanh nghiệp ký AOC và nộp cho acquirer, hoặc cho khách hàng nếu bạn là service provider, theo chu kỳ hằng năm. AOC xác nhận trạng thái tại thời điểm đánh giá; khi thay đổi cách nhận thanh toán, hãy đánh giá lại loại SAQ.
Có những loại SAQ nào?
PCI DSS v4.0.1 có 9 loại SAQ, mỗi loại kèm điều kiện đủ (eligibility criteria) trong phần hướng dẫn của chính SAQ đó. Bảng dưới tóm tắt; bản đầy đủ có trong thư viện tài liệu PCI SSC.
| Loại SAQ | Dành cho | Điều kiện chính |
|---|---|---|
| SAQ A | Merchant thương mại điện tử hoặc đặt hàng qua thư/điện thoại thuê ngoài toàn bộ việc xử lý dữ liệu thẻ | Không lưu, xử lý, truyền dữ liệu thẻ trên hệ thống của mình; trang thanh toán do nhà cung cấp tuân thủ PCI DSS cung cấp qua redirect hoặc iframe |
| SAQ A-EP | Merchant thương mại điện tử thuê ngoài xử lý thanh toán nhưng website tạo ra trang hoặc form thanh toán | Website của merchant ảnh hưởng đến bảo mật giao dịch, ví dụ direct post từ form trên trang của merchant |
| SAQ B | Merchant dùng máy in imprint hoặc terminal quay số độc lập | Không lưu dữ liệu thẻ dạng điện tử |
| SAQ B-IP | Merchant dùng terminal độc lập kết nối IP, được PCI SSC phê duyệt | Terminal không kết nối với hệ thống khác trong môi trường của merchant |
| SAQ C-VT | Merchant nhập giao dịch thủ công trên virtual terminal qua trình duyệt | Một thiết bị, một thời điểm; không lưu dữ liệu thẻ |
| SAQ C | Merchant dùng hệ thống ứng dụng thanh toán kết nối internet | Không lưu dữ liệu thẻ dạng điện tử |
| SAQ P2PE | Merchant chỉ dùng thiết bị trong giải pháp point-to-point encryption được PCI SSC liệt kê | Không lưu dữ liệu thẻ dạng điện tử |
| SAQ D for Merchants | Merchant không đủ điều kiện các SAQ trên | Ví dụ lưu dữ liệu thẻ hoặc tự xử lý thanh toán |
| SAQ D for Service Providers | Service provider được phép tự đánh giá | Áp dụng toàn bộ yêu cầu liên quan đến dịch vụ được đánh giá |
Chọn SAQ theo những bước nào?
Chọn SAQ là trả lời lần lượt các câu hỏi về vai trò và kiến trúc thanh toán, theo thứ tự dưới đây.
- Bạn là merchant hay service provider? Merchant chấp nhận thẻ để bán hàng hóa, dịch vụ của mình. Service provider lưu, xử lý, truyền dữ liệu thẻ thay mặt tổ chức khác, hoặc có thể ảnh hưởng đến bảo mật dữ liệu đó. Service provider chỉ có SAQ D for Service Providers hoặc ROC.
- Bạn có lưu dữ liệu thẻ dạng điện tử không? Nếu có, merchant gần như chắc chắn dùng SAQ D for Merchants.
- Kênh thanh toán là gì? Terminal tại quầy dẫn đến SAQ B, B-IP, C hoặc P2PE tùy thiết bị; virtual terminal dẫn đến SAQ C-VT; thương mại điện tử dẫn đến SAQ A, A-EP hoặc D.
- Ai tạo trang thanh toán? Nếu trang hoặc form thanh toán do nhà cung cấp phục vụ hoàn toàn qua redirect hoặc iframe, xét SAQ A. Nếu trang của bạn tạo form và gửi dữ liệu thẻ thẳng tới processor (direct post) hoặc tự sinh các phần của trang thanh toán, dùng SAQ A-EP.
- Có đáp ứng điều kiện về script không? Với iframe, kiểm tra điều kiện mới của SAQ A ở phần dưới.
- Xác nhận với acquirer trước khi điền, rồi lưu lý do chọn để trả lời assessor hoặc khách hàng.
SAQ A thay đổi gì từ năm 2025?
Ngày 30/1/2025, PCI SSC bỏ yêu cầu 6.4.3, 11.6.1 và 12.3.1 khỏi SAQ A và thay bằng một điều kiện đủ: merchant phải xác nhận website không dễ bị tấn công bằng script có thể ảnh hưởng hệ thống thương mại điện tử. Phiên bản SAQ A mới có hiệu lực từ 31/3/2025 (PCI SSC). Theo FAQ 1588, điều kiện này chỉ áp dụng cho trang nhúng form thanh toán của nhà cung cấp, chẳng hạn iframe, không áp dụng cho redirect. Merchant có thể đáp ứng bằng kỹ thuật như trong 6.4.3 và 11.6.1, hoặc bằng xác nhận từ nhà cung cấp thanh toán rằng giải pháp nhúng, khi triển khai đúng hướng dẫn, đã có cơ chế chống tấn công script (PCI SSC FAQ 1588).
Lỗi nào hay gặp khi chọn SAQ?
Lỗi thứ nhất là nghĩ "dùng Stripe hay cổng thanh toán là SAQ A". Điều đó chỉ đúng khi trang thanh toán do nhà cung cấp phục vụ qua redirect hoặc iframe và bạn đáp ứng điều kiện về script; nếu trang của bạn tạo form và gửi dữ liệu thẻ đi, bạn thuộc SAQ A-EP. Lỗi thứ hai là service provider tự xếp mình là merchant: công ty IT xây và vận hành hệ thống thanh toán cho khách hàng thường là service provider (xem bài cho công ty IT outsourcing). Lỗi thứ ba là bỏ qua yêu cầu trong hợp đồng: khách hàng lớn có thể đòi service provider có ROC dù thương hiệu thẻ cho phép SAQ.
Khi nào cần ROC thay vì SAQ?
ROC là đánh giá do QSA thực hiện, cần khi thương hiệu thẻ hoặc acquirer yêu cầu, thường với merchant Level 1 và service provider khối lượng lớn, hoặc khi khách hàng yêu cầu trong hợp đồng. ROC cũng đi kèm AOC. So sánh chi tiết hai cách ở SAQ vs ROC, còn chi phí từng cách ở chi phí PCI DSS.
pTrackly giúp gì khi làm SAQ?
pTrackly có sẵn framework PCI DSS 4.0.1 với requirement, control, policy template và evidence task, nên câu trả lời cho từng yêu cầu trong SAQ dựa trên bằng chứng đã thu thập theo lịch thay vì gom lại trước hạn nộp. Control dùng chung với ISO 27001 hoặc SOC 2 nếu doanh nghiệp đã có. Module Vendors lưu chứng nhận và trạng thái của nhà cung cấp thanh toán. pTrackly không chọn loại SAQ thay bạn, không ký AOC và không thay QSA hay ASV. Xem PCI DSS trên pTrackly.
Câu hỏi thường gặp
SAQ có phải là chứng nhận PCI DSS không?
Không. SAQ là bản tự đánh giá, kèm AOC do chính doanh nghiệp ký; PCI SSC không cấp chứng nhận cho merchant, và kết quả có giá trị theo chu kỳ hằng năm mà acquirer yêu cầu.
Dùng iframe của cổng thanh toán thì là SAQ A hay SAQ A-EP?
Theo PCI SSC, iframe và redirect dùng SAQ A, còn direct post dùng SAQ A-EP. Với iframe, bạn còn phải xác nhận website không dễ bị tấn công bằng script theo điều kiện mới từ năm 2025.
Service provider có được dùng SAQ không?
Có, nếu thương hiệu thẻ và khách hàng cho phép. Service provider dùng SAQ D for Service Providers; service provider khối lượng lớn hoặc theo yêu cầu hợp đồng phải làm ROC.
Có phải quét ASV khi làm SAQ không?
Tùy loại SAQ và tài sản public trong phạm vi. Khi yêu cầu quét bên ngoài áp dụng, việc quét phải do Approved Scanning Vendor được PCI SSC công nhận thực hiện mỗi quý; hãy xác nhận với acquirer.
Sau khi chọn đúng SAQ, các việc kỹ thuật cần chuẩn bị có trong PCI DSS compliance checklist. Nếu bạn muốn quản lý evidence cho SAQ ở một nơi, đặt lịch trao đổi với pTrackly.