Bộ câu hỏi đánh giá bảo mật nhà cung cấp: Cách hỏi và chấm theo rủi ro

Bảng câu hỏi an ninh nhà cung cấp rất dễ biến thành một màn kịch đôi bên cùng biết: bên mua gửi 200 câu sao chép, bên bán dùng thư viện câu trả lời năm ngoái, rồi procurement lưu file để chứng minh đã “đánh giá”. Khi sự cố xảy ra, không ai nhớ vendor xử lý dữ liệu nào, quyền truy cập ra sao hay đã cam kết báo sự cố trong bao lâu. Muốn tránh trò giấy tờ đó, câu hỏi phải đi từ rủi ro và dẫn đến quyết định.

Bài này tiếp nối khung quản trị rủi ro bên thứ ba, tập trung vào cách thiết kế questionnaire, yêu cầu bằng chứng, chấm ngoại lệ và chuyển kết quả sang hợp đồng/giám sát. Nó phù hợp cho SaaS, outsourcing, cloud, agency, payment, payroll và vendor có quyền truy cập hệ thống hoặc dữ liệu.

Phân tầng nhà cung cấp trước khi hỏi một câu

Đánh giá phải tỷ lệ với exposure. Một công cụ thiết kế không lưu dữ liệu nhạy cảm và không tích hợp production không cần cùng độ sâu với nhà cung cấp payroll giữ dữ liệu nhân viên hoặc MSP có quyền admin. Thu thập intake ngắn từ business owner: dịch vụ, dữ liệu, kết nối, đặc quyền, criticality, quốc gia xử lý, subprocessor và khả năng thay thế. Từ đó xếp tier và chọn module câu hỏi.

Tier không nên dựa vào doanh thu hay thương hiệu vendor. Một startup nhỏ có thể ít exposure; một tập đoàn cloud vẫn có thể là single point of failure. NIST SP 800-161 Rev.1 hướng dẫn tích hợp Cybersecurity Supply Chain Risk Management vào quản trị rủi ro nhiều cấp; tinh thần quan trọng là nhìn sản phẩm/dịch vụ xuyên vòng đời, không chỉ chấm một lần trước mua.

Viết câu hỏi để nhận bằng chứng, không nhận lời hứa

Câu “Bạn có chính sách bảo mật không?” hầu như luôn nhận “Có”. Câu hữu ích hơn: “Cung cấp ngày phê duyệt gần nhất, owner, phạm vi và bằng chứng review; mô tả cách ngoại lệ được chấp nhận.” Mỗi control question nên có bốn trường: điều muốn biết, applicability, evidence chấp nhận và tiêu chí pass/conditional/fail. Cho phép “Not applicable” kèm lý do để tránh vendor nói có cho mọi thứ.

Module 1 — Governance, quản trị rủi ro và assurance

• Ai chịu trách nhiệm an ninh và báo cáo lên cấp quản lý nào? Tần suất review risk/KPI và cơ chế chấp nhận rủi ro?
• Các policy cốt lõi bao phủ asset, access, change, vulnerability, incident, vendor, continuity và privacy; ngày phê duyệt gần nhất?
• Phạm vi ISO 27001, SOC 2 hoặc report độc lập có bao phủ dịch vụ đang mua, địa điểm và hệ thống liên quan không? Có ngoại lệ nào ảnh hưởng khách hàng?
• Internal audit/control testing được thực hiện bởi ai, độc lập thế nào và issue overdue được escalation ra sao?
• Cyber insurance có phù hợp không nếu hợp đồng cần; nhưng bảo hiểm không được dùng thay kiểm soát hoặc giới hạn trách nhiệm vô lý.

Nếu vendor cung cấp ISO/SOC, đọc scope và thời hạn. Với SOC 2, kiểm tra Type, period, exceptions, subservice organizations và complementary user entity controls. Với ISO, kiểm tra statement of scope và tổ chức chứng nhận. Bài SOC 2 cho công ty phần mềm và ISO 27001 giải thích chi tiết các giới hạn assurance.

Module 2 — Dữ liệu, quyền riêng tư và vòng đời

• Loại dữ liệu nào được thu, mục đích, vai trò pháp lý, nguồn, data flow, nơi lưu/xử lý và ai có thể truy cập?
• Data minimization, retention và deletion được cấu hình theo tenant hay một mặc định chung; backup hết hạn/xóa ra sao?
• Mã hóa khi truyền/lưu dùng cơ chế nào; key thuộc ai, phân quyền, rotation và separation thế nào?
• Danh sách subprocessor, quốc gia, dịch vụ, notification khi thay đổi và flow-down obligation?
• Quy trình hỗ trợ data subject request, legal hold, export, correction và deletion; SLA phối hợp?
• Dữ liệu khách hàng có được dùng cho analytics, quảng cáo hoặc huấn luyện AI/model không; opt-out và isolation thế nào?
• Khi chấm dứt, định dạng export, timeline, phí, xác nhận xóa và dữ liệu còn lại do luật/backup?

Tại Việt Nam, legal/privacy owner cần đối chiếu hợp đồng và luồng dữ liệu với Luật số 91/2025/QH15 và Nghị định 356/2025/NĐ-CP. Questionnaire không phải tư vấn pháp lý; nó thu facts để xác định vai trò, nghĩa vụ hồ sơ, chuyển dữ liệu và biện pháp bảo vệ. Câu “vendor tuân thủ mọi luật” không thay data map và điều khoản cụ thể.

Module 3 — IAM, kỹ thuật và secure development

• SSO/MFA có hỗ trợ và bắt buộc cho admin/workforce không; provisioning SCIM, role model, session, API key và break-glass được quản lý thế nào?
• Privileged access có approval, time-bound, logging, review và separation; support access vào tenant khách hàng được bật/tắt ra sao?
• Asset, endpoint, cloud baseline, patch/vulnerability SLA và ngoại lệ; exposure internet được phát hiện bằng nguồn nào?
• SDLC có threat modeling, code review, dependency/secret scanning, security test và release approval; finding đi vào backlog thế nào?
• Tenant isolation và authorization được thiết kế/test ở app, API, database và cache; test chéo tenant gần nhất?
• Log security/admin/data access nào được giữ, chống sửa, alert và cung cấp cho khách hàng; retention và timezone/correlation?
• Backup có tách quyền, immutable/offline khi phù hợp, restore test và RPO/RTO đã được chứng minh?

Đối với vendor cung cấp API, hỏi inventory/versioning, object/function authorization, rate/abuse control, webhook signature và credential rotation; dùng OWASP API Security Top 10 làm nguồn gợi ý, không biến Top 10 thành mười ô yes/no. Nếu dịch vụ critical, yêu cầu kiến trúc session hoặc evidence kỹ thuật thay vì chỉ policy.

Module 4 — Sự cố, khả dụng và khả năng phục hồi

• Incident plan, on-call, severity, crisis roles và lần tabletop/technical exercise gần nhất; action item đã đóng?
• Vendor xác định khách hàng bị ảnh hưởng bằng telemetry nào; contact và kênh thông báo khẩn cấp được duy trì ra sao?
• Cam kết notification bắt đầu từ phát hiện hay xác nhận; nội dung cập nhật, tần suất và final RCA?
• RPO/RTO, dependency, capacity, multi-region/backup strategy và kết quả restore/failover test phù hợp dịch vụ?
• Business continuity cho mất nhân sự, cloud/SaaS outage, ransomware, credential compromise và subprocessor failure?
• Quyền audit, cooperation, evidence preservation, regulator/customer support và chi phí response được phân bổ thế nào?

Một con số SLA đẹp không đủ nếu không biết kiến trúc và test result. Hỏi scenario cụ thể: “Nếu identity provider hoặc region chính mất, dịch vụ nào dừng, ai quyết failover và lần gần nhất đã thử khi nào?”. Điều khoản sự cố cần kết nối với playbook 72 giờ đầu của bên mua, gồm contact ngoài giờ và format dữ liệu điều tra.

Chấm điểm: tách inherent risk, control effectiveness và residual risk

Không cộng điểm yes/no rồi đặt ngưỡng 80%. Một vendor payroll thiếu marketing security policy có thể ít quan trọng hơn thiếu MFA admin; điểm trung bình che khuất control chặn deal. Đầu tiên chấm inherent risk từ data/access/criticality. Sau đó đánh giá từng control: thiết kế, coverage, bằng chứng và ngoại lệ. Cuối cùng xác định residual risk cùng quyết định: approve, approve with conditions, escalate/risk accept hoặc reject.

Critical question cần knockout hoặc escalation riêng, không bị hòa vào điểm. Ví dụ: vendor có production admin nhưng không MFA; không thể cam kết thông báo sự cố; dùng dữ liệu cho mục đích ngoài hợp đồng; không xóa được; hoặc scope audit không bao phủ dịch vụ. Risk acceptance phải có expiry và người chịu hậu quả, không phải security ký thay business owner.

Biến câu trả lời thành điều khoản và kế hoạch hành động

• Mô tả dữ liệu, mục đích, vị trí, subprocessor, security measures và hạn chế sử dụng.
• Access control/MFA/logging/encryption/vulnerability remediation tối thiểu có thể kiểm chứng.
• Incident notification, contact 24/7, cooperation, evidence, update và RCA.
• BCP/DR, SLA, RPO/RTO và quyền nhận kết quả test phù hợp criticality.
• Quyền nhận audit report/chứng nhận mới, thông báo material change và xử lý finding.
• Exit: export, transition support, revoke integration, delete/return data và xác nhận.
• Remediation plan: finding, owner hai bên, deadline, compensating control và consequence nếu trễ.

Đừng chép mọi câu trả lời vào hợp đồng; chọn những cam kết làm thay đổi residual risk. Đồng bộ với DPA, security addendum, SLA và order form để tránh mâu thuẫn. Nếu vendor nói control sẽ có quý sau và đó là điều kiện mua, ghi deadline cùng quyền xử lý khi không hoàn thành. Lời hứa trong sales call không phải control.

Sau ký hợp đồng: giám sát thay đổi thay vì gửi lại file mỗi năm

Tần suất review dựa trên tier và trigger: incident, ownership/M&A, kiến trúc/data location, subprocessor, audit exception, service degradation hoặc thay đổi scope. Thu report/chứng nhận mới, theo dõi remediation, access review và critical SLA. External rating có thể phát tín hiệu về exposure nhưng không nhìn thấy logic, quy trình hoặc phạm vi dữ liệu; dùng làm trigger điều tra, không làm phán quyết tự động.

Offboarding phải thu hồi SSO/API key/VPN, đóng account, dừng data flow, export dữ liệu, xác nhận xóa, xử lý backup và chuyển giao knowledge. Business owner xác nhận dịch vụ không còn dùng; IT/security xác nhận quyền; privacy/legal xác nhận dữ liệu. “Hợp đồng hết hạn” không tự tắt integration. Một vendor cũ còn credential là rủi ro mà questionnaire năm nào cũng đẹp không cứu được.

Kết luận: câu hỏi tốt phải thay đổi được quyết định

Questionnaire tốt không dài; nó có tỷ lệ với exposure, buộc câu trả lời gắn bằng chứng và chuyển ngoại lệ thành owner cùng cam kết. Chứng nhận giúp giảm effort nhưng không thay scope review. Khi procurement, business, legal và security dùng một residual-risk view chung, đánh giá vendor ngừng là cửa ải giấy tờ và trở thành cơ chế chọn đối tác đáng tin.