Ken and others have come close to pointing out the crux of the problem here, but I haven't seen anyone call out the well-proven solution by name: the
Incident Command System.
I have been a huge proponent of ICS as a structured means of handling critical incidents in the Internet services sector, as my career focus has been on designing/building/delivering stuff that has to meet >99.99% availability requirements. My first exposure to ICS was actually during some hard-core volunteer disaster-response training, where we were actually taught the full ICS curriculum by mistake -- the volunteers were apparently supposed to get some weaksauce short-form version instead, but we got the whole monty. I not only took to ICS naturally, as it was very similar to how I'd been running Operations teams for years at that point, but (along with others) did a lot of work on how to apply ICS effectively in the context of critical Internet services vs. its origin managing public safety problems.
To Ken's point, the flow of control in ICS may or may not align cleanly with normal command structure. This is because incident management is, by definition, different from the everyday business of the agencies involved. Under ICS the command structure is role-based, not politics-based, and does not necessarily leave room for command staff (e.g. Region Majors) to feel like they are Contributing Meaningfully To Team Success by Issuing Important Orders.
Few things shock me these days, but when I run into an agency that doesn't have
at least two operating modes (everyday and ICS) it really bugs the crap out of me. If I ever get tired of doing the technology thing, I'm pretty sure I could make a very good living as an independent consultant doing agency-level ICS training, despite all the free resources out there on how to apply ICS in the public safety context.