Tóm tắt
Cách viết Statement of Applicability (SoA) ISO 27001: rà 93 Annex A controls, ghi lý do loại trừ và liên kết với Risk Register để auditor chấp nhận.
Statement of Applicability ISO 27001 (SoA) là tài liệu bắt buộc theo clause 6.1.3 d của ISO/IEC 27001:2022: một bảng liệt kê control cần thiết, lý do đưa vào, tình trạng triển khai và lý do loại trừ từng control Annex A. Không có SoA được phê duyệt, doanh nghiệp không qua được audit chứng nhận, và đây là tài liệu auditor dùng để đối chiếu rủi ro với bằng chứng.
SoA là gì và vì sao bắt buộc?
Clause 6.1.3 d yêu cầu lập một Statement of Applicability chứa: các control cần thiết (từ Annex A hoặc nguồn khác), lý do đưa vào, control đó đã được triển khai hay chưa, và lý do loại trừ các control Annex A không áp dụng. Vì phải nêu cả lý do loại trừ, trên thực tế SoA liệt kê đủ 93 control của Annex A.
SoA bắt buộc vì nó chứng minh doanh nghiệp đã xem xét toàn bộ bộ control, không chỉ chọn những control dễ làm. Auditor dùng nó làm bản đồ: từ rủi ro trong risk register sang control trong SoA, rồi sang bằng chứng vận hành.
Một SoA chuẩn gồm những cột nào?
Mỗi dòng ứng với một control Annex A. Các cột thường dùng:
| Control | Tên control | Áp dụng? | Lý do đưa vào hoặc loại trừ | Tình trạng | Tài liệu, bằng chứng tham chiếu |
|---|---|---|---|---|---|
| 5.1 | Policies for information security | Có | Yêu cầu nền tảng của ISMS; yêu cầu hợp đồng khách hàng | Đã triển khai | Information Security Policy v2.1 |
| 5.18 | Access rights | Có | Rủi ro R-03: người đã nghỉ còn quyền truy cập | Đã triển khai | Quy trình access review, biên bản review quý gần nhất |
| 7.4 | Physical security monitoring | Không | Không có văn phòng hay cơ sở vật lý trong phạm vi ISMS; hạ tầng chạy trên cloud, giám sát vật lý data center thuộc nhà cung cấp (đã đánh giá theo 5.23) | Không áp dụng | Báo cáo chứng nhận của nhà cung cấp cloud |
Cột "lý do" là cột auditor đọc kỹ nhất. Lý do đưa vào nên trỏ về rủi ro, yêu cầu pháp lý hoặc hợp đồng cụ thể; lý do loại trừ nên trỏ về phạm vi ISMS.
93 control Annex A thường được áp dụng thế nào với công ty phần mềm?
ISO/IEC 27001:2022 có 93 control trong 4 nhóm. Với công ty phần mềm, mức độ loại trừ thường khác nhau theo nhóm:
- Tổ chức (5.1–5.37, 37 control): chính sách, vai trò, tài sản, truy cập, nhà cung cấp, sự cố, liên tục, pháp lý. Gần như luôn áp dụng toàn bộ.
- Con người (6.1–6.8, 8 control): tuyển dụng, hợp đồng, đào tạo, kỷ luật, offboarding, NDA, làm việc từ xa, báo cáo sự cố. Hầu như luôn áp dụng toàn bộ, kể cả công ty rất nhỏ.
- Vật lý (7.1–7.14, 14 control): nhóm có nhiều khả năng loại trừ nhất khi doanh nghiệp không có văn phòng hay phòng máy trong phạm vi. Tuy vậy 7.7 clear desk, clear screen, 7.9 tài sản ngoài cơ sở và 7.14 tiêu hủy thiết bị thường vẫn áp dụng cho laptop của nhân viên.
- Công nghệ (8.1–8.34, 34 control): endpoint, truy cập, lỗ hổng, log, mạng, mã hóa, phát triển an toàn, backup. Hầu hết áp dụng với công ty phần mềm và là nhóm tốn công triển khai nhất.
Giải thích chi tiết từng nhóm xem tại hướng dẫn ISO 27001 Annex A.
Lý do loại trừ thế nào thì auditor chấp nhận?
Lý do loại trừ phải gắn với phạm vi và bối cảnh, không phải với độ khó. Auditor không chấp nhận:
- "Không liên quan", quá chung chung;
- "Chưa triển khai", đây là tình trạng của control được áp dụng, không phải lý do loại trừ;
- để trống.
Ví dụ lý do loại trừ thường được chấp nhận:
- "Không có văn phòng hay cơ sở vật lý trong phạm vi ISMS" để loại trừ một số control khu vực an toàn như 7.1–7.4;
- "Không phát triển phần mềm trong phạm vi ISMS" để loại trừ các control phát triển như 8.25–8.29;
- "Không thuê ngoài phát triển phần mềm" để loại trừ 8.30 Outsourced development.
Nếu một control bị loại trừ nhưng rủi ro trong register lại cần đến nó, đó là mâu thuẫn auditor sẽ phát hiện.
SoA liên kết với risk register như thế nào?
SoA không đứng một mình. Auditor kiểm tra tính nhất quán theo hai chiều:
- Rủi ro sang control. Mỗi rủi ro được xử lý bằng control nào thì control đó phải được đánh dấu áp dụng trong SoA. Ví dụ register ghi rủi ro "truy cập trái phép vào production" xử lý bằng 8.2 Privileged access rights, mà SoA lại ghi 8.2 không áp dụng: mâu thuẫn.
- Control sang bằng chứng. Mỗi control ghi "đã triển khai" phải có bằng chứng vận hành. SoA ghi 8.15 Logging đã triển khai nhưng không có log được thu thập và review là tuyên bố không có cơ sở.
Cách dựng register để hai chiều này khớp nhau xem tại hướng dẫn ISO 27001 risk register.
Những lỗi phổ biến khi viết SoA?
- Ghi mọi control là "áp dụng" cho an toàn. Mỗi control áp dụng đều cần bằng chứng; đánh dấu thừa nghĩa là phải chứng minh thừa.
- Không ghi tài liệu tham chiếu. "Có policy" mà không nêu tên và phiên bản tài liệu thì auditor không kiểm tra được.
- SoA chưa được phê duyệt. Clause 7.5 yêu cầu thông tin dạng văn bản được review và phê duyệt về tính phù hợp; SoA nên có phê duyệt của người có thẩm quyền như CEO hoặc người phụ trách bảo mật.
- Không kiểm soát phiên bản. Nhiều bản SoA cùng tồn tại mà không rõ bản hiện hành sẽ khiến auditor nghi ngờ toàn bộ việc kiểm soát tài liệu.
- Không cập nhật khi có thay đổi. Khi phạm vi, rủi ro hoặc control thay đổi, SoA phải đổi theo; SoA không đổi trong hai năm khó phản ánh thực tế.
Lập SoA theo những bước nào?
- Hoàn thành risk assessment và risk treatment trước, để biết control nào cần cho rủi ro nào (xem hướng dẫn ISO 27001 risk assessment).
- Lấy danh sách 93 control Annex A làm khung.
- Với mỗi control, quyết định áp dụng hay loại trừ dựa trên phạm vi, rủi ro, yêu cầu pháp lý và hợp đồng, không dựa trên độ khó.
- Với control áp dụng, ghi tình trạng triển khai và tài liệu, bằng chứng tham chiếu.
- Rà toàn bộ với người hiểu cả kỹ thuật lẫn nghiệp vụ.
- Phê duyệt chính thức, gắn số phiên bản và lịch review.
Thời gian lập SoA phụ thuộc chủ yếu vào việc risk register và policy đã hoàn chỉnh chưa; nếu chưa, hãy bắt đầu bằng gap analysis ISO 27001.
Nên quản lý SoA bằng spreadsheet hay phần mềm?
Về mặt tiêu chuẩn, SoA có thể là một file Excel. Khó khăn thực tế nằm ở việc giữ SoA khớp với register và bằng chứng: khi auditor hỏi "cho xem bằng chứng control 8.15", việc tìm đúng file trong nhiều thư mục mất thời gian.
Trong pTrackly, framework ISO 27001:2022 có sẵn control, policy template và evidence task, trong đó có một evidence task riêng cho Statement of Applicability để SoA được giao owner và review theo lịch như các bằng chứng khác. Control dùng chung giữa các framework, và treatment action trong risk register ghi được control reference như "ISO 27001 A.5.17". Quyết định áp dụng hay loại trừ, lý do trong SoA và việc phê duyệt vẫn do đội ngũ của bạn thực hiện; tổ chức chứng nhận là bên đánh giá. Xem giải pháp ISO 27001 của pTrackly.
Câu hỏi thường gặp
SoA có phải liệt kê đủ 93 control Annex A không?
Có, trên thực tế. Clause 6.1.3 d yêu cầu nêu lý do loại trừ cho mọi control Annex A không áp dụng, nên SoA phải đề cập cả 93 control, kèm control bổ sung ngoài Annex A nếu có.
Có thể loại trừ toàn bộ nhóm control vật lý không?
Hiếm khi. Doanh nghiệp không có văn phòng trong phạm vi có thể loại trừ một số control khu vực an toàn, nhưng clear desk, clear screen (7.7), tài sản mang ra ngoài (7.9) và tiêu hủy thiết bị (7.14) thường vẫn áp dụng cho thiết bị của nhân viên.
Control "áp dụng nhưng chưa triển khai" có được không?
Được, nếu đó là tình trạng thật và có kế hoạch xử lý rủi ro kèm hạn chót. Tuy nhiên control cần thiết cho rủi ro cao mà chưa triển khai khi audit Stage 2 có thể dẫn đến nonconformity.
Bao lâu phải cập nhật SoA?
Mỗi khi phạm vi ISMS, kết quả đánh giá rủi ro hoặc control thay đổi, và ít nhất mỗi lần review rủi ro định kỳ. Mỗi lần cập nhật cần phiên bản và phê duyệt mới.
Tài liệu tham khảo:
- ISO/IEC 27001:2022, Information security management systems (iso.org/standard/82875.html)
- ISO/IEC 27002:2022, Information security controls (iso.org/standard/75652.html)
