Statement of Applicability (SoA) là tài liệu bắt buộc theo ISO 27001 Clause 6.1.3(d). Không có SoA, tổ chức không thể qua Stage 2 audit. Đây cũng là một trong những tài liệu auditor xem xét kỹ nhất vì nó thể hiện tổ chức hiểu rủi ro của mình đến đâu.
Bài này giải thích SoA là gì, cần có những gì, và những lỗi phổ biến khiến auditor reject.
SoA là gì và tại sao bắt buộc
SoA là bảng liệt kê tất cả 93 controls trong Annex A của ISO 27001:2022, kèm theo:
- Tổ chức có áp dụng control đó không (applicable / not applicable)
- Nếu applicable: control đã được triển khai chưa (implemented / not implemented)
- Lý do áp dụng hoặc loại trừ
- Tham chiếu đến policy hoặc procedure thực hiện control đó
SoA bắt buộc vì nó chứng minh tổ chức đã xem xét toàn bộ control framework, không chỉ chọn các controls dễ thực hiện. Auditor dùng SoA để kiểm tra tính nhất quán giữa Risk Register, controls đã chọn, và bằng chứng triển khai.
Cấu trúc một SoA chuẩn
Mỗi hàng trong SoA thường có các cột sau:
| Control ID | Tên control | Áp dụng | Lý do áp dụng / loại trừ | Trạng thái | Tài liệu liên quan |
|---|---|---|---|---|---|
| 5.1 | Policies for information security | Có | Yêu cầu cơ bản của ISMS | Đã triển khai | Information Security Policy v2.1 |
| 7.4 | Physical security monitoring | Không | Công ty làm việc remote 100%, không có văn phòng vật lý | , | , |
93 controls Annex A và cách phân loại
ISO 27001:2022 có 93 controls chia thành 4 nhóm. Hiểu cấu trúc này giúp đánh giá nhanh controls nào thường applicable với công ty phần mềm.
Organizational controls (5.1–5.37, 37 controls)
Bao gồm: chính sách bảo mật, phân công vai trò, liên hệ với cơ quan chức năng, quản lý nhà cung cấp, business continuity, xử lý sự cố.
Hầu hết các controls này applicable với mọi tổ chức. Công ty phần mềm hiếm khi loại trừ nhóm này.
People controls (6.1–6.8, 8 controls)
Bao gồm: screening tuyển dụng, điều khoản hợp đồng, đào tạo bảo mật, quy trình offboarding, remote working.
Thường applicable toàn bộ. Nếu công ty không tuyển nhân sự từ bên ngoài (ví dụ: chỉ có founder), một số controls có thể được điều chỉnh nhưng hiếm khi loại trừ hoàn toàn.
Physical controls (7.1–7.14, 14 controls)
Bao gồm: kiểm soát ra vào văn phòng, bảo vệ thiết bị, xử lý phương tiện lưu trữ, bảo mật nơi làm việc từ xa.
Đây là nhóm duy nhất có thể loại trừ nhiều controls nếu tổ chức làm việc remote hoàn toàn. Ví dụ: control 7.2 (Physical entry) không applicable nếu không có văn phòng cố định.
Technological controls (8.1–8.34, 34 controls)
Bao gồm: quản lý endpoint, quản lý quyền truy cập, mã hóa, logging, vulnerability scanning, secure development, backup.
Hầu hết applicable với công ty phần mềm. Đây là nhóm tốn nhiều effort triển khai nhất nhưng cũng là nhóm auditor kiểm tra kỹ nhất.
Lý do loại trừ phải đủ thuyết phục
Mỗi control "not applicable" cần lý do rõ ràng. Auditor sẽ không chấp nhận:
- "Không liên quan", quá chung chung
- "Chưa triển khai", đây là lý do để ghi "not implemented", không phải để loại trừ
- Bỏ trống, thiếu giải thích
Lý do loại trừ được chấp nhận:
- "Tổ chức làm việc remote 100%, không có cơ sở vật lý cố định" → loại trừ các controls vật lý liên quan đến văn phòng
- "Tổ chức không xử lý payment card data" → loại trừ controls liên quan đến PCI nếu có
- "Tổ chức không vận hành manufacturing hoặc industrial control systems" → loại trừ controls liên quan đến OT/ICS
Liên kết SoA với Risk Register
SoA không tồn tại độc lập. Auditor sẽ kiểm tra tính nhất quán theo hai chiều:
Chiều 1: Rủi ro → Control. Mỗi rủi ro trong Risk Register được xử lý bằng controls. Controls đó phải xuất hiện trong SoA với trạng thái "applicable" và "implemented".
Chiều 2: Control → Evidence. Mỗi control ghi "implemented" trong SoA phải có bằng chứng thực tế. Không có bằng chứng = control chưa được triển khai thực sự.
Ví dụ không nhất quán mà auditor sẽ phát hiện:
- Risk Register ghi rủi ro "unauthorized access to production" với control 8.2 (Privileged access rights), nhưng SoA ghi control 8.2 là "not applicable", mâu thuẫn
- SoA ghi control 8.15 (Logging) là "implemented", nhưng không có bằng chứng log được thu thập và review, tuyên bố không có cơ sở
Những lỗi phổ biến trong SoA
Ghi tất cả controls là "applicable" để an toàn. Auditor sẽ hỏi bằng chứng cho mọi control bạn ghi "implemented". Nếu bạn ghi 93/93 controls applicable, bạn cần 93 bộ bằng chứng tương ứng.
Không ghi tài liệu liên quan. "Policy" mà không có tên tài liệu cụ thể không giúp auditor verify được.
SoA không được phê duyệt chính thức. SoA phải có chữ ký (hoặc approval record trong hệ thống) của người có thẩm quyền, thường là CISO hoặc CEO. Một spreadsheet không có approval không phải là "documented information" theo định nghĩa của ISO.
Phiên bản SoA không được kiểm soát. Nếu SoA có nhiều phiên bản và không rõ phiên bản nào là hiện hành, auditor sẽ đặt câu hỏi về document control của toàn bộ ISMS.
SoA không được cập nhật khi có thay đổi. Khi tổ chức triển khai thêm controls hoặc thay đổi scope, SoA phải được cập nhật. SoA không thay đổi trong 2 năm sẽ bị xem là không phản ánh thực tế.
Quy trình tạo SoA thực tế
Không nên viết SoA từ đầu. Quy trình hợp lý:
- Hoàn thành Risk Register trước, biết được rủi ro nào cần xử lý và controls nào được chọn
- Lấy danh sách 93 controls Annex A làm khung
- Với mỗi control: xác định applicable/not applicable dựa trên scope và rủi ro, không phải dựa trên khả năng triển khai
- Với controls applicable: ghi trạng thái (implemented / not implemented) và tài liệu liên quan
- Review 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 và gắn version number
Thời gian thực tế: 1-2 tuần cho công ty 20-50 người nếu Risk Register đã hoàn chỉnh. Lâu hơn nếu phải đồng thời xây policies chưa có.
SoA bằng spreadsheet hay phần mềm
Về kỹ thuật, SoA có thể là Excel. Thực tế, vấn đề với spreadsheet ở SoA tương tự Risk Register: không có audit trail, không liên kết trực tiếp với evidence, và không nhắc nhở review khi có thay đổi.
Khi auditor yêu cầu "show me the evidence for control 8.15 (Logging)", việc tìm đúng bằng chứng trong hàng trăm file trải rải khắp Google Drive mất thời gian đáng kể. Nền tảng GRC liên kết SoA với control library và evidence collection, khi bạn đánh dấu "implemented", hệ thống tự động nhắc nhở cập nhật bằng chứng.
pTrackly có SoA template cho ISO 27001:2022 với 93 controls đã được mapping sẵn vào Risk Register và evidence library. Đặt demo để xem workflow đầy đủ từ Risk Register đến SoA đến audit-ready evidence.