The website is done. The agency sends the final invoice, you make the last payment, and the project moves into "launched" status. Somewhere in that handoff, an assumption usually goes unquestioned: that security was part of what you paid for. It rarely was, at least not in the way most business owners think, and the gap between what you assumed and what was actually contracted is exactly where real vulnerabilities live.
There's no default answer, because responsibility is split by design
Security responsibility for a website isn't automatically assigned to any single party. It's distributed across the business that owns the site, the agency that built it, the hosting provider running the infrastructure, and every third-party vendor whose code got embedded along the way. Unless a contract explicitly defines who owns which piece, the honest answer to "who's responsible for security" is that it's ambiguous, and ambiguous responsibility is functionally the same as nobody's responsibility until something breaks.
What the business actually owns
Regardless of who wrote the code, the business that operates the website owns the risk. If customer data is exposed, regulatory obligations under frameworks like state privacy laws or industry-specific requirements land on the business, not the agency that built the intake form. That's true even when the vulnerability originated entirely in code the business never touched.
Practically, the business is responsible for defining security requirements before development starts, not discovering them after launch. That means specifying security expectations in the statement of work, deciding whether independent verification happens before final acceptance, and owning the ongoing decision to patch, monitor, and reassess the site after the agency's contracted involvement ends. Most agency engagements are scoped to deliver a working website, not to maintain its security indefinitely, which means post-launch responsibility defaults back to the business unless a separate maintenance agreement says otherwise.
What the development agency is actually on the hook for
A competent agency is responsible for secure coding practices during the build itself: avoiding well-documented vulnerability classes like injection flaws and broken access control, following reasonable security standards during development, and not shipping code with obvious, avoidable weaknesses. That's a real and legitimate responsibility, and it belongs squarely with whoever wrote the code.
What most agencies are not contractually responsible for, unless it's explicitly written into the agreement, is ongoing security after handoff, vulnerabilities introduced by third-party plugins or integrations they didn't build, or security issues rooted in hosting configuration rather than application code. This is where a lot of business owners get surprised. An agency delivering a functional, feature-complete website has technically fulfilled a typical contract even if that website has real, exploitable vulnerabilities, because "secure" was never defined as a deliverable in the first place. If security wasn't in the statement of work as a measurable requirement, it's not something you can hold the agency accountable for after the fact.
What the hosting provider covers, and what it doesn't
Hosting operates on something close to a shared responsibility model, the same concept cloud providers use. Your host is generally responsible for physical infrastructure security, network-level protections, and platform uptime. What a hosting provider almost never covers is the security of the application running on top of that infrastructure. A perfectly secure server can still run a website with a broken authentication flow, an exposed admin panel, or a vulnerable plugin, and none of that is the hosting provider's problem to catch or fix.
Where this gets murkier is with managed hosting plans that bundle in some patch management, typically limited to the underlying platform and core software versions, not custom code, themes, or the specific configuration choices made during your build. Knowing exactly where your hosting provider's responsibility ends is worth confirming directly, because "managed hosting" means different things across providers.
What third-party vendors are responsible for, and why that's not enough
Every plugin, payment integration, analytics tag, and chat widget embedded in your site comes from a vendor responsible for the security of their own code. But you inherit the risk of that integration the moment it's live on your domain, regardless of whose logo is on it. This is exactly the mechanism behind web skimming and supply chain attacks, where a single compromised third-party script becomes the entry point into an otherwise well-built site. The vendor is responsible for their code. You're responsible for what happens when their code runs on your infrastructure.
Where vulnerabilities actually slip through
The pattern across all four parties is consistent: each one reasonably assumes security is being handled somewhere else in the chain. The agency assumes the host secures the infrastructure. The host assumes the agency wrote secure application code. Nobody assumes responsibility for third-party scripts because technically none of the other three parties wrote them. And the business, having paid for a finished product, assumes "finished" implicitly meant "secure." It didn't, unless someone tested the fully assembled, live system end to end, which is a step that happens in surprisingly few standard agency engagements unless the client specifically asked for it.
A website acceptance checklist before you sign off
Before treating a delivered website as complete, verify the following: HTTPS is enforced across every page with no fallback to plain HTTP, core security headers are configured rather than left at platform defaults, the admin login is protected with multifactor authentication and isn't reachable using default or placeholder credentials, no API keys or credentials are exposed in the delivered codebase or client-side scripts, every third-party script and integration is documented with a clear list of what data each one can access, session and cart cookies carry proper security attributes, backups are configured and confirmed to actually restore, and an independent vulnerability assessment has been completed with any critical or high-severity findings resolved before final payment releases.
An example contract clause to review with counsel
Language like the following can be adapted into a statement of work or master services agreement to make security an explicit, measurable deliverable rather than an assumed one:
"Developer warrants that the delivered website and all associated code will be free of critical and high-severity security vulnerabilities, as verified by an independent third-party vulnerability assessment conducted prior to final acceptance. Client reserves the right to commission such an assessment at Client's discretion. Any critical or high-severity findings identified within thirty (30) days of delivery shall be remediated by Developer at no additional cost as part of the original engagement, subject to retest verification."
This is a starting point for a conversation with an attorney, not a drop-in legal document, contract language needs to fit your specific engagement, jurisdiction, and risk tolerance, and should always be reviewed by legal counsel before it goes into a binding agreement.
A handoff testing procedure
A structured handoff, rather than an informal "looks good, ship it," protects both sides of the engagement. Start by defining a feature freeze once development is functionally complete, so testing happens against a stable target rather than a moving one. Have the agency deliver the site to a staging environment that mirrors production configuration. Commission an independent vulnerability assessment scoped specifically to the delivered site before it goes live, covering the web application, any connected APIs, and the hosting configuration. Route any findings back to the agency for remediation under the warranty period defined in your contract, rather than treating them as a new, separately billed project. Once fixes are deployed, run a focused retest confirming the specific findings were actually resolved, not just deployed and assumed fixed. Only then move to final acceptance, final payment, and go-live.
Why this belongs before acceptance, not after
An independent assessment run before you sign off and release final payment changes the entire dynamic of who fixes what. Findings surfaced before acceptance are the agency's responsibility to resolve as part of the original engagement, covered by whatever warranty language is in your contract. The same findings surfaced three months after launch, once the agency has moved on to its next client and your final payment has already cleared, become your problem entirely, on your budget, with no contractual leverage to push the fix back to whoever built it.
This is exactly the moment a scoped vulnerability assessment earns its cost many times over. A core audit against the delivered site, its web application, API, and hosting environment, can be scoped and started the same day, fast enough to fit inside a standard handoff window without holding up your launch timeline. For sites handling payment data, sensitive customer information, or complex authentication and access requirements, an extended audit adds deeper, authenticated penetration testing before you're willing to call the build complete.
And once the site is live and the agency's contracted involvement winds down, security review shouldn't stop with the acceptance test. A newly launched site keeps changing, plugins update, content gets added, integrations expand, which is exactly why rolling into a recurring quarterly assessment after launch closes the gap that a single pre-launch audit was never meant to cover indefinitely. The agency built the site. Verifying it's actually secure, both at handoff and on an ongoing basis afterward, is the one responsibility that was always going to land on you unless you put it in writing before the final invoice was paid.
