Khoảng trống giữa các audit
Audit ISO 27001 hay SOC 2 diễn ra mỗi năm một lần, hoặc lâu hơn. Trong khoảng thời gian đó, hệ thống vẫn thay đổi, team vẫn scale, vendor vẫn được thêm vào.
Với đội IT không có compliance tracking liên tục, những thay đổi này tích lũy mà không có visibility. Và đến khi audit đến, một phần trong số chúng đã trở thành vấn đề.
Dưới đây là 5 vấn đề cụ thể xuất hiện nhiều nhất trong pattern này.
1. Tài khoản không được thu hồi sau khi nhân viên nghỉ việc
Đây là vấn đề phổ biến nhất và cũng dễ bị underestimate nhất.
Khi nhân viên nghỉ việc, HR thực hiện offboarding, IT disable tài khoản email. Nhưng những hệ thống khác thì sao: AWS IAM user, GitHub repo access, database credentials được hardcode trong một project cũ, account trong SaaS tool mà team đó dùng riêng?
Không có centralized access tracking, những tài khoản này thường không được review theo cách có hệ thống. Chúng tồn tại, không active nhưng cũng không bị xóa.
Vấn đề vận hành thực sự: Tài khoản orphaned là attack vector. Nếu credential của tài khoản đó bị leak qua một breach cũ ở service khác, attacker có thể dùng nó mà không ai nhận ra ngay vì tài khoản trông như inactive. Credential stuffing là attack phổ biến và nhắm đúng vào loại tài khoản này.
ISO 27001 Control 9.2.6 và SOC 2 CC6.2 yêu cầu review định kỳ. Nhưng mục tiêu thực sự không phải là satisfy auditor mà là biết hệ thống của bạn không có cửa hậu ẩn.
2. Evidence gap tích lũy trong im lặng
SOC 2 Type 2 audit yêu cầu evidence liên tục trong suốt observation period, thường là 6 đến 12 tháng. Điều đó có nghĩa là auditor không chỉ hỏi "bạn đang làm X không?" mà hỏi "bạn đã làm X nhất quán trong 9 tháng qua chưa, và bạn có evidence không?"
Với đội IT quản lý compliance bằng spreadsheet và folder Drive, evidence thường được thu thập theo cách reactive:
- Screenshot được chụp vội khi auditor hỏi
- Log được export từ system cho khoảng thời gian gần nhất có thể lấy được
- Access review được thực hiện ngay trước audit, không phải theo lịch thực sự
Kết quả là evidence tồn tại cho một số controls nhưng thiếu cho controls khác, và nhiều evidence không có metadata rõ ràng về khi nào nó được thu thập và cho control nào.
Chi phí thực tế: Đội IT thường tốn 2 đến 4 tuần chuẩn bị cho mỗi audit, phần lớn là tìm và compile evidence đáng lẽ đã phải được tổ chức từ đầu.
3. Vendor risk không được monitor sau khi onboard
Nhiều team có quy trình vendor assessment tốt khi onboard: điền security questionnaire, check certifications, ký DPA hay BAA. Sau đó vendor đó được đánh dấu là "approved" và không ai nhìn vào nữa.
Nhưng vendor thay đổi theo thời gian:
- Subprocessor mới được thêm vào mà không có thông báo rõ ràng
- Certifications hết hạn và không được renew
- Vendor bị acquire và điều khoản dịch vụ thay đổi
- Security incident xảy ra ở phía vendor, ảnh hưởng đến data của bạn
Không có periodic vendor review tích hợp vào compliance workflow, những thay đổi này thường không được phát hiện cho đến khi xảy ra vấn đề, hoặc đến khi auditor hỏi về vendor management program của bạn.
Với doanh nghiệp xử lý PHI hay PII, đây không phải rủi ro trừu tượng. Nhiều breach thực tế bắt đầu từ third-party vendor, không phải từ hệ thống nội bộ.
4. Control drift trong infrastructure không được phát hiện
Infrastructure thay đổi liên tục trong môi trường cloud. Engineer thêm port mới vào security group để test, rồi quên đóng lại. Team tạo S3 bucket với public access để share file tạm thời, rồi bucket đó không ai nhớ đến. Database snapshot được enable logging nhưng sau một infrastructure update, setting bị reset về default.
Những thay đổi này hợp lý tại thời điểm xảy ra. Vấn đề là không có mechanism để track xem configuration hiện tại có còn khớp với baseline được approve hay không.
Đây là "configuration drift". Nó xảy ra không phải do ai cố ý làm sai, mà vì không có visibility liên tục.
Compliance framework yêu cầu periodic configuration review không phải vì auditor muốn thêm việc cho bạn, mà vì đây là loại drift duy nhất có thể phát hiện bằng cách nhìn vào.
5. Training gap ẩn trong team scale nhanh
Khi công ty scale từ 20 lên 60 người trong một năm, onboarding process thường bị kéo dài và security training bị cắt ngắn. Nhân viên mới được onboard, học tool, tham gia sprint, nhưng HIPAA training, data handling policy, incident reporting procedure thì chưa hoàn thành.
Điều này không rõ ràng ngay lập tức. Team vận hành bình thường. Không có ai nhìn thấy vấn đề vì không có tracking.
Sau 6 đến 9 tháng, một phần đáng kể team đang handle dữ liệu khách hàng mà không hiểu đầy đủ những gì họ được và không được làm. Human error trong handling PHI hay PII thường không phải từ cố ý mà từ không biết.
Tại sao những vấn đề này tồn tại song song
Năm vấn đề trên đều có một điểm chung: chúng không có triệu chứng rõ ràng cho đến khi trở thành sự cố.
Tài khoản orphaned không gây ra lỗi. Evidence gap không làm hệ thống chậm. Vendor risk không hiển thị trên dashboard. Control drift không trigger alert tự động. Training gap không tạo ra bất kỳ log nào.
Chúng chỉ xuất hiện khi auditor hỏi, khi incident xảy ra, hoặc khi khách hàng enterprise thực hiện vendor due diligence và yêu cầu bạn demonstrate compliance.
Compliance tracking liên tục không tạo ra thêm công việc. Nó biến công việc đã phải làm thành thứ gì đó visible và manageable trước khi trở thành khủng hoảng.
Một cách để bắt đầu
Không cần thay đổi toàn bộ quy trình cùng một lúc. Bắt đầu bằng câu hỏi đơn giản: trong 30 ngày qua, team bạn đã thực hiện những control nào và có evidence chưa?
Nếu câu trả lời cần nhiều hơn 5 phút để tìm ra, đó là signal đáng chú ý.
Xem thêm cách pTrackly tổ chức continuous evidence collection để bắt đầu với gap cụ thể nhất trong workflow hiện tại của bạn.