Tóm tắt
Duy trì ISO 27001 và PCI DSS cùng lúc nghĩa là hai chu kỳ audit, một bộ control dùng chung; bài cho fintech và payment cách lên lịch và tránh làm hai lần.
Duy trì ISO 27001 và PCI DSS sau chứng nhận nghĩa là vận hành hai chu kỳ audit khác nhau trên cùng một hệ thống: ISO 27001 có surveillance audit hằng năm do tổ chức chứng nhận thực hiện, PCI DSS có đánh giá hằng năm qua ROC với QSA hoặc SAQ. Phần lớn control chồng lên nhau, nên cách tiết kiệm nhất là map một lần, thu thập evidence một lần và lên một lịch chung cho cả năm.
Duy trì ISO 27001 và PCI DSS khác nhau thế nào?
Hai framework cùng yêu cầu control vận hành liên tục nhưng kiểm tra theo cách khác nhau. ISO 27001 đánh giá hệ thống quản lý (ISMS) và để bạn tự quyết tần suất theo đánh giá rủi ro; PCI DSS quy định tần suất cụ thể cho nhiều yêu cầu và chỉ áp dụng trong phạm vi môi trường dữ liệu thẻ (CDE).
| Khía cạnh | ISO 27001 | PCI DSS v4.0.1 |
|---|---|---|
| Ai đánh giá | Tổ chức chứng nhận được công nhận | QSA (ROC) hoặc tự đánh giá (SAQ), tùy loại và cấp độ do các hãng thẻ quy định |
| Chu kỳ | Chứng nhận 3 năm, surveillance audit năm 1 và năm 2, recertification năm 3 | Đánh giá lại mỗi năm |
| Phạm vi | Phạm vi ISMS bạn tự xác định | CDE và các hệ thống kết nối, xác nhận lại mỗi 12 tháng (12.5.2) |
| Tần suất control | Theo đánh giá rủi ro và "planned intervals" | Nhiều tần suất cố định: access review 6 tháng (7.2.4), scan nội bộ hằng quý (11.3.1), ASV scan hằng quý (11.3.2), pentest hằng năm (11.4) |
Nguồn: ISO/IEC 27001:2022 và PCI DSS v4.0.1 trong thư viện tài liệu PCI SSC. Chi tiết lịch surveillance audit và recertification nằm trong hướng dẫn duy trì ISO 27001 sau chứng nhận; danh sách yêu cầu PCI nằm trong 12 yêu cầu PCI DSS.
Control nào của ISO 27001 và PCI DSS dùng chung được?
Nhiều control trùng mục đích. Khi một control được thiết kế đủ chặt cho yêu cầu khắt khe hơn (thường là PCI DSS, vì có tần suất cố định), cùng một evidence dùng được cho cả hai.
| Chủ đề | ISO 27001:2022 Annex A | PCI DSS v4.0.1 | Lưu ý khi dùng chung |
|---|---|---|---|
| Review quyền truy cập | A.5.18 | 7.2.4 | Chạy ít nhất 6 tháng một lần để đáp ứng PCI |
| Quản lý lỗ hổng | A.8.8 | 11.3.1, 11.3.2 | Scan hằng quý; ASV scan bên ngoài là riêng của PCI |
| Kiểm thử xâm nhập | A.8.8 (theo rủi ro) | 11.4 | PCI yêu cầu ít nhất mỗi 12 tháng và sau thay đổi lớn |
| Log và giám sát | A.8.15, A.8.16 | 10.2, 10.4.1 | PCI yêu cầu review log bảo mật hằng ngày |
| Đào tạo nhận thức | A.6.3 | 12.6 | Khi tuyển dụng và ít nhất mỗi 12 tháng |
| Nhà cung cấp | A.5.19 đến A.5.22 | 12.8 | PCI yêu cầu theo dõi trạng thái tuân thủ của nhà cung cấp mỗi 12 tháng (12.8.4) |
| Ứng phó sự cố | A.5.24 đến A.5.26 | 12.10 | Một kế hoạch, kiểm thử ít nhất mỗi 12 tháng cho PCI |
| Policy | A.5.1 | 12.1 | Review ít nhất mỗi 12 tháng (12.1.2) |
Một năm vận hành cả hai trông như thế nào?
Lịch dưới đây là ví dụ minh họa cho một fintech có ROC tháng 3 và surveillance audit ISO 27001 tháng 9; tháng cụ thể phụ thuộc chu kỳ của bạn.
- Hằng ngày: review log bảo mật trong phạm vi CDE (PCI 10.4.1), kiểm tra cấu hình cloud tự động.
- Hằng quý: scan lỗ hổng nội bộ và ASV scan (PCI 11.3), review các evidence task đến hạn, cập nhật danh sách vendor.
- Mỗi 6 tháng: access review phủ cả CDE lẫn phạm vi ISMS (PCI 7.2.4, ISO A.5.18).
- Trước ROC (tháng 1 đến 2): xác nhận phạm vi PCI (12.5.2), pentest hằng năm (11.4), review policy (12.1.2, A.5.1).
- Sau ROC (tháng 4 đến 6): đóng finding của QSA, đưa kết quả vào đánh giá rủi ro ISO 27001.
- Trước surveillance audit (tháng 7 đến 8): internal audit ISO 27001 (điều 9.2) và management review (9.3), dùng lại evidence đã thu cho PCI.
Đặt mọi việc trên vào một lịch và một kho evidence là điều kiện để hai kỳ audit không thành hai đợt chạy nước rút riêng biệt.
Vì sao nhiều team vẫn vất vả dù đã có chứng nhận?
Ba lý do lặp lại ở hầu hết doanh nghiệp. Thứ nhất, consultant giúp đạt chứng nhận nhưng không ở lại vận hành, nên sau dự án mọi thứ quay về Excel và email. Thứ hai, người phụ trách thường kiêm nhiệm (CTO, IT manager), nên việc định kỳ bị đẩy xuống cho đến khi audit tới gần. Thứ ba, evidence nằm rải rác: log CloudTrail trong bucket, email access review, báo cáo scan trong folder cá nhân, hợp đồng vendor trong Drive pháp chế. Khi QSA hay auditor hỏi evidence của 12 tháng qua, team phải đi tìm thay vì xuất ra. Các vấn đề vận hành chung sau chứng nhận được phân tích trong bài duy trì compliance sau chứng nhận.
pTrackly hỗ trợ duy trì ISO 27001 và PCI DSS như thế nào?
pTrackly có sẵn ISO 27001 và PCI DSS 4.0.1, và control được dùng chung giữa các framework: một policy được publish hay một task hoàn thành được tính cho mọi framework liên kết với nó. Evidence task có tần suất từ hằng ngày đến hằng năm, owner, ngày review, nhắc 7, 3 và 1 ngày trước hạn và chuyển cấp khi quá hạn. Access review có thể lặp 6 tháng một lần và ghi lại từng quyết định; cloud tests có thể chạy hằng ngày làm evidence; module Pentest lưu lỗ hổng, tiến độ khắc phục và báo cáo cuối; vendor register nhắc trước khi chứng chỉ và hợp đồng hết hạn. Mỗi kỳ audit chạy trong một không gian riêng, auditor chỉ thấy audit họ được mời. pTrackly không phải QSA hay tổ chức chứng nhận: QSA thực hiện ROC, tổ chức chứng nhận thực hiện surveillance audit, còn team của bạn vận hành control. Xem pTrackly cho team đã có chứng nhận và trang PCI DSS.
Câu hỏi thường gặp
Có thể gộp ROC PCI DSS và surveillance audit ISO 27001 vào một đợt không?
Hai đợt do hai bên khác nhau thực hiện (QSA và tổ chức chứng nhận) theo hai tiêu chuẩn khác nhau, nên vẫn là hai audit. Điều gộp được là evidence: một kho evidence theo control phục vụ cả hai.
PCI DSS có yêu cầu gì chặt hơn ISO 27001 khi vận hành?
PCI DSS quy định tần suất cố định cho nhiều việc, như review tài khoản 6 tháng một lần (7.2.4), scan hằng quý (11.3) và review log hằng ngày (10.4.1). ISO 27001 để tần suất theo đánh giá rủi ro, nên thiết kế theo PCI thường đáp ứng được cả hai.
Surveillance audit ISO 27001 diễn ra bao lâu một lần?
Tổ chức chứng nhận thực hiện surveillance audit vào năm thứ nhất và thứ hai sau chứng nhận, rồi recertification audit trước khi chứng nhận 3 năm hết hạn.
Phạm vi PCI DSS và phạm vi ISMS có phải giống nhau không?
Không bắt buộc. Phạm vi PCI là CDE và các hệ thống kết nối; phạm vi ISMS do bạn xác định và thường rộng hơn. Control dùng chung cần bao phủ cả hai phạm vi.
