IT-Governance

This is not incompetence. It is the system behaving exactly as it did before, including in the room where the review takes place. Describing the incident instead of explaining it Most incident post-mortems or retrospectives reconstruct the sequence of events. What happened, in what order, and what could have been done differently. Useful, but shallow. The more important question is usually skipped: what had to be true about the organisation for this to happen at all? ...

Most organisations are aware of this. Very few act on it. The result is a detection posture that looks busy, looks measured, and quietly fails in the places that matter. This is where breaches tend to settle in and make themselves comfortable. A library of yesterday’s attacks Detection engineering is usually reactive. Something happens, a technique is identified, a rule is written. Over time this builds a library of detections that reflects what has already been seen, filtered through whatever incidents and intelligence happened to reach the team. ...

Architecture reviews exist to catch problems before they become expensive. In practice, most reviews catch a different set of problems from the ones they were designed to find, and miss a different set from the ones that will eventually cause trouble. This is not because the reviewers lack competence. It is because most architecture reviews are not designed to produce understanding. They are designed to produce alignment and distribute accountability. Once that is the function, the outcome is predictable. ...