Every software budget we see has a line for building the thing. Most have a line for hosting. Almost none have an honest line for what happens in the three years after launch, which is where roughly 60% of the total cost actually lands. That gap is about to get more expensive, because from 11 September 2026 a chunk of the European software industry acquires a legal duty to respond to security problems on a 24 hour clock.
TL;DR
- EU Cyber Resilience Act reporting obligations start on 11 September 2026: actively exploited vulnerabilities and severe incidents must be reported to your national CSIRT and ENISA within 24 hours, with a full notification inside 72 hours. The remaining CRA duties, including patching and remediation, follow on 11 December 2027.
- Budget 15% to 25% of the original build cost per year for maintenance. Consistently spending above 25% is a signal that the system needs deliberate technical debt reduction, not more patching.
- Deferred dependency updates compound viciously: a year of skipped updates is typically a two to three day job, two years is a two to three week job, because major version jumps cascade breaking changes.
- An SLA is not a support inbox. It needs severity tiers with defined response windows, an uptime commitment, named escalation contacts and a stated coverage window.
- Response time and resolution time are different promises. Agencies that quote only the first are selling you an acknowledgement, not a fix.
The date that changes the conversation
The Cyber Resilience Act has been coming for years, but 11 September 2026 is the first hard edge. From that date, manufacturers of products with digital elements placed on the EU market must notify their national CSIRT and ENISA of actively exploited vulnerabilities and severe security incidents. An early warning is due within 24 hours of becoming aware, a full notification within 72 hours, and a final report within 14 days of a corrective measure being available.
Two clarifications matter, because there has been a lot of loose commentary. First, the trigger is not every CVE that appears in your dependency tree. The obligation attaches to vulnerabilities being actively exploited in the wild, and to severe incidents. Second, scope is genuinely contested at the edges. Bespoke software built for a single client under contract sits in a much greyer area than a product placed on the market. If you sell a SaaS product, ship a mobile app, distribute a plugin or put firmware on a connected device in the EU, assume you are in scope and get advice. The Commission published implementing guidance at the end of July 2026, and it is worth reading before anyone in your organisation forms a confident opinion.
The practical consequence is the same either way. A 24 hour reporting clock is unmeetable if nobody is watching your dependency advisories, if your only developer contact is a freelancer who answers email when convenient, and if you have no agreed definition of who declares an incident. The regulation is forcing a maturity level that good teams already had, and it is exposing everyone else.
What maintenance actually costs
The working benchmark across the industry is 15% to 25% of the original build cost per year. A €60,000 platform therefore carries something in the region of €9,000 to €15,000 annually. Small brochure sites sit at the bottom of that range and often lower in absolute terms, typically €800 to €3,000 per year. Integrated systems with payment gateways, third party APIs and real user volume sit at the top.
The number people find uncomfortable is what happens when they refuse to spend it. Maintenance is not optional work that you can decline; it is work that you either schedule or eventually do in an emergency at a worse rate. If your annual maintenance spend keeps climbing past 25% of the build cost, that is not a pricing problem. It is the system telling you it needs architectural attention, and continuing to patch is the expensive option.
The four things a maintenance agreement is actually buying
Security patching and dependency currency. Framework releases, library CVEs, runtime end-of-life migrations. This is the least visible category and the one that quietly determines whether year three is calm or catastrophic.
Corrective work. Bugs found in production, broken integrations after a third party changes their API, data issues. Note that a third party breaking their API is not your agency’s defect, but fixing it is still someone’s job, and the agreement should say whose.
Adaptive work. Browser behaviour changes, new OS versions, payment provider requirements, regulatory changes such as accessibility or the CRA itself. Nothing is broken; the world moved.
Monitoring and operations. Uptime checks, error tracking, backup verification, certificate renewals. The unglamorous category that turns a four hour outage into a fifteen minute one.
Feature development is deliberately not on that list. Bundling new features into a maintenance retainer is how retainers quietly become underfunded development contracts, and it is why the security patching category is usually the first thing to get starved.
Reading an SLA properly
Most SLAs in this sector use three or four severity tiers. Critical incidents covering an application-down or data-loss event typically carry a one to four hour response commitment with 24/7 coverage. High severity issues, meaning a major feature failure affecting a significant user segment, usually get eight business hours. Medium and low severity items land in a three to ten business day window.
Uptime commitments are worth doing the arithmetic on. A 99.9% guarantee permits roughly 8.7 hours of downtime per year. A 99.99% guarantee permits about 52 minutes. The gap between those two numbers is a substantial difference in infrastructure cost, and an agency quoting four nines on single-instance shared hosting is quoting a number it cannot deliver.
Three questions expose a weak SLA quickly. Does it distinguish response time from resolution time, or does it only promise the former? What are the coverage hours, and does 24/7 mean an on-call engineer or an autoresponder? What happens when the SLA is missed, and is there any remedy beyond an apology?
The dependency debt clock
The compounding maths here is the single most useful thing to explain to a board. A year of skipped dependency updates is typically two to three days of work. Two years is two to three weeks, because you are no longer applying patches, you are navigating major version jumps whose breaking changes cascade through the codebase. Three years and you are frequently in rebuild-versus-refactor territory, which we have written about separately.
AI-assisted development has made this worse, not better. Codebases generated quickly carry more duplication and more dependencies than hand-written equivalents, and every dependency is a future update obligation. The build got cheaper; the maintenance surface got larger. Anyone quoting you an AI-driven discount on the build without adjusting the maintenance figure upward has only done half the sum.
What to insist on in the agreement
- Severity definitions with response and resolution targets, and stated coverage hours for each tier
- A named escalation path with a human contact, not a shared inbox
- An explicit monthly or quarterly hours allocation, with a stated policy on whether unused hours roll over
- Dependency and security patching listed as in-scope work, not as billable extras
- A defined boundary between maintenance and new feature development
- Reporting: what you receive, how often, and in enough detail to verify the work happened
- Exit terms, including notice period and handover obligations, which should align with the ownership and access checklist from our handover guide
- Under CRA, a stated position on who monitors advisories, who declares an incident and who files the notification
The red flags
A flat monthly fee with no defined scope is a fee for nothing in particular. An SLA quoting only response times is selling acknowledgement rather than repair. Maintenance bundled inseparably into a hosting package usually means neither is being done properly. And an agency that cannot tell you which dependencies your system runs, and their current version status, is not maintaining it in any meaningful sense.
The honest version of this conversation is that maintenance is the least exciting line in the budget and the one that determines whether the asset you paid for is still working in four years. The CRA deadline in September has simply made that argument legible to people who previously found it easy to defer.
REPTILEHAUS builds and maintains web platforms, SaaS products and integrations for clients across Ireland and the EU, including DevOps, monitoring and security patching under defined SLAs. If you are unsure what your current arrangement actually covers, or whether the CRA reporting duty applies to what you have shipped, get in touch and we will go through it with you.
📷 Photo by Paul Calvo on Unsplash
