Who should own decisions about business backup solutions?
Senior leadership should retain overall accountability for business backup decisions, because backup affects operational continuity, data protection and regulatory risk. IT or a managed IT provider should advise on the technical design and administration, while department and data owners define which information is critical and how quickly it must be recoverable.
Decisions about business backup solutions should be owned through a documented governance model, with a named person accountable for each decision rather than treating backup as an unassigned IT task. Ownership should cover what is protected, how it is recovered, how long copies are retained, who can change the configuration and who approves exceptions.
A practical approach is to create a backup decision register. This records each decision, its owner, the people who provide technical or operational input, the approval date and the date for review. It should include:
- Backup scope: which servers, endpoints, applications, cloud services, databases and shared data repositories must be included.
- Recovery priorities: which systems are needed first after an incident and what level of data loss the organisation can accept.
- Retention: how long different categories of backup data must be kept, including any contractual, regulatory or internal requirements.
- Storage and access: where backup copies are held, who can reach them and which controls protect them from unauthorised alteration or deletion.
- Testing: how recovery exercises are approved, what evidence is recorded and who signs off the results.
- Exceptions: what happens when a system cannot meet the standard backup policy, including who accepts the resulting risk and when the exception is reviewed.
The person approving business risk should not be the only person involved. Data owners understand the importance and dependencies of particular information. System owners can explain application requirements, compatibility constraints and acceptable downtime. Finance or procurement may need to assess the cost and contractual implications of the chosen service. Compliance, legal or information governance specialists may need to advise on retention, privacy and access requirements.
Technical responsibility should be separated into clear activities. The administrator managing the backup platform may configure schedules, investigate failures, control permissions and maintain integrations. That person should not normally be able to approve their own exception without independent review. Separating configuration, approval and audit responsibilities reduces the risk that a mistake or unauthorised change remains unnoticed.
Decision ownership should also reflect the organisation’s structure. In a single-site business, one operational manager may own several data sets. In a multi-site organisation, local managers may identify site-specific systems while a central owner sets the common standard. Where an external managed IT provider is involved, the agreement should state which decisions remain with the customer and which operational actions the provider may take under instruction.
Ownership becomes particularly important when backup reports show a failure, a protected system changes or a new cloud application is introduced. Someone must decide whether the issue is a temporary technical fault, a gap requiring remediation or a risk that needs formal acceptance. An alert alone does not establish accountability. The process should define who reviews it, how it is recorded and when it is escalated.
Access to backup systems deserves specific ownership because privileged credentials can affect every protected copy. A designated security or systems owner should approve administrative access, review whether permissions are still necessary and ensure that departing staff or changing responsibilities trigger an access review. Recovery credentials should be available to authorised personnel who can use them during a major incident, but they should not be shared informally or left undocumented.
Responsibilities should be written into the backup policy and related procedures, not left in meeting notes. A simple responsibility matrix can show who:
- approves the policy and accepts documented risk;
- defines the recovery needs of each critical service;
- implements and maintains the technical controls;
- reviews alerts, failures and capacity issues;
- authorises recovery during an incident;
- checks that recovery tests provide usable evidence; and
- reviews the arrangement after major changes to systems, suppliers or business processes.
The arrangement should be reviewed when the organisation adopts a new application, changes its data-handling obligations, moves services to the cloud, opens or closes a site, or changes the people responsible for technology and information. A periodic review is also useful because ownership can become unclear as systems and teams develop.
S2 Technology Group can help organisations document these responsibilities, assess the technical implications of their decisions and administer an agreed backup arrangement. The business should nevertheless retain a clear record of who has authority to approve scope, risk, retention and recovery priorities. That record makes backup a governed business control rather than a technical setting with no accountable owner.
Backup decisions should be assigned according to who can accept the consequences of data loss or service disruption, not simply who manages the backup software. A technical administrator may recommend a configuration, but the owner of the affected business service should confirm that the proposed recovery point and recovery time are acceptable.
This distinction is especially important where different systems support different levels of business activity. The person responsible for a customer database may require a different recovery priority from the person responsible for an internal archive. Making those decisions at service level prevents a general backup policy from obscuring the operational importance of individual systems.
Where authority is delegated, the limits should be explicit. The documentation should state which changes can be approved without further escalation, which require senior management approval and who can accept residual risk when the agreed protection cannot be provided. This gives technical teams a clear route for action while keeping business consequences with an appropriately accountable decision-maker.
