Thứ tự quan trọng hơn tốc độ sửa. Sửa vội mà không giữ log thì mất luôn khả năng biết dữ liệu nào đã bị lấy.
1. Xác nhận và phân loại (phút đầu). Tự tái hiện trên tài khoản test để chắc chắn báo cáo là thật. Xác định phạm vi: endpoint nào, dữ liệu gì, có cần đăng nhập không. Cử một người điều phối sự cố — người này không đồng thời là người viết fix.
2. Bảo toàn bằng chứng. Snapshot log truy cập, log DB, log WAF trước khi thay đổi gì. Nhiều hệ thống chỉ giữ log vài ngày; mất đoạn này thì phần điều tra sau không có dữ liệu.
3. Chặn tạm. Nếu chưa có fix an toàn ngay: tắt tính năng bằng feature flag, chặn ở WAF/edge, hoặc siết rate limit. Giảm thiệt hại trước, đúng đắn sau — nhưng đừng dừng ở đây và quên bước sau.
4. Sửa và triển khai. Fix tối thiểu, có test tái hiện đúng kịch bản khai thác (test này ở lại repo vĩnh viễn). Review nhanh nhưng vẫn phải có review. Deploy rồi xác minh lại bằng chính cách khai thác ban đầu.
5. Điều tra tác động. Rà log để trả lời: đã bị khai thác chưa, ai, bao nhiêu bản ghi. Câu trả lời quyết định bước tiếp theo. Nếu có dữ liệu cá nhân bị truy cập trái phép thì có nghĩa vụ thông báo — theo GDPR là trong 72 giờ, và Nghị định 13 cũng yêu cầu báo cáo sự cố; đây là lúc phải kéo pháp chế vào, không phải quyết định của một mình đội kỹ thuật.
6. Rà lỗi cùng loại. IDOR hiếm khi xuất hiện một chỗ. Grep toàn bộ endpoint có nhận id từ client và kiểm tra xem có bước xác thực quyền sở hữu không.
7. Hậu sự cố. Viết postmortem không đổ lỗi cá nhân: vì sao lọt qua review, vì sao không có test, vì sao không phát hiện được qua monitoring. Trả lời researcher và ghi nhận đóng góp.
Hai lỗi thường gặp: im lặng với người báo cáo (họ có thể công bố công khai) và coi việc deploy fix là kết thúc sự cố, trong khi phần điều tra tác động mới là phần có nghĩa vụ pháp lý.