Who can authorise emergency IT support actions during a business-critical incident?

During a business-critical incident, authority should sit with a pre-agreed business decision-maker who understands the organisation’s operational, legal and financial priorities. IT personnel may carry out technical measures that fall within their approved remit, but decisions that materially affect business operations, customer access, personal data or evidence should be authorised by an appropriately empowered representative of the organisation.

The authorisation model should distinguish between technical execution and business approval. For example, an IT team may be permitted to disable a suspected account, block a malicious connection or preserve system logs under standing incident procedures. By contrast, taking a major service offline, shutting down a production environment, notifying customers or accepting data loss may require explicit approval from a business leader.

A practical incident response structure commonly assigns authority across several roles:

• Incident owner: coordinates the overall response, confirms priorities and maintains the decision record.
• Business process owner: assesses the effect on essential operations and decides which services take priority.
• IT or security lead: evaluates technical risk, recommends containment and recovery actions, and confirms whether a proposed measure is technically safe.
• Data protection or legal adviser: advises where personal data, contractual duties, regulated information or potential reporting obligations are involved.
• Communications lead: controls approved messages to employees, customers, suppliers and other stakeholders.
• Executive sponsor: approves decisions with significant commercial, reputational or operational consequences.

These roles do not necessarily need to be separate people. In a smaller organisation, one director may hold several responsibilities, while an external managed IT provider may supply technical coordination. The important point is that each decision has a clearly identified owner and that technical personnel are not forced to infer business priorities during a crisis.

Before an incident, the organisation should document an authority matrix. This can specify which actions are pre-approved, which require case-by-case consent and which must be escalated to an executive or specialist adviser. Useful categories include:

• account suspension, password resets and access-token revocation;
• isolation of devices, servers, networks or cloud workloads;
• changes to firewall rules, email security controls or remote access;
• restoration of systems from backups or failover to an alternative environment;
• deletion, reimaging or other actions that could affect forensic evidence;
• contact with insurers, regulators, law enforcement, customers or suppliers;
• acceptance of temporary loss of functionality, data or connectivity.

The matrix should define the limits of delegated authority rather than simply listing job titles. A named person might approve an access change but not authorise permanent data deletion. Similarly, an IT provider may be allowed to isolate a device immediately under a documented containment rule, while approval is still required before a wider network segment is disconnected.

Emergency procedures should also allow proportionate action where waiting for approval would increase harm. This is usually handled through a pre-authorised list of protective measures, together with a requirement to notify the responsible business owner as soon as practicable. Such provisions should be specific enough to prevent unnecessary disruption. “Protect the business” is too broad; “disable a confirmed compromised account and preserve its audit records” gives the technical team a clearer boundary.

Every significant decision should be recorded with the time, action, reason, person requesting it, person approving it and person carrying it out. Where approval is given verbally or through an incident channel, it should be documented afterwards. A decision log helps the response team avoid contradictory instructions, supports later investigation and shows why a disruptive measure was considered proportionate at the time.

Authority can become unclear when several departments or business sites are affected. The organisation should identify whether local managers can make decisions for their own systems or whether control transfers to a central incident owner. Shared services, customer-facing platforms and interconnected networks normally require coordinated approval, because a local action may affect other parts of the business.

Conflicts should be resolved through defined escalation rules. For instance, an operational manager may want a system restored quickly, while the security lead may recommend keeping it isolated until its integrity has been checked. The procedure should state whose decision prevails, what evidence is required and how the risk acceptance is documented. This prevents the most senior person present, rather than the person with the relevant authority, from making an unsuitable technical decision.

Businesses should review authorisation arrangements after each major incident, significant organisational change or change to their technology estate. Staff changes, outsourced services, new cloud platforms and revised regulatory responsibilities can all make an existing authority matrix inaccurate. The objective is to ensure that emergency IT support actions are approved by someone with genuine decision rights, while technical responders have enough clearly defined authority to limit damage within those boundaries.