Implementing incident management processes and managing information security incidents
Operating the process
Implementation turns design into routine: one intake point for reports, a ticket for every event including false positives, triage against agreed criteria, and a named incident manager with authority to escalate. The incident record should capture what was known, what was decided, by whom and when - memory reconstructs badly after a long night.
Managing the incident
Manage by severity. For major incidents, switch to crisis mode: a single commander, a fixed communication rhythm, a decision log and an executive sponsor. Keep stakeholders informed with facts and next update times, not reassurance. Involve legal, privacy, HR and communications early; notification deadlines run from awareness, not from certainty. Handle evidence with chain of custody and hashes, and keep distribution need-to-know.
Worked example
A service desk ticket reports a shared mailbox sending odd invoices. Triage links it to a recent phishing campaign; the incident manager raises severity, disables the account, blocks the sender domain, checks for forwarding rules, and asks finance to verify no payment details changed. Communications tells staff what to report. Closure records credential theft without MFA as the root cause.
Traps
Letting the loudest technical voice become the incident manager. Waiting for complete certainty before notifying. Mixing an incident channel with general chat. Reconstructing the timeline only at the end. Treating a false positive as waste - it is tuning data.