Trả lời ngắn
ISO 27001 cho startup nên bắt đầu với phạm vi nhỏ quanh sản phẩm chính, chia trách nhiệm theo domain và giữ tài liệu vừa đủ, kể cả khi chưa có người riêng.
ISO 27001 cho startup khả thi khi làm theo quy mô thật của công ty: phạm vi ISMS nhỏ quanh sản phẩm và dữ liệu khách hàng, control chọn theo đánh giá rủi ro thay vì áp cả 93 control, trách nhiệm chia theo domain cho người đang làm, và tài liệu ngắn nhưng được dùng thật. ISO/IEC 27001:2022 áp dụng cho tổ chức mọi quy mô, nên một startup 15 người vẫn có thể đạt chứng nhận.
Startup có cần ISO 27001 không?
Startup cần ISO 27001 khi khách hàng hoặc thị trường yêu cầu, không phải vì giai đoạn phát triển. Tín hiệu rõ nhất là khách hàng doanh nghiệp gửi bảng câu hỏi bảo mật hoặc hỏi chứng chỉ trong vendor assessment, hoặc khi bạn nhắm thị trường như Nhật Bản, EU, Singapore nơi ISO 27001 thường được hỏi. Nếu khách hàng chủ yếu là doanh nghiệp Mỹ, SOC 2 có thể được hỏi nhiều hơn; so sánh hai lựa chọn trong ISO 27001 vs SOC 2. Nếu chưa có khách hàng nào yêu cầu, startup có thể bắt đầu với các control nền tảng (MFA, quản lý quyền truy cập, sao lưu, xử lý sự cố) và để chứng nhận sau khi có business case.
Startup nên xác định phạm vi ISMS thế nào?
Sai lầm phổ biến nhất là đưa toàn bộ tổ chức vào phạm vi ngay từ đầu. Phạm vi nên bao quanh thứ khách hàng thực sự quan tâm: sản phẩm hoặc dịch vụ xử lý dữ liệu nhạy cảm nhất, với ranh giới hệ thống rõ ràng, ví dụ "nền tảng SaaS chạy trên AWS, gồm dữ liệu khách hàng, hạ tầng backend và quy trình phát triển". Phạm vi nhỏ và rõ giúp giảm số control và evidence cần quản lý, rút ngắn audit và dễ duy trì khi team còn mỏng; khi công ty lớn lên, phạm vi có thể mở rộng ở các kỳ đánh giá sau.
| Câu hỏi khi chọn phạm vi | Ví dụ cho startup SaaS |
|---|---|
| Sản phẩm nào khách hàng hỏi về bảo mật? | Ứng dụng web và API chính |
| Dữ liệu nào cần bảo vệ? | Dữ liệu khách hàng doanh nghiệp, thông tin đăng nhập, mã nguồn |
| Hệ thống nào chứa và xử lý dữ liệu đó? | Tài khoản cloud production, repository, công cụ CI/CD |
| Ai có quyền truy cập? | Đội kỹ thuật, support, nhà thầu phụ nếu có |
| Địa điểm vật lý nào liên quan? | Văn phòng (nếu có) hoặc làm việc từ xa |
Startup nên chọn control Annex A như thế nào?
Annex A của ISO 27001:2022 có 93 control trong 4 nhóm: tổ chức (A.5, 37 control), con người (A.6, 8), vật lý (A.7, 14) và công nghệ (A.8, 34). Startup chọn control dựa trên đánh giá rủi ro, rồi ghi lý do áp dụng hoặc loại trừ từng control trong Statement of Applicability (SoA); số control áp dụng tùy rủi ro và phạm vi, không có con số chuẩn. Ví dụ, team làm việc hoàn toàn từ xa trên cloud có thể loại trừ một số control vật lý với lý do rõ ràng. Với startup công nghệ, các nhóm thường được ưu tiên là:
- A.8 công nghệ: quyền truy cập, xác thực, mã hóa, phát triển an toàn, sao lưu, ghi log.
- A.5 tổ chức: chính sách an toàn thông tin, quản lý tài sản, nhà cung cấp, xử lý sự cố.
- A.6 con người: onboarding và offboarding, đào tạo nhận thức, cam kết bảo mật.
- A.7 vật lý: ở mức tối thiểu nếu không có văn phòng hay hạ tầng riêng.
Danh sách đầy đủ các bước và tài liệu bắt buộc có trong ISO 27001 checklist.
Không có người lo compliance riêng thì làm thế nào?
Đây là thực tế của hầu hết startup: công việc compliance rơi vào CTO, engineering lead hoặc product manager kiêm nhiệm. Cách làm khả thi là chia trách nhiệm theo domain chứ không dồn cho một người: CTO sở hữu control kỹ thuật, người phụ trách nhân sự sở hữu control con người, CEO phê duyệt chính sách và chủ trì management review như điều khoản 5 yêu cầu. Mỗi người chỉ cần hiểu phần của mình. Tài liệu nên vừa đủ: một chính sách ngắn, rõ, được review định kỳ có giá trị hơn bộ tài liệu dài không ai đọc. Evidence nên được thu thập theo lịch thay vì chạy nước rút trước mỗi kỳ audit. Internal audit phải do người không trực tiếp vận hành phần được audit thực hiện, hoặc thuê bên ngoài.
Chi phí và thời gian ISO 27001 cho startup ra sao?
Cả hai phụ thuộc phạm vi, số nhân sự trong phạm vi và mức độ control đã chạy sẵn. Chi phí gồm phí tổ chức chứng nhận (tính theo số ngày audit, phụ thuộc quy mô và độ phức tạp), chi phí tư vấn hoặc nền tảng, và thời gian nội bộ; xem chi phí triển khai ISO 27001 tại Việt Nam. Về thời gian, ISO 27001 mất bao lâu phân tích từng giai đoạn; mốc 3 tuần readiness và 4 tuần audit của pTrackly (và một khách hàng) có được vì ISMS đã vận hành sẵn, nên chỉ là ví dụ.
pTrackly hỗ trợ startup triển khai ISO 27001 thế nào?
pTrackly tạo sẵn control, mẫu chính sách và evidence task cho ISO 27001:2022; mỗi task có người phụ trách, tần suất và nhắc việc trước hạn, nên team kiêm nhiệm không phải tự nhớ lịch. Một số evidence có thể chạy kiểm tra qua tích hợp như AWS, Google Cloud, GitHub hay Google Workspace; phần còn lại được tải lên theo mẫu. Nếu sau này cần thêm SOC 2, control dùng chung được tái sử dụng. pTrackly không quyết định phạm vi hay rủi ro thay bạn và không cấp chứng chỉ. Xem giải pháp cho startup và trang ISO 27001.
Câu hỏi thường gặp
Startup ở giai đoạn nào nên bắt đầu chuẩn bị ISO 27001?
Khi bắt đầu có khách hàng doanh nghiệp, khi sales nhận bảng câu hỏi bảo mật, hoặc khi chuẩn bị vào thị trường thường hỏi ISO 27001. Nếu chưa có business case, hãy làm control nền tảng trước.
Startup có thể tự triển khai mà không thuê tư vấn không?
Có thể, đặc biệt nếu team có nền tảng kỹ thuật và dùng công cụ hỗ trợ. Giai đoạn cần tư vấn nhất thường là đánh giá rủi ro lần đầu và chuẩn bị audit.
Internal audit có bắt buộc với startup không?
Có. Điều khoản 9.2 áp dụng cho mọi quy mô; internal auditor có thể là người trong công ty không trực tiếp vận hành phần được audit, hoặc một bên độc lập.
Startup có nên làm SOC 2 thay vì ISO 27001 không?
Tùy khách hàng. Khách hàng Mỹ thường hỏi báo cáo SOC 2; khách hàng Nhật Bản và châu Âu thường hỏi chứng chỉ ISO 27001. Control của hai framework trùng nhau nhiều, nên làm một cái trước giúp cái sau nhanh hơn.
Nguồn: ISO/IEC 27001:2022
pTrackly giúp bạn triển khai ISO 27001 nhanh hơn với templates và evidence collection tự động.
Đặt Demo Miễn Phí