PCI DSS không phải dự án một lần
Nhiều đội security xử lý PCI DSS như một dự án có điểm đầu và điểm cuối: chuẩn bị tài liệu, vượt qua audit, đóng ticket. Rồi 11 tháng sau, lặp lại từ đầu.
Vấn đề là cái khung đó không khớp với cách PCI DSS thực sự hoạt động. Chứng nhận có thể hàng năm, nhưng rất nhiều yêu cầu bên trong là liên tục.
ASV (Approved Scanning Vendor) scan bắt buộc mỗi quý một lần. Log review diễn ra định kỳ. Access review cần được thực hiện đều đặn. Security awareness training bắt buộc hàng năm. Patch management không bao giờ dừng. Tất cả các hoạt động này đều cần bằng chứng, và bằng chứng đó cần được lưu trữ đúng cách.
Kết quả của việc xử lý compliance như một "sprint" là phần lớn bằng chứng chỉ tồn tại trên giấy trong vài tuần trước audit. Giữa các kỳ kiểm tra, tình trạng thực tế của môi trường có thể lệch khỏi những gì đã được ghi lại mà không ai chú ý.
Chi phí vận hành của PCI DSS làm thủ công
SAQ D dành cho Service Provider có 329 yêu cầu. Với mỗi yêu cầu, đội compliance cần bằng chứng cụ thể: screenshot, log export, policy document, hoặc approval record. Quản lý tất cả những thứ đó trong một spreadsheet nghĩa là hàng trăm dòng, hàng chục file đính kèm, và không có cách nào để biết cái nào đã hết hạn.
ASV scan mỗi quý không chỉ là bấm nút. Phải lên lịch với vendor, chạy scan, review kết quả, phân loại và xử lý false positive, rồi nộp báo cáo cho QSA. Nhân lên 4 lần một năm, mỗi lần mất vài ngày nếu có findings cần giải trình.
CDE (Cardholder Data Environment) access review theo Requirement 7.2.4 và 8.6.1 yêu cầu xác nhận định kỳ rằng ai đang có quyền truy cập gì. Trong thực tế, việc này thường được thực hiện bằng cách export danh sách user từ các hệ thống, dán vào Google Sheets, rồi email cho từng manager xác nhận. Khi số lượng hệ thống tăng lên, quy trình này trở nên không scalable.
12 policy area trong PCI DSS, mỗi cái phải được review ít nhất hàng năm, với bằng chứng ghi lại ai review, khi nào, và ai phê duyệt. Nếu làm bằng tay, đây là thêm một bảng tính nữa để theo dõi.
Incident log yêu cầu ghi lại mọi security incident, kết quả điều tra, và các follow-up action, bất kể có phải báo cáo chính thức hay không. Bằng chứng này cần có khi auditor hỏi.
Continuous compliance là gì
Continuous compliance là cách tiếp cận khác về mặt vận hành: thay vì chuẩn bị để audit, mục tiêu là duy trì trạng thái tuân thủ liên tục.
Sự khác biệt thực tế là khi audit đến, không cần sprint. Bằng chứng đã được thu thập tự động hoặc được track liên tục. Khoảng cách giữa trạng thái được ghi lại và trạng thái thực tế của môi trường nhỏ hơn nhiều.
Về mặt kỹ thuật, điều này thường được thực hiện qua automated evidence collection: scan chạy theo lịch và kết quả được lưu tự động, policy acknowledgment được track trong hệ thống, access log được export định kỳ. Thay vì manual review theo từng đợt, một số control có thể được monitor real-time với alert khi phát sinh drift.
Những gì có thể tự động hóa trong PCI DSS
Requirement 1-2 về network security: firewall rule review và configuration drift detection là những tác vụ mà tool có thể làm tốt hơn người vì chúng cần so sánh trạng thái hiện tại với baseline, không cần judgment phức tạp.
Requirement 3-4 về data protection: automated scan có thể phát hiện PAN (primary account number) không được mã hóa trong logs hoặc databases, những thứ rất khó tìm bằng tay trong môi trường lớn.
Requirement 6 về vulnerability management: tích hợp với CI/CD pipeline cho phép tự động scan dependency và chạy SAST mỗi khi có code thay đổi. Kết quả được ghi lại và có thể dùng làm bằng chứng.
Requirement 7-8 về access control: thay vì export thủ công và email cho manager, workflow access review có thể được tự động hóa với reminder, deadline, và audit trail được ghi lại tự động. Alert khi user không hoạt động vẫn còn quyền cũng có thể set up được.
Requirement 10 về logging: log aggregation tự động và anomaly detection giảm đáng kể thời gian review.
Requirement 11 về testing: scheduled ASV scan theo lịch cố định, với kết quả tự động lưu vào evidence repository.
Những gì không thể tự động hóa hoàn toàn
Có những phần của PCI DSS mà tool chỉ hỗ trợ, không thể thay thế.
Risk assessment theo Requirement 12.3 cần judgment của người có hiểu biết về business context. Tool có thể thu thập dữ liệu và tạo template, nhưng quyết định về mức độ rủi ro và biện pháp xử lý vẫn cần người.
Security awareness training: có thể tự động schedule, gửi nhắc nhở, và track completion rate. Nhưng nội dung training phải do người thiết kế, và hiệu quả training không phải là con số tự động đo được.
Incident response: system có thể detect và alert khi có dấu hiệu bất thường. Nhưng điều tra incident, xác định root cause, và quyết định escalation cần người thực hiện.
Policy review và approval: có thể nhắc nhở khi policy đến hạn review và track trạng thái. Nhưng approval cần người có thẩm quyền ký, không thể tự động hóa bước đó.
Ranh giới này ảnh hưởng trực tiếp đến cách thiết kế quy trình. Những phần không tự động hóa được không phải vì thiếu tool, mà vì chúng cần người hiểu context để đưa ra quyết định.
So sánh thực tế: spreadsheet thủ công và compliance platform
| Spreadsheet thủ công | Compliance platform | |
|---|---|---|
| Thu thập bằng chứng | Copy/paste thủ công từ nhiều nguồn | Automated ingestion từ cloud APIs và hệ thống nội bộ |
| Audit trail | Không có hoặc dễ bị chỉnh sửa | Immutable log ghi lại mọi thay đổi |
| Nhắc nhở và deadline | Calendar alert cá nhân, dễ bỏ sót | Automated workflow với escalation |
| Reporting | Export thủ công, format tùy vào người làm | Report theo template chuẩn, on-demand |
| Cross-framework | Làm lại từ đầu khi thêm framework | Control mapping giữa PCI DSS, ISO 27001, SOC 2 |
Nhiều công ty cần tuân thủ nhiều hơn một framework cùng lúc: PCI DSS cho payment processing, SOC 2 cho enterprise sales, ISO 27001 cho khách hàng tại một số thị trường. Với spreadsheet, mỗi framework là một bộ tài liệu riêng biệt, với rất nhiều nội dung trùng lặp. Control mapping tự động giúp tránh việc thu thập và duy trì bằng chứng cho cùng một control nhiều lần với nhiều tên gọi khác nhau.
Điểm xuất phát thực tế
Với đội compliance đang dùng spreadsheet, chuyển sang công cụ khác không phải quyết định dễ vì có chi phí migration và learning curve. Câu hỏi thực tế hơn là: chi phí vận hành hiện tại là bao nhiêu, và chi phí đó có xu hướng tăng hay giảm khi scope compliance mở rộng?
Với môi trường nhỏ và scope giới hạn, spreadsheet có thể đủ dùng. Với môi trường lớn hơn, nhiều hệ thống, nhiều team liên quan, và yêu cầu multi-framework, chi phí duy trì spreadsheet thường tăng nhanh hơn chi phí chuyển sang tool chuyên dụng.
Continuous compliance không phải một lần thiết lập xong là quên, nó là cách vận hành đòi hỏi duy trì. Với đội nhỏ, câu hỏi thực tế là liệu chi phí duy trì đó có thấp hơn chi phí chạy sprint compliance mỗi năm hay không. Câu trả lời phụ thuộc vào scope, số framework, và số hệ thống trong môi trường.