Tuyên Bố Áp Dụng (SoA) Trong ISO 27001 Gồm Những Gì?

Tuyên bố áp dụng — Statement of Applicability, viết tắt SoA — là tài liệu bắt buộc của ISO/IEC 27001 và là thứ đánh giá viên yêu cầu gần như đầu tiên. Bài viết trình bày SoA gồm những gì, cách lập cho đúng, và những mâu thuẫn khiến nó bị nêu điểm không phù hợp.

SoA là gì và vì sao bắt buộc

SoA là bảng đối chiếu giữa 93 biện pháp kiểm soát trong Phụ lục A của ISO/IEC 27001:2022 với thực tế tổ chức. Với mỗi biện pháp, tài liệu phải nêu rõ ba điều:

Có áp dụng hay không.
Nếu áp dụng: đã triển khai như thế nào — dẫn tới quy trình, cấu hình hoặc hồ sơ cụ thể.
Nếu không áp dụng: lý do loại trừ.

Đây là tài liệu duy nhất cho phép người ngoài nhìn thấy toàn cảnh: tổ chức này bảo vệ thông tin bằng những gì, và những gì họ cố ý không làm cùng lý do. Vì vậy nó thường là tài liệu đầu tiên được yêu cầu — cả khi đánh giá chứng nhận lẫn khi khách hàng thẩm định nhà cung cấp.

SoA phải nhất quán với đánh giá rủi ro

Đây là điểm mấu chốt và cũng là nguồn gốc phần lớn điểm không phù hợp liên quan tới SoA.

SoA không phải là danh sách độc lập. Nó là đầu ra của quá trình xử lý rủi ro: tổ chức nhận diện rủi ro, chọn biện pháp xử lý, rồi đối chiếu Phụ lục A để kiểm tra không bỏ sót. Do đó:

Nếu đánh giá rủi ro chỉ ra một rủi ro đáng kể về kiểm soát truy cập, mà SoA lại loại trừ nhóm biện pháp tương ứng — đó là mâu thuẫn nội tại.
Ngược lại, ghi “áp dụng” cho một biện pháp mà không có bằng chứng vận hành cũng là điểm không phù hợp, thường nặng hơn vì nó là tuyên bố sai.

Loại trừ biện pháp: khi nào hợp lý

Loại trừ là bình thường và được phép — không tổ chức nào áp dụng đủ 93 biện pháp. Lý do loại trừ hợp lệ thường thuộc các nhóm:

Không có đối tượng áp dụng. Tổ chức không tự phát triển phần mềm thì các biện pháp về an toàn trong phát triển không áp dụng.
Nằm ngoài phạm vi ISMS. Biện pháp liên quan tới một bộ phận không nằm trong phạm vi đã khai báo.
Rủi ro tương ứng đã được đánh giá là chấp nhận được theo tiêu chí đã đặt ra.
Đã xử lý bằng biện pháp khác đạt mục tiêu tương đương.

Lý do không hợp lệ: “chưa có thời gian”, “tốn kém”, “sẽ làm sau” — đó là rủi ro chưa xử lý, không phải loại trừ. Nếu thực sự chưa làm được, cách đúng là ghi vào kế hoạch xử lý rủi ro với thời hạn, không phải loại trừ trong SoA.

Cấu trúc một SoA dùng được

Tiêu chuẩn không quy định biểu mẫu. Một bảng thường có các cột:

Mã và tên biện pháp theo Phụ lục A (ví dụ 5.12 Phân loại thông tin).
Áp dụng / Không áp dụng.
Lý do — nếu áp dụng: rủi ro nào dẫn tới, hoặc yêu cầu pháp luật/hợp đồng nào. Nếu loại trừ: căn cứ loại trừ.
Cách triển khai — dẫn chiếu tới quy trình, chính sách, cấu hình cụ thể.
Trạng thái — đã triển khai, đang triển khai, hay có kế hoạch.
Người chịu trách nhiệm.

Cột “cách triển khai” là cột tạo ra giá trị thật. Một SoA chỉ có “Áp dụng / Có” ở 93 dòng không nói được gì và không giúp gì cho chính tổ chức.

Một số tổ chức bổ sung thêm cột nguồn gốc yêu cầu — phân biệt biện pháp đến từ đánh giá rủi ro, từ nghĩa vụ pháp luật, hay từ điều khoản hợp đồng với khách hàng. Cột này hữu ích khi rà soát: biện pháp đến từ hợp đồng sẽ phải xem lại khi hợp đồng đó kết thúc, còn biện pháp đến từ rủi ro thì không.

Về độ dài, SoA của một tổ chức nhỏ thường gọn trong vài trang bảng; của tổ chức lớn có thể vài chục trang do phải mô tả cách triển khai khác nhau ở nhiều đơn vị. Tiêu chuẩn không đặt ra giới hạn — thước đo là người đọc có hiểu được tổ chức bảo vệ thông tin bằng cách nào hay không.

SoA cho khách hàng xem — cân nhắc mức chi tiết

SoA thường được khách hàng doanh nghiệp yêu cầu khi thẩm định nhà cung cấp. Điều này đặt ra một cân nhắc thực tế: bản SoA đầy đủ có thể tiết lộ chính những chỗ tổ chức chưa bảo vệ.

Cách xử lý thông thường:

Bản nội bộ — đầy đủ chi tiết, dẫn chiếu tới quy trình, cấu hình, hệ thống cụ thể. Đây là bản dùng cho đánh giá chứng nhận.
Bản chia sẻ — giữ nguyên cột áp dụng/loại trừ và lý do ở mức khái quát, lược bỏ chi tiết kỹ thuật nhạy cảm như tên hệ thống, phiên bản phần mềm, sơ đồ mạng.

Hai bản phải nhất quán về nội dung — chỉ khác mức chi tiết. Một bản chia sẻ nói khác bản nội bộ là vấn đề nghiêm trọng hơn nhiều so với việc lộ thông tin kỹ thuật.

Lập SoA khi mới bắt đầu: thứ tự thực tế

Chốt phạm vi ISMS trước. Phạm vi quyết định biện pháp nào có đối tượng áp dụng.
Hoàn tất đánh giá rủi ro và chọn phương án xử lý.
Lập danh sách biện pháp cần thiết xuất phát từ rủi ro, chưa nhìn Phụ lục A.
Đối chiếu Phụ lục A — kiểm tra 93 biện pháp xem có cái nào cần mà mình chưa nghĩ tới.
Bổ sung yêu cầu pháp luật và hợp đồng — một số biện pháp phải áp dụng vì luật hoặc vì khách hàng yêu cầu, không phải vì rủi ro nội bộ.
Ghi trạng thái thật — đã triển khai, đang triển khai, có kế hoạch. Ghi “đã triển khai” cho thứ chưa làm là cách nhanh nhất để mất uy tín trong cuộc đánh giá.
Trình phê duyệt cùng kế hoạch xử lý rủi ro.

Kiểm soát phiên bản

SoA là tài liệu sống. Nó phải được cập nhật khi: phạm vi ISMS thay đổi; kết quả đánh giá rủi ro thay đổi; có biện pháp mới được triển khai; có yêu cầu pháp luật hoặc hợp đồng mới; hoặc sau đánh giá nội bộ và xem xét của lãnh đạo.

Vì vậy SoA cần số phiên bản, ngày ban hành và người phê duyệt rõ ràng. Đánh giá viên thường đối chiếu ngày của SoA với ngày của báo cáo đánh giá rủi ro — hai tài liệu lệch nhau quá xa là dấu hiệu một trong hai không được duy trì.

Năm mâu thuẫn khiến SoA bị nêu không phù hợp

Loại trừ một biện pháp mà rủi ro tương ứng lại được đánh giá ở mức cao. Mâu thuẫn trực tiếp giữa hai tài liệu bắt buộc.
Ghi “áp dụng” nhưng không có bằng chứng vận hành. Nặng hơn loại trừ sai, vì đây là tuyên bố không đúng sự thật.
Lý do loại trừ mang tính nguồn lực — “chưa đủ ngân sách”, “sẽ triển khai năm sau”. Đó là rủi ro chưa xử lý, phải nằm trong kế hoạch xử lý rủi ro chứ không phải cột loại trừ.
SoA cũ hơn phạm vi ISMS. Tổ chức mở rộng phạm vi sang một chi nhánh mới mà SoA vẫn giữ nguyên — nghĩa là các biện pháp chưa được xem xét cho phần mới.
Số lượng biện pháp không khớp với phiên bản tiêu chuẩn. SoA còn liệt kê 114 biện pháp theo cấu trúc bản 2013 trong khi tổ chức chứng nhận theo bản 2022 — dấu hiệu SoA chưa được chuyển đổi.

Ba câu hỏi thường gặp khi đánh giá

“Vì sao biện pháp này được loại trừ?” — câu trả lời phải dẫn về đánh giá rủi ro hoặc phạm vi, không phải về nguồn lực.
“Cho tôi xem bằng chứng của biện pháp này.” — chọn ngẫu nhiên vài dòng ghi “đã triển khai” và yêu cầu hồ sơ. Đây là lúc SoA sao chép từ mẫu bị lộ.
“SoA này phiên bản nào, ai phê duyệt?” — kiểm tra tính được duy trì.

Ai lập và ai phê duyệt

SoA thường do người phụ trách ISMS soạn, nhưng nội dung phải lấy từ nhiều nơi: bộ phận CNTT cho nhóm biện pháp công nghệ, nhân sự cho nhóm con người, hành chính cho nhóm vật lý, pháp chế cho phần tuân thủ.

Về phê duyệt, thực tế phổ biến là lãnh đạo cao nhất hoặc người được uỷ quyền ký ban hành, còn phần chấp nhận rủi ro còn lại thì do chủ sở hữu rủi ro ký — hai vai trò này có thể khác nhau. Đánh giá viên thường kiểm tra xem người ký có đúng thẩm quyền hay không, vì một SoA do nhân viên kỹ thuật tự ký không thể hiện được cam kết của lãnh đạo.

Quan hệ với các tài liệu khác

SoA nằm giữa quá trình đánh giá và xử lý rủi ro và bộ hồ sơ vận hành. Danh mục 93 biện pháp và cách chúng được nhóm lại được trình bày tại bài Phụ lục A của ISO/IEC 27001:2022; hướng dẫn triển khai từng biện pháp nằm ở ISO/IEC 27002:2022; toàn bộ bộ tài liệu ISMS xem tại bộ tài liệu ISO 27001.

Bước tiếp theo

Cách kiểm tra SoA của bạn có dùng được không: chọn ba biện pháp ghi “đã triển khai”, đi tìm bằng chứng vận hành của từng cái. Nếu tìm không ra, SoA đang mô tả một tổ chức khác.

Nếu doanh nghiệp bạn mới bắt đầu, đừng viết SoA trước — hãy hoàn tất đánh giá rủi ro rồi để SoA hình thành từ đó. SoA viết trước rồi mới đi tìm rủi ro cho khớp là thứ tự ngược, và mâu thuẫn giữa hai tài liệu gần như chắc chắn sẽ lộ ra khi đánh giá. Xem thêm quy trình chứng nhận ISO 27001.

🔗 Tin liên quan: ISMS là gì? Hệ thống quản lý an toàn thông tin trong ISO 27001

Hoa Linh

Chuyên Gia at Viện Nghiên Cứu Phát Triển Chứng Nhận Toàn Cầu – hoalinh@chungnhantoancau.vn – Web

Hoa Linh là chuyên gia tư vấn và triển khai hệ thống quản lý theo tiêu chuẩn quốc tế ISO với hơn 8 năm kinh nghiệm hỗ trợ doanh nghiệp Việt Nam đạt chứng nhận ISO 9001, ISO 14001, ISO 45001, ISO 22000, ISO 27001 và ISO 50001. Với nền tảng kiến thức chuyên sâu về quản lý chất lượng, quản lý môi trường, an toàn lao động và an toàn thông tin, Hoa Linh đã đồng hành cùng hàng trăm doanh nghiệp trong đa dạng lĩnh vực như sản xuất, thực phẩm, logistics, xây dựng, dịch vụ thương mại và công nghệ. Khả năng phân tích hệ thống hiện tại của doanh nghiệp, tư vấn các giải pháp cải tiến phù hợp, xây dựng tài liệu ISO chuyên nghiệp, đào tạo đội ngũ nhân sự, đánh giá nội bộ và hỗ trợ doanh nghiệp làm việc với tổ chức chứng nhận quốc tế.
Hiện tại, Hoa Linh là chuyên gia của Viện Nghiên Cứu Phát Triển Chứng Nhận Toàn Cầu (GCDRI) và trực tiếp tham gia tư vấn - đào tạo - hỗ trợ doanh nghiệp đạt chứng nhận ISO theo yêu cầu của khách hàng và đối tác quốc tế.