Xây dựng chương trình quản lý rủi ro an toàn thông tin của nhà cung cấp.

Nhìn quan hệ cung cấp qua dữ liệu, quyền và mức phụ thuộc

Không nên đánh giá mọi nhà cung cấp theo cùng một bộ yêu cầu dài. Một đơn vị cung cấp thiết bị không tiếp cận dữ liệu có đặc điểm khác với bên quản trị ứng dụng chứa hồ sơ khách hàng. Nếu không phân nhóm, đội đánh giá vừa làm nặng quan hệ ít rủi ro vừa có thể bỏ qua câu hỏi quan trọng của dịch vụ nhạy cảm.

Bước đầu cần ghi dịch vụ được cung cấp, chủ quan hệ, dữ liệu trao đổi, quyền truy cập và hoạt động kinh doanh phụ thuộc. Có nhà cung cấp giữ ít dữ liệu nhưng là điểm duy nhất giúp dịch vụ vận hành. Có bên không trực tiếp giữ dữ liệu nhưng có quyền thay cấu hình. Mức rủi ro phải được nhìn từ tác động, không chỉ từ giá trị hợp đồng.

Quan hệ cũng có thể kéo dài qua nhà thầu phụ hoặc nền tảng bên dưới. Doanh nghiệp cần mức thông tin phù hợp để hiểu các phụ thuộc quan trọng, đặc biệt khi một phần công việc hoặc dữ liệu được chuyển tiếp. Không nhất thiết thu thập toàn bộ sơ đồ chi tiết của mọi bên, nhưng cần biết khoảng trống nào có thể ảnh hưởng quyết định.

NIST SP 800-161 Rev. 1, bản cập nhật, cung cấp hướng dẫn quản lý rủi ro an ninh mạng chuỗi cung ứng ở nhiều cấp. Với doanh nghiệp, nguyên tắc hữu ích là đưa rủi ro vào quy trình mua sắm và vận hành thay vì giao toàn bộ cho một lần đánh giá kỹ thuật. Hướng dẫn không thay thế việc xác định nghĩa vụ pháp lý và hợp đồng cụ thể.

Nhóm có thể vận dụng quản lý rủi ro IT để xây tiêu chí phân nhóm. Các tiêu chí cần giúp quyết định độ sâu đánh giá, thẩm quyền phê duyệt và cách theo dõi sau ký. Chúng không nên chỉ tạo một điểm tổng khiến những khoảng trống quan trọng biến mất trong giá trị trung bình.

Đặt yêu cầu và thu bằng chứng trước khi lựa chọn

Khi nghiệp vụ đã xác định nhu cầu, nhóm đánh giá cần chuyển nó thành yêu cầu bảo vệ có thể kiểm tra. Ví dụ, dữ liệu nào được xử lý, ai được tiếp cận, trách nhiệm phục hồi tới đâu và khi có sự cố cần cung cấp thông tin gì? Những câu hỏi này nên xuất hiện trước lúc giải pháp đã được lựa chọn và lịch triển khai đã cố định.

Bằng chứng có thể gồm tài liệu quy trình, kết quả kiểm tra, báo cáo độc lập hoặc minh họa cách thực hiện. Cần xem phạm vi và thời điểm của mỗi nguồn. Một chứng nhận có thể liên quan một đơn vị hoặc dịch vụ nhất định; không nên suy ra toàn bộ sản phẩm, nhà thầu phụ và cấu hình mà doanh nghiệp sử dụng đều đã được bao phủ.

Bảng tự khai có ích để mở thảo luận, nhưng chưa phải xác nhận hiệu lực. Những câu trả lời “có” về sao lưu, phân quyền hoặc xử lý sự cố cần được làm rõ theo phạm vi sử dụng. Đánh giá sâu nên tập trung vào các kiểm soát quyết định mức rủi ro, tránh yêu cầu nhiều hồ sơ nhưng không dùng chúng để chọn phương án.

Với khoảng trống chưa giải quyết, cần phân biệt yêu cầu bắt buộc để bắt đầu với hành động có thể hoàn thiện sau dưới điều kiện được duyệt. Nếu chấp nhận triển khai trước, chủ rủi ro phải hiểu phần còn thiếu và hậu quả. Lịch kinh doanh gấp không tự thay thế quyết định này.

Năng lực quản lý bảo mật thông tin giúp đội ngũ chọn bằng chứng phù hợp và diễn giải giới hạn. Kết luận nên nói rõ phần đã xác nhận, phần chưa biết và điều kiện cần theo dõi. Cách trình bày này hữu ích hơn khẳng định một nhà cung cấp “an toàn” chỉ từ một tài liệu.

Chuyển kết luận đánh giá thành trách nhiệm trong hợp đồng

Những yêu cầu quyết định rủi ro cần được đưa vào cơ chế làm việc với nhà cung cấp. Hợp đồng và phụ lục phù hợp nên thể hiện phạm vi dịch vụ, trách nhiệm bảo vệ, quyền truy cập và điều kiện sử dụng dữ liệu. Đầu mối pháp lý và mua sắm cần kiểm tra tính phù hợp; đội bảo mật không nên tự suy đoán hiệu lực của một điều khoản.

Thông báo và phối hợp khi sự cố cần đủ cụ thể để có thể vận hành. Các bên phải hiểu sự kiện nào cần báo, đầu mối nào tiếp nhận, thông tin nào có thể cung cấp và cách cập nhật. Thời hạn phải bám nghĩa vụ áp dụng cùng mức rủi ro của dịch vụ; không có một thời hạn duy nhất phù hợp cho mọi quan hệ.

Khả năng kiểm tra cũng cần được thống nhất. Tổ chức có thể cần báo cáo theo kỳ, quyền yêu cầu giải thích hoặc phương pháp xác nhận khác. Nếu doanh nghiệp không được kiểm tra trực tiếp, phải hiểu giới hạn của bằng chứng thay thế và cách xử lý khi tài liệu không đủ. Cam kết không có cơ chế xác nhận dễ trở thành lời hứa khó sử dụng.

Bảng là gợi ý quản lý quan hệ, không phải mẫu hợp đồng chuẩn. Cần làm rõ phần doanh nghiệp vẫn tự chịu trách nhiệm, như cấu hình quyền trong ứng dụng hoặc lựa chọn dữ liệu gửi đi. Thuê ngoài một hoạt động không tự chuyển hết rủi ro và nghĩa vụ của tổ chức sang đối tác.

Theo dõi khi dịch vụ và điều kiện cung cấp thay đổi

Đánh giá trước ký có thể nhanh chóng mất phù hợp nếu nhà cung cấp thay nền tảng, thêm nhà thầu phụ hoặc doanh nghiệp mở rộng dữ liệu sử dụng. Chương trình cần các điểm kích hoạt xem lại, không chỉ một lịch gửi bảng câu hỏi định kỳ. Chủ quan hệ phải biết khi nào cần đưa thay đổi tới nhóm đánh giá.

Theo dõi nên tập trung vào đầu ra liên quan rủi ro: quyền được sử dụng, cam kết khắc phục, khả năng phục hồi hoặc chất lượng thông tin sự cố. Số email đã gửi và số chứng nhận đã thu không phản ánh việc các kiểm soát đang vận hành đúng. Khi bằng chứng thiếu, cần phân biệt chưa xác nhận với không đạt.

Cũng cần nhìn rủi ro tập trung. Nhiều dịch vụ mang tên khác nhau có thể phụ thuộc cùng một nền tảng hoặc nhà cung cấp bên dưới. Nếu chỉ đánh giá từng hợp đồng riêng, tổ chức có thể không thấy tác động đồng thời khi điểm chung đó gián đoạn. Quyết định dự phòng và phương án chuyển đổi cần thông tin ở cấp tổng thể.

Sự phối hợp với quản lý dịch vụ IT giúp theo dõi cam kết trong hoạt động hằng ngày. Thông tin sự cố, thay đổi và hiệu suất dịch vụ có thể trở thành đầu vào xem lại rủi ro. Nhờ đó, chương trình không phải đợi tới lần mua sắm tiếp theo mới biết quan hệ đang có vấn đề.

Một tình huống: dịch vụ hỗ trợ được mở thêm quyền

Trong tình huống giả định, doanh nghiệp thuê đối tác hỗ trợ một ứng dụng nội bộ. Đánh giá ban đầu dựa trên việc đối tác chỉ tiếp nhận thông tin lỗi đã lược bỏ dữ liệu. Sau một thời gian, nhóm vận hành cấp thêm quyền truy cập để xử lý nhanh hơn, nhưng không cập nhật phạm vi quan hệ và điều kiện bảo vệ.

Khi rà một ticket, doanh nghiệp nhận ra đối tác có thể xem hồ sơ thật và xuất tài liệu để phân tích. Cam kết cũ chưa đề cập rõ cách giữ, chia sẻ và kết thúc sử dụng những bản sao này. Nhà cung cấp có chính sách bảo mật chung, nhưng bằng chứng đó chưa trả lời đủ nhu cầu mới của doanh nghiệp.

Các bên xác định lại phần quyền cần thiết, giới hạn dữ liệu được dùng và cơ chế xác nhận xử lý sau hỗ trợ. Chủ nghiệp vụ đánh giá việc tăng quyền có phù hợp lợi ích và rủi ro hay không. IT thu hẹp những quyền không cần, còn mua sắm cùng pháp lý xem lại cam kết theo phạm vi mới.

Sau đó, doanh nghiệp bổ sung điểm kiểm tra rủi ro vào quy trình thay đổi quyền cho đối tác. Tình huống giả định cho thấy sai lệch thường bắt đầu từ một mở rộng hợp lý về vận hành nhưng không được nhìn như thay đổi quan hệ cung cấp. Đánh giá trước ký chỉ tiếp tục có giá trị khi tổ chức giữ được mối liên hệ này.

Chuẩn bị cách kết thúc và duy trì trách nhiệm sở hữu

Kết thúc hợp đồng cần được tính từ lúc lựa chọn, nhất là với dịch vụ giữ dữ liệu hoặc có mức phụ thuộc cao. Tổ chức cần biết cách chuyển tiếp, thu hồi quyền, lấy dữ liệu và xác nhận xử lý các bản sao theo yêu cầu áp dụng. Không nên đến ngày cuối mới phát hiện định dạng dữ liệu hoặc điều kiện hỗ trợ chưa được thống nhất.

Một số nghĩa vụ có thể còn tiếp tục sau khi ngừng dịch vụ. Các bên cần xác định phần lưu giữ hợp lệ, phạm vi bảo vệ và đầu mối liên hệ, có người chuyên môn xác nhận khi liên quan pháp luật hoặc hợp đồng. Không mặc nhiên yêu cầu xóa mọi dữ liệu nếu có nghĩa vụ giữ, cũng không để dữ liệu tồn tại vô thời hạn vì chưa ai hỏi.

Ở cấp quản lý IT, danh mục quan hệ phải có chủ sở hữu hiện hành. Khi người phụ trách đổi vị trí, trách nhiệm theo dõi và quyết định cần được bàn giao. Chương trình có hiệu quả khi mọi quan hệ quan trọng đều có người biết điều kiện đã phê duyệt, bằng chứng cần nhận và hành động phải thực hiện khi điều kiện đó không còn đúng.

Bài viết liên quan

• Quản lý sự cố an toàn thông tin: Từ phát hiện đến ứng phó, khôi phục và rút kinh nghiệm.
• Bảo vệ dữ liệu trong môi trường Cloud, SaaS và làm việc từ xa.
• Đánh giá nội bộ và xem xét lãnh đạo: Hai cơ chế giữ ISMS vận hành hiệu quả
• Triển khai ISMS trong doanh nghiệp: Từ đánh giá hiện trạng đến vận hành và cải tiến

Nguồn tham khảo

1. NIST — SP 800-161 Rev. 1, updated: Cybersecurity Supply Chain Risk Management Practices
2. CIS — Critical Security Control 15: Service Provider Management
3. ISO — ISO/IEC 27001:2022: Information security management systems