Website Maintenance Plan: What to Cover After Launch

Opening answer (BLUF)

A website maintenance plan after launch is an operating contract, not a leftover punch list from go-live. It should name who keeps the site available, who applies updates, how backups are stored and restore-tested, how changes are proven on staging before production, and who is accountable when the site is down. CISA still treats the 3-2-1 backup rule as a trusted baseline and tells operators to test full and partial restores, not just to confirm that a backup job finished.[1] CIS Control 11 goes further for day-to-day operations: automate backups at least weekly, keep an isolated copy, and test recovery on a sample of assets at least quarterly.[2]

Launch is not the finish line

Once the site is public, it is a production system. Forms, content, DNS, TLS, the CMS, the database, and the host all have to keep working while the business keeps changing pages and depending on the URL. NIST's 2010 Contingency Planning Guide (SP 800-34 Rev. 1, still the current NIST information-system contingency guide) defines that work as plans, procedures, and technical measures so a system can be recovered as quickly and effectively as possible after a disruption.[3]

You need a recovery time you can live with (how long the site can stay down), a recovery point you can live with (how much recent work you can afford to lose), and a named person who will execute the plan. NIST calls those the recovery time objective (RTO) and recovery point objective (RPO), and ties them to maximum tolerable downtime, the outage the process owner is willing to accept.[3] If those numbers are not written down, you do not have a maintenance plan. You have a hope. Our team sees the same gap on new sites and on sites that have been live for years: the launch vendor has moved on, backups exist somewhere in a dashboard, and nobody can say who gets the 2 a.m. call.

Backups you can actually restore

A backup that has never been restored is a rumor. CISA's backup guidance is blunt: keep three copies of important files, on two different types of storage media, with one copy off-site, and test procedures so the team can restore data fully and partially and roll back at least seven days if needed.[1] CIS Control 11 adds the operating cadence we actually want on a live site. Safeguard 11.2 calls for automated backups of in-scope assets weekly, or more often based on data sensitivity. Safeguard 11.4 requires an isolated instance of recovery data (offline, cloud, or off-site, as long as it is not sitting next to production). Safeguard 11.5 requires restore tests at least quarterly on a sample of those assets.[2]

CISA's #StopRansomware Guide (updated 2023) is the reason isolation matters. Maintain offline, encrypted backups of critical data and test availability and integrity in a disaster-recovery scenario, because many ransomware variants hunt for accessible backups and then delete or encrypt them so restoration is impossible unless a ransom is paid.[4] On the same CISA backup page, Verizon's 2025 Data Breach Investigations Report is cited for a simple fact: ransomware figured into 44% of the breaches Verizon investigated.[1] A marketing site with a form database or uploaded documents is still data you cannot reconstruct by hand.

The backup set has to be more than public HTML: application code and configuration, the CMS database and media library, web-server and TLS settings, DNS and registrar details stored offline, and a documented rebuild path for the host. Secrets belong in a vault, with the runbook saying how to reattach them. Record the last successful restore test (date, who ran it, how long it took, whether the restored site could send email, accept a form, and serve a valid certificate). CISA tells teams to write the procedures down and train people to use them.[1] CIS wants that recovery process documented, with scope, prioritization, and backup security, and reviewed at least annually.[2]

If a vendor says "we take daily backups," ask three owner-level questions. Where does the isolated copy live? When did someone last restore it onto a clean environment? How many hours of content would we lose at the current RPO? If those answers are vague, the website maintenance plan is incomplete.

Uptime is a measured job, not a hope

Availability is not a feeling. It is a check that runs on a schedule and a person who is supposed to act when the check fails. Cloudflare's load-balancing health-monitor guidance is a useful, vendor-neutral model even if you never use their load balancer. Each health check is trying to answer two questions: is the endpoint offline (does it respond at all, and quickly enough), and is it working as expected (does it return the expected HTTP codes, and does the body contain what you told the monitor to look for).[5] A homepage that returns 200 with a database-error string is not "up." A contact form that times out is not "up." A checkout or booking path that 500s while the marketing page still loads is not "up."

Write the monitors into the plan: which URLs are checked and how often, what "healthy" means (status code, time, a string that must be present or absent), who is alerted after hours, and who they escalate to. NIST SP 800-34, even as a 2010 document, is still the right frame. Contingency planning exists to mitigate unavailability with recovery strategies that match the impact of downtime.[3] For a lead-generating site, that impact is missed inquiries and a dead form. For an agency running client sites, it is those problems multiplied by every property on the same unattended stack.

Uptime also includes planned work. A maintenance window is not an outage if it is scheduled, announced, and reversible. An unannounced runtime update that takes the site down on a Tuesday afternoon is an incident, even if nobody attacked you. The plan should say which class of work is allowed in production without a window, and which class is not.

Who patches, and on what clock

Patching is not a personality trait. It is a job with an owner, a cadence, and a verification step. NIST SP 800-40 Revision 4 (April 2022) defines enterprise patch management as identifying, prioritizing, acquiring, installing, and verifying patches, updates, and upgrades, and it frames that work as preventive maintenance, a cost of doing business if you need the technology to keep serving the mission.[6] Leadership, business owners, and the security or technology team are supposed to jointly set the strategy. The guide also says a patch should be tested before it is placed into production, specifically to reduce operational risk by finding problems before users do.[6]

CIS Control 7 turns that into a calendar. Safeguard 7.3 calls for automated operating-system patching monthly or more often. Safeguard 7.4 says the same for applications. Safeguard 7.2 wants a documented, risk-based remediation process reviewed at least monthly. Defenders are expected to assess risk, regression-test patches, and install them, because attackers get the same public information and often move faster.[7]

A website maintenance plan should name, by role, who updates the host and OS, the runtime and web server, CMS core and extensions, TLS certificates, custom-code dependencies, and DNS or CDN configuration. If two vendors both "handle updates," nobody does. If the owner "approves everything," say how fast that approval happens when a known exploited vulnerability lands on an internet-facing service. CISA's Cross-Sector Cybersecurity Performance Goals tell operators to patch or otherwise mitigate known exploited vulnerabilities on internet-facing systems within a risk-informed window, with more critical assets first.[8] The ransomware guide makes the same point in plainer language: regularly patch software and operating systems, and prioritize internet-facing servers, especially for known exploited vulnerabilities.[4]

NIST is honest about the trade-off. Deploying faster shrinks the window for attackers and raises the chance of a self-inflicted outage. Testing more lowers operational risk and leaves the vulnerability open longer.[6] The useful answer is a default monthly (or faster) cadence, a staging gate, and a documented emergency path that skips the queue when the risk is already being exploited. The plan should also say what happens when a component cannot be patched (end-of-life CMS, abandoned extension, frozen custom fork). NIST lists that case: the vendor may no longer support the software, so a patch will never arrive, and the organization has to mitigate, replace, or accept the risk in writing.[6]

Staging before production is part of the plan

Staging is how you keep patching from becoming an outage. NIST's patch-preparation steps include validating the patch (authenticity and integrity) and testing it before deployment.[6] CIS Control 7 says the same in different words: when a vulnerability is public, vendors ship patches, and defenders still have to regression-test and install them.[7] A website maintenance plan that says "we apply updates" without a staging rule is volunteering for surprise downtime.

Staging does not need to be a perfect clone of production. It does need the same major runtime and extensions, a recent (sanitized) database copy, and the caching and redirect behavior users actually hit, plus a short checklist: homepage, key landing pages, forms, login, and any checkout or booking flow. Production then gets a backup immediately before the change, a change window, and a rollback path. NIST notes that a bad install can require uninstalling the patch, reverting to the previous version, or restoring from backups.[6] That is only possible if the backup is restorable and someone on the call has permission to roll back. Write those permissions down.

Emergency patches still belong on staging, even if the test is a 20-minute smoke test. Distinguish routine updates (monthly window, full checklist) from emergency updates (same checklist, compressed clock, named approver).

Who is on the hook when the site is down

This is the clause most "maintenance" pages skip, and it is the one owners actually need at 2 a.m. CIS Control 17 exists because protections fail, and a shop with good people but no written plan still will not know the reporting path or communications strategy when something breaks.[9] Safeguard 17.1 is the owner-level line: designate one key person, and at least one backup, to manage incident handling. Those people can be employees, a service provider, or a hybrid. If you use a provider, designate at least one person inside the business to oversee the third-party work, and review that designation annually.[9]

That internal overseer is not optional. The vendor can restart a host. The owner still has to decide whether to fail over, whether to restore from last night's backup (and lose today's form submissions), whether to take the site to a holding page, and what to tell customers. CIS 17.4 wants a documented incident-response process that covers roles, compliance duties, and a communication plan. CIS 17.2 wants a current contact list: internal staff, vendors, law enforcement, cyber insurance, relevant agencies. CIS 17.6 wants primary and secondary communication channels, because email may be part of the outage.[9] CISA's ransomware guide adds a practical detail: keep a hard copy of the incident-response and communications plan, plus an offline version, and exercise the plan instead of only filing it.[4]

Put names, not logos, on the page: incident lead and backup with phone numbers that work when chat is down; host, registrar, CDN, TLS, and email vendors with after-hours contacts; who can authorize a restore or failover; who talks to staff and customers; how someone reports "the site looks wrong." CIS 17.7 asks for routine incident-response exercises at least annually, testing communication channels, decision-making, and workflows.[9] For a brochure site that can be a 45-minute tabletop: homepage is down, form is 500, DNS looks fine, who does what in the first 30 minutes? If nobody can answer without opening a five-year-old statement of work, the plan is not operational yet. NIST SP 800-34 treats the contingency plan as a user's manual that has to be tested, trained, and maintained, not written once at launch and forgotten.[3]

What to put in the written operating contract

You do not need a 40-page federal template. You do need a document a non-technical owner can read and a technician can execute. At minimum it should record:

1. Inventory of the live stack (host, CMS, runtime, DNS, TLS, email, analytics, forms, payment or booking, if any).
2. Backup locations, isolation method, encryption, retention, RPO, last restore-test date, and who is allowed to restore.
3. Uptime monitors, alert roster, after-hours coverage, and the definition of "down."
4. Patch owners, monthly (or faster) cadence, staging rule, emergency path, and what is explicitly out of support.
5. Incident lead, backup, vendor contacts, communication channels, and who oversees any third party.
6. A review date. CIS wants the recovery process and the incident designations reviewed at least annually, or when the stack changes in a way that would invalidate the plan.[2][9]

If a vendor will not put those six items in writing, you do not have a maintenance plan. You have a retainer.

Practical takeaways

• Treat the live site as a production system with an RTO and RPO, not as a project that ended on launch day.[3]
• Keep three copies of site data, on two kinds of media, with one copy off-site, and restore-test full and partial recoveries (CISA), on at least a quarterly sample (CIS).[1][2]
• Isolate and encrypt backups so ransomware cannot delete the only copy you have.[4]
• Monitor more than the homepage: check that the endpoint is reachable and that it is behaving as expected.[5]
• Name who patches the host, the runtime, the CMS, and the certificates, on a monthly-or-faster clock, with verification after install.[6][7]
• Test updates on staging, take a fresh backup, then change production, with a documented rollback.
• Designate one incident lead and one backup, plus an internal person to oversee any vendor, and keep an offline contact list.[9]
• Exercise the down-site runbook at least once a year so the first rehearsal is not a real outage.[4][9]

How we can help

Have more questions or want to get in touch? Our team treats post-launch care as an operating contract: restore-tested backups, uptime checks, a named patch owner, staging before production, and a human who is on the hook when the site is down. If you want that work spelled out against your stack, start with our website maintenance page or contact us.

Citations

1. Cybersecurity and Infrastructure Security Agency (CISA), "Back Up Government Data" (2025)
2. Center for Internet Security, "CIS Control 11: Data Recovery" (CIS Controls v8 assessment specification)
3. National Institute of Standards and Technology, "SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems" (2010-05, updated 2010-11-11)
4. Cybersecurity and Infrastructure Security Agency (CISA), "#StopRansomware Guide" (2023-09)
5. Cloudflare Docs, "Server and pool health" (updated 2026-04-23)
6. National Institute of Standards and Technology, "Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology (SP 800-40 Rev. 4)" (2022-04-06)
7. Center for Internet Security, "CIS Control 7: Continuous Vulnerability Management" (CIS Controls v8 assessment specification)
8. Cybersecurity and Infrastructure Security Agency (CISA), "Cybersecurity Performance Goals (CPGs)" (Cross-Sector CPGs; known-exploited-vulnerability patching goal 1.E)
9. Center for Internet Security, "CIS Control 17: Incident Response Management" (CIS Controls v8.1 assessment specification)