Tóm tắt
PCI DSS mất bao lâu với fintech Việt Nam: phụ thuộc phạm vi CDE, loại SAQ hay ROC do QSA thực hiện, cộng với ASV scan hằng quý và đánh giá lại mỗi năm.
PCI DSS mất bao lâu phụ thuộc chủ yếu vào phạm vi cardholder data environment (CDE) và cách bạn phải xác nhận tuân thủ: tự đánh giá bằng SAQ, hay Report on Compliance (ROC) do QSA thực hiện. Merchant dùng trang thanh toán hosted có thể xong trong thời gian ngắn; hệ thống tự lưu dữ liệu thẻ cần nhiều tháng khắc phục. PCI DSS cũng không xong một lần: việc xác nhận lặp lại hằng năm.
PCI DSS mất bao lâu, và điều gì quyết định timeline?
PCI DSS là tiêu chuẩn do PCI Security Standards Council (PCI SSC) ban hành, áp dụng cho mọi tổ chức lưu trữ, xử lý hoặc truyền dữ liệu thẻ. Phiên bản hiện hành là v4.0.1; v4.0 đã ngừng hiệu lực ngày 31/12/2024 (PCI SSC). Thời gian tuân thủ do ba yếu tố quyết định: số hệ thống nằm trong CDE, cách xác nhận mà acquirer hoặc card brand yêu cầu (SAQ hay ROC), và số control phải khắc phục. Không có con số chuẩn; ước tính đáng tin bắt đầu từ việc xác định phạm vi.
| Giai đoạn | Ai quyết định thời gian | Phụ thuộc vào |
|---|---|---|
| Xác định phạm vi CDE và luồng dữ liệu thẻ | Team của bạn (xác nhận với acquirer) | Dữ liệu thẻ có đi qua server của bạn không, tokenization, trang thanh toán hosted |
| Gap assessment theo 12 requirement | Team của bạn | Loại SAQ hoặc ROC, control đã có |
| Khắc phục (segmentation, MFA, logging, quản lý script) | Team của bạn | Hạ tầng, số hệ thống trong CDE, mua sắm công cụ |
| ASV scan bên ngoài và penetration test | ASV, pentest vendor | Lịch vendor, số lần phải scan lại sau khi sửa |
| SAQ tự đánh giá hoặc ROC do QSA đánh giá | Team của bạn hoặc QSA | Merchant level, yêu cầu của acquirer, lịch QSA |
Merchant level ảnh hưởng thế nào đến timeline?
Merchant level do từng card brand quy định, không phải PCI SSC, và quyết định cách bạn phải xác nhận tuân thủ. Theo cách phân loại phổ biến của Visa, Level 1 là merchant có trên 6 triệu giao dịch Visa mỗi năm và cần ROC do QSA thực hiện; Level 2 đến Level 4 thường được dùng SAQ, nhưng acquirer có thể yêu cầu khác. Service provider có ngưỡng riêng. Vì vậy hãy hỏi acquirer trước khi lập kế hoạch. Phân biệt chi tiết có ở bài SAQ vs ROC.
Vì sao giảm phạm vi CDE là cách rút ngắn timeline hiệu quả nhất?
Mọi hệ thống lưu, xử lý hoặc truyền dữ liệu thẻ, và hệ thống có thể kết nối tới chúng, đều nằm trong CDE và phải đáp ứng yêu cầu PCI DSS. Càng ít hệ thống trong CDE, càng ít control phải khắc phục và kiểm thử. Ba cách phổ biến:
- Trang thanh toán hosted (redirect hoặc iframe của cổng thanh toán): dữ liệu thẻ không đi qua server của bạn.
- Tokenization: hệ thống của bạn chỉ giữ token, payment processor giữ số thẻ thật.
- P2PE được PCI SSC công nhận: cho chấp nhận thẻ tại điểm bán.
Merchant chỉ dùng trang hosted và đáp ứng điều kiện thường dùng SAQ A, ngắn hơn nhiều so với SAQ D. Từ ngày 30/1/2025, PCI SSC thay đổi tiêu chí SAQ A liên quan đến script trên trang thanh toán. Cách xác định CDE có ở bài CDE là gì và cách xác định phạm vi PCI DSS, cách chọn SAQ ở bài SAQ PCI DSS là gì.
Những yêu cầu nào thường làm chậm PCI DSS?
Các yêu cầu cần thay đổi hạ tầng và có lịch kiểm thử cố định thường tốn nhiều thời gian nhất, vì không thể rút ngắn bằng cách thêm người:
| Yêu cầu (v4.0.1) | Vì sao tốn thời gian |
|---|---|
| Req 1: network security controls và segmentation | Thiết kế và chứng minh CDE được cô lập, sau đó kiểm thử segmentation |
| Req 8.4.2: MFA cho mọi truy cập non-console vào CDE | Phải triển khai cho cả công cụ quản trị nội bộ |
| Req 10: logging, lưu log 12 tháng (3 tháng truy cập ngay) | Cần log tập trung và bằng chứng review log |
| Req 11.3: ASV scan bên ngoài hằng quý, scan nội bộ hằng quý | Scan lỗi thì phải sửa và scan lại cho đến khi đạt |
| Req 11.4: penetration test hằng năm và sau thay đổi lớn | Phụ thuộc lịch vendor và segmentation đã xong |
| Req 6.4.3 và 11.6.1: quản lý script và phát hiện thay đổi trên trang thanh toán | Bắt buộc từ 31/3/2025, cần inventory script và cơ chế giám sát |
Toàn bộ 51 yêu cầu future-dated của v4.0 đã bắt buộc từ ngày 31/3/2025 (PCI SSC). Mốc hiệu lực và từng thay đổi có ở PCI DSS v4.0: những thay đổi quan trọng; các hạng mục chi phí (QSA, ASV, pentest, hạ tầng, nhân sự) có ở chi phí PCI DSS.
Sau khi đạt PCI DSS thì phải làm gì định kỳ?
PCI DSS là việc lặp lại, không phải dự án một lần. Hằng năm bạn nộp lại SAQ hoặc ROC kèm Attestation of Compliance; hằng quý chạy ASV scan bên ngoài và scan nội bộ; review quyền truy cập ít nhất 6 tháng một lần (Req 7.2.4); review log sự kiện bảo mật hằng ngày (Req 10.4.1); review policy hằng năm (Req 12.1.2). Khi QSA hoặc acquirer hỏi, bạn cần bằng chứng cho cả năm, không chỉ tháng trước kỳ đánh giá. Ranh giới giữa phần tự động hóa được và phần cần ASV, QSA hay người quyết định có ở bài tự động hóa tuân thủ PCI DSS.
pTrackly giúp gì và không làm gì?
pTrackly có framework PCI DSS 4.0.1 với policy template, evidence task lặp lại theo tần suất (ví dụ hằng quý cho ASV scan, nửa năm cho access review) kèm nhắc việc 7, 3 và 1 ngày trước hạn, access review với nguồn dữ liệu từ hệ thống định danh, module pentest, và audit workspace cho QSA làm việc với request list và bằng chứng. pTrackly không phải ASV hay QSA, không quét dữ liệu thẻ và không xác định phạm vi CDE thay bạn; việc khắc phục kỹ thuật và quyết định phạm vi vẫn thuộc về team của bạn. Xem nền tảng PCI DSS của pTrackly.
Câu hỏi thường gặp
Fintech tích hợp Stripe hoặc cổng thanh toán Việt Nam có cần PCI DSS không?
Có, nhưng phạm vi nhỏ hơn nhiều nếu bạn dùng trang thanh toán hosted và không nhận hay lưu dữ liệu thẻ. Khi đó thường dùng SAQ A; hãy xác nhận loại SAQ với acquirer.
Có thể tự đánh giá PCI DSS không?
Merchant thuộc các level được acquirer cho phép có thể tự đánh giá bằng SAQ. Merchant Level 1 và nhiều service provider cần ROC do QSA được PCI SSC công nhận thực hiện.
Bao lâu phải đánh giá PCI DSS lại?
Mỗi năm một lần cho SAQ hoặc ROC, cộng với ASV scan hằng quý và penetration test hằng năm hoặc sau thay đổi lớn.
PCI DSS v4.0 còn dùng được không?
Không. PCI DSS v4.0 đã ngừng hiệu lực ngày 31/12/2024; mọi đánh giá hiện nay theo v4.0.1.
