Scope and audience

This document is written for small and mid size digital teams that need a lean, actionable sustainability policy for websites and apps. It assumes the team owns product decisions and delivery but has limited dedicated sustainability headcount. The goal is to produce a policy you can adopt in weeks and govern reliably in sprints and procurement cycles.

Why a short operational policy wins

Long aspirational statements are easy to write and hard to use. A usable policy is concise, focuses on measurable outcomes, assigns clear ownership, and ties into existing processes such as backlog triage, procurement, and release approvals. That makes the policy a working tool rather than a public relations document.

Core sections every policy needs

Below are the minimum sections that make a sustainability policy practical and enforceable. Each section includes suggested wording you can adapt and a short note on how to operationalize it.

1. Policy statement

   Suggested wording Example: The product team will minimise avoidable digital resource use while protecting user experience and accessibility. We prioritise design and engineering choices that reduce energy use and network transfer across our web properties and mobile apps.

   Operational note Tie this statement to a single owner who is accountable for publishing targets and reporting quarterly.

2. Scope

   Suggested wording Example: This policy covers public websites, customer facing applications, and third party integrations that affect performance and data transfer. It applies to new features, significant redesigns, and major vendor contracts.

   Operational note List included systems by name if feasible. Exclude internal only systems only if you plan separate rules for them.

3. Objectives and measurable targets

   Suggested wording Example: Objectives include reducing average page weight and device CPU work, improving cache efficiency, and limiting unnecessary data collection. Targets will be set annually using baseline measurements and expressed as relative improvements or absolute thresholds.

   Operational note Use simple, verifiable KPIs such as median page weight, 75th percentile Time to Interactive, percent of page views meeting a page weight threshold, and supplier energy disclosure availability. Choose no more than three KPIs for the first year.

4. Acceptance criteria for changes

   Suggested wording Example: All feature work must document expected impact on the chosen KPIs. New features must meet the low impact design patterns checklist or include a mitigation plan approved by the sustainability owner.

   Operational note Implement this as a pull request checklist and an acceptance gate in your feature branch or deployment pipeline.

5. Measurement and evidence

   Suggested wording Example: The team will maintain baseline measurements using both lab and real user monitoring. Reports will be produced each quarter and retained for audit.

   Operational note Define the measurement methods to avoid ambiguity. Use lab tests for repeatable comparisons and RUM for real world trends. Archive raw runs and configuration so audits can reproduce the results.

6. Supplier and procurement controls

   Suggested wording Example: Procurement must require sustainability information from vendors relevant to service delivery. Contracts will include rights to request performance data and to accept mitigation plans for high impact suppliers.

   Operational note Add a short sustainability clause to request energy or efficiency disclosures and logging access that is reasonable for the service type.

7. Roles and governance

   Suggested wording Example: A named sustainability owner will coordinate policy application. Product managers, engineering managers, and procurement retain role based responsibilities documented in the governance section.

   Operational note See the governance RACI example later in the article.

8. Review cadence and exceptions

   Suggested wording Example: Policy and targets will be reviewed annually or after major architecture changes. Exception requests must explain the user or business need, propose mitigations, and receive written approval from the sustainability owner.

   Operational note Keep the exception process light but auditable. Log approvals with scope and expiry.

Practical templates you can copy

Below are short templates for the three items teams use most often: the policy summary, an acceptance checklist for feature work, and a simple supplier clause.

Policy summary template

Policy title Digital sustainability policy for product and engineering

Policy statement The team commits to reducing avoidable digital resource use while preserving accessibility and core user experience. We will define measurable targets, integrate sustainability into delivery processes, and require basic sustainability disclosure from vendors.

Scope Public websites and apps, customer facing APIs, and third party integrations that affect end user experience and data transfer.

Owner Name, role and contact

Review frequency Annual

Feature acceptance checklist template

1. Document expected change to the agreed KPIs and the measurement method.
2. Confirm caching and CDN patterns are specified and appropriate for the content.
3. Validate that images and media include responsive delivery and an estimate of transfer size.
4. Confirm tags and third party scripts are justified and listed with a retention plan.
5. If the change adds >10 percent to median page weight or degrades performance, include a mitigation plan and estimate of user benefit.
6. Obtain approval from the sustainability owner for any exception.

Supplier clause template

Supplier must provide documentation of data transfer and processing relevant to service delivery on request. Supplier will cooperate in reasonable tests of service efficiency. Contracts exceeding a defined spend threshold will require an efficiency plan or emissions disclosure aligned with industry practice.

Decision rules and acceptance criteria

Decision rules translate policy into day to day choices. They must be simple, measurable, and enforceable.

Example rule Keep default image delivery responsive and modern format enabled for all public image endpoints unless a business requirement prevents it.

Example rule Avoid shipping new third party scripts on the critical path. New tags must be justified by a named business metric and approved by product and sustainability owners.

Example rule All feature tickets must include a short estimate of additional bytes transferred and any changes to server compute per 1000 users. If the estimate exceeds the agreed threshold the feature requires an explicit mitigation plan.

Governance roles and a RACI example

Clear roles prevent miscommunication. Below is a compact RACI approach mapped to typical activities.

1. Sustainability owner Responsible for maintaining the policy, approving exceptions, and publishing quarterly reports.
2. Product manager Accountable for including sustainability acceptances in feature scope and for prioritising mitigations when necessary.
3. Engineering manager Consulted on technical feasibility and responsible for ensuring checklists are enforced in code reviews.
4. Procurement lead Responsible for adding clauses to vendor contracts and screening suppliers during the sourcing process.
5. QA or Release manager Informed of exceptions and responsible for ensuring that accepted changes are tested against the documented KPIs.

Measurement strategy

A practical measurement strategy uses two complementary approaches. Lab tests capture repeatable comparisons and regressions. Real user monitoring captures actual user device and network conditions and reveals distributional effects.

For lab tests pick a representative set of pages and device network presets. Run tests consistently and store configuration and raw output. For RUM capture the KPIs you selected and segment results by device type, geography, and traffic source.

Report the KPIs each quarter, include a short narrative on major changes, and keep the raw data so changes can be audited.

Rollout roadmap for the first 90 days

1. Week 1 to 2 Draft the one page policy summary and identify the named owner. Publish for comment internally.
2. Week 3 to 4 Run a quick baseline measurement on the chosen KPIs and pick the first year targets.
3. Week 5 to 6 Add the acceptance checklist to the definition of done and set it as a required item in pull requests for new features.
4. Week 7 to 9 Update procurement templates with the supplier clause and screen major vendors.
5. Week 10 to 12 Train product and engineering on the checklist and publish the first short quarterly report with baseline measurements.

Common operational pitfalls and how to avoid them

Pitfall The policy is too broad and becomes ignored. Avoidance Keep the policy focused on systems you control and limit the initial KPI set.

Pitfall Measurement is inconsistent. Avoidance Standardise test pages and RUM metrics and store raw runs and configurations.

Pitfall Procurement forgets to enforce clauses. Avoidance Make sustainability checks part of final contract signoff and include procurement in governance meetings.

How to scale the policy as the team grows

Once the policy is stable add one new KPI per year, extend supplier disclosure requirements for critical vendors, and embed sustainability acceptance into user research and analytics design. Consider a lightweight audit once a year that reproduces the key lab tests and reviews exception logs.

Next steps you can implement this week

Choose an owner and publish the one page policy summary. Run a small set of lab tests on priority pages to establish a baseline. Add the acceptance checklist to the definition of done. Update procurement templates to include the supplier clause for upcoming renewals.

Those steps convert a policy from words on a page into repeatable governance that fits into existing delivery workflows.