Corrective maintenance: definition, defect severity and response times

Corrective maintenance covers the work that fixes the defects of a live application: whatever does not work as agreed is restored. In a third-party application maintenance (TMA) contract, it is the part that commits to response times. This guide gives the definition, a way to classify defects by severity, the times to write into the contract and what to monitor.

It is written for managing directors, CIOs and product managers whose application is in production, whether they already entrust its application maintenance to a provider or are about to.

Corrective maintenance: definition

Corrective maintenance means the work that brings a live application back to its expected behaviour after a defect has been found. It does not change what the application does: it makes it do again what it was supposed to do.

The general administrative clauses for French public information and communication technology contracts, the CCAG-TIC 2021, serve as a reference well beyond public procurement. Its article 38 states that “corrective” means “the measures consisting in correcting defects”. The terminology dictionary of the Office québécois de la langue française defines it as “maintenance intended to correct the errors found in software after its delivery”.

Both definitions set the same limit: corrective maintenance applies to a delivered application. A defect found during development or acceptance testing is fixed within the project, before going live.

Corrective is one of the four families of maintenance, with preventive, adaptive and evolutive. Our article on evolutive maintenance draws the boundaries between the four.

What is a defect, and what is not?

A defect is a gap between what the application does and what was agreed: a specification, a signed acceptance, documentation, or established behaviour that nobody asked to change. Article 38 of the CCAG-TIC does not define the word: that is the contract’s job.

Borderline cases exist. A defect can arise from a change in the environment, such as a browser or an exchange interface: the contract then says who handles it and under which heading. The safest approach is to qualify every request on entry, in writing, before handling it.

How do you classify a defect by severity?

The severity of a defect is measured by its effect on the business, not by how hard it is to fix. Four questions are enough to set it: is the affected function essential? How many users are affected? Is there an acceptable workaround? Are data or security at stake?

The names and number of levels vary from one contract to another. What matters is that each level is defined by written criteria, with examples taken from the application itself. Without this grid, urgency is decided case by case, over the phone.

Who classifies? The client proposes a severity when reporting, the provider confirms or discusses it at qualification, and a disagreement goes up to a named contact on each side. A security flaw follows its own rule: in its article 40, the CCAG-TIC provides for deadlines to apply security updates set “according to the associated level of risk”. For a software publisher, the Cyber Resilience Act adds reporting obligations.

What times should the contract set?

A corrective maintenance commitment comes down to three times, set for each severity level.

• The response time. From the report to the moment the provider starts handling the defect, and says so.
• The workaround time. The time to get the business running again with a temporary solution when the fix takes longer: a manual procedure, a temporary patch, a disabled function.
• The fix time. The time to deliver the final, tested fix to production.

Three details change the meaning of these times:

• The service hours. Business hours or round the clock, public holidays included or not. The CCAG-TIC thus provides that the time allowed to respond to a request for intervention “only runs during the intervention period defined in the specific contract documents” (article 39).
• The starting point. Receipt of the report, or qualification of the defect: the two do not necessarily happen at the same moment.
• What suspends the clock. Information awaited from the client, missing access, a validation to be done on the client’s side.

The CCAG-TIC leaves it to each contract’s documents to define the service levels, the means of measuring them and “the sanctions applicable if the agreed levels are not met” (article 38). In a private contract, the logic is the same: a time with no measurement and no consequence remains an intention.

How does a fix run, from report to closure?

A well-handled defect goes through seven steps, in a tracking tool that both the client and the provider can see.

• The report. What was expected, what happened, when, for which user, with a screenshot or the error message. A precise report shortens the diagnosis.
• Qualification. Defect or not, and which severity.
• Reproduction and diagnosis. The defect is reproduced outside production and its cause is found.
• The workaround, if the defect is blocking. The business restarts before the final fix.
• The fix and its tests. The fix, then regression tests: it must not break anything elsewhere.
• Validation and release. The client checks on a test environment, then the fix goes to production.
• Closure. The ticket is closed with the cause, the fix and the version delivered. For a blocking defect, a short analysis says why it happened and what will stop it from coming back.

How is corrective maintenance invoiced?

Corrective maintenance lends itself to a fixed price: its volume can be estimated from the application, its age and its defect history. It can also be counted as time spent, against a reserved allowance, or combine the two, with a ceiling above which time is invoiced separately.

One question is settled separately: fixing defects introduced by the provider itself. The contract says whether it is at the provider’s expense, for how long after delivery, and what is excluded. The clauses to check are detailed in our guide to the application maintenance contract.

What should you monitor to know whether corrective maintenance works?

Five indicators, reviewed every month with the provider, show whether corrective maintenance is under control and whether it is decreasing.

• Open defects, by severity and by age. What is waiting, and since when.
• Times met. The defects handled and fixed within the contract times, level by level.
• Reopened defects. A fix that does not hold is a fix to be redone.
• Defects that come back in the same place. They point to a fragile module.
• The share of corrective work in the time spent. If it does not fall over the months, the application is not stabilising.

Frequently asked questions

Corrective maintenance: write the rules before the first defect

Corrective maintenance goes well when three things are written down before the first defect: what counts as one, how it is classified, and within what times it is handled. The rest is measured every month.

The iones team provides application maintenance for live applications, corrective work included, and can start with an audit of what exists. To hand maintenance over to a provider, our guide to outsourcing your application maintenance details the steps. You can also write to us for an initial discussion.