Annex A Control 5.9 của ISO 27001:2022 yêu cầu tổ chức xây và duy trì "an inventory of information and other associated assets". Đây là một trong những controls đầu tiên auditor kiểm tra vì asset inventory là nền tảng để thực hiện risk assessment và xác định phạm vi bảo vệ.
Bài này hướng dẫn cách xây asset inventory thực tế cho công ty phần mềm, không phải lý thuyết về tất cả loại tài sản có thể tưởng tượng, mà là những gì auditor cần thấy.
Asset inventory trong ISO 27001 là gì
Không phải danh sách thiết bị IT. Asset inventory trong ngữ cảnh ISO 27001 là danh sách tài sản thông tin: bất cứ thứ gì có giá trị đối với tổ chức và cần được bảo vệ.
ISO 27001:2022 định nghĩa "information asset" rộng hơn thiết bị:
- Dữ liệu và thông tin (dữ liệu khách hàng, source code, credentials)
- Phần mềm và hệ thống (ứng dụng, database, OS)
- Phần cứng (server, laptop, thiết bị mạng)
- Dịch vụ (cloud services, SaaS tools, internet connectivity)
- Con người và kỹ năng của họ (knowledge assets)
- Uy tín và thương hiệu
Đối với công ty phần mềm B2B, thường chỉ cần tập trung vào 3 nhóm đầu cộng với dịch vụ cloud. Con người và uy tín ít khi được đưa vào asset inventory cụ thể (thay vào đó được xử lý qua people controls và business continuity).
Tại sao asset inventory quan trọng trong ISMS
Asset inventory không chỉ là checkbox để pass audit. Nó phục vụ ba mục đích thực tế:
Làm nền tảng cho risk assessment. Không thể đánh giá rủi ro cho tài sản mà bạn không biết tồn tại. Nếu có một S3 bucket chứa dữ liệu khách hàng không nằm trong inventory, rủi ro liên quan đến bucket đó không được đánh giá và control không được triển khai.
Xác định phạm vi bảo vệ. Khi xảy ra sự cố, asset inventory cho biết ngay tài sản nào có thể bị ảnh hưởng và ai là người chịu trách nhiệm liên hệ.
Hỗ trợ offboarding. Control 6.5 (Responsibilities after termination) yêu cầu thu hồi quyền truy cập khi nhân viên rời công ty. Không có asset inventory, không biết cần thu hồi quyền truy cập vào những hệ thống nào.
Cấu trúc asset inventory thực tế
Mỗi tài sản cần ghi tối thiểu:
| Trường | Mô tả | Ví dụ |
|---|---|---|
| Asset ID | Mã định danh duy nhất | INF-001 |
| Tên tài sản | Tên mô tả rõ ràng | Production PostgreSQL database |
| Loại tài sản | Data / Software / Hardware / Service | Data |
| Mô tả | Tài sản chứa/làm gì | Dữ liệu khách hàng: tên, email, lịch sử giao dịch |
| Phân loại | Mức độ nhạy cảm | Confidential |
| Asset owner | Người chịu trách nhiệm | CTO |
| Vị trí | Nơi lưu trữ/vận hành | AWS RDS, region ap-southeast-1 |
| Phụ thuộc | Kết nối với tài sản nào | API server (INF-003), Backup S3 (INF-008) |
Cách phân loại tài sản thông tin
Phân loại (classification) xác định mức độ bảo vệ cần thiết. Không có thang phân loại bắt buộc trong ISO 27001, nhưng tổ chức phải định nghĩa và áp dụng nhất quán.
Thang phổ biến nhất cho công ty phần mềm B2B:
Confidential (Bí mật): Dữ liệu khách hàng, credentials/API keys, private keys, source code, hợp đồng thương mại, thông tin M&A. Nếu bị lộ: ảnh hưởng nghiêm trọng đến khách hàng hoặc tổ chức.
Internal (Nội bộ): Tài liệu nội bộ, email công việc, meeting notes, code không chứa logic kinh doanh nhạy cảm. Không phù hợp để công khai nhưng thiệt hại nếu bị lộ không nghiêm trọng.
Public (Công khai): Tài liệu marketing, website, tài liệu kỹ thuật công khai. Có thể chia sẻ tự do.
Phần lớn assets của công ty phần mềm là Confidential hoặc Internal.
Ví dụ asset inventory cho công ty SaaS 30 người
Không cần liệt kê từng file trong hệ thống. Nhóm theo loại và tầm quan trọng:
Dữ liệu:
- Customer data (production database), Confidential
- Customer data (staging/test), Confidential nếu dùng real data, Internal nếu dùng test data
- Source code, Confidential
- Employee data (HR system), Confidential
- API keys và credentials, Confidential
- Log files, Internal
- Backup data, Confidential
Hệ thống:
- Production application servers, Critical
- Production database servers, Critical
- CI/CD pipeline, High
- Development environments, Medium
- Monitoring và logging infrastructure, High
Dịch vụ:
- AWS/GCP/Azure account, Critical
- GitHub/GitLab, Critical (chứa source code)
- Google Workspace, High (email, documents)
- Slack, Internal
- Jira/Linear, Internal
- HR system, High (employee data)
- Password manager, Critical
Thiết bị:
- Developer laptops, High (có thể chứa source code, credentials)
- Company phones nếu có, Medium
Asset owner: ai chịu trách nhiệm gì
Mỗi tài sản cần có một người chịu trách nhiệm, asset owner. Đây không nhất thiết là người sử dụng tài sản hàng ngày, mà là người có quyền quyết định về tài sản đó.
Ví dụ phân công thực tế:
| Tài sản | Asset owner | Lý do |
|---|---|---|
| Production database | CTO | Chịu trách nhiệm về kiến trúc và bảo mật kỹ thuật |
| Customer data | CEO/CPO | Chịu trách nhiệm pháp lý về dữ liệu khách hàng |
| HR data | COO/HR Manager | Chịu trách nhiệm về dữ liệu nhân sự |
| Source code | CTO/Lead Engineer | Chịu trách nhiệm về tài sản kỹ thuật |
| Cloud accounts | CTO/DevOps Lead | Chịu trách nhiệm về hạ tầng |
Duy trì asset inventory sau khi được chứng nhận
Asset inventory không phải tài liệu làm một lần. Nó cần được cập nhật khi:
- Triển khai hệ thống mới hoặc đưa vào sử dụng tool mới
- Tắt hệ thống cũ (tài sản cần được ghi là "decommissioned", không xóa khỏi inventory)
- Thay đổi asset owner do nhân sự thay đổi
- Thay đổi phân loại do tính chất dữ liệu thay đổi
- Phát hiện tài sản chưa được đăng ký trong review định kỳ
Review định kỳ ít nhất mỗi năm một lần là bắt buộc. Surveillance audit sẽ hỏi: "Tài sản nào được thêm/bỏ từ kỳ audit trước? Quy trình cập nhật như thế nào?"
Những lỗi phổ biến
Liệt kê quá chi tiết. Từng laptop riêng lẻ thay vì "Developer laptops (25 units)" làm inventory không quản lý được. Nhóm theo loại là đủ trừ khi các thiết bị có mức độ rủi ro khác nhau.
Không bao gồm SaaS tools. GitHub, Slack, Google Workspace đều là tài sản thông tin quan trọng. Nhiều tổ chức chỉ inventory on-premise và bỏ qua cloud services.
Asset owner là "IT Department" hoặc "Company". Cần là một cá nhân cụ thể, không phải bộ phận hay tổ chức.
Không cập nhật khi có thay đổi. Tài sản mới không được đăng ký là lỗi điển hình trong surveillance audit.
Staging chứa real customer data nhưng phân loại là Internal. Nếu staging environment chứa bản sao của production data, phân loại phải là Confidential và controls tương ứng phải được áp dụng.
Spreadsheet hay phần mềm
Asset inventory có thể là spreadsheet. Thực tế vấn đề xuất hiện khi inventory lớn và cần duy trì lâu dài: ai cập nhật khi có thay đổi, làm sao biết tài sản nào chưa được review, làm sao liên kết tài sản với risk và controls tương ứng.
Nền tảng GRC tích hợp asset inventory với risk register và control library. Khi thêm tài sản mới, hệ thống tự động gợi ý risk assessment và controls cần xem xét. Khi có surveillance audit, toàn bộ lịch sử thay đổi inventory đã được ghi lại.
pTrackly có asset inventory module tích hợp với ISO 27001 control framework, giúp mỗi tài sản được liên kết trực tiếp với rủi ro và bằng chứng controls. Đặt demo để xem inventory của bạn sẽ trông như thế nào sau khi được map vào ISMS.