Designing and developing an organizational incident management process based on ISO/IEC 27035
Start from context, not templates
Design begins with the organisation's context: legal and regulatory duties (privacy breach notification deadlines, sector rules, contractual notification windows), risk appetite, size, technology estate and existing structures such as the service desk, security operations, BCM and HR. Top management must approve the incident management policy and provide authority, resources and a named owner.
Design elements
- Policy and scope - what counts, who is covered, objectives, reporting duty, non-retaliation for good-faith reporting.
- Classification scheme - incident types mapped to the estate, plus a severity matrix combining impact (financial, operational, legal, reputational) and urgency.
- Roles and RACI - incident manager, CSIRT, owners, communications, legal, privacy and executive sponsor; deputies for absence.
- Interfaces - escalation, emergency change, BCP invocation, third-party and supply-chain contacts, law enforcement.
- Records and tooling - incident register, ticket fields, evidence store, secure communication channel.
Worked example
A retailer's draft severity matrix rates website defacement as low because no data is stolen. Design review adds reputational and regulatory impact and makes public-facing defacement high, with a mandatory communications step. Severity must be derived from impact and urgency in context, not from the attack technique.
Traps
Adopting another organisation's classification verbatim. No deputies or out-of-hours route. Leaving legal, privacy and communications out of the design until an incident occurs. Designing a process the service desk cannot operate.