What should an emergency IT support agreement define before an incident?

An emergency IT support agreement should turn assumptions into precise, testable rules. It needs to explain how the arrangement operates in practice, what evidence must be preserved, how technical decisions are controlled, how information is handled and what happens when the agreed process needs to change.

Define the contractual relationship

Identify the legal entities, the services included, the documents that form part of the agreement and which document takes precedence if wording conflicts. Define terms such as “incident”, “service”, “business data”, “outage”, “containment” and “restoration”. This prevents a disagreement over terminology from delaying a technical decision.

The agreement should also state its period of validity, renewal arrangements and the circumstances in which either party can amend or end it. If an organisation changes its trading name, ownership, sites or technology estate, the agreement should specify how those changes are recorded rather than relying on informal conversations.

Describe the operating model in practical terms

A useful agreement explains what the provider may do during an incident and which actions require additional approval. Examples include isolating a device, disabling an account, blocking a connection, restoring a backup, applying a configuration change or engaging another supplier. It should distinguish between actions intended to contain immediate harm and actions that alter production systems or business data.

It should also define how technical evidence is treated. The parties may need rules for preserving logs, disk images, email headers, firewall records and relevant user reports. The agreement can state who collects each type of evidence, how it is stored, who may access it and when it may be released to insurers, legal advisers, regulators or law enforcement. This is particularly important where an incident may later require investigation or legal disclosure.

Set out dependencies and decision points

Emergency support can depend on internet providers, cloud platforms, software vendors, hardware suppliers, cyber-insurance requirements or an organisation’s internal approval process. The agreement should identify these dependencies and explain what happens if a third party must take action. It should record whether the provider may contact that third party directly, whether the customer must authorise the contact and how information is shared.

Business continuity decisions should be clear as well. For example, the agreement can specify who decides whether to operate from a backup system, restore a service in a limited mode, revert a change or keep a system isolated. Separating technical recommendations from business decisions helps prevent confusion about who accepted the operational risk.

Make information-handling requirements specific

General confidentiality wording is rarely enough for an emergency arrangement. Define the categories of information that may be accessed, the permitted methods of transfer, the controls for privileged credentials and the records that must be retained. Where remote administration tools are used, the agreement should cover authorisation, session logging, user identification and the removal or review of access after the work is complete.

If personal data, financial information, intellectual property or regulated records may be involved, state how the parties will cooperate with the organisation’s data-protection procedures. The agreement should not assume that emergency circumstances remove the need for appropriate safeguards.

Clarify commercial treatment without ambiguity

The financial section should separate work included within the agreement from work charged separately. It can address investigative work, restoration, travel, replacement equipment, third-party costs, specialist consultancy and remedial projects. If approval limits or spending caps apply, state who can approve expenditure and what happens when an action is necessary to prevent further damage but approval cannot be obtained immediately.

Also define the records used to support an invoice, such as incident references, work logs or supplier charges. Clear commercial rules reduce the risk of a technical dispute becoming a billing dispute while an incident is still being resolved.

Specify records and closure requirements

At the end of an incident, the agreement should require a consistent record of the symptoms, findings, actions taken, affected services, outstanding risks and recovery status. It should distinguish between restoring a service and resolving the underlying cause; a system may be operational while further corrective work remains necessary.

Closure should require confirmation of any residual risk, temporary workaround or follow-up task. Where appropriate, the record should capture lessons about monitoring, backups, configuration, staff procedures or supplier dependencies. The agreement can then require those actions to be assigned, tracked and reviewed rather than allowing them to disappear when the immediate disruption ends.

Include assurance and change control

An emergency agreement should be checked against the organisation’s actual systems, contacts and working practices. A structured review can confirm that the listed services remain accurate, access still functions, evidence can be obtained and decision-makers understand their roles. Testing should be planned carefully so that it does not create unnecessary operational risk.

Finally, define when the agreement must be updated: for example, after a major technology change, acquisition, office move, change of insurer, significant incident or alteration to the organisation’s risk profile. A document that accurately described last year’s systems may not govern the next incident effectively.

For a small or medium-sized business, the most useful test is whether an unfamiliar person could read the agreement and understand what can happen next without relying on informal knowledge. S2 Technology Group can help organisations around Stourbridge, Kinver, Wordsley, Kingswinford, Kidderminster, Halesowen, Dudley and neighbouring areas review the technical and governance detail behind an emergency IT support arrangement.