Software maintenance agreement: SLA, backups and updates

A software maintenance agreement should set out the scope of work and the response and resolution times for each ticket priority. It should also cover backups with restore tests, security updates and monitoring. It should also include a set number of development hours each month, access to the code and the rules for handing the application over when the contract ends. If the contractor has access to personal data as part of maintenance, for example in the database, backups or logs, you also need a data processing agreement.

The applications we maintain after launch include the booking system for MRI scans, Offer Exchange and INVENTA Licenses. Each of the points below comes up when we discuss the agreement, worded so that a specific party is responsible for each area. You will find the scope of our service on our application maintenance page.

Scope of the agreement: what exactly it covers

Start with a list of the elements the contractor is responsible for. These are usually the application code, the database, the server or cloud environment, the domain and the SSL certificate. If any element stays on your side, say so explicitly.

The two layers most often confused are the application and the server. A server administrator will look after the operating system and the firewall, but will not update the libraries in your code. At Conetso, our teams handle both layers, so the application and the server can be covered by a single agreement.

SLA: response time and resolution time

A service level agreement (SLA) defines how quickly the contractor deals with a ticket. Response time is the time from the report to the start of work. Resolution time is the time until the system works again, sometimes through a workaround. Include both, because a quick reply alone does not fix an outage.

Link the times to ticket priorities:

Priority	Example	What to specify
Critical	the application is down or stops all users from working	the shortest response and resolution times, an emergency reporting channel
High	an important feature does not work, but people can keep working	response time and a deadline for a workaround
Normal	a bug in a single view or report	response time, fix in the next release
Change	a new field, a filter, a change to a report	a quote and a deadline, within the hours set for development

Also specify the hours during which these times run. Our standard is business days, 8:00–17:00 Polish time. Under our standard SLA, we respond within 2 business hours. Faster response and work outside these hours are agreed in the SLA. Add how tickets are reported: a helpdesk portal, email, or phone for outages.

Backups and restore tests

The agreement should state what is backed up, how often, where the backups are stored and for how long. Keep backups away from the application server. A restore test in a separate environment, carried out regularly and timed, matters just as much.

The test answers the question that will be asked during an outage: how many hours until the system is back, and with data from which day. These two values have names. RPO (recovery point objective) is the maximum period of data you can afford to lose. RTO (recovery time objective) is the maximum time it takes to restore the system.

Backups and the restore test environment contain the same personal data as production. Protect them in the same way, and state in the data processing agreement where they are stored.

Security updates

A large part of any web application is other people’s code: the framework, libraries, the runtime and the database. Each of these receives security patches and has a defined support period. An application left without updates for two years already needs a migration, which costs more than ongoing maintenance.

In the agreement, specify:

• what is updated: libraries, the framework, the server operating system, the database,
• how quickly security patches are deployed, and how quickly regular updates are,
• that every change goes through a test version first,
• that a database backup is made before each production deployment,
• who pays for an update that requires code changes,
• checks of payment gateway webhooks and of the API (application programming interface) version, if the application takes payments (more in our article on Stripe subscriptions in a SaaS application).

Application monitoring

Monitoring should detect a problem before a user reports it. Specify what is checked: application availability, errors in the logs, disk space, certificate expiry. Also agree who receives alerts and how an alert translates into a ticket priority.

Development hours each month

We bill maintenance as a monthly plan that includes a set number of development hours each month. This works well when the application is in daily use and small requests keep coming in. In the agreement, state the number of hours. Also set the rate for work beyond them, because we bill larger changes and urgent work outside the monthly plan by the hour.

Ask for a monthly report on the work done and the hours used. This makes it easier to plan the next changes.

Access to the code and repository

As the owner of the application, you should have access to the code, the technical documentation and the administrative credentials. Specify where the code repository is and who has access to it. Rights to the code are agreed in the contract for building the application, as we describe in our article on the custom software development process. In the maintenance agreement, add that the same rules apply to changes made during maintenance.

Handing over the application when the agreement ends

This is the point most often overlooked when the agreement is signed. Specify the notice period and a list of what you receive when the work ends:

• the current code, with its change history in the repository,
• a copy of the database in an agreed format,
• technical documentation and a description of the deployment,
• passwords and access to the server, domain and external services,
• time for the new contractor’s questions after the handover.

Also specify when the contractor deletes the data from its systems, including backups.

We also take over maintenance of applications built by other companies, priced individually. The list above shows what to ask the previous contractor for in that case.

GDPR: the data processing agreement

A maintenance contractor usually has access to personal data in the database, backups and logs. It then processes that data on your behalf as a processor, and the obligations of both parties are set out in a data processing agreement under Article 28 of the GDPR. If your application processes your clients’ data on their behalf, for example in a SaaS model, the contractor is a sub-processor. Its involvement then requires the authorisation of your clients as data controllers.

Article 28(3) of the GDPR sets out what the data processing agreement must contain. This includes, among other things:

• the subject matter and duration of the processing, its nature and purpose, the type of personal data and the categories of data subjects,
• processing only on your documented instructions, including with regard to transfers outside the European Economic Area,
• a confidentiality commitment from the people who have access to the data,
• the security measures required by Article 32 of the GDPR,
• the conditions for engaging sub-processors,
• the contractor’s assistance with data subjects’ rights, breach handling and data protection impact assessments,
• the return or deletion of the data at the end of the services, at your choice, including copies, unless the law requires them to be kept,
• making available to you the information needed to demonstrate compliance, and allowing audits.

If the contractor orders hosting or an SMS gateway itself, those providers are sub-processors. The contractor may use them only with your prior written authorisation, either specific or general (Article 28(2) of the GDPR). With general authorisation, it informs you of any intended changes, and you can object to them.

The contractor imposes the same obligations on the sub-processor by contract and remains fully liable to you for it (Article 28(4) of the GDPR). If you sign the hosting contract yourself, the hosting provider is your processor and needs a separate data processing agreement. Also check whether data is transferred outside the European Economic Area. Such a transfer must be provided for in the agreement, and its legal basis must meet the conditions in Chapter V of the GDPR.

The GDPR requires the contractor to notify you of a personal data breach without undue delay (Article 33(2)). You notify it to your data protection supervisory authority (in Poland, the President of the Personal Data Protection Office, UODO) where feasible within 72 hours of becoming aware of it (Article 33(1)). Notification is not required if the breach is unlikely to result in a risk to the people the data concerns.

Where the risk is high, you also have to inform those people (Article 34 of the GDPR). That is why the agreement should specify how quickly the contractor must notify you and what information it must provide.

This article describes our practice as a software contractor and is not legal advice.

Tell us what your application runs on and what response time you need, and we will propose a maintenance scope.