Incident response is having a defined person and process to pick up a failure when it happens, diagnose it, restore service, and record what caused it, rather than the work landing on whoever happened to touch the system last.
Let's TalkThere is a defined person on it, so the first question is not who is dealing with this.
Response stops defaulting to whoever last touched the system and happens to be available.
A short account afterwards, so the business understands the event rather than merely noticing it.
Causes get fixed rather than symptoms, which is what prevents the second occurrence.
This is one part of our maintenance and support work. Engagements rarely stay in one box: a platform rollout turns into something custom, and both then need looking after. That is why our software development and implementation practice treats implementation, custom development, and ongoing support as one continuous piece of work rather than three separate vendors.