SRE Responsibilities and Boundaries

The SRE responsibility model defines the activities owned by the Managed Service SRE team and the boundaries between SRE, delivery teams, application owners and other stakeholders.

Clear responsibility boundaries are essential in a managed service environment. SRE owns the reliability and operation of services within the agreed scope, but does not become the default owner for unresolved delivery activities, application development work, platform engineering changes or activities outside the contracted service.

The purpose of these boundaries is to ensure SRE can provide a reliable operational service while maintaining clear accountability with the teams responsible for building, changing and evolving the service.

SRE responsibilities

Once a service has completed delivery, handover and hypercare, SRE owns the ongoing operational reliability of the service within the agreed service scope.

SRE responsibilities include, but are not limited to:

Area	SRE responsibility
Service operation	Operate and support the production service according to agreed service levels and operational procedures.
Monitoring and alerting	Maintain monitoring, alerting and operational visibility required to identify service-impacting issues.
Incident management	Respond to incidents, coordinate recovery activities and restore service operation.
Problem management	Analyse recurring operational issues and drive reliability improvements.
Observability	Maintain service telemetry including metrics, logs and traces within agreed responsibilities.
Operational documentation	Maintain operational procedures, runbooks and service knowledge required for operation.
Reliability engineering	Identify and implement agreed reliability improvements within operational scope.
Capacity and performance management	Monitor service performance trends and highlight operational risks.
Operational reporting	Provide visibility of service health, incidents, reliability trends and improvement opportunities.
Change support	Support approved changes through operational validation and readiness activities.
Service governance	Participate in service reviews, operational meetings and reliability discussions.

Responsibility boundaries

SRE ownership begins after a service has been accepted into managed operations.

The transition into SRE ownership requires that:

• Delivery work is complete or explicitly accepted as incomplete with an agreed owner.
• Required documentation has been provided.
• Operational requirements have been met.
• Monitoring and observability standards have been implemented.
• Known risks and limitations have been documented.
• Support responsibilities have been agreed.

SRE does not accept operational ownership of undefined or incomplete delivery responsibilities.

Activities outside SRE responsibility

The following activities are outside the responsibility of Managed Service SRE unless explicitly agreed through contract change, additional scope or a separately planned engagement.

Unfinished delivery work

SRE is not responsible for completing unfinished delivery activities. Examples include:

• Completing incomplete application development.
• Resolving delivery backlog items.
• Finishing configuration work left incomplete during delivery.
• Completing testing activities that were not finished before handover.
• Implementing missing integrations.
• Completing incomplete infrastructure build activities.

Any incomplete delivery activities must have a named owner before operational acceptance. SRE may identify gaps during operational readiness reviews, but identifying a gap does not transfer ownership to SRE.

New feature development

SRE is not responsible for implementing new application or platform features. Examples include:

• New user-facing functionality.
• New business processes.
• New application modules and integrations.
• Changes requested to support new business requirements.
• Enhancements that alter application behaviour.

Feature development remains the responsibility of the appropriate delivery or product engineering team.

Functional application changes

After transition into managed operation, SRE is not responsible for functional changes to the application. Examples include:

• Changing application workflows or business logic.
• Altering user journeys or application rules.
• Adding configuration that changes functional behaviour.

SRE may support the operational deployment of approved changes, but does not own the development or validation of functional requirements.

Platform engineering changes

SRE is not automatically responsible for engineering changes to underlying platforms unless those activities are explicitly included within the agreed service scope. Examples include:

• Major platform upgrades.
• New platform capabilities or platform redesigns.
• Migration activities or architectural changes.
• Introducing new shared services.

Where platform changes are required, ownership must be agreed with the responsible platform or engineering team.

Work outside contracted scope

SRE responsibilities are limited to the services, applications, environments and activities explicitly defined within the contract. Requests outside the agreed scope require:

• Impact assessment.
• Resource planning.
• Commercial agreement where required.
• Agreed delivery timelines.

SRE should not absorb additional responsibilities informally through operational conversations or incident activity.

Future delivery phases

SRE is not responsible for supporting future development phases without planned engagement. Future phases must:

• Be communicated with sufficient notice.
• Include appropriate technical planning.
• Include SRE involvement during design and delivery.
• Have agreed resource requirements.
• Have defined transition activities.
• Have appropriate commercial approval where required.

SRE should not be expected to provide operational readiness, support preparation or production ownership for undocumented or unplanned future releases.

Project and programme delivery activities

SRE does not own project delivery responsibilities. Examples include:

• Managing development projects.
• Coordinating delivery milestones.
• Managing third-party delivery commitments.
• Tracking project risks and dependencies.
• Delivering project outcomes.

SRE can provide operational input and reliability guidance, but delivery accountability remains with the project or engineering teams.

Data management responsibilities

SRE is not responsible for business-owned data activities. Examples include:

• Data quality issues.
• Incorrect business data and data correction activities.
• Data ownership decisions and business data validation.
• Data migration activities.

SRE may support technical recovery activities where data issues affect service availability, but ownership remains with the appropriate data or application owner.

Security Ownership

SRE supports secure operations but does not automatically assume ownership of security activities.

The default responsibility model is that security ownership remains with the appropriate security, application and platform owners.

SRE is not responsible for:

• Defining security policies.
• Approving security exceptions.
• Performing security risk assessments.
• Owning application security vulnerabilities.
• Remediating application code vulnerabilities.
• Managing compliance obligations outside the agreed service scope.

In some managed service engagements, additional security capabilities may be embedded within the SRE service, such as:

• Security engineers.
• Compliance managers.
• Security operations specialists.
• Governance or risk specialists.

These capabilities are only provided where they are explicitly defined, agreed, and resourced as part of the contract or Statement of Work (SoW).

The presence of security capability within an SRE team does not automatically transfer all security responsibilities to SRE. Responsibilities, ownership boundaries and deliverables must be clearly defined within the agreed service scope. Any additional security activities outside that scope must follow the appropriate change and commercial process.

Client responsibilities

Clients and service owners remain responsible for:

Area	Responsibility
Application ownership	Understanding application behaviour and business requirements.
Business decisions	Defining priorities, requirements and acceptable outcomes.
Functional testing	Validating application functionality before release.
Development	Building and maintaining application features.
Third-party suppliers	Managing suppliers outside the SRE service scope.
Approvals	Providing timely decisions, access and approvals required for operation.
Service knowledge	Providing sufficient information about business-critical processes.

Boundary protection principles

The following principles protect the SRE operating model.

Operational ownership does not equal development ownership

Operating a service does not make SRE responsible for building, modifying or redesigning that service.

Finding a problem does not create ownership

SRE is responsible for identifying operational issues and coordinating resolution. Ownership of the underlying cause remains with the appropriate team.

Incident response does not expand service scope

During incidents, SRE may coordinate multiple teams to restore service. Incident involvement does not transfer ownership of application, platform or business issues to SRE.

Operational support requires operational readiness

SRE cannot be accountable for reliability where required operational capabilities were not delivered or where known risks were accepted outside the SRE remit.

Additional work requires formal agreement

Requests outside the managed service scope must follow an agreed change process. Informal requests, recurring favours or incident-driven additions should not become permanent responsibilities.

Summary responsibility model

Activity	SRE ownership	Other team ownership
Running production services	Yes	Support as required
Monitoring and alerting	Yes	Provide application knowledge
Incident response	Yes	Resolve owned technical issues
Reliability improvements	Yes, within scope	Contribute where application changes are required
New features	No	Delivery / application teams
Functional changes	No	Application owners
Unfinished delivery work	No	Delivery teams
Future development phases	No, unless planned	Delivery teams
Business process changes	No	Business / application owners
Application defects	No, beyond operational support	Application teams
Platform redesign	No, unless contracted	Platform teams

Clear responsibility boundaries allow SRE to focus on its primary purpose: maintaining reliable, measurable and supportable services while ensuring ownership remains with the teams best positioned to make changes.