Contracts and support promises

Introduction

Commercial promises quickly become operational obligations. A young SaaS company should be careful not to promise enterprise-grade support, availability or recovery before the platform and team can evidence it.

This does not mean avoiding commitments. It means making commitments that match the current stage of the business. A Pilot can have cautious terms. Early Production can have clear but limited support hours. Mature Production can increase promises when monitoring, incident response, backups, failover and staffing can support them.

Why this matters

Contracts are not separate from architecture. If a contract promises rapid incident notification, the team needs an incident process. If it promises deletion, the data model and backup position need to support deletion. If it promises uptime, the platform, monitoring and support model need to make that credible.

The danger is not only legal exposure. The bigger practical risk is that sales promises create operational debt. A small team can accidentally commit to a service level that requires a larger support function, more expensive infrastructure or a recovery model that does not yet exist.

Detailed commercial positions

At minimum, the company should decide:

• Terms of service.
• Acceptable use policy.
• Support hours.
• SLA or no-SLA position.
• Incident notification timings.
• Recovery point objective and recovery time objective, where promised or implied.
• Customer security, privacy and breach-notification contacts.
• Controller/Processor and DPA notification responsibilities.
• Data retention commitments.
• Exit and data export.
• Liability expectations.
• Whether Pilot users receive different terms from Production users.
• Whether enterprise customers can negotiate bespoke terms.

Practical guidance

Start with plain-language commitments. If support is best-effort during Pilot, say so. If downtime may be needed for out-of-hours updates, say so. If Pilot data may need to be deleted or recreated, say so before users enter anything valuable.

As the product matures, align each contractual promise with evidence:

• Support hours should match named people or a named rota.
• Incident notification should match the incident response procedure.
• Breach notification should match Controller/Processor position, contract terms, DPA obligations

and recorded customer contacts.

• Data deletion should match the data model, backups and retention rules.
• Uptime and recovery promises should match monitoring, backup restore tests, achieved RPO/RTO,

recovery and failover capability.

• Exit terms should match export tooling or a manual export procedure.

Recovery promises

RPO and RTO are customer promises when they appear in contracts, support terms, trust packs or sales conversations. They are also implied promises when customers reasonably depend on the service being recoverable within a certain time or with limited data loss.

The company should record:

• the promised or expected RPO
• the promised or expected RTO
• the backup or failover mechanism that supports each promise
• the latest restore or failover test evidence
• the achieved RPO and achieved RTO from testing
• any variance between promise and evidence
• the owner of follow-up action where evidence no longer supports the promise

If achieved RPO or RTO worsens materially, the change should be treated as a risk. Record it in the technical risk register and escalate it to the company risk register where it affects customer trust, contractual promises, service availability, revenue or board-level expectations.

Breach contact records

For each customer or material supplier, the company should record who needs to be contacted if there is a security incident, suspected breach or confirmed personal data breach.

Useful fields include:

• customer or supplier name
• Controller/Processor position
• contract or DPA reference
• security contact
• privacy or DPO contact
• support or escalation contact
• notification timing
• required notification route
• whether the customer must be contacted before data subjects
• internal owner for the relationship

These records should be available to the incident coordinator and the DPO/data protection owner during an incident. They should be rehearsed before Production scales.

How this evolves as the company grows

• During Pilot, customer promises should be plain and cautious: be honest about limitations, data handling and support expectations.

• Before Production, contracts, support routes, breach contacts, RPO/RTO and privacy commitments need to match operational evidence.

• At Production, support promises become operating obligations that affect monitoring, incident response, restore testing and staffing.

• As the company scales, commercial promises should be reviewed whenever customer dependency, regulated usage or support load changes materially.

What an agent should look for

• Do contracts match support capacity?

• Do RPO/RTO and breach timings match evidence?

• Are customer contacts recorded for incidents?

What good looks like

The company can explain the decision, show the evidence behind it and identify the next point where the control needs to mature.