A custom software maintenance agreement should identify the systems covered, the work included, the service hours, the incident process and the evidence that routine maintenance is happening. It should also separate response commitments from restoration objectives and define what happens when the relationship ends.
A monthly retainer is a commercial arrangement, not a complete operating model. Two suppliers can charge for “support” while accepting very different responsibilities. The buyer needs those responsibilities written down before a production incident forces the discussion.
Inventory what the agreement covers
List the applications, environments, repositories, integrations and infrastructure within scope. Identify the current versions and known limitations at the start of the service. An inherited application with no repeatable build needs different onboarding work from a well-documented system.
Name the owner of each dependency: cloud hosting, domain registration, email delivery, payment processing, database operations and identity provider. If the supplier supports the application but another team controls infrastructure, define the boundary and escalation route.
Record who may authorize changes and spending. Without that decision, an engineer may identify a problem but be unable to purchase capacity, change a configuration or schedule the work required to resolve it.
Separate four kinds of work
Distinguish incident response, preventive maintenance, defects against the accepted scope and new development. They may share a team, but they need different commercial and acceptance rules.
Incident response investigates a service disruption. Preventive maintenance addresses work such as supported-version upgrades, dependency review and recovery exercises. Warranty or defect correction depends on the original agreement. New capabilities belong in a prioritized development backlog.
Ask whether the retainer reserves engineering capacity, pays for completed work or provides a defined operating service. Establish how unused capacity, urgent work and requests beyond the included scope are handled. The description should make the purchase understandable without inventing unlimited availability.
Define severity through business impact
Severity labels should describe impact and urgency, not how strongly a ticket is worded. A hypothetical order-processing platform might distinguish a complete inability to submit orders from a reporting issue with an available workaround.
For each severity, specify:
- ▸The business impact that qualifies.
- ▸The support channel that activates the process.
- ▸The hours during which the commitment applies.
- ▸A response target and what counts as a response.
- ▸The investigation and update cadence.
- ▸The restoration objective or escalation decision.
- ▸Who may change the severity as evidence develops.
Use times your organization and supplier can actually support. Acknowledging an automated ticket is not necessarily the same as an engineer beginning investigation. State the difference explicitly.
Make coverage work across countries
For a buyer in Canada and an engineering team in Europe, “business hours” is ambiguous. Write the time zone, days of coverage and treatment of public holidays. Define which party manages seasonal clock changes and how on-call exceptions are arranged.
Israeli and European teams may also have different working-week patterns. Record the agreed overlap rather than assuming that everyone observes the same weekend. This is an operational planning question, not a claim that one delivery location is inherently better.
Identify what happens outside the coverage window. Automated alerts may continue while human response is unavailable. Decide whether an emergency contact exists, which incidents qualify and how that work is authorized. Avoid describing monitoring as continuous support unless both are actually included.
Specify preventive maintenance evidence
A maintenance report should show meaningful work and unresolved risks, not just a list of closed tickets. Ask for changes made, dependency issues assessed, capacity concerns, recovery exercises and decisions awaiting the business owner.
The NIST Secure Software Development Framework includes practices for responding to vulnerabilities and addressing their causes. It offers a useful vocabulary for discussing vulnerability handling, but the service agreement still needs named responsibilities and a practical process.
Define how an update is evaluated, tested and released. An urgent vulnerability may require a different change window from a routine library update. Clarify how the team identifies affected components, communicates risk and records the decision when an update is postponed.
Agree recovery requirements and rehearse them
Define the business tolerance for downtime and data loss before choosing a backup schedule or restoration objective. Identify what must be recovered together: databases, uploaded files, configuration and access to supporting services.
Request a recovery exercise with documented scope and results. A backup job reporting success does not show that a replacement environment can run the application. NIST's contingency planning guidance provides background for determining recovery priorities and planning the required procedures.
Clarify who approves a restore that may overwrite newer records, how users are informed and what happens to work performed during an outage. These are business decisions that should not be improvised by an engineer under pressure.
Treat changes and incidents as different conversations
After an incident, request a proportionate review of what happened, its impact, contributing conditions and the changes proposed to reduce recurrence. Not every incident needs a long report, but recurring failures need an owner and a decision.
For enhancements, agree a separate brief and acceptance criteria. A support ticket asking for a new workflow should not silently consume all capacity reserved for keeping the existing application healthy.
Use the quote comparison worksheet when assessing separate modernization or feature proposals. It helps expose whether a supplier's estimate includes the testing and operating changes the new capability requires.
Include an orderly exit
Specify notice, transition assistance, documentation updates and transfer of access. Confirm where the current source code, infrastructure definitions and operational records are held. A maintenance arrangement should preserve the organization's ability to change providers.
Before service begins, walk through one hypothetical incident and one routine change. If the parties disagree about who acts, when or at whose cost, revise the agreement while the discussion is still calm.
Explore software engineering services and share the application inventory and support constraints to discuss an operating scope tied to your business needs.