Architecture Survives Incidents. Configurations Do Not.

Post-incident reviews tend to land at the configuration layer because that is where the change is most operationally feasible. The MFA policy was loose; we tighten it. The conditional-access rule had an exception; we remove it. The service account had broad permissions; we narrow them. Each change is reasonable. None of them are architecture.

Architecture sits one level above. The architecture-level question after an incident is whether the design produced the configuration that failed, or whether the design was sound and the configuration drifted away from it. The MFA policy was loose because the design treated identity assurance as a single decision, not as a continuous one. The conditional-access exception existed because the design granted exceptions individually rather than through a structured override. The service account had broad permissions because the design did not place machine identities under the same lifecycle as humans.

A post-incident review that does not reach the architectural cause produces a configuration patch that satisfies the auditor and leaves the same incident in scope for next year. A review that reaches it produces a design change that retires the class of incident.

This is the work we do. When we engage on incident response, we run the configuration tightening at the same time as the architectural review — so the immediate ask is satisfied while the systemic cause is being closed.