Bạn là merchant hay service provider?

PCI DSS phân biệt hai loại entity chính: merchant là tổ chức chấp nhận thanh toán thẻ trực tiếp từ khách hàng cuối. Service provider là tổ chức cung cấp dịch vụ cho merchant hoặc các payment entity khác, và trong quá trình đó có thể ảnh hưởng đến bảo mật CHD (Cardholder Data).

Hầu hết công ty IT outsourcing Việt Nam xây hệ thống thanh toán cho khách hàng nước ngoài rơi vào loại thứ hai: service provider, không phải merchant. Đây không phải chi tiết nhỏ.

Service provider có yêu cầu PCI DSS riêng, phải dùng SAQ (Self-Assessment Questionnaire) khác, và trong nhiều trường hợp phải đáp ứng mức cao hơn so với merchant cùng quy mô giao dịch. SAQ D dành cho service provider có 329 câu hỏi, bao phủ toàn bộ 12 yêu cầu PCI DSS, không có ngoại lệ nào. SAQ A dành cho merchant e-commerce nhỏ chỉ có 22 câu.

Nguồn: PCI DSS v4.0.1 Glossary (pcisecuritystandards.org/document_library)

Khi nào công ty IT Việt Nam nằm trong phạm vi PCI DSS

Ranh giới ở đây không rõ như nhiều người nghĩ.

Bạn host ERP, EHR, hoặc payment platform cho công ty Mỹ có xử lý thẻ thì bạn đang vận hành một phần của CDE (Cardholder Data Environment). Đó là service provider theo định nghĩa PCI DSS, không cần bàn thêm.

Bạn cung cấp managed IT services cho merchant Mỹ và có quyền truy cập vào hệ thống thanh toán cũng vậy. Ngay cả khi bạn không đọc số thẻ, chỉ cần bạn có thể ảnh hưởng đến bảo mật của hệ thống chứa CHD là đủ để bị xem là in-scope.

Bạn xây payment gateway component, API layer, tokenization service, hoặc 3DS integration: component đó xử lý hoặc truyền CHD, nên nằm trong CDE, và bạn là service provider.

Bạn cung cấp cloud hoặc hosting cho công ty xử lý thẻ: infrastructure service provider có nghĩa vụ PCI DSS cho phần infrastructure của họ, ngay cả khi không thấy dữ liệu thẻ.

Không nằm trong phạm vi: xây UI/UX front-end không có JavaScript trên checkout page, redirect sang third-party payment processor mà không lưu hoặc truyền CHD; cung cấp HR hay project management tool không liên quan đến payment flow; phát triển analytics tool chỉ nhận dữ liệu đã tokenized hoặc de-identified.

Tiêu chí PCI DSS dùng là "có thể ảnh hưởng đến bảo mật CHD", rộng hơn nhiều người nghĩ. Nếu bạn có admin access vào server của merchant mà server đó chạy payment software, bạn đã đủ điều kiện để bị xem là in-scope.

Nghĩa vụ service provider khác merchant thế nào

Service provider không phải một loại duy nhất. Level quyết định bạn phải làm gì và ai phải đánh giá.

Service provider Level 1 (xử lý trên 300.000 giao dịch Mastercard mỗi năm, hoặc theo yêu cầu của acquiring bank): phải có ROC (Report on Compliance) hàng năm do QSA (Qualified Security Assessor) thực hiện, cộng với ASV (Approved Scanning Vendor) scan quarterly cho external-facing infrastructure. ROC là đánh giá tại chỗ, không phải tự khai.

Service provider Level 2: có thể dùng SAQ D Service Provider thay vì ROC. SAQ D Service Provider là bộ câu hỏi tự đánh giá với 329 câu hỏi bao phủ toàn bộ 12 yêu cầu PCI DSS. Không có câu hỏi nào bị loại ra.

So sánh: merchant Level 4 (dưới 20.000 giao dịch e-commerce/năm) có thể dùng SAQ A với 22 câu. Cùng là công ty nhỏ, nhưng nếu bạn là service provider, bạn phải làm 329 câu.

Ngoài SAQ/ROC, PCI DSS v4.0.1 bổ sung Requirement 12.9: service provider phải ký "written agreement" với khách hàng để xác nhận trách nhiệm PCI DSS của từng bên. Đây là quy định tương đương PCI DSS của BAA trong HIPAA. Thiếu văn bản này là một finding trong quá trình đánh giá.

Nguồn: PCI DSS v4.0.1 Req 12.9 (pcisecuritystandards.org/document_library)

Responsibility matrix: ai chịu trách nhiệm phần nào

Khi công ty Việt Nam cung cấp service cho merchant Mỹ, toàn bộ 12 yêu cầu PCI DSS vẫn phải được đáp ứng, nhưng không nhất thiết một bên phải làm tất cả. Trách nhiệm được chia trong hợp đồng và ghi lại qua responsibility matrix.

Ví dụ điển hình: merchant chịu trách nhiệm policy, workforce training, physical security tại văn phòng của họ. Service provider chịu trách nhiệm technical controls trên infrastructure mà họ quản lý: patch management, network segmentation, encryption, monitoring.

PCI SSC có template responsibility matrix mà service provider nên điền và cung cấp cho khách hàng theo Req 12.9.2. Template này liệt kê từng yêu cầu PCI DSS và xác định ai chịu trách nhiệm: service provider, merchant, hay shared.

Khi QSA đến đánh giá merchant, họ sẽ hỏi về trách nhiệm của từng service provider. Nếu merchant không có written agreement và matrix từ bạn, đó là finding cho merchant. Câu hỏi ngược lại cũng sẽ xuất hiện: tại sao bạn chưa cung cấp tài liệu đó.

Điều cần chuẩn bị trong hợp đồng với khách hàng

Có bốn điểm thường bị bỏ qua khi ký hợp đồng payment project với merchant Mỹ hoặc EU.

Thứ nhất là phân chia trách nhiệm PCI DSS. Điều khoản phải ghi rõ phần nào là trách nhiệm của bạn, phần nào là của merchant. Không để "as agreed verbally", không để mặc định. Req 12.9 yêu cầu written agreement, không phải thỏa thuận miệng.

Thứ hai là quyền audit của khách hàng. Merchant cần có quyền kiểm tra compliance của bạn, hoặc yêu cầu bạn cung cấp SAQ/ROC khi họ cần. Điều khoản này thường do merchant yêu cầu, nhưng nếu không có, đánh giá viên của merchant sẽ flag.

Thứ ba là breach notification timeline. PCI DSS yêu cầu notification "immediately" và không quá 72 giờ với nhiều card brand. Nhiều hợp đồng thực tế đặt yêu cầu 24-72 giờ. Bạn cần có quy trình phát hiện và báo cáo incident đủ nhanh để đáp ứng.

Thứ tư là danh sách subcontractors. Nếu bạn dùng subcontractor xử lý CHD, phải liệt kê trong hợp đồng và đảm bảo họ cũng tuân thủ PCI DSS. Tương đương điều khoản subcontractor trong BAA theo HIPAA.

Hợp đồng không thay thế được technical compliance. Nhưng thiếu điều khoản hợp đồng đúng là một trong những finding thường gặp nhất khi QSA xem xét vendor management của merchant.

Bước đầu tiên cho IT outsourcing company

Bước đầu tiên không phải mở SAQ D ra làm. Nếu bạn chưa biết mình là merchant hay service provider, chưa biết hệ thống nào nằm trong CDE, thì làm 329 câu hỏi đó có thể sẽ sai scope ngay từ đầu.

Thứ tự thực tế hơn:

  1. Xác định scope trước. Hệ thống nào của bạn chứa, xử lý, truyền, hoặc có thể ảnh hưởng đến CHD của khách hàng? List ra từng system, từng team có access. Phần này thường cần 1-2 buổi làm việc với technical lead và account manager.

  2. Phân loại entity type. Bạn là merchant hay service provider? Service provider Level 1 hay Level 2? Level phụ thuộc vào volume giao dịch và yêu cầu của card brand hoặc acquiring bank của khách hàng.

  3. Review hợp đồng hiện tại. Có điều khoản PCI DSS nào không? Bạn đã ký written agreement với khách hàng về phân chia trách nhiệm PCI DSS chưa? Nếu chưa, Req 12.9 đang bị thiếu và đó là finding sẽ xuất hiện trong lần đánh giá đầu tiên.

  4. Chọn SAQ type. Với service provider thường là SAQ D Service Provider, trừ khi acquiring bank yêu cầu ROC đầy đủ.

  5. Thực hiện gap assessment so với 329 yêu cầu trong SAQ D. Làm nội bộ trước để có bức tranh ban đầu. QSA cần thiết khi bạn muốn kết quả được chấp nhận bởi card brand hoặc merchant.

Nguồn: PCI DSS v4.0.1 (pcisecuritystandards.org/document_library)

Tài liệu tham khảo:

Thẻ:
PCI DSSIT OutsourcingService ProviderVietnam
← Quay lại Blog