Tóm tắt
Thêm framework mà không đổi cách vận hành khiến workload tăng gần tuyến tính, không vì compliance phức tạp hơn mà vì control và evidence bị làm lặp lại.
Vận hành nhiều framework compliance không làm workload tăng gấp đôi nếu control và evidence được làm một lần rồi gán cho mọi framework liên quan. Workload chỉ tăng gần tuyến tính khi mỗi framework có bảng tính, bộ evidence và người thu thập riêng. Phần việc thật sự mới khi thêm framework là phần gap mà framework đó yêu cầu thêm.
Vì sao thêm framework thường làm workload tăng gần gấp đôi?
Khi công ty đã có ISO 27001 và bắt đầu chuẩn bị SOC 2, phản ứng đầu tiên thường là: "Mình đã có nền tảng rồi, phần còn lại chỉ là điền vào." Về lý thuyết điều này không sai. Nhưng trên thực tế, hai framework thường vận hành như hai hệ thống tách biệt, với hai bộ bằng chứng riêng, hai bảng tính riêng, và hai lần thu thập cho cùng một thông tin. Thêm PCI DSS thì thành ba. Workload khi đó tăng theo số framework, không phải vì compliance vốn phức tạp hơn mà vì cùng một việc bị làm lặp lại.
Ví dụ cụ thể: cùng một chính sách xác thực, ba bộ evidence
Chính sách xác thực (mật khẩu, MFA) xuất hiện trong cả ISO 27001, SOC 2 và PCI DSS với cách diễn đạt khác nhau nhưng bản chất giống nhau. ISO 27001:2022 có control A.5.17 về thông tin xác thực và A.8.5 về xác thực an toàn; SOC 2 đánh giá qua tiêu chí CC6.1 về kiểm soát truy cập logic; PCI DSS v4.0 có yêu cầu 8.3 về xác thực mạnh, trong đó 8.3.6 đặt độ dài mật khẩu tối thiểu 12 ký tự (hoặc 8 nếu hệ thống không hỗ trợ 12).
Không có một lớp mapping nối các framework lại, người phụ trách compliance sẽ thu thập bằng chứng riêng cho từng framework: ảnh chụp cấu hình Active Directory cho ISO 27001, export log cho SOC 2, tài liệu chính sách riêng cho PCI DSS. Ba bộ bằng chứng, tất cả đều trỏ về cùng một cấu hình đang chạy trên cùng một hệ thống.
Những nhóm control nào lặp lại giữa các framework?
Xác thực chỉ là một ví dụ. Bảng dưới là các nhóm control xuất hiện đồng thời trong ba framework phổ biến với công ty ITO và SaaS Việt Nam. Số hiệu theo ISO/IEC 27001:2022, AICPA Trust Services Criteria và PCI DSS v4.0.
| Nhóm control | ISO 27001:2022 | SOC 2 (TSC) | PCI DSS v4.0 |
|---|---|---|---|
| Kiểm soát truy cập | A.5.15–A.5.18 | CC6.1–CC6.3 | Yêu cầu 7 và 8 |
| Logging và monitoring | A.8.15, A.8.16 | CC7.2 | Yêu cầu 10 |
| Quản lý sự cố | A.5.24–A.5.28 | CC7.3–CC7.5 | Yêu cầu 12.10 |
| Quản lý thay đổi | A.8.32 | CC8.1 | Yêu cầu 6.5 |
| Quản lý nhà cung cấp | A.5.19–A.5.22 | CC9.2 | Yêu cầu 12.8 |
Với những nhóm này, evidence thường đã có sẵn trong hệ thống. Câu hỏi là evidence đó đang được gán vào một framework, nhiều framework, hay đang nằm rải rác mà không gắn vào đâu.
Mapping layer thay đổi phép tính như thế nào?
Khi có một lớp mapping nối control giữa các framework, một bộ evidence có thể đáp ứng nhiều framework cùng lúc. Ví dụ, tài liệu và log access review có thể dùng cho SOC 2 CC6.1 và ISO 27001 A.5.15 / A.8.3, miễn là tài liệu đủ chi tiết cho cả hai.
Mapping không có nghĩa là một framework chấp nhận bằng chứng của framework kia một cách mù quáng. Mỗi framework vẫn có ngôn ngữ, phạm vi và yêu cầu riêng, và auditor của từng framework vẫn kiểm tra theo tiêu chí của mình. Nhưng thay vì thu thập hai lần cho cùng một control từ cùng một nguồn, người phụ trách chỉ cần thu thập một lần và gán đúng tham chiếu cho mỗi framework.
Khi thêm PCI DSS vào tổ chức đã có ISO 27001 và SOC 2, phần workload thực sự tăng là phần PCI DSS yêu cầu mà hai framework kia không bao phủ, chẳng hạn yêu cầu về môi trường dữ liệu chủ thẻ (CDE) và phạm vi của nó. Không phải toàn bộ bộ evidence từ đầu.
Nếu chưa chắc nên bắt đầu với framework nào, bài chứng nhận bảo mật nào phù hợp giúp chọn theo thị trường và loại dữ liệu.
Nên bắt đầu đo overlap giữa các framework thế nào?
- Liệt kê các framework đang vận hành hoặc sắp triển khai, kèm phạm vi hệ thống của từng framework.
- Đặt danh sách control của từng framework cạnh nhau theo nhóm: truy cập, logging, sự cố, thay đổi, nhà cung cấp, đào tạo, rủi ro.
- Với mỗi nhóm, ghi evidence đang có và framework nào đang dùng nó.
- Đánh dấu evidence đang bị thu thập lặp lại cho nhiều framework; đó là phần có thể gộp.
- Phần còn lại là gap thật của framework mới; lập kế hoạch riêng cho phần này.
Nếu đang cân nhắc chạy ISO 27001 và SOC 2 song song, bài triển khai ISO 27001 và SOC 2 cùng lúc đi sâu vào lộ trình, còn trang so sánh ISO 27001 và SOC 2 giúp chọn thứ tự.
pTrackly xử lý nhiều framework thế nào?
Trong pTrackly, control được dùng chung giữa các framework: khi thêm ISO 27001 trên nền SOC 2, các control, policy và task trùng nhau được tái sử dụng thay vì tạo bản sao, và một policy được publish hoặc một task hoàn thành sẽ tính cho mọi framework liên kết. Phần gap của framework mới hiện ra như các control và task chưa có evidence. Nền tảng không quyết định thay auditor rằng một evidence đủ cho framework nào; người phụ trách vẫn kiểm tra phạm vi và yêu cầu riêng của từng framework. Xem ISO 27001 trên pTrackly và PCI DSS trên pTrackly.
Câu hỏi thường gặp
Thêm framework thứ hai có làm workload tăng gấp đôi không?
Không, nếu control và evidence được làm một lần rồi gán cho nhiều framework. Workload chỉ tăng gần gấp đôi khi mỗi framework có bộ evidence và quy trình thu thập riêng.
Evidence của ISO 27001 có dùng lại được cho SOC 2 không?
Phần lớn evidence vận hành như access review, log, quản lý thay đổi và quản lý nhà cung cấp có thể dùng lại nếu đủ chi tiết và cùng thời kỳ. SOC 2 Type II còn yêu cầu evidence phủ suốt observation period, nên cần kiểm tra mốc thời gian.
Khi thêm PCI DSS, phần nào thường là việc mới?
Thường là xác định phạm vi môi trường dữ liệu chủ thẻ (CDE) và các yêu cầu riêng về bảo vệ dữ liệu thẻ, cùng hình thức đánh giá (SAQ hoặc ROC). Các nhóm control chung như truy cập, logging và sự cố có thể dùng lại từ ISO 27001 hoặc SOC 2.
Có cần một người riêng cho từng framework không?
Không bắt buộc. Một owner cho mỗi control, phụ trách evidence dùng chung cho mọi framework, thường hiệu quả hơn chia người theo framework.
