Tóm tắt
ISO 27001 Clause 6.1.2 yêu cầu phương pháp risk assessment lặp lại được. Bài này giải thích yêu cầu, cách xây risk register và các cách tiếp cận thực tế.
ISO 27001 risk assessment là quy trình đánh giá rủi ro được định nghĩa và lặp lại được mà clause 6.1.2 của ISO/IEC 27001:2022 yêu cầu, gồm nhận diện, phân tích và đánh giá rủi ro bảo mật thông tin. Kết quả là risk register có owner và mức rủi ro, làm đầu vào cho xử lý rủi ro (clause 6.1.3), từ đó quyết định control Annex A nào được áp dụng và ghi vào Statement of Applicability.
Vì sao ISO 27001 bắt đầu từ rủi ro?
ISO/IEC 27001 là tiêu chuẩn dựa trên rủi ro: tiêu chuẩn không đưa sẵn một danh sách control cố định mà yêu cầu doanh nghiệp chọn control để xử lý rủi ro của chính mình. Ngược lại, PCI DSS quy định sẵn yêu cầu cho mọi môi trường lưu trữ, xử lý hoặc truyền dữ liệu thẻ.
Vì vậy risk assessment là "bộ não" ra quyết định của ISMS. Nếu đánh giá chung chung ("có thể bị hack"), control chọn ra cũng chung chung, và auditor của tổ chức chứng nhận sẽ hỏi vì sao chọn hoặc loại trừ một control cụ thể.
Clause 6.1.2 yêu cầu gì?
Clause 6.1.2 yêu cầu doanh nghiệp định nghĩa và áp dụng một quy trình đánh giá rủi ro, đồng thời lưu thông tin dạng văn bản về quy trình đó. Quy trình phải:
- thiết lập tiêu chí, gồm tiêu chí chấp nhận rủi ro và tiêu chí thực hiện đánh giá;
- cho kết quả nhất quán, hợp lệ và so sánh được khi lặp lại;
- nhận diện rủi ro liên quan đến mất tính bảo mật, toàn vẹn và sẵn sàng trong phạm vi ISMS, và xác định risk owner cho từng rủi ro;
- phân tích rủi ro bằng cách đánh giá khả năng xảy ra thực tế và hậu quả tiềm ẩn, rồi xác định mức rủi ro;
- đánh giá rủi ro bằng cách so sánh kết quả với tiêu chí và ưu tiên rủi ro cần xử lý.
Tiêu chuẩn không bắt buộc phương pháp cụ thể. Doanh nghiệp tự chọn thang điểm và công thức, miễn là phương pháp được viết ra và người khác chạy lại vẫn cho kết quả so sánh được. Clause 8.2 tiếp đó yêu cầu thực hiện đánh giá rủi ro theo chu kỳ đã định và khi có thay đổi đáng kể, và lưu lại kết quả.
Risk assessment khác risk treatment thế nào?
Risk assessment (6.1.2) là phân tích: điều gì có thể xảy ra, ai chịu trách nhiệm, khả năng và mức độ nghiêm trọng ra sao. Risk treatment (6.1.3) là quyết định: làm gì với từng rủi ro vượt ngưỡng chấp nhận.
Clause 6.1.3 yêu cầu chọn phương án xử lý, xác định control cần thiết, đối chiếu với Annex A, lập Statement of Applicability, xây kế hoạch xử lý rủi ro, và lấy phê duyệt của risk owner cho kế hoạch cùng việc chấp nhận rủi ro còn lại. ISO/IEC 27001 không liệt kê các phương án xử lý; bộ phương án thường dùng, mô tả trong ISO/IEC 27005, là:
| Phương án | Thuật ngữ ISO/IEC 27005 | Ví dụ |
|---|---|---|
| Giảm thiểu (mitigate) | Risk modification | Bật MFA để giảm rủi ro chiếm đoạt tài khoản |
| Chấp nhận (accept) | Risk retention | Chấp nhận rủi ro tác động thấp trong thời hạn xác định, có owner ký duyệt |
| Chuyển giao (transfer) | Risk sharing | Chuyển việc xử lý thẻ cho nhà cung cấp thanh toán; mua bảo hiểm an ninh mạng |
| Tránh (avoid) | Risk avoidance | Ngừng lưu loại dữ liệu không cần thiết |
Risk register cần những trường nào?
Tiêu chuẩn không quy định mẫu, nhưng để đáp ứng 6.1.2 và 6.1.3, mỗi rủi ro cần thể hiện đủ năm bước: nhận diện, owner, phân tích, đánh giá và xử lý. Tối thiểu gồm: tài sản hoặc kịch bản, mối đe dọa và lỗ hổng, risk owner, khả năng xảy ra và hậu quả, mức rủi ro, phương án và hành động xử lý, control Annex A liên quan, rủi ro còn lại và ngày review gần nhất, kế tiếp.
Cách thiết kế từng cột, ví dụ dòng mẫu và lỗi hay gặp khi duy trì register được trình bày riêng trong hướng dẫn ISO 27001 risk register.
Nên chọn cách tính điểm rủi ro nào?
Phần lớn doanh nghiệp làm ISO 27001 lần đầu dùng ma trận định tính: khả năng xảy ra và mức tác động mỗi thứ chấm từ 1 đến 5, mức rủi ro bằng khả năng × tác động, cho thang từ 1 đến 25. Doanh nghiệp đặt ngưỡng chấp nhận trong tiêu chí, ví dụ "rủi ro từ 10 điểm trở lên phải xử lý", và định nghĩa rõ ý nghĩa từng mức để hai người chấm cùng một kịch bản ra cùng một điểm.
ISO/IEC 27005:2022 mô tả hai cách nhận diện rủi ro: theo sự kiện (event-based) và theo tài sản (asset-based). Cách theo sự kiện bắt đầu từ kịch bản ("nhân viên đã nghỉ vẫn còn quyền vào production"); cách theo tài sản bắt đầu từ danh mục tài sản và hỏi điều gì có thể ảnh hưởng đến từng tài sản. Doanh nghiệp nhỏ thường thấy cách theo sự kiện nhanh và cụ thể hơn, rồi đối chiếu lại với asset inventory để không bỏ sót.
Đánh giá rủi ro cần bao phủ những vùng nào?
Bao phủ toàn bộ phạm vi ISMS, dùng bốn nhóm control Annex A làm danh sách kiểm tra:
- Tổ chức: phụ thuộc nhà cung cấp và cloud, lỗ hổng trong xử lý sự cố, vai trò không rõ, nghĩa vụ pháp lý và hợp đồng.
- Con người: lạm dụng nội bộ, nhận thức bảo mật thấp, social engineering, tài khoản không bị thu hồi khi nghỉ việc.
- Vật lý: ra vào văn phòng, mất hoặc bị trộm laptop, tiêu hủy thiết bị.
- Công nghệ: cấu hình cloud sai, hệ thống chưa vá, xác thực yếu, thiếu mã hóa hoặc log, code không an toàn.
Viết mỗi rủi ro thành một kịch bản cụ thể gắn với tài sản hoặc quy trình. Rủi ro cụ thể dẫn đến control cụ thể; rủi ro mơ hồ dẫn đến control mơ hồ mà auditor sẽ chất vấn. Nếu chưa rõ điểm xuất phát, gap analysis ISO 27001 giúp xác định phạm vi trước.
Khi nào phải đánh giá lại rủi ro?
Theo chu kỳ doanh nghiệp đã định (thường ít nhất mỗi năm) và mỗi khi có thay đổi đáng kể được đề xuất hoặc xảy ra, như clause 8.2 yêu cầu. Các tình huống thường kích hoạt đánh giá lại:
- triển khai hạ tầng cloud mới hoặc region mới;
- tính năng sản phẩm mới xử lý dữ liệu nhạy cảm hoặc dữ liệu cá nhân;
- thay đổi nhà cung cấp quan trọng;
- sự cố bảo mật hoặc suýt xảy ra sự cố;
- thay đổi tổ chức như sáp nhập hoặc tuyển dụng lớn;
- vào thị trường có yêu cầu pháp lý khác.
Surveillance audit năm thứ hai và thứ ba của chu kỳ chứng chỉ sẽ tìm một bản đánh giá phản ánh vận hành hiện tại.
Risk assessment liên kết với Annex A và SoA thế nào?
Quyết định xử lý rủi ro xác định control cần thiết; doanh nghiệp đối chiếu danh sách đó với 93 control Annex A và ghi kết quả vào Statement of Applicability. Mọi control Annex A đều xuất hiện trong SoA dưới dạng áp dụng hoặc loại trừ, kèm lý do, và control được áp dụng phải truy ngược được về rủi ro đã xử lý hoặc yêu cầu khác như hợp đồng, pháp luật. Chi tiết từng nhóm control xem tại hướng dẫn ISO 27001 Annex A.
Auditor kiểm tra gì trong risk assessment?
- Phương pháp được văn bản hóa, lặp lại được, có tiêu chí chấp nhận.
- Owner có tên cho mọi rủi ro.
- Quyết định xử lý có lý do, gồm cả việc chấp nhận rủi ro còn lại có chữ ký owner.
- Risk register và SoA nhất quán với nhau.
- Bằng chứng review theo chu kỳ và sau thay đổi đáng kể.
Finding phổ biến nhất khi chứng nhận lần đầu là register quá chung chung. Hãy để internal audit ISO 27001 kiểm tra năm điểm này trước khi tổ chức chứng nhận làm.
pTrackly hỗ trợ risk assessment ISO 27001 thế nào?
Risk register trong pTrackly chấm mỗi rủi ro theo khả năng × tác động trên thang 1–5, ghi rủi ro inherent và residual, mối đe dọa và lỗ hổng, risk owner và tài sản liên quan. Với mỗi rủi ro, doanh nghiệp chọn Mitigate, Accept, Transfer hoặc Avoid; treatment action có owner, hạn chót, control reference như "ISO 27001 A.5.17" và tham chiếu bằng chứng, rồi owner hoặc admin xác minh. Rủi ro được chấp nhận cần lý do và ngày hết hạn chấp nhận, và mỗi rủi ro có ngày review gần nhất, kế tiếp. Việc định nghĩa phương pháp và tiêu chí, nhận diện rủi ro và ra quyết định xử lý vẫn thuộc về đội ngũ của bạn. Xem giải pháp ISO 27001 của pTrackly.
Câu hỏi thường gặp
ISO 27001 có bắt buộc một phương pháp đánh giá rủi ro cụ thể không?
Không. Clause 6.1.2 yêu cầu một quy trình được định nghĩa, có tiêu chí, cho kết quả nhất quán, hợp lệ và so sánh được. Ma trận khả năng và tác động 1–5 đơn giản vẫn được chấp nhận nếu được văn bản hóa và áp dụng nhất quán.
ISO/IEC 27005 có bắt buộc khi làm ISO 27001 không?
Không. ISO/IEC 27005 là tiêu chuẩn hướng dẫn quản lý rủi ro bảo mật thông tin. Doanh nghiệp chỉ được đánh giá theo ISO/IEC 27001, dù làm theo 27005 giúp phương pháp dễ bảo vệ hơn khi audit.
Bao lâu phải cập nhật risk assessment ISO 27001?
Theo chu kỳ doanh nghiệp tự định, phổ biến là mỗi năm, và mỗi khi có thay đổi đáng kể được đề xuất hoặc xảy ra, như clause 8.2 yêu cầu. Lưu kết quả có ngày tháng làm thông tin dạng văn bản.
Ai nên là risk owner?
Người có trách nhiệm và thẩm quyền quản lý rủi ro đó, thường là trưởng bộ phận hoặc owner của hệ thống bị ảnh hưởng, không mặc định là đội security. Risk owner phê duyệt kế hoạch xử lý và chấp nhận rủi ro còn lại.
Tài liệu tham khảo:
- ISO/IEC 27001:2022, Information security management systems (iso.org/standard/82875.html)
- ISO/IEC 27005:2022, Guidance on managing information security risks (iso.org/standard/80585.html)
