Statement of Applicability (SoA): Là Gì Và Cách Viết

Statement of Applicability (SoA) là gì?

Statement of Applicability, thường gọi tắt là SoA, là một tài liệu bắt buộc trong ISO 27001. Nó liệt kê toàn bộ các control thuộc Annex A, đồng thời ghi rõ lý do tổ chức quyết định áp dụng (include) hoặc không áp dụng (exclude) từng control, cùng với trạng thái triển khai thực tế. SoA không chỉ là danh sách tích/bỏ, đây là bằng chứng cho thấy tổ chức hiểu rõ phạm vi rủi ro của mình và đưa ra quyết định có căn cứ về cách bảo vệ thông tin.

Cấu trúc của một SoA chuẩn

Một SoA đầy đủ thường bao gồm các cột thông tin sau cho từng control trong Annex A:

• Control ID và tên: Ví dụ A.8.1, User Endpoint Devices
• Applicable (Có/Không): Control này có áp dụng cho tổ chức hay không
• Justification for inclusion/exclusion: Lý do bao gồm hoặc loại trừ, thường liên kết với kết quả risk assessment hoặc yêu cầu pháp lý
• Implementation status: Trạng thái triển khai, chưa bắt đầu, đang triển khai, hoàn thành, hay đã được audit
• Reference to policy/procedure: Dẫn chiếu đến tài liệu nội bộ liên quan

ISO 27001:2022 cập nhật Annex A từ 114 controls (phiên bản 2013) xuống còn 93 controls, tổ chức lại thành 4 nhóm chủ đề: Organizational, People, Physical, và Technological. Khi viết SoA, cần đảm bảo phiên bản Annex A đang dùng khớp với phiên bản tiêu chuẩn tổ chức đang chứng nhận.

Cách xác định include hay exclude một control

Quyết định include/exclude không phải tùy ý, nó phải xuất phát từ quá trình risk assessment và risk treatment. Quy trình thực tế thường như sau:

Bước 1, Kết nối với risk treatment plan: Mỗi risk được xác định trong quá trình assessment cần được map sang ít nhất một control trong Annex A. Nếu một control giúp giảm thiểu risk đã được xác định, nó gần như chắc chắn cần được include.

Bước 2, Xem xét yêu cầu bên ngoài: Một số controls có thể bắt buộc do yêu cầu pháp lý, hợp đồng với khách hàng, hoặc quy định ngành. Ví dụ, doanh nghiệp trong lĩnh vực tài chính tại Việt Nam có thể bị ràng buộc bởi các quy định của NHNN liên quan đến kiểm soát truy cập và mã hóa dữ liệu.

Bước 3, Viết justification rõ ràng: Lý do exclude một control cần được giải thích thuyết phục. "Không áp dụng vì không có nhà cung cấp bên ngoài" là lý do hợp lệ, nhưng cần đảm bảo điều này thực sự đúng với phạm vi ISMS đã xác định.

Bước 4, Review với các bên liên quan: SoA không nên chỉ do bộ phận IT hoặc compliance viết một mình. Các bộ phận vận hành, HR, pháp lý cần được tham vấn để đảm bảo không bỏ sót control quan trọng.

Những lỗi phổ biến khi viết SoA

Nhiều tổ chức gặp khó khăn trong lần đầu viết SoA vì một số nguyên nhân thường gặp:

Exclude control mà không có lý do rõ ràng: Auditor sẽ hỏi ngay nếu thấy một control quan trọng bị exclude mà justification chỉ ghi "không liên quan". Cần giải thích tại sao nó không liên quan trong ngữ cảnh cụ thể của tổ chức.

Khai implementation status không chính xác: Ghi "Completed" cho một control chưa thực sự được triển khai đầy đủ là rủi ro lớn khi audit. Nên dùng trạng thái trung gian như "Partially implemented" hoặc "In progress" để phản ánh thực tế.

Không cập nhật SoA sau khi có thay đổi: SoA là tài liệu sống, khi tổ chức thay đổi phạm vi ISMS, thêm hệ thống mới, hoặc hoàn thành triển khai một control, SoA cần được cập nhật tương ứng.

Tách rời SoA khỏi risk register: SoA và risk treatment plan phải nhất quán với nhau. Nếu risk register ghi nhận một rủi ro cụ thể nhưng SoA lại exclude control tương ứng mà không giải thích, đây là điểm yếu dễ bị chỉ ra trong audit.

Câu hỏi thường gặp

SoA có bắt buộc phải dùng format chuẩn không? Không, ISO 27001 không quy định format cụ thể. Tổ chức có thể dùng spreadsheet, tool quản lý compliance, hoặc tài liệu Word, miễn là đủ các thông tin cần thiết và dễ dàng kiểm soát phiên bản.

Có thể exclude toàn bộ một nhóm control không? Về mặt kỹ thuật là có thể, nhưng cần justification rất thuyết phục. Ví dụ, nếu ISMS không bao gồm bất kỳ cơ sở vật lý nào (toàn bộ hạ tầng trên cloud), nhóm Physical controls có thể được exclude một phần, nhưng vẫn cần review từng control riêng lẻ.

SoA có phải chia sẻ với khách hàng không? Không bắt buộc, nhưng một số khách hàng doanh nghiệp hoặc đối tác có thể yêu cầu xem SoA như một phần của vendor assessment. Tổ chức có thể cung cấp phiên bản rút gọn (chỉ gồm danh sách controls và trạng thái) thay vì toàn bộ tài liệu nội bộ.

Nếu bạn đang xây dựng ISMS và cần quản lý SoA cùng với risk register, evidence tracking và các tài liệu ISO 27001 khác trong cùng một nơi, pTrackly hỗ trợ các nhóm compliance tại Việt Nam làm điều đó mà không cần quản lý thủ công bằng spreadsheet.