Tóm tắt
Mô hình vận hành compliance cho startup SaaS và công ty ITO chưa có team chuyên trách: phân vai, quản lý owner, evidence và duy trì công việc hàng tuần.
CTO kiêm nhiệm compliance vẫn vận hành được nếu CTO chỉ làm program owner, còn từng control được giao cho người đang vận hành công việc đó, có approver rõ ràng, một nguồn dữ liệu chung và nhịp rà soát hằng tuần. Mô hình thất bại khi một người vừa hiểu mọi requirement, vừa nhắc việc mọi phòng ban, vừa tự nhớ mọi deadline.
Ở nhiều công ty SaaS và ITO Việt Nam, compliance không có team riêng. CTO, Engineering Manager hoặc IT Lead nhận thêm vai trò điều phối bên cạnh việc sản phẩm và hạ tầng; policy nằm trong Word, evidence trong Drive, tiến độ trong Excel.
CTO nên giữ vai trò gì và giao việc gì?
CTO có thể là sponsor hoặc program owner, nhưng control phải được giao cho người đang vận hành công việc tương ứng. ISO/IEC 27001 cũng yêu cầu lãnh đạo phân công và truyền đạt trách nhiệm, quyền hạn cho các vai trò liên quan đến an toàn thông tin (điều khoản 5.3, ISO/IEC 27001); điều đó không có nghĩa một người làm hết.
| Nhóm công việc | Owner phù hợp | Vai trò của CTO hoặc compliance lead |
|---|---|---|
| Access, cloud, endpoint | IT hoặc Platform | Xác nhận scope và xử lý gap có ảnh hưởng lớn |
| Secure SDLC, change management | Engineering | Phê duyệt nguyên tắc và theo dõi ngoại lệ |
| Onboarding, offboarding, training | HR và IT | Bảo đảm workflow nối được giữa các đội |
| Vendor và hợp đồng | Procurement hoặc Legal | Phê duyệt risk acceptance khi cần |
| Risk, policy, audit coordination | Compliance owner kiêm nhiệm | Điều phối, báo cáo và đưa vấn đề lên management |
Nếu mọi task đều mang tên CTO, hệ thống chưa có ownership. Nó chỉ có một nơi đổ trách nhiệm. Cách xác định control owner cho từng phòng ban được mô tả chi tiết trong bài riêng.
Vì sao Word và Excel nhanh chóng quá tải?
Word phù hợp để soạn policy. Excel phù hợp để lập một danh sách. Vấn đề xuất hiện khi team dùng chúng như hệ thống vận hành:
- Không rõ requirement nào liên kết với policy hoặc control nào.
- Một evidence được sao chép sang nhiều folder.
- Owner thay đổi nhưng file không được cập nhật.
- Không có cảnh báo khi policy đến hạn review.
- Trạng thái trong spreadsheet khác với ticket của engineering.
- Kiến thức nằm trong đầu người điều phối.
Khi người đó nghỉ phép hoặc chuyển công việc, team phải dựng lại bối cảnh từ email và folder cũ. Đây là rủi ro vận hành, không chỉ là bất tiện hành chính.
Operating model tối thiểu cho team kiêm nhiệm gồm những gì?
Một program owner
Program owner quản lý phạm vi, lịch, dependency và báo cáo cho management. Người này không tự xác nhận mọi control. Họ bảo đảm đúng owner đã thực hiện và cung cấp evidence.
Control owner tại từng bộ phận
Control owner chịu trách nhiệm cho cách control vận hành. Ví dụ, HR sở hữu quy trình offboarding; IT thu hồi tài khoản; manager xác nhận ngày kết thúc. Một control có thể cần nhiều người thực hiện nhưng chỉ nên có một owner chịu trách nhiệm cuối cùng.
Approver cho nội dung có tính cam kết
Policy, risk acceptance và câu trả lời security questionnaire có thể tạo nghĩa vụ với khách hàng. Team cần chỉ rõ ai có quyền phê duyệt trước khi chia sẻ ra ngoài.
Một nguồn dữ liệu dùng chung
Requirement, control, task và evidence cần liên kết với nhau. File gốc có thể vẫn nằm trong Drive hoặc hệ thống chuyên môn, nhưng workspace compliance phải cho biết file nào là evidence hiện hành, thuộc control nào và do ai quản lý.
Nhịp vận hành hằng tuần và hằng tháng nên thế nào?
Team kiêm nhiệm không cần họp compliance dài mỗi ngày. Một nhịp ngắn, đều và có dữ liệu thường hiệu quả hơn.
Hàng tuần
- Xem task quá hạn và control vừa thay đổi trạng thái.
- Kiểm tra evidence mới hoặc evidence sắp hết hiệu lực.
- Gỡ dependency giữa HR, IT, Legal và Engineering.
- Ghi nhận thay đổi đáng kể về sản phẩm, hạ tầng hoặc vendor.
Hàng tháng
- Rà lại risk register và các risk treatment đang mở.
- Báo cáo gap quan trọng cho management.
- Kiểm tra các hoạt động định kỳ sắp đến hạn.
- Xác nhận owner còn đúng sau thay đổi nhân sự.
Tần suất chính xác phụ thuộc framework, risk và cách công ty vận hành. Mục tiêu là phát hiện thay đổi khi nó xảy ra, không phải tạo thêm một lịch họp cố định cho đẹp quy trình.
Xử lý yêu cầu evidence của khách hàng thế nào?
Một team chưa có hệ thống thường bắt đầu bằng email: hỏi IT lấy access log, tìm policy trong Drive, mở Jira để kiểm tra change request, rồi tạo folder mới cho auditor. Phần lớn thời gian được dùng để di chuyển thông tin từ nơi nó phát sinh sang nơi người review cần xem.
Với operating model rõ ràng, request được xử lý khác đi:
- Xác định requirement và control liên quan.
- Kiểm tra evidence hiện hành đã được gắn với control chưa.
- Giao phần còn thiếu cho đúng owner.
- Rà soát tính nhạy cảm và phạm vi trước khi chia sẻ.
- Lưu lại phiên bản đã gửi để dùng cho lần sau.
Đây cũng là nền tảng để trả lời security questionnaire mà không viết lại từ đầu.
AI Assistant nên làm phần nào?
AI có thể hỗ trợ người kiêm nhiệm tìm requirement liên quan, tóm tắt gap, tạo bản nháp policy hoặc gợi ý evidence cần kiểm tra. AI không nên tự phê duyệt policy, tự chấp nhận risk hoặc xác nhận một control đang hoạt động khi chưa có evidence.
Ranh giới này giúp team tiết kiệm công việc nghiên cứu và soạn thảo mà vẫn giữ trách nhiệm ở đúng người.
Khi nào công ty cần tuyển compliance chuyên trách?
Không có một ngưỡng nhân sự áp dụng cho mọi công ty. Hãy xem tải công việc và rủi ro:
- Nhiều framework chạy song song và có lịch đánh giá chồng nhau.
- Security review trở thành hoạt động thường xuyên của sales.
- Ngành có nghĩa vụ pháp lý hoặc hợp đồng cần phán đoán chuyên sâu.
- Control owner liên tục trễ vì không có người điều phối.
- Management không có dữ liệu đáng tin cậy về trạng thái compliance.
Nền tảng không thay thế vai trò cần phán đoán chuyên môn. Nó giúp công ty trì hoãn việc xây một bộ máy hành chính lớn chỉ để theo dõi file, nhắc task và tìm evidence. Dù có tuyển hay không, hãy chắc rằng chương trình bàn giao được khi người phụ trách nghỉ việc.
pTrackly hỗ trợ CTO kiêm nhiệm thế nào?
Trên pTrackly, evidence task có người phụ trách, tần suất và ngày review; người phụ trách được nhắc trước 7, 3 và 1 ngày, task quá hạn được báo cho owner, và owner, admin nhận digest các task đang mở vào thứ Hai hằng tuần. Policy có vòng phê duyệt trước khi publish; mỗi thay đổi trạng thái, giao việc và quyết định duyệt đều có lịch sử. Ask Tracky, trợ lý AI, trả lời từ dữ liệu của tổ chức, tìm task quá hạn và gap giữa các framework, và chỉ đề xuất thay đổi để owner hoặc admin duyệt; nó không tự phê duyệt policy hay chấp nhận risk. Quyết định về phạm vi, risk và cách vận hành control vẫn thuộc về CTO và các control owner.
Xem pTrackly cho SaaS, pTrackly cho ITO hoặc dùng checklist audit readiness để kiểm tra mô hình hiện tại.
Câu hỏi thường gặp
CTO có nên tự làm compliance cho công ty SaaS nhỏ không?
CTO có thể làm program owner, nhưng không nên tự thực hiện mọi control. Giao control cho người đang vận hành công việc tương ứng và giữ vai trò điều phối, phê duyệt các quyết định lớn.
Bao nhiêu thời gian mỗi tuần là đủ cho compliance kiêm nhiệm?
Không có con số chung; nó phụ thuộc số framework, phạm vi và mức độ tự động hóa. Một buổi rà soát ngắn hằng tuần dựa trên danh sách task quá hạn thường hiệu quả hơn các đợt dồn việc trước audit.
Khi nào nên tuyển người chuyên trách compliance?
Khi nhiều framework chạy song song, security review thành việc thường xuyên của sales, control owner liên tục trễ hạn, hoặc ban lãnh đạo không có dữ liệu đáng tin về trạng thái compliance.
AI có thay được người phụ trách compliance không?
Không. AI hỗ trợ tìm requirement, tóm tắt gap và soạn bản nháp; phê duyệt policy, chấp nhận risk và xác nhận control vận hành vẫn do con người chịu trách nhiệm.
