Tóm tắt
Hướng dẫn xây ISO 27001 Risk Register từng bước: xác định tài sản, đánh giá rủi ro, chọn controls từ Annex A, và duy trì register sau khi được chứng nhận.
ISO 27001 risk register là hồ sơ lưu kết quả đánh giá và xử lý rủi ro mà clause 6.1.2, 6.1.3 và 8.2 của ISO/IEC 27001:2022 yêu cầu giữ dưới dạng thông tin văn bản. Mỗi dòng ghi một rủi ro cụ thể, owner, mức rủi ro trước và sau xử lý, quyết định xử lý và control liên quan. Auditor xem register ở cả Stage 1, Stage 2 và mọi kỳ surveillance.
Risk register trong ISO 27001 là gì và vì sao quan trọng?
Risk register là nơi kết quả risk assessment trở thành danh sách việc cần làm. Tiêu chuẩn không bắt buộc tên gọi hay mẫu cụ thể, nhưng yêu cầu lưu kết quả đánh giá rủi ro (8.2) và kết quả xử lý rủi ro (8.3), và yêu cầu kế hoạch xử lý được risk owner phê duyệt (6.1.3). Phần lớn doanh nghiệp gom tất cả vào một register.
Register cũng là điểm nối giữa rủi ro và Statement of Applicability: control nào được đưa vào SoA phải truy ngược được về rủi ro trong register hoặc về yêu cầu pháp lý, hợp đồng. Nếu register không phản ánh rủi ro thật, SoA và toàn bộ control phía sau cũng không đứng vững. Phương pháp đánh giá (tiêu chí, thang điểm, cách lặp lại) được trình bày trong hướng dẫn ISO 27001 risk assessment; bài này tập trung vào cách dựng và duy trì register.
Risk register cần những cột nào?
Không có format bắt buộc; auditor đánh giá nội dung. Bộ cột dưới đây đủ để chứng minh từng yêu cầu của clause 6.1.2, 6.1.3 và 8.2.
| Cột | Nội dung | Yêu cầu liên quan |
|---|---|---|
| Mã và tên rủi ro | Mô tả ngắn, cụ thể | 6.1.2 c (nhận diện) |
| Tài sản hoặc quy trình | Đối tượng bị ảnh hưởng trong phạm vi ISMS | 6.1.2 c |
| Mối đe dọa, điểm yếu | Điều gì có thể xảy ra và vì sao | 6.1.2 c |
| Risk owner | Người có thẩm quyền quản lý rủi ro | 6.1.2 c |
| Khả năng, tác động, mức rủi ro (inherent) | Theo thang điểm trong phương pháp | 6.1.2 d, e |
| Phương án xử lý | Giảm thiểu, chấp nhận, chuyển giao, tránh | 6.1.3 a |
| Control và hành động | Control Annex A hoặc control bổ sung, owner, hạn chót | 6.1.3 b, c, e |
| Rủi ro còn lại (residual) | Mức sau khi control vận hành, kèm phê duyệt của owner | 6.1.3 f |
| Ngày review gần nhất, kế tiếp | Bằng chứng đánh giá lại theo chu kỳ | 8.2 |
Xây risk register ISO 27001 theo những bước nào?
- Chốt phạm vi. Register chỉ bao gồm hệ thống, dữ liệu, con người và bên thứ ba trong phạm vi ISMS đã định nghĩa ở clause 4.3. Phạm vi quá rộng làm register không quản lý được; quá hẹp thì bỏ sót rủi ro thật.
- Lập danh mục tài sản. Control 5.9 yêu cầu danh mục thông tin và tài sản liên quan; dùng nó làm khung để không bỏ sót (xem hướng dẫn ISO 27001 asset inventory). Nhóm tài sản theo loại và mức quan trọng, không cần liệt kê từng laptop.
- Viết rủi ro thành kịch bản. Mỗi rủi ro là tổ hợp tài sản + mối đe dọa + điểm yếu, viết đủ cụ thể để chọn được control.
- Chấm điểm theo thang và định nghĩa trong phương pháp đã duyệt.
- Chọn phương án xử lý và hành động cho mọi rủi ro vượt ngưỡng chấp nhận.
- Gắn control từ Annex A hoặc control bổ sung, rồi cập nhật Statement of Applicability.
- Chấm lại rủi ro còn lại và lấy phê duyệt của risk owner.
Ví dụ một risk register cho công ty phần mềm trông thế nào?
Bảng dưới là ví dụ minh họa, không phải mẫu áp dụng nguyên xi; điểm số phụ thuộc thang điểm và bối cảnh của từng doanh nghiệp.
| Tài sản | Mối đe dọa / điểm yếu | Rủi ro | Control Annex A | Hành động ví dụ |
|---|---|---|---|---|
| Source code repository | Nhân viên đã nghỉ / không review quyền định kỳ | Người cũ vẫn truy cập được code | 5.18 Access rights, 8.4 Access to source code | Thu hồi quyền trong quy trình offboarding, access review hằng quý |
| Database production | SQL injection / thiếu kiểm tra đầu vào | Lộ dữ liệu khách hàng | 8.28 Secure coding, 8.29 Security testing | Chuẩn secure coding, kiểm thử bảo mật trước release |
| Laptop developer | Mất, bị trộm / ổ đĩa không mã hóa | Lộ code và credential | 8.1 User endpoint devices, 8.24 Use of cryptography | Bắt buộc FileVault hoặc BitLocker, quản lý thiết bị |
| API key trong code | Rò rỉ credential / key hardcode trong repository | Key lộ qua lịch sử git | 5.17 Authentication information, 8.28 Secure coding | Quét secret trước khi merge, lưu key trong secret manager |
| Backup | Ransomware / chưa từng thử khôi phục | Không khôi phục được sau sự cố | 8.13 Information backup | Lịch thử khôi phục định kỳ có biên bản |
Cách chọn và loại trừ control cho cả 93 control xem tại hướng dẫn ISO 27001 Annex A.
Nên chấm điểm rủi ro trong register thế nào?
ISO 27001 không quy định cách tính điểm, nhưng cách chấm phải nhất quán và giải thích được. Cách phổ biến nhất là khả năng × tác động, mỗi trục từ 1 đến 5, cho mức rủi ro từ 1 đến 25, rồi chia thành các mức như thấp, trung bình, cao, nghiêm trọng theo ngưỡng doanh nghiệp tự đặt.
Điều quan trọng là định nghĩa từng mức trong tài liệu phương pháp. "Khả năng 3" nên có mô tả cụ thể, ví dụ "có thể xảy ra trong 12 tháng tới", thay vì chỉ ghi "trung bình". Nếu mọi rủi ro trong register đều rơi vào cùng một mức, nhiều khả năng định nghĩa thang điểm chưa đủ rõ.
Ai làm risk owner và ai phê duyệt rủi ro còn lại?
Risk owner là 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: CTO hay Head of Engineering cho rủi ro kỹ thuật, COO cho rủi ro vận hành. Clause 6.1.3 yêu cầu risk owner phê duyệt kế hoạch xử lý và chấp nhận rủi ro còn lại, nên register cần lưu ai phê duyệt và khi nào.
Duy trì risk register sau khi được chứng nhận thế nào?
Clause 8.2 yêu cầu đánh giá rủi ro theo chu kỳ đã định và khi có thay đổi đáng kể. Phần lớn doanh nghiệp review register ít nhất mỗi năm, cộng thêm khi:
- ra sản phẩm hoặc tính năng mới xử lý dữ liệu nhạy cảm;
- thay đổi hạ tầng như chuyển cloud, thêm nhà cung cấp quan trọng;
- xảy ra sự cố bảo mật;
- thay đổi nhân sự chủ chốt;
- quy định pháp lý thay đổi.
Mỗi lần review cần để lại bằng chứng: ngày, người review và kết quả (không đổi, cập nhật rủi ro nào, thêm rủi ro nào). Lịch duy trì tổng thể xem tại duy trì ISO 27001 sau chứng nhận.
Những lỗi phổ biến khi xây risk register?
- Chép template từ internet mà không điều chỉnh; auditor nhận ra ngay vì rủi ro không khớp môi trường thật.
- Mọi rủi ro đều "trung bình", dấu hiệu thang điểm chưa được định nghĩa rõ.
- Không có risk owner, nên rủi ro không ai theo dõi.
- Register tách rời thực tế: control ghi trong register nhưng không có bằng chứng vận hành.
- Không cập nhật sau thay đổi: register 18 tháng không review là điểm trừ lớn ở surveillance audit.
Nên dùng spreadsheet hay phần mềm?
Spreadsheet là đủ về mặt tiêu chuẩn; không có yêu cầu dùng phần mềm chuyên dụng. Khó khăn thường xuất hiện ở giai đoạn duy trì: chứng minh review đúng lịch, theo dõi treatment action đã xong chưa, và liên kết từng control với bằng chứng của nó.
pTrackly có risk register chấm điểm khả năng × tác động trên thang 1–5, ghi rủi ro inherent và residual (residual do người dùng tự đặt, không tự tính), mối đe dọa, lỗ hổng, risk owner và tài sản liên quan từ asset inventory. Treatment action có owner, hạn chót, control reference như "ISO 27001 A.5.17" và tham chiếu bằng chứng, được 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, và mỗi rủi ro có ngày review gần nhất, kế tiếp. Nhận diện rủi ro, chấm điểm và quyết định xử lý vẫn là việc của đội ngũ bạn. Xem giải pháp ISO 27001 của pTrackly.
Câu hỏi thường gặp
Risk register có phải tài liệu bắt buộc của ISO 27001 không?
Tiêu chuẩn không bắt buộc tên gọi "risk register", nhưng bắt buộc lưu thông tin dạng văn bản về quy trình đánh giá rủi ro, kết quả đánh giá và kết quả xử lý rủi ro. Register là cách phổ biến nhất để đáp ứng các yêu cầu đó.
Risk register và Statement of Applicability khác nhau thế nào?
Risk register liệt kê rủi ro, mức độ và cách xử lý. Statement of Applicability liệt kê đủ 93 control Annex A, cho biết control nào áp dụng, lý do và trạng thái triển khai. Hai tài liệu phải khớp nhau: control áp dụng nên truy ngược được về rủi ro hoặc yêu cầu khác.
Bao lâu phải review risk register một lần?
Theo chu kỳ doanh nghiệp đã định trong phương pháp, phổ biến là mỗi năm, và mỗi khi có thay đổi đáng kể, như clause 8.2 yêu cầu. Mỗi lần review cần có ngày, người thực hiện và kết quả.
Một rủi ro có thể gắn với nhiều control không?
Có, và thường là vậy. Ví dụ rủi ro lộ dữ liệu từ laptop bị mất liên quan đến 8.1 thiết bị đầu cuối, 8.24 mã hóa và 6.8 báo cáo sự cố. Ngược lại một control cũng có thể xử lý nhiều rủi ro.
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)
