Whoever the agreement names owns updates. If it names nobody, the client technically does, but they usually cannot act on it, so the site decays. Agencies and clients should choose one of three models before launch and write down scope, cadence and who pays for emergency patches.
This is a planning guide, not legal advice. Have counsel review contract wording.
Why this gets missed
Project contracts end at launch. Maintenance is a different job with a different rhythm. Yet the code keeps depending on packages that publish advisories every week. The gap between "delivered" and "maintained" is where most client site problems start.
Three models
| Model | How it works | Fits when |
|---|---|---|
| Retainer | Agency reviews and applies updates on a fixed cadence | Client has no developers |
| Client in house | Client team owns it, agency hands over the pack | Client has engineers |
| On demand | Agency acts only when asked or when an advisory lands | Low risk sites with a tight budget |
None is wrong. Each fails if it is unstated.
What to define
- Cadence. Weekly review, monthly release, quarterly major upgrades.
- Trigger for urgent patches. For example, a known exploited flaw in a package the site uses. Name how you will learn about it and how fast you will respond.
- Test scope. What gets checked before a deploy. A dependency bump without testing is a risk transfer, not a fix.
- Access. Who has repository, hosting and pipeline access, and how it is reviewed. See who should own client hosting, domain and code accounts.
- Evidence. A monthly note of what changed and what is outstanding.
- End of life. What happens when a framework or runtime stops receiving support.
Make the risk visible
Clients cannot judge a lockfile. Give them a one page status: count of outdated packages, count of known advisories, items accepted with reasons. Trend it. A line that goes down over six months is a persuasive deliverable.
When the client declines maintenance
Some will. Record it. Send a short note stating that updates are the client's responsibility, list the known open items at handover, and keep a copy. This protects both sides and often prompts a second conversation.
Common mistakes
Promising "ongoing security" without defining it. Letting automated pull requests pile up in a repository nobody reads. Assuming the hosting provider patches application libraries; they usually patch the platform, not your packages.
Quick check
Is a maintenance retainer required?
No, but some owner is. A retainer is one way. A trained in house team is another.
How fast should an urgent patch happen?
Agree it in writing. The right number depends on the site, the flaw and exploitation evidence, so there is no single answer.
Safeguard
Safeguard's continuous dependency monitoring and SBOM scanning can give both sides the same list of open items. A free scan is at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
