Service standards for an analytics service, from freshness to incident response

Privacy first measurement service standards should tell a team when collection may run, when a report may inform a decision and when either must stop. They are not a single uptime promise. A technically available dashboard can still contain stale, inaccessible or unauthorised data.

This method was checked on 5 September 2026 for organisations in England. It provides blank indicators, not universal targets. Owners must set thresholds from user need, risk and system behaviour, with qualified specialist review.

What to take away

Give every standard a complete definition

For each indicator, record the service boundary, unit, calculation, window, data origin, owner and target. Add exclusions, alert route and decision consequence.

The target figures are illustrative starting ranges, not universal service levels.

The GOV.UK Service Standard sets expectations for public services in England across performance, security, privacy, accessibility and iteration. It does not set service levels for a private analytics deployment, but it gives a structure for defining measures before launch. A private team must still choose its own thresholds.

Freshness and completeness

Define freshness as elapsed time between an eligible event and its availability in a named report. State units and percentile or maximum treatment. A breach may first require a visible stale-data label.

For a near-real-time dashboard, an illustrative start is a median under 60 seconds, a 95th percentile under 5 minutes and a maximum under 15 minutes. Label data stale after 30 minutes. For a daily batch, a maximum of 2 hours and a stale label after 6 hours are typical starting points.

Completeness needs an independent denominator, such as eligible orders in an operational system. Define both populations first:

completeness (%) = eligible records present in the measurement output / eligible records in the approved comparison source x 100

Both populations cover the same period, geography and inclusion rules. Exclude documented cancellations or test traffic consistently. Review if the comparison changes or unexplained variance exceeds tolerance. Completeness still says nothing about causation.

An illustrative start for core order reporting is a target of 99.5%, with an alert below 99% or when unexplained variance exceeds 0.5 percentage points.

Permission-state integrity

Maintain synthetic tests for acceptance, refusal and withdrawal on relevant collection routes. Never average a prohibited collection event away. One confirmed unapproved field should invoke the stated stop and investigation route.

In England, the Privacy and Electronic Communications Regulations 2003 and UK GDPR govern storage and access to information on user devices. The ICO's storage and access technology guidance is UK-wide and requires analysis of actual operations and purposes, not a cookie banner check alone. A qualified reviewer should set the expected behaviour for each acceptance, refusal and withdrawal case.

Security operations

Specify times for alert acknowledgement, triage and containment by severity, leaving figures blank until security approves them. Monitor privileged access, configuration changes and service identities.

The NCSC operational security guidance covers incident planning, activity logging and periodic review for SaaS use in the UK. It supports security evidence for local alerts, access removal and recovery, which a supplier's service commitment does not prove.

Accessible reporting and support

Set a standard for critical journeys, not just pages scanned. Name the dashboard, export and support route each user group needs. Track barriers by severity, affected task, workaround and repair date.

GOV.UK's testing guidance calls for automated and manual checks and assistive-technology coverage in government services. In England, public bodies also have duties under the Equality Act 2010 to make reasonable adjustments. Private analytics services must determine their own legal position and representative user coverage.

Incident and evidence standards

Define the elapsed time from detection to internal escalation separately from external notification. Use illustrative starting ranges by severity:

These figures require security approval and do not replace legal deadlines.

The ICO's breach guide sets out the UK GDPR test. Organisations need detection, investigation and internal reporting procedures, must assess risk and must document personal data breaches.

Under UK GDPR and the Data Protection Act 2018, the 72-hour notification clock runs from awareness where notification is required. A named specialist decides whether an incident is a personal-data breach and what notification is required.

Evidence standards should require a version, timestamp, responsible person and immutable location for releases, approvals, tests, exceptions and incidents. Set retention according to a justified schedule. Retaining everything indefinitely is not an audit strategy.

Review triggers and consequences

Review a standard when the metric definition, permission interface, data route, supplier, user need or risk changes. Repeated breaches can indicate that a target or service design is wrong. Tightening a number without funding the response is cosmetic; loosening it to make a chart green hides the decision risk.

Write the consequence beside the threshold: label stale, restrict access, suppress a report, pause collection, roll back a release or convene specialist review. The service owner decides business use, while privacy and security owners retain authority over their gates. That division stops an operational deadline from converting a failed control into an assumed approval.

Before you act, check that the recorded boundary, unit, calculation, window, origin, owner and target still match the live service. Confirm the independent denominator, permission-state tests, alert times and evidence schedule remain valid. If any has changed, treat the standard as due for review.

Common questions

Why is a single uptime promise not enough for a measurement service?

A dashboard can be technically available while data is stale, access is wrong or collection is unlawful. The standards must cover freshness, completeness, permission state, security and evidence, not just server availability.

How should completeness be calculated and what are its limits?

Divide eligible records present in the measurement output by eligible records in the approved comparison source, then multiply by 100. Both populations must cover the same period, geography and inclusion rules. Exclude documented cancellations or test traffic consistently. A high percentage does not prove lawful collection or decision impact.

What should happen when a standard is breached repeatedly?

Treat repeated breaches as a design or target problem. Review the standard, then either fund the response or change the service, not just the number.