Risk Register là tài liệu trung tâm của mọi chương trình ISO 27001. Auditor sẽ xem xét nó ở cả Stage 1 và Stage 2. Nếu Risk Register không phản ánh rủi ro thực tế của tổ chức, toàn bộ ISMS xây trên nó đều có vấn đề.
Bài này hướng dẫn cách xây Risk Register đúng chuẩn ISO 27001:2022, không phải copy template từ internet rồi điền tên công ty vào.
Risk Register là gì trong ISO 27001
ISO 27001 yêu cầu tổ chức thực hiện quy trình đánh giá rủi ro (risk assessment) theo Clause 6.1.2 và lưu giữ kết quả dưới dạng "documented information". Risk Register là tài liệu lưu kết quả đó.
Cụ thể, Risk Register cần ghi lại:
- Rủi ro đã xác định (với tài sản, mối đe dọa, điểm yếu liên quan)
- Mức độ rủi ro trước khi xử lý (inherent risk)
- Quyết định xử lý rủi ro (treat, tolerate, transfer, terminate)
- Controls đã chọn từ Annex A (hoặc controls bổ sung)
- Mức độ rủi ro sau khi xử lý (residual risk)
- Người chịu trách nhiệm (risk owner)
- Trạng thái triển khai control
Không có format bắt buộc. Auditor sẽ đánh giá theo nội dung, không phải theo format.
Bước 1: Xác định phạm vi đánh giá rủi ro
Trước khi liệt kê rủi ro, cần biết đánh giá rủi ro cho cái gì. Phạm vi này phải nhất quán với ISMS scope đã định nghĩa trong Clause 4.3.
Ví dụ: nếu ISMS scope là "hệ thống phát triển phần mềm và vận hành dịch vụ cloud cho khách hàng B2B", thì risk assessment chỉ bao gồm:
- Các hệ thống, dịch vụ, và dữ liệu trong scope đó
- Con người làm việc với hệ thống đó
- Bên thứ ba có quyền truy cập vào scope đó
Nhiều tổ chức mắc lỗi ở bước này: hoặc scope quá rộng (toàn bộ công ty) khiến risk register không quản lý được, hoặc quá hẹp đến mức bỏ sót rủi ro thực tế.
Bước 2: Xác định tài sản thông tin
ISO 27001:2022 không yêu cầu danh sách tài sản riêng biệt bắt buộc, nhưng hầu hết tổ chức xây asset inventory trước rồi mới đánh giá rủi ro theo từng tài sản. Annex A Control 5.9 (Information and other associated assets) đề cập đến điều này.
Các loại tài sản thường gặp trong công ty phần mềm:
Dữ liệu: source code, dữ liệu khách hàng, credentials/API keys, log files, backup data, hợp đồng và tài liệu pháp lý.
Hệ thống: production servers, CI/CD pipeline, database servers, development environments, endpoint devices (laptop của developer).
Dịch vụ: cloud providers (AWS/GCP/Azure), SaaS tools (GitHub, Jira, Slack, Google Workspace), thư điện tử.
Con người: developer, DevOps, customer support, bên thứ ba có quyền truy cập.
Không cần liệt kê từng laptop riêng lẻ. Nhóm theo loại và mức độ quan trọng là đủ.
Bước 3: Xác định rủi ro cho từng tài sản
Với mỗi tài sản, xác định tổ hợp: mối đe dọa (threat) + điểm yếu (vulnerability) = rủi ro.
Ví dụ cụ thể:
| Tài sản | Mối đe dọa | Điểm yếu | Rủi ro |
|---|---|---|---|
| Source code repository | Insider threat | Không có access review định kỳ | Developer cũ vẫn có quyền truy cập sau khi nghỉ việc |
| Database production | SQL injection | Input validation không đầy đủ | Kẻ tấn công trích xuất toàn bộ dữ liệu khách hàng |
| Laptop developer | Mất/đánh cắp thiết bị | Disk không encrypt | Dữ liệu source code và credentials bị lộ |
| API keys trong code | Credential leak | Keys hardcoded trong repository | Keys bị expose qua public git history |
| Backup data | Ransomware | Backup không được test | Không khôi phục được sau sự cố |
Không cần liệt kê mọi rủi ro có thể tưởng tượng được. Tập trung vào rủi ro có khả năng xảy ra thực tế với tổ chức của bạn.
Bước 4: Đánh giá mức độ rủi ro
ISO 27001 không quy định cách tính điểm rủi ro. Tổ chức tự chọn methodology, nhưng phải nhất quán và có thể giải thích với auditor.
Methodology phổ biến nhất: Likelihood × Impact = Risk Score.
Ví dụ thang điểm 1-5:
| Impact 1 (Thấp) | Impact 3 (Trung bình) | Impact 5 (Cao) | |
|---|---|---|---|
| Likelihood 1 (Thấp) | 1 | 3 | 5 |
| Likelihood 3 (Trung bình) | 3 | 9 | 15 |
| Likelihood 5 (Cao) | 5 | 15 | 25 |
Sau đó phân loại: 1-5 = Thấp, 6-12 = Trung bình, 13-25 = Cao.
Điểm quan trọng: likelihood và impact phải được định nghĩa rõ ràng trong Risk Assessment Methodology document. "Likelihood 3" cần có định nghĩa cụ thể, ví dụ "xảy ra 1-2 lần mỗi năm trong ngành" thay vì chỉ ghi "trung bình".
Bước 5: Quyết định xử lý rủi ro
Với mỗi rủi ro đã đánh giá, tổ chức chọn một trong bốn hướng xử lý:
- Treat (xử lý): Triển khai control để giảm likelihood hoặc impact. Đây là hướng phổ biến nhất.
- Tolerate (chấp nhận): Residual risk nằm trong ngưỡng chấp nhận của tổ chức. Cần ghi rõ lý do.
- Transfer (chuyển giao): Mua bảo hiểm cyber hoặc chuyển trách nhiệm sang bên thứ ba qua hợp đồng.
- Terminate (loại bỏ): Ngừng hoạt động tạo ra rủi ro. Ví dụ: tắt tính năng không cần thiết.
Đối với rủi ro "Treat", cần liên kết với controls cụ thể từ Annex A hoặc controls tùy chỉnh.
Bước 6: Chọn controls từ Annex A
ISO 27001:2022 có 93 controls trong Annex A, chia thành 4 chủ đề:
- 5.x Organizational controls (37 controls): Chính sách, quản trị, quản lý nhà cung cấp
- 6.x People controls (8 controls): Tuyển dụng, đào tạo, offboarding
- 7.x Physical controls (14 controls): Bảo mật văn phòng, thiết bị
- 8.x Technological controls (34 controls): Access control, encryption, logging, vulnerability management
Không phải tổ chức nào cũng cần tất cả 93 controls. Danh sách controls bạn chọn và lý do loại trừ các controls còn lại được ghi trong Statement of Applicability (SoA): tài liệu bắt buộc riêng biệt với Risk Register.
Ví dụ liên kết rủi ro với control:
| Rủi ro | Control Annex A | Mô tả |
|---|---|---|
| Developer cũ còn quyền truy cập | 5.18 Access rights | Quy trình revoke access trong 24 giờ sau offboarding |
| API keys hardcoded | 8.13 Information backup / 8.25 Secure development | Quét secrets trong code trước khi merge |
| Disk không encrypt | 8.24 Use of cryptography | Bật FileVault/BitLocker trên tất cả endpoint |
Bước 7: Tính residual risk và ghi risk owner
Sau khi chọn controls, tính lại risk score. Residual risk phải nằm trong ngưỡng chấp nhận rủi ro (risk appetite) mà ban lãnh đạo đã phê duyệt.
Mỗi rủi ro cần có một risk owner: người chịu trách nhiệm theo dõi và báo cáo. Thường là:
- CTO hoặc Head of Engineering cho rủi ro kỹ thuật
- COO cho rủi ro vận hành
- CEO cho rủi ro chiến lược
Duy trì Risk Register sau khi được chứng nhận
Đây là phần nhiều tổ chức bỏ qua nhưng auditor sẽ kiểm tra kỹ trong surveillance audit.
Risk Register phải được review ít nhất mỗi năm một lần (Clause 6.1.3) hoặc khi có thay đổi đáng kể:
- Sản phẩm mới hoặc tính năng mới xử lý dữ liệu nhạy cảm
- Thay đổi hạ tầng (di chuyển cloud, thêm vendor)
- Sự cố bảo mật
- Thay đổi nhân sự quan trọng
- Thay đổi quy định pháp lý
Mỗi lần review phải có bằng chứng: ngày review, người review, kết quả (không thay đổi / cập nhật rủi ro X / thêm rủi ro Y).
Những lỗi phổ biến khi xây Risk Register
Sao chép template từ internet mà không điều chỉnh. Auditor nhận ra ngay. Risk Register phải phản ánh môi trường thực tế của tổ chức, không phải rủi ro của một công ty giả định.
Đánh giá tất cả rủi ro là "Medium". Nếu mọi rủi ro đều có cùng điểm số, methodology đánh giá rủi ro của bạn có vấn đề.
Không có risk owner. Rủi ro không có người chịu trách nhiệm không được theo dõi và không được xử lý.
Risk Register tồn tại độc lập với thực tế. Nếu controls ghi trong Risk Register không được triển khai thực sự, auditor sẽ phát hiện khi kiểm tra evidence.
Không cập nhật sau thay đổi. Một Risk Register từ 18 tháng trước không được review sẽ là điểm trừ lớn trong surveillance audit.
Dùng spreadsheet hay phần mềm
Về kỹ thuật, Risk Register có thể là một file Excel. Không có yêu cầu dùng phần mềm chuyên dụng.
Thực tế, vấn đề với spreadsheet xuất hiện ở giai đoạn duy trì: khi controls thay đổi, khi rủi ro mới xuất hiện, khi cần chứng minh với auditor rằng review đã diễn ra đúng lịch. Spreadsheet không có audit trail, không nhắc nhở review deadline, và không liên kết trực tiếp với evidence của từng control.
Các nền tảng GRC tích hợp Risk Register với control library và evidence collection, khi một control có bằng chứng, residual risk tự động được cập nhật. Khi đến hạn review, hệ thống gửi nhắc nhở. Lịch sử mọi thay đổi được lưu lại với timestamp.
pTrackly có Risk Register tích hợp sẵn với 93 Annex A controls đã được map sẵn, giúp rút ngắn thời gian xây Risk Register từ vài tuần xuống còn vài ngày. Đặt demo để xem cụ thể với môi trường kỹ thuật của bạn.