Owner, Operator and Brand: Who Owns Data, SLAs and Operational Change?

Three roles, one accountability gap

In mature service organizations and on large, asset-heavy sites, the functions rarely sit in a single position. The brand sets the promise to the customer and the standards of experience, the operator runs daily delivery through support and technical teams, and the owner carries end-to-end accountability for the result across the entire lifecycle. When these three circles are not separated, a classic failure appears: when a service degrades or an incident strikes, no single person is accountable, escalation is slow, root causes go unaddressed, and improvement stalls in coordination gaps.

In ITSM terms, the service owner is the single point of accountability for a specific service regardless of where its components and support staff physically sit. The owner agrees targets and SLAs, represents the service to the organization and at change advisory boards, and ensures fixes are implemented through proper change control. The operator — support groups, engineers, and contractors — executes the agreed work, while the brand and business sponsor define what level of quality and user experience is genuinely required.

The first rule of any governance model follows: fix in writing who sets requirements, who executes, and who answers for the outcome, in service agreements and an accountability matrix rather than in the heads of managers.

• Brand — owner of the customer promise and experience standards (consulted on technique, accountable for experience quality).
• Operator — executor and coordinator of daily delivery, support, and restoration.
• Owner — the named individual accountable for the service or asset outcome overall.

Who owns the data: owner, steward, custodian

Data is an asset, and every asset needs a business owner. The data owner holds ultimate business accountability for a data domain: defining its value and classification, approving who gets access and on what basis, and initiating archiving or deletion when operational need ends. A data steward manages the day-to-day work within the domain — maintaining glossary definitions, monitoring data quality, and processing access requests. Technical custodians operate the infrastructure: storage, backups, encryption, and access controls at the system level.

The most common error is to name a database administrator, the security team, or the IT director as the data owner. Such specialists are custodians of infrastructure, not owners of a business asset. Only the business function whose work depends on the data can judge its true criticality and the consequences of a leak. When the owner does not understand the value and lifecycle of an asset, protection becomes either needlessly expensive or leaves risks unaddressed.

Regulators and frameworks differ by jurisdiction, and in some countries (for example Russia) the law may define an 'operator' who organizes and processes personal data rather than a 'data owner' as such; the owner role then exists in practice as an internal representative of that operator with decision rights. Treat this as general context, not legal advice, and verify the current rules that apply to your data.

• Data owner: classification, value, access approval, lifecycle decisions.
• Data steward: daily quality, definitions, access-request handling.
• Data custodian: storage, backups, encryption, technical enforcement of policy.

Who owns the SLA: service owner versus service level manager

Service levels are owned by two distinct but closely linked roles. The service level manager is accountable for the service level management process as a whole — for the existence and performance of all SLAs across the company and for the final word on service-level targets. The service owner is accountable for a specific service: delivering it at the agreed level, translating business requirements into understandable tasks, representing the service in the organization and at change advisory boards, and carrying duties across change, incident, and request management.

These two roles are the ones most often confused. The boundary is simple: the service level manager owns the process and all SLAs, while the service owner owns particular services and their levels within many processes. The roles must interact closely but must not merge, or targets are left without an owner and SLA breaches without anyone driving corrective action.

The owner may delegate day-to-day operations to a service manager, but the service owner remains accountable and on record. In practice this means every SLA has a named owner who investigates breaches, drives corrective actions, and reviews targets in quarterly service reviews with the business, measuring not only process metrics but real customer satisfaction.

• Service level manager: owns the SLA process and final service-level targets.
• Service owner: answers for delivering specific services to agreed levels.
• Service manager: executes daily duties on delegation while the owner remains accountable.

Who authorizes operational change

Operational changes — configuration updates, equipment replacement, data migration — must pass through change management rather than be decided by a single executor. A change manager runs the process and convenes a change advisory board (CAB) that includes the owners of all affected services and technical experts. The service owner represents the service at the CAB, evaluates the risk of each change to it, and is responsible for ensuring that a found solution to a problem is implemented through the proper controls of change and release management.

The brand and business sponsor should not become technical approvers of every routine request; their role is consultative, confirming business requirements and priorities. Otherwise the approval body bloats, decisions slow down, and accountability dissolves among participants who lack domain expertise.

Emergency changes follow a different rule. A named senior owner — typically the service owner or an IT executive — must have authority to decide immediately and document the decision within an agreed period, commonly 'decide now, review within 24 hours'. Without such a role, urgent changes are either blocked waiting for a quorum or executed with no trace; both are dangerous.

• Routine change: change manager plus CAB with owners of affected services.
• Brand/business: consulted on requirements, not approving each technical request.
• Emergency change: named senior owner, decide now, document and review post hoc.

Follow the one-accountable rule

A RACI matrix separates four levels of involvement: Responsible (does the work), Accountable (owns the result and has final decision authority), Consulted (advises before a decision), and Informed (kept updated). The governing rule is one Accountable per task or outcome: accountability for the result cannot be delegated or split between several people. Many people can be Responsible for execution, but the owner of the outcome is one, or 'no one' becomes accountable when things go wrong.

The typical mistake is to name a whole team or department as Accountable. That reproduces the very accountability gap the role exists to close: under pressure, an individual decides, not a committee. If workload is the concern, narrow the service scope or appoint a deputy, but keep a single named owner on record.

The matrix earns its keep not only at start-up but through organizational change and mergers. Acquired services often run for months or years in a governance vacuum while integration teams focus on infrastructure. The recommendation is to run a service-ownership mapping exercise as part of every integration playbook and assign at least a provisional owner within the first 30 days so SLAs and vendor contracts do not drift.

Ground accountability in the asset record

Role separation does not work unless it is recorded in the systems of record. IT asset management (ITAM) covers detecting, tracking, managing, and optimizing assets through all stages of their lifecycle and is an enabling competency for information security, configuration and change management, disaster recovery, and IT financial management. Without knowing which assets exist and how they are configured, an organization cannot determine whether a configuration is correct or detect unauthorized changes.

The owner of a service or asset should be bound to its record in the service catalog and configuration management database (CMDB). Accountability for retirement matters as much as for creation: the owner role stays active until the service is fully decommissioned, covering migration of dependent users, closure of vendor contracts, and removal of records from the CMDB. Releasing the role too early leaves decommissioning orphaned and produces 'zombie services' that keep consuming budget with no one accountable for shutting them down.

In practice, tie the role to a signed decommission checklist rather than a project milestone, and run quarterly reviews of the accountability matrix with the business. Then data, SLAs, and operational changes each have an owner, and accountability follows the structure instead of a ceremonial document.