A year-end maintenance contract should name specific versions, deadlines and measurement methods, not just "updates and support." The clauses that matter most right now are the PHP branch your host will run, automated certificate renewal, plugin patching cadence, accessibility conformance, payment-page script controls, and a performance metric with a stated threshold. Each of those has a date attached to it in the next twelve to eighteen months. A renewal signed without them leaves the site owner holding risks the agency has quietly priced out.
Table of Contents
- Name the PHP branch, not just "keeps PHP updated"
- Certificate renewal has to be automated now
- Plugin patching is where the money goes
- Accessibility obligations that already apply
- Payment pages carry their own script rules
- Write the performance clause as a metric, not an adjective
- Frequently Asked Questions
Name the PHP branch, not just "keeps PHP updated"
PHP is the language WordPress and Drupal run on, and each release branch has a fixed support end date. According to the PHP Group's supported versions page, PHP 8.2 now receives security fixes only through 31 December 2026, and 8.1 is no longer listed as supported at all. PHP 8.3 runs to 31 December 2027, 8.4 to 31 December 2028, and 8.5 to 31 December 2029.
A contract that renews for twelve months starting in January 2027 and leaves the site on 8.2 is a contract that covers an unsupported platform for its entire term. Write the branch into the agreement, with the date of the planned move and who tests the site against it. The testing clause matters as much as the upgrade clause. A major PHP bump breaks abandoned plugins and custom theme code, so the contract should say whether the vendor tests on a staging copy first, who fixes what breaks, and whether that work is included or billed separately.
Certificate renewal has to be automated now
TLS certificates — the ones that produce the padlock and HTTPS — are getting dramatically shorter lives. As Sectigo explains, under CA/Browser Forum ballot SC-081v3, approved in April 2025, no publicly trusted certificate authority has been allowed to issue a certificate valid longer than 200 days since 15 March 2026. That ceiling drops to 100 days on 15 March 2027 and 47 days on 15 March 2029.
At 47 days, manual renewal is roughly eight events a year per certificate. Any contract still describing "annual SSL renewal" is describing a task that no longer exists. Ask for these specifics in writing:.
- Which ACME client or host feature performs the renewal, and on what schedule
- Who monitors renewal failures, and how an expiry alert reaches a human
- The response time for a failed renewal, since a lapsed certificate makes the site unreachable for most visitors
- Whether wildcard or multi-domain certificates, and any non-web certificates, are covered
Plugin patching is where the money goes
The volume argument for a maintenance contract sits almost entirely in third-party code. Wordfence's 2024 annual security report recorded 8,233 distinct new WordPress vulnerabilities added to its database that year, a 68% rise over 2023. Tracker Patchstack counted 11,334 in 2025, with roughly 91% in plugins and only two in WordPress core. Cadence is the clause to negotiate.
One week in December 2025 saw 192 vulnerabilities disclosed across 174 plugins and two themes, per Wordfence's weekly vulnerability report. Measured against that rate, "monthly updates" can leave a known, actively exploited plugin flaw live for four weeks. A workable contract separates routine updates from emergency ones. Routine plugin and theme updates can run weekly or monthly; a disclosed critical vulnerability in a plugin the site actually uses should trigger a named response window measured in hours or days, with an explicit statement of who is watching the disclosure feeds.
Accessibility obligations that already apply
The European Accessibility Act, Directive (EU) 2019/882, has applied to e-commerce services sold to EU consumers since 28 June 2025, and it applies regardless of where the seller is based. As accessible.org's summary of the requirements sets out, service providers with fewer than 10 employees and no more than €2 million in turnover or balance sheet total are exempt, and a transitional period runs to 28 June 2030 for services that rely on products already in use. In the United States, the deadline that moved is the public-sector one.
Seyfarth Shaw's ADA Title III blog reports that a Department of Justice Interim Final Rule published in the Federal Register on 20 April 2026 delayed ADA Title II web compliance by one year, putting large state and local entities serving populations of 50,000 or more at 26 April 2027. WCAG 2.1 Level AA remains the standard, and the firm stresses that ongoing Title II obligations continue regardless of the delay. Translate that into contract language rather than a goal. Name the conformance target (WCAG 2.1 AA), say whether new content and new templates are audited before launch or only in an annual sweep, and state who remediates third-party components — a checkout widget, a booking embed, a chat bubble — that the agency does not control.
Payment pages carry their own script rules
If the site takes card payments, two PCI DSS requirements changed status on 31 March 2025. As summarised in Report URI's PCI DSS guidance, requirements 6.4.3 and 11.6.1 stopped being "best practice" and became mandatory: every script on a payment page must be authorized, integrity-assured, and inventoried with a written justification, and a mechanism must detect unauthorized changes to scripts and to security-impacting HTTP headers in the consumer's browser, alerting at least weekly. There is a genuine off-ramp for small merchants.
SecurityMetrics notes that these requirements were removed from SAQ A, so a merchant using a fully hosted iframe can instead obtain written confirmation from its PCI-compliant processor. The limit is important: scripts on the parent page, including the one that creates the iframe, stay in scope and remain the site owner's problem. That makes the real question a scoping question. Decide before renewal whether the vendor maintains the script inventory and the change-detection alerting, or whether it only promises not to add scripts — and if a marketing team can inject tags through a tag manager, say who reviews those.
Write the performance clause as a metric, not an adjective
"Fast site" is unenforceable. Interaction to Next Paint (INP) measures how quickly a page responds to a user's clicks and taps, and Google's web.dev documentation scores it as good at 200 milliseconds or less and poor above 500 ms, assessed at the 75th percentile of real user visits. INP replaced First Input Delay as a Core Web Vital in March 2024.
The 75th-percentile detail is the one that changes contracts. A lab test on an agency laptop can pass while a quarter of real visitors on mid-range phones fail, so the clause should specify field measurement from real users rather than a synthetic score. Set the threshold, the measurement source, and what happens when a page misses it — investigation included, or a separate engagement. Also agree which pages are covered: a homepage that passes tells you nothing about a checkout or a filtered product listing, which are usually where interaction delays live.
Frequently Asked Questions
Our host says it "manages PHP for us." Is that enough?
Only if the contract names the branch and the move date. Managed hosting often pins an older branch for compatibility, so ask which one the site will be on in December 2027 when PHP 8.3 reaches its end of security support.
We use a fully hosted payment iframe. Do we still need script monitoring?
Not under SAQ A, if your processor gives you written confirmation of its compliance. But the scripts on the page that loads the iframe remain yours to inventory and justify.
Does the one-year ADA Title II delay apply to our private business site?
No. That Interim Final Rule covers state and local government entities under Title II. Private-sector obligations and litigation risk are unchanged by it.
