Nhiều đơn vị biết mình cần làm hồ sơ cấp độ nhưng lại mắc ngay ở câu hỏi đầu tiên: hệ thống này nên đề xuất cấp độ nào? Nếu trả lời quá sớm, toàn bộ phạm vi hồ sơ, phương án kỹ thuật và dự toán phía sau có thể bị lệch.
Cách làm phù hợp không phải là nhìn số lượng máy chủ hoặc chọn một cấp độ “vừa ngân sách”. Trước hết phải xác định đúng hệ thống, chức năng, dữ liệu, nhóm người dùng, phạm vi ảnh hưởng và quy định áp dụng; sau đó mới đối chiếu tiêu chí pháp lý để hình thành đề xuất sơ bộ.
Nếu đơn vị chưa chắc đã gom đủ đầu vào để bắt đầu phân loại, hãy đi qua 5 bước tự đánh giá mức độ ATTT trước. Còn nếu câu hỏi hiện tại là bộ tài liệu này thực chất gồm những gì và dùng để làm gì, xem hồ sơ đề xuất cấp độ là gì để giữ đúng owner intent giữa “definition” và “classification”.
Tóm tắt: Việt Nam phân loại hệ thống thông tin theo 5 cấp độ trong Nghị định 85/2016/NĐ-CP. Việc xác định cấp độ phải dựa trên loại hệ thống, phạm vi phục vụ và mức độ ảnh hưởng khi mất an toàn, không chỉ dựa vào quy mô hạ tầng. Tự rà soát chỉ tạo ra đề xuất sơ bộ; cấp độ chính thức còn phải đi theo hồ sơ, thẩm quyền và quy trình áp dụng.

Xác định cấp độ an toàn thông tin là gì?
Xác định cấp độ là quá trình khoanh đúng hệ thống thông tin, phân tích chức năng và đối tượng phục vụ, nhận diện dữ liệu cùng hậu quả nếu tính bí mật, tính toàn vẹn hoặc tính sẵn sàng bị ảnh hưởng, rồi đối chiếu tiêu chí để đề xuất cấp độ 1, 2, 3, 4 hoặc 5.
Thông tư 12/2022/TT-BTTTT hướng dẫn chi tiết một số nội dung của Nghị định 85/2016/NĐ-CP, gồm xác định hệ thống, thuyết minh đề xuất cấp độ và yêu cầu bảo đảm an toàn. Vì vậy, một bài viết hoặc checklist chỉ có thể hỗ trợ chuẩn bị đầu vào, không thay thế việc đối chiếu văn bản và thủ tục cụ thể.
| Cần xác định | Câu hỏi cần trả lời | Đầu ra |
|---|---|---|
| Ranh giới hệ thống | Thành phần nào nằm trong hệ thống, thành phần nào dùng chung hoặc thuộc bên thứ ba? | Danh mục tài sản và sơ đồ phạm vi |
| Chức năng | Hệ thống phục vụ nghiệp vụ, đối tượng và hoạt động nào? | Mô tả chức năng và nhóm người dùng |
| Dữ liệu | Dữ liệu nào được thu thập, lưu, truyền, sửa, xuất hoặc xóa? | Danh mục dữ liệu và luồng xử lý |
| Mức độ ảnh hưởng | Điều gì xảy ra nếu dữ liệu bị lộ, sửa sai, mất hoặc dịch vụ bị gián đoạn? | Phân tích tác động có căn cứ |
| Cấp độ sơ bộ | Tiêu chí pháp lý nào phù hợp với hệ thống đã khoanh? | Bản thuyết minh đề xuất để rà soát |
Vì sao phải xác định đúng ngay từ đầu?
Cấp độ đề xuất là đầu vào cho hồ sơ và phương án bảo đảm an toàn thông tin. Nếu phạm vi hoặc cấp độ bị xác định sai, đơn vị có thể chọn thiếu biện pháp cần thiết, đầu tư vượt nhu cầu hoặc phải sửa lại nhiều tài liệu sau khi đã hoàn thành.
| Sai lệch | Hệ quả thường gặp | Cách phòng tránh |
|---|---|---|
| Khoanh phạm vi quá rộng | Gom nhiều hệ thống khác nhau vào một hồ sơ, khó xác định trách nhiệm | Tách theo chức năng, chủ quản, dữ liệu và ranh giới vận hành |
| Khoanh phạm vi quá hẹp | Bỏ sót API, database, dịch vụ dùng chung hoặc kết nối có tác động | Rà luồng dữ liệu và phụ thuộc bên thứ ba |
| Đề xuất thấp hơn thực tế | Phương án bảo vệ có thể không tương xứng với tác động | Lập luận từ hậu quả và tiêu chí, không từ ngân sách mong muốn |
| Đề xuất cao hơn không cần thiết | Tăng phạm vi kiểm soát, chi phí và khối lượng vận hành | Chứng minh từng yếu tố thay vì chọn theo cảm giác |
| Hồ sơ không khớp hệ thống | Khó thẩm định, nghiệm thu và chứng minh khi kiểm tra | Dùng một nguồn dữ liệu chuẩn và người xác nhận hiện trạng |
Hiểu đúng về 5 cấp độ an toàn thông tin
Nghị định 85/2016/NĐ-CP quy định 5 cấp độ và tiêu chí pháp lý tương ứng. Không nên rút gọn thành công thức “website nhỏ là cấp 1”, “có dữ liệu cá nhân là cấp 2” hoặc “nhiều máy chủ là cấp 3”. Những mô tả như vậy có thể bỏ qua loại hệ thống, đối tượng phục vụ và mức độ ảnh hưởng được quy định.
Cách đọc an toàn hơn là xem 5 cấp độ như một thang phân loại tăng dần về mức độ quan trọng và hậu quả khi mất an toàn, nhưng cấp cụ thể phải được xác định bằng điều kiện pháp lý của từng cấp. Khi lập hồ sơ, đơn vị cần chỉ rõ mình đáp ứng tiêu chí nào và bằng chứng nào hỗ trợ kết luận đó.
| Không nên kết luận từ | Cần đối chiếu thêm |
|---|---|
| Số lượng máy chủ hoặc người dùng | Chức năng, đối tượng phục vụ và phạm vi ảnh hưởng |
| Tên gọi “website”, “portal”, “ERP” hoặc “CRM” | Ranh giới thật, dữ liệu và mức độ phụ thuộc nghiệp vụ |
| Việc hệ thống public hay nội bộ | Loại thông tin, quyền truy cập, kết nối và hậu quả sự cố |
| Một ví dụ hoặc hồ sơ của đơn vị khác | Tiêu chí pháp lý áp dụng cho hệ thống cụ thể |
| Ngân sách dự kiến | Mức độ bảo vệ cần thiết và lộ trình xử lý khoảng trống |
Khi chưa đủ căn cứ để chốt, nên ghi “cấp độ đề xuất sơ bộ” và danh sách thông tin còn thiếu. Không nên biến một nhận định ban đầu thành kết luận chính thức.
Những yếu tố phải rà trước khi đề xuất cấp độ
Vai trò và chức năng của hệ thống
Cần mô tả hệ thống đang hỗ trợ hoạt động nào, ai phụ thuộc vào nó và nếu dừng hoạt động thì nghiệp vụ nào bị ảnh hưởng. Một hệ thống kỹ thuật đơn giản vẫn có thể quan trọng nếu là điểm duy nhất phục vụ một quy trình thiết yếu.
Dữ liệu và luồng xử lý
Không chỉ liệt kê “có dữ liệu cá nhân” hoặc “có dữ liệu nội bộ”. Cần xác định dữ liệu đến từ đâu, ai được xem hoặc sửa, được truyền sang hệ thống nào, lưu bao lâu và hậu quả nếu bị lộ, sai lệch hoặc mất.
Đối tượng và phạm vi phục vụ
Hệ thống phục vụ một nhóm nội bộ nhỏ khác với hệ thống cung cấp dịch vụ cho nhiều đơn vị hoặc người dùng bên ngoài. Tuy nhiên, số lượng người dùng không phải tiêu chí duy nhất; cần xem thêm vai trò của dịch vụ và tác động khi sự cố xảy ra.
Tác động đến bí mật, toàn vẹn và sẵn sàng
- Bí mật: ai bị ảnh hưởng nếu thông tin bị truy cập hoặc công bố trái phép?
- Toàn vẹn: quyết định hoặc giao dịch nào bị sai nếu dữ liệu bị sửa, xóa hoặc giả mạo?
- Sẵn sàng: hoạt động nào bị gián đoạn nếu hệ thống ngừng phục vụ?
Chủ thể, thẩm quyền và quy định chuyên ngành
Không phải mọi tổ chức và hệ thống đều đi qua cùng một luồng xử lý. Cần xác định chủ quản, đơn vị vận hành, cơ quan hoặc người có thẩm quyền và các quy định chuyên ngành có liên quan. Chỉ thị 09/CT-TTg ngày 23/02/2024 nhấn mạnh việc tuân thủ trong phạm vi các đối tượng được giao nhiệm vụ, nhưng không nên suy rộng các deadline của văn bản thành nghĩa vụ giống nhau cho mọi doanh nghiệp.
Quy trình tự rà soát sơ bộ theo 4 bước
Bốn bước dưới đây giúp chuẩn bị đầu vào và hình thành đề xuất ban đầu. Kết quả không thay thế hồ sơ, thẩm định hoặc phê duyệt.
Bước 1: Khoanh đúng hệ thống
- Đặt một tên chính thức và mô tả mục tiêu.
- Liệt kê ứng dụng, máy chủ, database, API, domain và dịch vụ liên quan.
- Tách thành phần nằm trong phạm vi, thành phần dùng chung và thành phần bên thứ ba.
- Xác định đơn vị chủ quản, vận hành và người xác nhận hiện trạng.
Bước 2: Lập danh mục chức năng, dữ liệu và người dùng
- Chức năng nào là cốt lõi, chức năng nào chỉ hỗ trợ?
- Dữ liệu nào được thu thập, lưu, truyền, xuất hoặc xóa?
- Nhóm người dùng nào có quyền sử dụng hoặc quản trị?
- Hệ thống phụ thuộc dịch vụ, API hoặc nhà cung cấp nào?
Bước 3: Phân tích kịch bản mất an toàn
Với từng chức năng và dữ liệu quan trọng, mô tả hậu quả của ít nhất ba tình huống: bị lộ, bị sửa sai và không thể truy cập. Cần ghi đối tượng bị ảnh hưởng, phạm vi, thời gian, khả năng phục hồi và tác động đến hoạt động hoặc quyền lợi liên quan.
Bước 4: Đối chiếu tiêu chí và lập luận đề xuất
Đối chiếu các thông tin đã xác minh với điều kiện của từng cấp trong Nghị định 85/2016/NĐ-CP và hướng dẫn của Thông tư 12/2022/TT-BTTTT. Bản đề xuất cần chỉ ra tiêu chí, dữ kiện hỗ trợ, nội dung chưa chắc chắn và người xác nhận; không chỉ ghi một con số cấp độ.
Checklist đầu vào có thể dùng ngay
| Nhóm | Câu hỏi cần trả lời | Bằng chứng nên có |
|---|---|---|
| Phạm vi | Hệ thống gồm những thành phần nào? | Sơ đồ và danh mục tài sản |
| Chủ thể | Ai chủ quản, vận hành, phê duyệt và hỗ trợ? | Phân công hoặc hợp đồng |
| Chức năng | Nghiệp vụ nào phụ thuộc vào hệ thống? | Mô tả chức năng và quy trình |
| Dữ liệu | Dữ liệu nào được xử lý và ai có quyền? | Danh mục dữ liệu, vai trò và luồng xử lý |
| Người dùng | Hệ thống phục vụ nội bộ, đối tác hay công chúng? | Nhóm người dùng và quy mô dự kiến |
| Kết nối | Có API, cloud, dịch vụ dùng chung hoặc bên thứ ba không? | Sơ đồ kết nối và trách nhiệm |
| Tác động | Hậu quả khi dữ liệu bị lộ, sửa hoặc dịch vụ gián đoạn? | Bảng phân tích kịch bản |
| Hiện trạng ATTT | Tài khoản, backup, log, bản vá và ứng cứu đang ở trạng thái nào? | Cấu hình, biên bản hoặc báo cáo |
| Căn cứ | Tiêu chí nào hỗ trợ cấp độ đề xuất? | Bảng đối chiếu văn bản và dữ kiện |
Không dùng số lượng câu trả lời “có” để tự chốt cấp độ. Một thông tin có tác động lớn có thể quan trọng hơn nhiều câu hỏi nhỏ; ngược lại, việc hệ thống public Internet không tự động quyết định cấp độ nếu chưa phân tích đầy đủ.
Ví dụ để nhận diện đầu vào, không dùng để kết luận cấp độ
| Ví dụ | Thông tin cần làm rõ | Không nên kết luận ngay |
|---|---|---|
| Website giới thiệu | Có form, tài khoản, API, dữ liệu và vai trò kinh doanh nào? | “Website nhỏ nên chắc chắn cấp thấp” |
| Cổng khách hàng | Loại dữ liệu, quyền, giao dịch và tác động khi gián đoạn? | “Có đăng nhập nên mặc định cấp 2” |
| Phần mềm nội bộ | Nghiệp vụ nào phụ thuộc, người dùng nào và có kết nối ngoài không? | “Nội bộ nên mức ảnh hưởng thấp” |
| Hệ thống giáo dục hoặc y tế | Chủ thể, phạm vi phục vụ, dữ liệu và quy định chuyên ngành nào? | “Tên ngành tự quyết định cấp độ” |
| API hoặc nền tảng tích hợp | Hệ thống nào phụ thuộc và hậu quả khi dữ liệu hoặc dịch vụ sai? | “Không có giao diện nên ít quan trọng” |
Những lỗi thường làm đề xuất cấp độ sai
- Chọn cấp độ trước rồi viết ngược căn cứ: làm lập luận thiếu khách quan.
- Đánh giá theo số máy chủ: bỏ qua dữ liệu và tác động nghiệp vụ.
- Gộp hoặc tách phạm vi tùy tiện: làm mất quan hệ giữa các thành phần.
- Chỉ hỏi đội kỹ thuật: thiếu thông tin về nghiệp vụ, người dùng và hậu quả.
- Dùng hồ sơ hệ thống khác: tên gọi giống nhưng chức năng và chủ thể có thể khác.
- Xem dữ liệu cá nhân là tiêu chí duy nhất: bỏ qua loại hệ thống và điều kiện pháp lý khác.
- Không ghi điều còn thiếu: biến đề xuất sơ bộ thành kết luận có vẻ chắc chắn.
Sau khi có đề xuất sơ bộ, làm gì tiếp?
- Cho người nắm nghiệp vụ và kỹ thuật xác nhận phạm vi, dữ liệu và tác động.
- Rà lại tiêu chí pháp lý và thẩm quyền áp dụng.
- Lập bảng khoảng trống về tài liệu, quản lý và kỹ thuật.
- Soạn hồ sơ từ cùng một nguồn dữ liệu chuẩn.
- Rà chéo cấp độ đề xuất với phương án bảo đảm ATTT và bằng chứng.
- Trình, xử lý góp ý và lưu phiên bản theo quy trình phù hợp.
Quy trình chi tiết được trình bày tại quy trình lập hồ sơ đề xuất cấp độ. Khi cần xem cách tổ chức tài liệu, dùng mẫu cấu trúc hồ sơ đề xuất cấp độ như khung tham khảo, không phải file dùng chung cho mọi hệ thống.
Khi nào nên thuê đơn vị hỗ trợ?
Nên cân nhắc hỗ trợ độc lập khi hệ thống có nhiều đơn vị vận hành, tài liệu thiếu, ranh giới không rõ, dữ liệu hoặc tác động phức tạp, hoặc nội bộ chưa có người kết nối được góc nhìn pháp lý, nghiệp vụ và kỹ thuật.
Phạm vi hỗ trợ cần nêu rõ: khảo sát, dựng sơ đồ, phân tích cấp độ sơ bộ, soạn hồ sơ, rà phương án ATTT hay hỗ trợ xử lý góp ý. Đơn vị tư vấn không thể thay chủ thể có thẩm quyền phê duyệt và không nên cam kết kết quả khi đầu vào hoặc hiện trạng chưa được xác minh.
Nếu nhu cầu là hỗ trợ từ phạm vi đến bộ hồ sơ, xem dịch vụ lập hồ sơ đề xuất cấp độ ATTT. Trang báo giá chỉ phù hợp khi đơn vị đã cần dự toán chi phí theo phạm vi cụ thể.
FAQ
Có bao nhiêu cấp độ an toàn thông tin?
Nghị định 85/2016/NĐ-CP quy định 5 cấp độ, từ cấp độ 1 đến cấp độ 5. Tiêu chí của từng cấp phải được đối chiếu trực tiếp với hệ thống cụ thể.
Có thể tự xác định cấp độ không?
Đơn vị có thể tự rà và lập đề xuất sơ bộ nếu có đủ thông tin và năng lực. Tuy nhiên, kết quả chính thức còn phụ thuộc hồ sơ, thẩm quyền và quy trình áp dụng.
Hệ thống ít máy chủ có phải cấp độ thấp không?
Không thể kết luận như vậy. Cấp độ phụ thuộc loại hệ thống, chức năng, đối tượng phục vụ và mức độ ảnh hưởng khi mất an toàn, không chỉ số lượng thiết bị.
Có dữ liệu cá nhân thì mặc định cấp độ 2 hay 3?
Không nên tự động gán cấp độ chỉ từ một yếu tố. Cần phân tích loại dữ liệu, chủ thể, phạm vi, chức năng, hậu quả và các tiêu chí pháp lý tương ứng.
Khi nào phải xác định lại cấp độ?
Cần rà lại khi phạm vi, chức năng, dữ liệu, đối tượng phục vụ, kiến trúc, đơn vị vận hành hoặc mức độ ảnh hưởng thay đổi, và theo yêu cầu của quy trình quản lý áp dụng.
Kết luận
Xác định cấp độ an toàn thông tin là bài toán phân loại hệ thống và tác động, không phải phép đếm máy chủ hoặc lựa chọn theo ngân sách. Cần bắt đầu từ phạm vi, chức năng, dữ liệu, người dùng và hậu quả sự cố; sau đó mới đối chiếu tiêu chí để lập đề xuất có thể kiểm tra.
Một kết quả tốt không chỉ ghi “cấp độ mấy”, mà còn giải thích vì sao, dựa trên dữ kiện nào, ai xác nhận và thông tin nào còn thiếu. Đây là nền để hồ sơ, phương án kỹ thuật và kế hoạch đầu tư đi cùng một hướng.
Nguồn chính thức
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.

