--- title: Website Maintenance Onboarding Checklist for Agencies description: Use this agency checklist to define ownership, secure access, test backups, record website health, map critical journeys, and start monitoring safely. source: https://pingvera.com/blog/website-maintenance-onboarding-checklist.html --- # Website Maintenance Onboarding Checklist for Agencies Onboarding a website for maintenance means accepting operational responsibility for a system your agency may not have built, on infrastructure it may not own, with dependencies spread across several vendors. The safe sequence is to define responsibility, inventory the system, secure access, establish a baseline, test recovery, map business-critical journeys, and only then make changes. The onboarding is complete when both parties can answer five questions: what is covered, who owns each dependency, how the website can be recovered, what “working” means, and who is alerted when it is not working. ## At a glance Before the maintenance start date: 1. name operational and emergency contacts on both sides; 2. assign ownership for domain, DNS, hosting, CDN, CMS, email, payments, and integrations; 3. receive access through a secure, auditable process; 4. revoke or reduce obsolete supplier accounts after approval; 5. record the website's baseline condition before changing it; 6. verify that a backup can be restored, not merely that a backup job is green; 7. test the lead, order, payment, login, or booking journeys that make the website valuable; 8. create a known-issues and accepted-risks register; 9. configure monitoring, escalation, maintenance windows, and fallback contacts; 10. obtain written acceptance of the baseline and support boundaries. ## Why agencies should not begin with updates The first impulse is often to update the CMS, remove suspicious plugins, or clean an error log. That creates unnecessary risk. Before the baseline is recorded, the agency cannot reliably distinguish a pre-existing defect from a change it introduced. Start with observation. Change only what is required to make the assessment safe, and record every emergency change. ## Step 1: define the service boundary “The client handles the domain” is too vague. Record an accountable role, an authorised contact, and the fallback if that person cannot be reached. The services agreement and SLA should state what the agency controls, what it coordinates, and what it only observes. Have local counsel review contractual language; this checklist is an operational aid, not legal advice. ## Step 2: create a website passport The passport is a concise operational record. It should let an on-call engineer understand the service without searching old chats. # Client website passport Client: [organisation] Production URL: [canonical URL] Purpose: [leads / ecommerce / booking / account / publishing] Business criticality: [high / medium / low] Support tier and hours: [reference] ## Contacts - Client service owner: [role, channel] - Client emergency approver: [role, channel] - Agency service owner: [role] - Technical escalation: [team or role] - Security escalation: [role and out-of-band channel] ## Ownership and infrastructure - Domain registrar and account owner: [value] - Renewal date and renewal method: [value] - DNS provider: [value] - Hosting/cloud account: [value] - CDN/WAF: [value] - TLS issuance and renewal: [value] - Repository and production branch: [links] - Deployment process: [pipeline/runbook] - Staging environment: [URL or none] ## Application - CMS/framework and version: [value] - Runtime and database: [value] - Critical plugins/modules: [list] - Scheduled jobs and queues: [runbook link] - Email provider: [value] - Integrations: [payments, CRM, ERP, PIM, shipping, tax, identity] ## Recovery - Backed-up components: [files, database, configuration, media] - Frequency and retention: [value] - Separate storage location: [reference, not secret] - RPO / RTO target: [value] - Last successful restore test: [date, evidence] - Recovery owner: [role] ## Critical user journeys 1. [journey and measurable success condition] 2. [journey and measurable success condition] 3. [journey and measurable success condition] ## Operational channels - Routine work: [help desk/project tracker] - Incidents: [channel] - Status page: [URL or none] - Planned maintenance notice: [channel and notice period] Do not place passwords, private keys, recovery codes, or API tokens in the passport. Store a reference to the relevant secret-manager entry. ## Step 3: accept access safely Typical access includes the registrar, DNS, cloud or hosting account, CDN, CMS, SSH/SFTP, database, repository, CI/CD, backup storage, mail provider, payment platform, CRM, analytics, and monitoring. Use these rules: - prefer named agency accounts to a shared client login; - grant the least privilege required for the actual task; - enable MFA and verify that recovery belongs to the right organisation; - keep production write access separate from read-only monitoring; - record owner, purpose, approval, and expiry for privileged access; - keep break-glass access controlled, logged, and tested; - revoke former supplier and departed employee access through an approved process; - never request credentials in a normal email thread or group chat. OWASP recommends centralised secret storage, fine-grained access, auditable use, rotation, revocation, expiration, and tested break-glass procedures. The precise implementation depends on the client's environment. ## Step 4: record the baseline ### External checks - canonical redirects between HTTP/HTTPS and host variants; - TLS validity and chain; - DNS resolution from important audience regions; - unexpected redirects, injected content, or defacement; - representative response times and phase timing; - `robots.txt`, sitemap, canonical, and accidental `noindex` state; - important pages rather than only the homepage; - CDN error pages that can hide an unhealthy origin. ### Application checks - CMS, runtime, database, and critical extension versions; - unsupported components and known compatibility constraints; - unknown administrative accounts; - application, web-server, queue, and scheduled-job errors; - mail delivery configuration; - storage capacity and database health; - existing monitoring and security controls. ### Business checks - submit each revenue-critical form and confirm where the lead arrives; - place a controlled test order and verify payment mode, confirmation, inventory, tax, shipping, and downstream records; - test account creation, login, reset, and MFA where relevant; - test booking availability and confirmation; - confirm analytics and conversion events without collecting unnecessary personal data. Use synthetic data and documented test accounts. Do not create real charges, shipments, or customer records accidentally. ## Step 5: prove recovery A successful backup job proves that a file was created. It does not prove that the website can be restored. Record: - the components covered by backup; - encryption and access restrictions; - storage separation from production; - retention and point-in-time options; - the selected recovery point; - restore duration; - data freshness compared with the RPO; - application checks completed after restore; - remaining manual steps and single-person dependencies. Restore to an isolated target whenever possible. AWS Well-Architected guidance likewise recommends periodic recovery to a new location, validation of usable data, and measurement against RTO and RPO. ## Step 6: create the known-issues register Do not bury baseline defects in an audit PDF. Turn them into an agreed register. Possible decisions are: fix before start, include in the first maintenance cycle, accept temporarily, exclude from scope, or stop onboarding until resolved. ## Step 7: configure monitoring and escalation At minimum, monitor: - the canonical URL and one or more critical pages; - TLS and domain expiry; - form submission and, where permitted, delivery to the destination mailbox; - critical scheduled jobs or integration heartbeats; - unexpected redirects and selected security signals; - WordPress or application health where a safe integration exists. Define confirmation rules, alert owner, fallback channel, maintenance windows, time zone, and closure conditions. A monitor without an owner is only a future ignored notification. ## Step 8: sign off the operational baseline The onboarding record should include: Website: [URL] Baseline recorded: [UTC timestamp] Support starts: [UTC timestamp] Scope reference: [document/version] Known issues reference: [document/version] Recovery status: [tested / untested / partial] Critical journeys accepted: [list] Monitoring active: [checks and owners] Client acceptance: [name/role/date] Agency acceptance: [name/role/date] Example: taking over a WooCommerce store An agency receives WordPress administrator access and a hosting login. It pauses planned plugin updates, identifies that DNS is in a former employee's account, and records that transfer as a high risk. A test order succeeds, but the fulfilment record does not reach the warehouse system. The backup restores successfully to staging in 74 minutes, which exceeds the draft 60-minute RTO. The agency starts maintenance with three accepted actions: transfer domain/DNS ownership, repair fulfilment reconciliation, and improve restore time. None of these pre-existing issues can later be confused with a defect introduced by routine maintenance. ## Common onboarding mistakes - treating possession of a CMS password as complete handover; - changing production before recording the baseline; - accepting a backup icon instead of testing a restore; - monitoring only the homepage; - storing all client secrets in one shared document; - leaving payment, email, or integration ownership undefined; - promising a resolution target for systems the agency cannot change; - failing to obtain written acceptance of known defects. ## FAQ ### How long should website maintenance onboarding take? A small brochure site may take several hours; a transactional website with several integrations can take days. Completion should depend on evidence, not a fixed duration. ### Should an agency require full server access? No. Access should match scope. External monitoring may require no inbound production access, while incident recovery may require controlled, temporary privilege. ### Can onboarding continue if a restore has not been tested? Only if the parties explicitly accept the risk and define a deadline and owner. Do not describe recovery as verified. ### Who should own the domain? Normally the client organisation or another explicitly authorised entity, not an individual agency employee. Confirm this with the client's legal and operational requirements. ## Sources and further reading - [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) - [AWS Well-Architected: periodic recovery testing](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_backing_up_data_periodic_recovery_testing_data.html) - [NIST SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final) Reviewed: **8 August 2026**. Next: [Client website monitoring policy template](02-client-website-monitoring-policy.md) and [agency access control matrix](15-web-agency-access-control-matrix.md). Pingvera can provide the external layer of the onboarding baseline: availability, timing, TLS and domain checks, forms, lead delivery, selected security signals, and CMS-specific health checks. Define the process first; automate the accepted checks second.