Software Maintenance Contracts: Scope, SLAs and Costs

A software maintenance contract is a written agreement under which a supplier keeps a production system working after delivery: it fixes defects, keeps the software compatible with its environment, applies security patches and, where agreed, extends functionality. Its value depends almost entirely on how precisely those obligations are defined. A contract that says only “maintenance and support” invites disputes about what is included, how fast the supplier must react and what an additional request costs. This guide sets out the clauses that matter, the cost logic behind them and the points at which buyers most often accept ambiguity they later regret.

TL;DR

• A sound contract separates corrective, adaptive and evolutive maintenance, and states which are covered by the recurring fee and which are quoted separately.
• Service levels should distinguish response time from resolution time and attach both to defined severity levels.
• Security patching, vulnerability assessment and monitoring belong in the contract as recurring, named obligations, not as goodwill.
• Annual maintenance is commonly budgeted at roughly 15 to 25% of the original build cost, but the real figure depends on architecture quality, integrations and regulatory exposure.
• Exit terms, documentation and code ownership decide whether you can ever change supplier without rebuilding.

Table of Contents

• What a maintenance contract actually buys
• The three categories of maintenance
• Service levels: response, resolution and severity
• Security and patch management as recurring obligations
• Understanding the cost of maintenance
• Clauses to check before signing
• Our perspective
• When maintenance needs senior technical oversight
• A practical sequence for drafting or reviewing a contract
• FAQ
• Sources

What a maintenance contract actually buys

Maintenance is not a single activity. ISO/IEC/IEEE 14764:2022, the international standard for maintenance within the software life cycle, treats it as a structured process with its own planning, analysis and control, rather than as an informal tail to development. The practical consequence for a buyer is that a contract should describe a service with defined inputs and outputs: how a request arrives, who classifies it, who authorises work, how a change is tested and how it reaches production.

A maintenance agreement is also an accessory to something else. Italian legal commentary on standard clauses describes it as one of the most widespread contract types in the IT sector, and often an indispensable complement to software that has been commissioned or acquired, as the commented model contract published by Tuscia Fisco puts it. The same logic applies in every market: a system that is not maintained degrades, because the operating systems, browsers, libraries and third-party interfaces around it keep changing.

The three categories of maintenance

The most useful structural distinction in any contract is the one between corrective, adaptive and evolutive work. A technical note attached to a public healthcare tender by ASST Mantova is a good example of how institutional buyers specify the scope of software support, and the same three-way split recurs in most professional agreements.

The ambiguity usually sits in the second row. A minor dependency upgrade is adaptive maintenance; moving from one major framework version to the next, or replacing a payment provider that has retired its API, can be a project in itself. A careful contract names the boundary, for example by defining a maximum number of engineering days per quarter inside the fee and requiring a written estimate for anything above it.

A fourth activity, preventive maintenance, deserves a mention. It covers refactoring, dependency clean-up, test coverage and performance tuning carried out before a failure forces the issue. Contracts that exclude it entirely tend to produce technical debt, since the supplier is paid to react but never to reduce the probability of reacting.

Service levels: response, resolution and severity

A service level agreement turns the promise of support into something measurable. Legal guidance on IT maintenance contracts, such as the overview by Avvocato Liverani, singles out the response time as a core element, expressed in hours or working days, together with a statement of whether the clock runs only during business hours. These details are routinely omitted and routinely disputed.

Three definitions need to be explicit.

First, severity. A contract should define at least three levels: a critical incident that stops a core business process or exposes data, a major degradation with a workaround, and a minor defect or request. Each level carries its own targets, and the contract should say who assigns the level and how disagreements are resolved.

Second, response versus resolution. A response time is the delay before a qualified engineer acknowledges and begins to analyse the issue. A resolution time is the delay before service is restored or a workaround delivered. Suppliers readily commit to the first and are reluctant to commit to the second, because it depends on the root cause. A balanced agreement commits to restoration targets for critical incidents and to a diagnosis and plan within a fixed window for the rest.

Third, the measurement window. Availability commitments, where the supplier also operates the hosting, should state the calendar period over which uptime is calculated, which maintenance windows are excluded and what remedy applies on a breach. Service credits are common, but a credit that never exceeds a small percentage of the monthly fee is a weak incentive, and the contract should also give the buyer a right to terminate after repeated failures.

Public procurement documents are a useful reference for how detailed this can become. The European Commission’s general terms and conditions for information technology contracts include specific provisions for hardware and software maintenance, among them the point at which contractual maintenance begins relative to the guarantee period of delivered products. That detail is worth copying into private contracts: the warranty on new development and the paid maintenance period should join without a gap and without an overlap in which nobody is clearly responsible.

Security and patch management as recurring obligations

Maintenance that omits security is incomplete. The NIST guidance on enterprise patch management recommends that organisations create a dedicated patch and vulnerability group to identify, prioritise, test and deploy fixes, and treats testing of patches and non-patch remediations as a distinct step. When software maintenance is outsourced, that function is effectively transferred to the supplier, and the contract must say so. Otherwise each party assumes the other is watching the advisories.

In practice, the security schedule of a maintenance contract should name the following obligations: monitoring of vulnerability disclosures for every framework, library and container image in the stack; a defined timeframe for assessing a disclosed vulnerability and a separate timeframe for deploying a fix, scaled to severity; regression testing before release; a rollback procedure; and a written record of what was patched and when. An ad-hoc approach is not neutral. It leaves the client holding the risk while believing it has been delegated.

Regulation reinforces the point for some sectors. In the financial sector, the EU’s Digital Operational Resilience Act (DORA) defines ICT assets broadly, and ESMA’s questions and answers on DORA confirm that end-user computing tools can fall within that definition when they are software used in a financial entity’s network and information systems. A supplier maintaining such software therefore operates inside a regulated perimeter, and the contract should anticipate audit rights, incident notification and subcontractor transparency. Organisations outside financial services should not assume that DORA applies to them, but the same questions are sensible due diligence for any software embedded in sensitive workflows.

Security responsibilities also extend to the people and processes around the code. Operational advice such as these data security tips, written for fleet managers, illustrates how access control, encryption and staff practice recur in every sector that handles customer data, and a maintenance contract is the natural place to allocate who owns each of them.

The European Commission’s own tender documentation for a large IT service, the MAIA service requirements and SLA annex, defines maintenance as the regular enhancement of software to eliminate bugs, improve performance and modify features. That definition is broader than many commercial contracts admit, and it illustrates why a buyer should check that “maintenance” in the supplier’s draft means what the buyer assumes.

Understanding the cost of maintenance

Buyers who ask what maintenance should cost usually receive a percentage. A commonly cited rule of thumb, repeated in educational material on software engineering economics, is that maintenance costs around 15 to 25% of the original development cost per year, and that it can account for most of the total life-cycle cost of a system. Treat this as an orientation, not a quotation. A system of EUR 200,000 build cost would, on that rule, imply an annual maintenance budget between EUR 30,000 and EUR 50,000, but the true figure moves with several variables.

Three pricing models dominate. A fixed monthly retainer gives predictability and suits stable systems with a defined scope. A time-and-materials arrangement with a prepaid bank of hours suits systems with irregular demand, provided unused hours are handled sensibly, ideally by rolling over for a limited period. A hybrid model combines a modest retainer for monitoring, patching and incident response with separately estimated evolutive work. The hybrid is frequently the most honest, because it prices the predictable and the unpredictable differently.

The cheapest quote is rarely the lowest cost. A low retainer that excludes security patching, caps incident hours tightly or charges for every diagnosis simply moves the expense into invoices that arrive when something is already broken. Compare quotes by asking what a bad month would cost under each contract, not what a quiet month costs.

Clauses to check before signing

Beyond scope, service levels and price, several clauses repay careful reading.

Ownership and access. The contract should confirm who owns the source code, the configuration and the infrastructure definitions, and the buyer should have access to the repository and the deployment pipeline throughout, not only on request. Where the supplier uses proprietary components, a licence that survives termination is essential.

Documentation and knowledge transfer. Architecture notes, runbooks and an up-to-date list of dependencies should be deliverables, reviewed periodically. They are what makes a change of supplier feasible, and a supplier confident in its work has no reason to resist producing them.

Change control. Evolutive work should follow a written estimate and approval, so that scope never expands informally. The same applies to adaptive work that crosses the boundary into a project.

Liability and data protection. Liability caps should be proportionate to the risk the software carries, and the allocation of data protection roles, controller or processor, with the corresponding instructions on sub-processors and breach notification, should be explicit wherever personal data is touched.

Term, renewal and exit. Automatic renewal with a long notice period is a common trap. A reasonable agreement allows termination for convenience on defined notice after an initial term, and obliges the supplier to cooperate in an orderly handover. Italian commentary on technical assistance agreements, such as that of Studio Legale FCLEX, likewise stresses that the contract should be explicit about the activities the supplier performs and the circumstances in which it performs them.

Our perspective

We approach maintenance as an engineering discipline that begins before the contract is drafted. The quality of a maintenance agreement is bounded by the quality of the software it covers: a codebase with peer-reviewed changes, targeted automated tests, production monitoring and clear documentation can be supported on predictable terms, whereas an opaque system forces the supplier to price uncertainty into every clause.

For that reason we favour a structure in which the client speaks directly with the engineers who build and maintain the system, with no account-manager layer between a production incident and the person able to diagnose it. Decisions about what is a defect, what is adaptive work and what deserves a separate budget are technical judgements, and they are better made quickly by the people with the context. We also limit the number of simultaneous projects we take on, because a maintenance commitment that cannot be staffed is worse than none.

We consider the written record as important as the fix. Consulting engagements with us end in written recommendations, and the same principle applies to maintenance: every patch, every dependency upgrade and every architectural decision should be traceable, so that the client is never dependent on any single supplier, including us.

— Pepe F.

When maintenance needs senior technical oversight

Some organisations hold a maintenance contract but lack someone able to judge whether it is being performed well: whether the backlog is healthy, whether the architecture is ageing or whether a quote for a migration is reasonable. For that situation we offer CTO advisory and fractional CTO subscriptions: CTO Advisory from 1800 EUR per month, Fractional CTO from 4000 EUR per month and CTO Partner from 7500 EUR per month, with an initial assessment from 3500 EUR one-off. Where the question is the state of an existing codebase before a contract is drawn up, our code audit and technical debt service, described among our software services, gives an independent basis for defining the maintenance scope.

A practical sequence for drafting or reviewing a contract

A workable process has a clear order. Begin with an inventory of the system: components, hosting, integrations, data flows and the people who currently understand each part. Then classify the expected work into corrective, adaptive, preventive and evolutive, and estimate the annual volume of each from incident history if it exists. Next, define severity levels with business consequences instead of technical labels, and set response and restoration targets that the business genuinely needs rather than the highest the market offers. Add the security schedule with named recurring duties and timeframes. Only then request prices, asking every candidate to quote against the same scope so that the figures are comparable. Finally, test the exit: ask what the supplier would deliver, in what format and within what period, if the relationship ended tomorrow.

A review after the first quarter closes the loop. Compare actual incident volumes, response times and hours consumed with the assumptions in the contract, and adjust the retainer or the scope. A maintenance agreement that is never revisited is usually either overpriced or under-delivering.

FAQ

What is the difference between a maintenance contract and a support contract?

Support usually means helping users and resolving incidents, while maintenance also includes changing the software to keep it correct, compatible and secure. Many suppliers bundle the two in one agreement, so check that the document covers both incident handling and planned technical work. If it covers only the first, the system will still age.

How much does a software maintenance contract cost?

A common budgeting benchmark is 15 to 25% of the original development cost per year, though architecture quality, integrations, hosting and response targets can move the figure considerably. Ask each supplier to price a defined scope, including security patching, so the quotes can be compared. A written estimate for a specific system is the only reliable number.

Should security patching be included in the fee?

Yes, as a named recurring obligation with timeframes by severity. NIST guidance treats patch management as a systematic process with clear responsibility, and a contract that leaves it implicit leaves that responsibility unassigned. Where the software supports a regulated activity, ask your compliance adviser which obligations apply.

Can I change supplier without rebuilding the software?

Yes, provided the contract guarantees access to source code, infrastructure definitions and documentation, and requires the supplier to cooperate in a handover. Without those terms, switching can be costly or impractical. Negotiate them at signing, when the leverage is yours.

How long should the initial term be?

Twelve months is a common starting point, long enough to understand the system’s real maintenance profile and short enough to renegotiate. Prefer termination for convenience after the initial term on a defined notice period over automatic multi-year renewal. Have a solicitor review the term and liability clauses before you sign.

Sources

• ISO/IEC/IEEE 14764:2022, Software life cycle processes: Maintenance
• Contratto-tipo di manutenzione del software, Tuscia Fisco
• Contratto di manutenzione IT, Avvocato Liverani
• European Commission, general terms and conditions for IT contracts
• NIST Special Publication 800-40 version 2, patch management
• ESMA, DORA questions and answers 2103
• European Commission, MAIA service requirements and SLA annex
• Cost and efforts of software maintenance, GeeksforGeeks
• Contratto di assistenza tecnica hardware e software, Studio Legale FCLEX

This article was produced with AI assistance and reviewed for accuracy. It is provided for general information only and is not professional advice.