Web Developer Client Handover Security Checklist

A website handover can leave security gaps when credentials, DNS ownership, deployment access, backups, and monitoring are not documented. A structured checklist makes the handover easier to audit later.

• Clients need enough information to maintain the site without depending on undocumented developer knowledge.
• Developers need a clear record of what was delivered, transferred, and intentionally left out of scope.
• Basic scanning after handover can verify externally visible configuration, but it cannot validate every custom workflow.

• Checks the launched site for externally visible HTTPS, header, cookie, DNS, redirect, robots, and sitemap signals.
• Provides a scan record that can be attached to the handover notes.
• Highlights configuration drift if the client or host changes settings after launch.
• Does not replace manual pentesting, source review, dependency audit, or credential rotation.

• Registrar, DNS, hosting, and CMS access are not transferred or documented.
• Temporary developer accounts remain active after launch.
• Backups exist but restore access is unclear.
• Security headers or HTTPS redirects differ between staging and production.
• robots.txt, sitemap, analytics, and search console ownership are not handed over.

• Transfer ownership or document named owners for registrar, DNS, hosting, repository, CMS, email, and analytics.
• Rotate shared credentials and remove temporary accounts after launch.
• Document backup location, retention, and restore steps.
• Run an external scan on the production hostname and include findings or accepted risks in the handover pack.
• Separate basic scan results from manual security work that was not part of the project scope.