Tóm tắt
Cách công ty SaaS và ITO Việt Nam chuẩn bị security questionnaire: xác định owner, gom evidence, trả lời nhất quán và rút ngắn thời gian security review.
Security questionnaire là bộ câu hỏi mà khách hàng dùng để đánh giá cách một nhà cung cấp bảo vệ dữ liệu, quản lý truy cập, xử lý sự cố và kiểm soát rủi ro. Với công ty SaaS hoặc ITO, đây thường là một phần của quy trình mua hàng, vendor due diligence hoặc security review trước khi ký hợp đồng.
Một questionnaire không phải là audit chứng nhận. Tuy vậy, câu trả lời thiếu nhất quán hoặc không có bằng chứng có thể khiến khách hàng yêu cầu giải trình thêm, thu hẹp phạm vi dịch vụ hoặc trì hoãn phê duyệt nhà cung cấp.
Vì sao khách hàng gửi security questionnaire?
Khách hàng enterprise cần hiểu rủi ro khi giao dữ liệu, mã nguồn hoặc một phần hệ thống cho nhà cung cấp. NIST mô tả quản lý rủi ro chuỗi cung ứng an ninh mạng là việc nhận diện, đánh giá và giảm rủi ro trong suốt vòng đời của sản phẩm và dịch vụ công nghệ.
Questionnaire giúp bộ phận procurement, security và legal thu thập thông tin theo một cấu trúc chung. Một số khách hàng dùng mẫu nội bộ. Một số dùng bộ câu hỏi đã được chuẩn hóa. Chẳng hạn, Shared Assessments SIG bao phủ các nhóm rủi ro về an ninh mạng, quyền riêng tư, quản trị dữ liệu và khả năng phục hồi kinh doanh.
Security questionnaire thường hỏi những gì?
Nội dung thay đổi theo ngành, loại dữ liệu và phạm vi dịch vụ. Phần lớn bộ câu hỏi sẽ chạm đến các nhóm sau:
| Nhóm câu hỏi | Khách hàng muốn xác minh | Evidence thường dùng |
|---|---|---|
| Quản trị bảo mật | Ai chịu trách nhiệm và chính sách được phê duyệt thế nào | Chính sách, sơ đồ trách nhiệm, biên bản phê duyệt |
| Quản lý truy cập | Ai được truy cập dữ liệu và quyền được rà soát ra sao | Cấu hình MFA, access review, hồ sơ offboarding |
| Phát triển phần mềm | Thay đổi mã nguồn được kiểm soát thế nào | Branch protection, code review, CI/CD records |
| Quản lý lỗ hổng | Team phát hiện và xử lý lỗ hổng ra sao | Báo cáo scan, pentest, ticket khắc phục |
| Ứng phó sự cố | Có quy trình phát hiện, thông báo và phục hồi hay không | Incident response plan, tabletop exercise, incident log |
| Bảo vệ dữ liệu | Dữ liệu nằm ở đâu, được mã hóa và lưu giữ bao lâu | Data flow, cấu hình encryption, retention policy |
| Nhà cung cấp phụ | Bên thứ ba nào tham gia xử lý dữ liệu | Vendor register, DPA, danh sách subprocessor |
| Business continuity | Dịch vụ được duy trì và khôi phục thế nào | BCP/DR plan, kết quả kiểm thử, backup report |
ISO 27001, SOC 2 hoặc một báo cáo pentest có thể giúp trả lời một phần câu hỏi. Chúng không tự động thay thế toàn bộ questionnaire vì khách hàng vẫn cần thông tin đúng với sản phẩm, dữ liệu và kiến trúc trong phạm vi hợp đồng.
Quy trình trả lời security questionnaire
1. Xác nhận phạm vi trước khi trả lời
Đừng bắt đầu bằng cách chuyển file cho engineering. Trước hết, hãy xác định:
- Sản phẩm hoặc dịch vụ nào đang được đánh giá?
- Công ty sẽ xử lý loại dữ liệu nào?
- Hạ tầng, nhân sự và nhà cung cấp nào nằm trong phạm vi?
- Khách hàng đang yêu cầu câu trả lời, evidence hay một chứng nhận cụ thể?
- Hạn trả lời và đầu mối phê duyệt là ai?
Phạm vi không rõ khiến team trả lời quá rộng, công bố thông tin không cần thiết hoặc cam kết cho cả hệ thống trong khi hợp đồng chỉ liên quan đến một dịch vụ.
2. Gán owner theo nhóm câu hỏi
Một người có thể điều phối questionnaire, nhưng không nên tự trả lời mọi thứ. Security xác nhận control kỹ thuật. Engineering xác nhận SDLC và hạ tầng. HR phụ trách vòng đời nhân sự. Legal rà soát điều khoản dữ liệu. Người có thẩm quyền cuối cùng phê duyệt câu trả lời mang tính cam kết.
Mỗi câu hỏi nên có owner, trạng thái và ngày rà soát. Nếu chỉ gửi spreadsheet qua email, rất khó biết phiên bản nào đã được duyệt.
3. Trả lời đúng trạng thái của control
Một cách trả lời hữu ích thường gồm bốn phần:
- Câu trả lời trực tiếp: có, không, không áp dụng hoặc đang triển khai.
- Phạm vi áp dụng: hệ thống, đội ngũ hoặc dữ liệu nào được bao phủ.
- Cách control vận hành: ai làm, làm khi nào và ghi nhận ở đâu.
- Evidence hoặc tài liệu tham chiếu: tên policy, báo cáo hoặc bản ghi liên quan.
Nếu control chưa hoàn thành, hãy ghi đúng trạng thái và kế hoạch xử lý đã được phê duyệt. Một câu trả lời trung thực, có owner và mốc xử lý rõ ràng đáng tin hơn một câu "có" nhưng không thể chứng minh.
4. Kiểm tra tính nhất quán
Questionnaire thường lặp lại cùng một chủ đề bằng nhiều cách. Một câu có thể hỏi chu kỳ access review, câu khác hỏi cách thu hồi quyền khi nhân viên nghỉ việc. Hai câu trả lời phải khớp với policy và evidence.
Hãy kiểm tra các điểm dễ mâu thuẫn:
- Policy nói review hàng quý nhưng evidence chỉ có một lần.
- Tài liệu ghi dữ liệu ở một khu vực, còn kiến trúc mới đã dùng khu vực khác.
- Sales deck nói có chứng nhận nhưng phạm vi certificate không bao phủ sản phẩm đang bán.
- Câu trả lời cũ nhắc đến nhà cung cấp đã ngừng sử dụng.
5. Tạo thư viện câu trả lời có kiểm soát
Sau lần đầu, đừng lưu questionnaire như một file độc lập rồi quên nó. Tách câu trả lời thành thư viện dùng lại, liên kết mỗi câu với control, owner, evidence và ngày rà soát.
Khi khách hàng mới gửi mẫu khác, team có thể dùng lại phần đã được phê duyệt và chỉ xử lý câu hỏi mới. Cách này cũng giảm nguy cơ sales, legal và engineering gửi ba phiên bản khác nhau của cùng một câu trả lời.
Khi nào nên dùng nền tảng compliance?
Spreadsheet vẫn dùng được khi số câu hỏi ít, chỉ có một người phụ trách và nhu cầu phát sinh hiếm. Nó bắt đầu quá tải khi nhiều khách hàng gửi questionnaire cùng lúc, evidence nằm ở nhiều hệ thống hoặc câu trả lời cần được cập nhật sau mỗi thay đổi kỹ thuật.
Một nền tảng compliance phù hợp cần cho phép team:
- Ánh xạ câu hỏi với control của ISO 27001, SOC 2 hoặc framework liên quan.
- Gán owner và theo dõi phê duyệt.
- Liên kết câu trả lời với evidence thay vì sao chép file.
- Cảnh báo khi policy hoặc evidence hết hạn.
- Dùng AI để gợi ý bản nháp dựa trên dữ liệu đã được phê duyệt, sau đó để con người kiểm tra trước khi gửi.
AI Assistant không nên tự đưa ra cam kết pháp lý hoặc tự xác nhận một control đang hoạt động. Vai trò hợp lý của AI là tìm thông tin liên quan, tạo bản nháp và chỉ ra phần còn thiếu.
Checklist trước khi gửi cho khách hàng
- [ ] Phạm vi sản phẩm, dữ liệu và hạ tầng đã được xác nhận.
- [ ] Mỗi nhóm câu hỏi có owner chịu trách nhiệm.
- [ ] Câu trả lời khớp với policy và cách team đang vận hành.
- [ ] Evidence còn hiệu lực và đúng phạm vi.
- [ ] Các câu trả lời lặp lại không mâu thuẫn.
- [ ] Legal đã rà soát nội dung có tính cam kết.
- [ ] Thông tin nhạy cảm được chia sẻ qua kênh phù hợp.
- [ ] Phiên bản cuối có người phê duyệt và ngày phê duyệt.
Security questionnaire có thay thế ISO 27001 hoặc SOC 2 không?
Không. Questionnaire là cách một khách hàng thu thập thông tin cho quyết định của họ. ISO 27001 là tiêu chuẩn cho hệ thống quản lý an toàn thông tin, còn SOC 2 là báo cáo đánh giá control theo Trust Services Criteria. Chứng nhận hoặc báo cáo độc lập có thể giảm số câu hỏi cần giải trình, nhưng khách hàng vẫn có thể hỏi thêm về phạm vi dịch vụ cụ thể.
Nếu team đang trả lời questionnaire bằng cách tìm lại tài liệu từ đầu, vấn đề không nằm ở biểu mẫu của khách hàng. Team đang thiếu một nguồn dữ liệu compliance dùng chung. pTrackly dành cho SaaS và pTrackly dành cho ITO tổ chức requirement, owner và evidence trên cùng một hệ thống để mỗi security review không trở thành một dự án mới.
