Application maintenance contract (TMA): the 9 clauses to check before signing

An application maintenance contract sets out what a provider maintains, within what timescales, on what conditions, and what it hands back to you at the end. Nine clauses separate a contract that protects from a subscription that reassures. This guide goes through them using a public text that anyone can consult: the CCAG-TIC 2021, the general administrative clauses for public IT contracts.

It is written for executives, CIOs and purchasing managers who are about to sign, or renegotiate, an application maintenance contract, also known as a third-party application maintenance (TMA) contract. You will find no “standard” price or timescale here: they depend on the application and are negotiated. You will find what each clause must say.

What an application maintenance contract is

The application maintenance contract, or TMA contract, organises a provider’s upkeep of an application in service. The CCAG-TIC 2021, the general administrative clauses for public information and communication technology contracts, defines third-party application maintenance as all the services that keep an information system in a state that allows it to fulfil its function; it may also cover the evolution or adaptation of software.

This text applies only to public contracts that refer to it. But it is public, recent and written for this type of service: it is a good reading grid for a private contract, which the parties draft freely. This guide uses it as a reference point, never as a rule that would be binding on you.

A maintenance contract consists of a main document and appendices: the description of the scope, the service level grid, the financial terms and the reversibility plan. The nine clauses that follow appear in these documents.

Scope: what the contract covers, and what it excludes

This is the clause on which all the others depend. It answers four questions.

• Which applications, and which environments. Production only, or also acceptance testing and pre-production; mobile applications, interfaces with other systems and scheduled processes, included or not.
• Which types of work. The CCAG-TIC distinguishes four: preventive, corrective, adaptive and evolutive. The contract says which are included, and within what limit. These types are detailed in our guide to outsourcing your application maintenance.
• Where correction stops and evolution begins. A defect is a deviation from what the application was meant to do; an evolution changes what it is meant to do. Write the rule down, and who decides in case of doubt. Our guide to evolutive maintenance details this boundary.
• What falls under operations. Hosting, monitoring, backups and their restoration are not part of application maintenance by default. The CCAG-TIC treats the operation of the IT system, hosting included, under another name: managed IT services. If you expect it from the same provider, it appears in the contract.

The same text sets a rule that sums up what is at stake: maintenance operations not provided for in the contract can only be carried out after the contractor’s agreement (article 39). What the scope overlooks is therefore discussed at the moment you need it, rarely the best time to negotiate.

Pricing: fixed fee, time credit or time and materials

Three options exist, and they can be combined in a single contract.

None is better in itself. A fixed fee suits work whose volume can be forecast, such as preventive and corrective maintenance; evolutions lend themselves better to a time credit or a quotation per request. In every case, the contract specifies the price revision: on what date, and according to what rule.

Service levels: timescales, measurement and penalties

A service level (a service level agreement, or SLA) is a quantified commitment: a timescale, a rate, a frequency. For managed IT services, the CCAG-TIC requires the contract to set three things: the levels agreed for the quality indicators, the means of measuring them and the penalties for non-compliance (article 38). The three go together: remove one, and the commitment no longer applies.

• A severity scale. What a blocking, major or minor incident is, with examples taken from your application. Without a definition, every incident becomes a discussion.
• Two distinct timescales. The time to pick up (someone is dealing with it) and the time to restore or work around (the application works again). The first guarantees nothing about the second.
• The intervention window. The days and hours during which the timescales run. The CCAG-TIC says so for on-site maintenance: the response time only runs during the intervention period defined in the contract (article 39). The same timescale does not mean the same thing in office hours and round the clock, nights and weekends included.
• Measurement. The tracking tool of record, the time at which the timescale starts, and the periodic report that gives the results.
• The consequence. A penalty, a credit note, or the right to terminate in the event of repeated failures.

On penalties, the CCAG-TIC gives a method rather than an amount. In a public maintenance contract, when unavailability exceeds the threshold provided for, the penalty is calculated from the monthly maintenance fee, at the rate of one thirtieth per day (article 14.2). The idea to keep for a private contract: the penalty is tied to what you pay for the service, and its calculation leaves no room for interpretation.

Security and updates

Maintaining an application starts with keeping it up to date. The CCAG-TIC devotes an entire article to it, “maintenance in security condition” (article 40), four of whose requirements transfer as they stand to a private contract.

• The provider uses only software components that their vendor undertakes to maintain for the duration of the contract; failing that, it keeps and follows a migration roadmap towards maintained systems.
• A procedure sets the deadlines for applying security updates according to the level of risk, the emergency cases and what to do if an update fails.
• The inventory of the software that makes the service run, with its versions, is kept up to date.
• The versions installed are stable and still supported, and the effect of an update is checked before it is applied.

The same article gives an order of magnitude: in a public contract, the checks that precede the acceptance of a delivery may be refused if components are not up to date with security patches published more than three months earlier.

Two other points deserve a line in the contract. First, the right to audit: the CCAG-TIC allows the buyer to have the contractor’s security audited and, where applicable, that of its subcontractors, with fifteen days’ notice (article 24). Second, the security commitments themselves: the guide to outsourcing from the French national cybersecurity agency (ANSSI), published in 2010 and still online, proposes a risk assessment approach, relies on a security assurance plan and provides standard security clauses.

Personal data

If the application processes personal data (customers, employees, users), the provider that has access to it acts as a processor within the meaning of the GDPR. Article 28 of the GDPR then requires a written contract, which may take the form of an appendix to the maintenance contract. It provides in particular that the processor processes the data only on documented instructions, ensures its confidentiality and security, engages another processor only with written authorisation, and deletes or returns the data at the end of the service.

The CCAG-TIC adds a useful detail: for six months after the end of the contract, the buyer can check that the data has indeed been destroyed (article 24). An equivalent clause avoids relying on a simple declaration.

Code ownership, documentation and access

Paying for a service is not enough to hold the rights to the code produced: with an external provider, a written assignment is needed, as Bpifrance Création points out. The Intellectual Property Code sets its form: each of the rights assigned is the subject of a separate mention in the deed, and the field of use is limited as to its extent, purpose, place and duration (article L131-3). The drafting of this clause deserves a review by a lawyer.

In maintenance, the question arises with every delivery: the clause must cover the corrections and evolutions that the provider will write during the contract, not only what already exists.

The CCAG-TIC shows what a complete clause looks like (article 46). In a public contract, the contractor assigns to the buyer the property rights in the results, on a non-exclusive basis as a general rule, worldwide and for the legal term of the rights. It delivers the source code and its documentation at the same time as the object code, with the information needed for subsequent maintenance. The text deals separately with what existed before the contract and which the provider incorporates into it (its tools, its libraries, standard components), under the name “prior knowledge”: ask for the list, with the licences.

Three practical points complete the clause.

• The code repository is in your company’s name, and the provider is invited to it. You thus keep the full history, not just a copy handed over at the end.
• The documentation follows the deliveries. The CCAG-TIC provides for technical documentation in French, handed over with each update or new version: technical environment, design, testing, use and operation (article 22).
• The accounts are yours. Hosting, domain name, third-party services, app stores: they are opened in the company’s name, with named access for the provider.

Monitoring, advice and subcontracting

A maintenance contract runs over time. Three working rules need to be written down.

• Monitoring. A request tracking tool that you can consult freely, a periodic report (requests handled, timescales met, time used, state of versions) and a regular meeting to set priorities.
• Advice. The CCAG-TIC places on the contractor a permanent duty to advise and to warn (article 3). This is what distinguishes a maintainer from someone who merely carries out tasks: it warns you of a version coming to the end of its support, or of a choice that will be costly later, without waiting to be asked.
• The people involved. In a public contract, the contractor asks the buyer to accept each subcontractor (article 3). Ask for the equivalent: to know who actually works on your application, and to be told of a change of team.

Term, renewal and termination

• Term and renewal. Fixed term or tacit renewal; in the latter case, the deadline for objecting.
• The start-up phase. A contract rarely starts at steady state: a transition period lets the provider get to grips with the application. The CCAG-TIC caps it at six months for public contracts (article 38). A private contract sets its own freely, but it is worth limiting it and saying what is delivered at its end.
• Termination. The cases in which each party can end the contract, the notice period, and what remains due.
• Liability and insurance. The provider’s liability caps and insurance certificate are read before signing, not after an incident.

Reversibility: preparing the end from signing

Reversibility is what lets you change provider, or take maintenance back in-house, without starting from zero. The CCAG-TIC distinguishes two cases (articles 38 and 42): reversibility, when the client takes the services back itself or entrusts them to a third party it designates, and transferability, when a new contractor takes them over. In both cases, a plan appended to the contract describes the duration and the conditions.

• What is handed over. The text cites, without being limited to, the executable software and, where applicable, the source code, the associated documentation, the configuration files and the operating scripts, as well as the data in documented formats.
• The access given to the successor. The outgoing provider opens access to hardware and software to the extent needed, without compromising the continuity of the service.
• The security of the transfer. Technical and organisational measures protect the data and the applications during the handover.
• The duration and the assistance. How long the handover lasts, how many days of support it includes, and at what price. The CCAG-TIC refers these points to the plan: what is not costed in it at signing is negotiated on the day of departure.
• The end of access. The deletion of the provider’s accounts, then the return or destruction of the data, with a certificate.

Before signing: the checklist

• Does the scope name the applications, the environments and the types of work included?
• Is the boundary between correction and evolution written down, with the person who decides?
• Are hosting, monitoring and backups assigned to someone, by name?
• Does each service level have an intervention window, a means of measurement and a consequence?
• Are the deadlines for applying security updates set, and do you receive the inventory of versions?
• If personal data is involved, is the processing agreement provided for by article 28 of the GDPR attached?
• Does the assignment of rights cover the code written during the contract, and is the repository in your name?
• Do you know who works on your application, and will you be told of a change?
• Are the term, the renewal and the notice period clear?
• Is the reversibility plan appended, with its duration and its price?

Frequently asked questions

Application maintenance contract: what is negotiated before, not after

An application maintenance contract is judged less by its price than by three moments: the day of an incident, the day of an unplanned request and the day you want to leave. If the scope, the service levels and the reversibility answer these three situations, the rest follows.

To go further, the iones team carries out the audit and application maintenance of existing applications. You can also write to us for an initial discussion.