The proposal says "ongoing maintenance." When you ask what that covers, the answer becomes "it depends." The system still matters to sales, inventory, billing, or customer service, but the agreement does not say who responds to a failure, who approves a change, or what happens if the provider stops serving the business.

Before comparing price, turn maintenance into questions the business can check. If the operation needs ongoing responsibility for its business software, that responsibility also needs to appear in the conversation about scope, access, decisions, and continuity.

This is a buying checklist, not a legal template. The FTC’s Cybersecurity for Small Business guidance, retrieved September 27, 2026, recommends putting security expectations in vendor contracts and verifying that they are followed. Have counsel review terms that create legal obligations in your jurisdiction.

Diagram showing a software maintenance agreement divided into scope, response, access, changes, and exit.

The short answer

  • Define which systems, environments, and workflows are covered.
  • Separate maintenance, incidents, questions, training, and new projects.
  • Agree on the channel, priority, hours, and updates without promising a response the provider cannot deliver.
  • Keep company accounts, data, and recovery under business control, with provider access limited to what is needed.
  • Require a transfer path if the agreement ends or the person who knows the system cannot continue.

What should “maintenance” mean?

Maintenance is not a promise to do anything that comes up. At minimum, the agreement should connect each service to a system, environment, or workflow and describe the expected result. The business should be able to look at a request and decide whether it is included support, a correction, an update, an approved change, or a separate project.

A practical way to organize the scope is to separate:

  • Correction: the existing system did something it was expected to do and stopped doing it.
  • Adaptation: a dependency, outside service, or operating rule changed and the workflow needs an adjustment.
  • Prevention and security: updates, checks, backups, monitoring, or reviews included in the service.
  • Evolution: a new screen, integration, report, or business rule that changes what the product does and needs its own decision.

These labels are not a law or a required standard. They keep “maintenance” from hiding four different kinds of work. The NIST guidance on building a small business cybersecurity team, retrieved September 27, 2026, recommends documenting the service level, responsibilities, and expectations in a formal agreement when a business outsources this work.

What belongs inside and outside the scope?

An understandable scope lets two people classify the same request in roughly the same way. It does not need to list every detail of the system, but it should name the areas that create disputes: integrations, data, infrastructure, outside vendors, users, reports, and process changes.

Use a table as a discussion guide, not as a ready-made clause:

Area Question for the provider What to record
Failure What counts as a defect in the existing service? Affected workflow and expected evidence
Updates Who maintains versions, certificates, and dependencies? Covered systems and each party’s responsibility
Integration Who investigates when another system changes or stops responding? Contact, boundary, and exception handling
Data Who runs, reviews, and tests backups? Location, retention, access, and restore test
Evolution When does a request stop being maintenance? Estimation, approval, and acceptance process
Third parties Can the provider depend on another vendor? Subcontracting, escalation, and responsibility

Do not write only "support for all software." Say whether support covers an application built by the provider, a product you bought, a cloud service, or a connection between companies. If the work depends on a third party, the agreement should explain what happens when that third party fails.

How should the agreement handle incidents and response times?

A response time is not the same as the time to restore the workflow or fix the cause. The agreement is clearer when it separates those stages and explains what the business receives while the issue is open. Without that distinction, "respond within X" may mean only an acknowledgment that the ticket exists.

Before accepting a service-level table, check:

  1. Channel: where should an incident be opened, and what information must be included?
  2. Priority: what makes a problem critical to the operation rather than merely inconvenient?
  3. Hours: does the clock run only during business hours, or also on weekends and holidays?
  4. Response: does the provider identify an owner and the next step?
  5. Workaround: is there a temporary way to keep sales, billing, or service moving?
  6. Updates: how often does the business receive an update while it waits?
  7. Escalation: who decides when another provider or a different priority is needed?

Do not copy time commitments from another agreement. A promise helps only if the provider has the access, context, and capacity to meet it. NIST also recommends clarifying and documenting service levels, responsibilities, and expectations when external services are used. The business still owns the operational risk even when part of the work is outsourced.

Who controls the accounts and data?

The provider may administer a system without being the only owner of the accounts that keep the operation running. Domains, hosting, repositories, service email, databases, payment tools, and third-party consoles should be tied to the business, with individual accounts and revocable access.

The FTC advises limiting a provider’s access to what it needs and for as long as it needs it. The same guidance recommends recording how data will be used, shared, retained, and deleted. Turn that into plain buying questions:

  • Does the account belong to the company, or was it created with the provider’s personal email?
  • Who can grant, review, and revoke access?
  • Where is the data stored, and how does the business export it in a usable form?
  • Does the provider use subcontractors? If so, are they part of the access path?
  • How will the business be notified about a security incident?
  • What happens to copies, credentials, and data when the work ends?

The CISA fact sheet for SMB vendor assessment, retrieved September 27, 2026, includes vetting providers that receive critical access to systems or data as one of its use cases. You do not need to turn every purchase into a large audit. You do need to find out who can act, on what, and under which rule.

How do you separate maintenance from a new change?

A support request starts to feel unfair when the client believes it bought unlimited evolution and the provider believes it sold only corrections. The agreement should give examples on both sides and define what happens when the classification is not obvious.

Ask an operational question: does the request return the system to the agreed behavior, or does it change the work the system performs? Repairing an integration that stopped may be maintenance. Adding a new integration for a workflow that was never covered usually needs a project decision. A field change may be small, or it may alter reports, permissions, and billing.

The process can be short:

  1. The business describes the required result and affected workflow.
  2. The system owner confirms whether the request is a failure, adaptation, or evolution.
  3. If it is new work, the provider states the scope, risk, effort, and acceptance test.
  4. Someone with authority at the business approves it before work begins.
  5. The delivery records what changed and how to verify the result.

The checklist for comparing software development proposals before signing helps when a support request becomes a delivery with its own scope. The important rule is not to begin paid work outside the agreement based on a vague conversation.

How can you test continuity before signing?

Read the exit clause as if the provider could not help for a month. Does the business know who can enter the accounts, where the data is, how to keep the most important workflow running, and who decides the next fix? If the answer is "we will ask the developer," the agreement still depends on one person’s memory.

Run a transfer test with a small, safe case. Ask the provider to show:

  • the inventory of covered systems, services, and integrations;
  • where documentation and the change history live;
  • how the business exports data and identifies the latest version;
  • how someone checks a backup and performs a restore;
  • which access will be delivered, retained, or revoked;
  • how much time is available to transfer context, credentials, and open work;
  • who remains responsible for an open incident during the transition.

The agreement should also say what happens to work in progress, data, copies, documentation, licenses, subcontractors, and charges at termination. It does not need to promise an instant exit. It needs to keep the business from discovering the cost of leaving only when it is in a hurry.

Freelancer, agency, or ongoing owner?

The agreement does not automatically make a freelancer an agency, or an agency accountable for the business. The choice depends on the amount of work, the need for coordination, and who has authority to set priorities. The guide to who maintains custom software after launch compares these models through access, context, maintenance, and transfer.

If the business needs one small correction, a well-defined project may be enough. If the software takes part in sales, inventory, billing, or service every day, the agreement needs to name the responsibility that continues after delivery. That may sit with an internal person, a freelancer, or an outside team that keeps context and owns the agreed evolution.

Do not choose by label. Ask who will be available, who decides, who documents, and who takes the next step when the operation changes.

Questions to take into the negotiation

Does the agreement need an exact time for every failure?

It needs to define how priority is set, when the clock starts, what response is provided, and how the issue is updated. A time commitment without scope, channel, and responsibility can look precise while saying nothing about when the workflow will work again.

Does the business need an internal technical employee?

Not necessarily. Even without a developer on staff, someone at the business needs to approve priorities, control accounts, confirm the result, and decide what is acceptable for the operation. The provider can do the work, but should not be the only person able to explain the system.

Does a maintenance agreement remove the risk of vendor dependence?

No. It reduces ambiguity when it defines scope, access, change records, data, continuity, and exit. Dependence remains high if the business does not control the accounts, cannot export its data, or has no way to transfer context to another person.

Conclusion

Before signing a software maintenance agreement, ask five questions: what is included, how is a failure handled, who controls access, when does a change become a project, and how can the business leave? The answers should appear in the agreement and make sense to the person running the operation, not only to the person who wrote the proposal.

If the business still does not know whether it needs a project, ongoing support, or an internal function, compare that decision with when a small business should hire a software developer. If the problem began because systems do not share information, use the diagnosis of disconnected business systems.

Maintenance is not only about repairing what broke. It is an agreement about who cares for the system, where that responsibility ends, and how the business continues when it needs another person.

Sources

  • Federal Trade Commission, “Cybersecurity for Small Business”, retrieved September 27, 2026, https://www.ftc.gov/business-guidance/small-businesses/cybersecurity
  • National Institute of Standards and Technology, “Building Your Small Business’s Cybersecurity Team”, retrieved September 27, 2026, https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/building-your-team
  • Cybersecurity and Infrastructure Security Agency, “Assisting Small and Medium-sized Businesses Assess Vendors and Suppliers Fact Sheet”, retrieved September 27, 2026, https://www.cisa.gov/resources-tools/resources/assisting-small-and-medium-sized-businesses-assess-vendors-and-suppliers-fact-sheet