Your Software Is Live: Who Is Responsible for Keeping It Secure?

Launch changes the work rather than ending it

A delivered application can pass acceptance tests and still become insecure later. Runtimes reach end of support, packages publish advisories, staff change roles, certificates expire and attackers learn new techniques. Production also reveals data flows and operational shortcuts that were not visible during development.

The contract phrase “hosted and supported” is too vague to allocate this work. Hosting may cover physical facilities, operating systems or a managed runtime. Support may mean answering user questions, restoring availability or modifying code. Unless patching and security response are named, each party can reasonably assume another owns them.

Start with a responsibility register: task, accountable owner, delivery party, evidence, target time and escalation route. Shared responsibility should create coordinated work, not shared ambiguity.

The cloud provider secures the service boundary

A cloud provider protects data centres and the services described by its platform commitments. In infrastructure hosting, the customer may still own the guest operating system and everything above it. In platform services, the provider may patch more of the runtime while the customer retains application code, identities, configuration and data.

Managed does not mean universally managed. An Azure App Service platform update does not upgrade an application from an obsolete target framework, replace a vulnerable NuGet package or correct broken authorisation logic. A managed database does not decide which employees should query customer records.

The precise boundary varies by service and configuration. Architecture documentation should state it per component rather than relying on a generic cloud diagram.

The software supplier owns what the agreement assigns

During active development, a supplier should use supported tools, respond to relevant advisories and avoid knowingly introducing unsafe designs. After handover, continuing duties depend on the maintenance agreement. Source-code ownership does not compel the original developer to monitor it forever.

A useful support agreement distinguishes runtime servicing, dependency updates, defect correction, security advisory response, monitoring, incident assistance and feature work. It states service hours and severity definitions. A response time to acknowledge an incident is not a restoration promise.

If the original supplier leaves, responsibility does not vanish. The business needs access to repositories, build instructions, cloud resources, dependency inventory and operational records so another capable team can take over.

The business remains accountable for business decisions

The owner decides who should access the system, how long data is retained, which risks are acceptable and how much downtime the organisation can tolerate. A developer can implement role-based rules but cannot invent the company's authority model responsibly.

Joiner, mover and leaver processes need business ownership. Identity automation is useful, but a perfectly functioning process will faithfully preserve incorrect source data. Privileged access should be reviewed against current job need, not merely whether an account is active.

The business also funds lifecycle work. Deferring an upgrade is a risk decision, not a free neutral state. Decision-makers should see the affected assets, exposure, compensating controls, expiry date and costed remediation route.

A practical responsibility matrix

“Typical” is not contractual truth. Use the table to find questions, then record the actual model for each application.

Vulnerability monitoring must lead to a decision

Scanning can identify a package with a published advisory, but somebody must establish whether the affected component is deployed, reachable and exploitable in context. A raw alert queue is not vulnerability management.

Prioritise with exposure, exploit maturity, privilege, data consequence and available remediation. Internet-facing critical issues often demand hours or days; an unreachable development tool may follow a different path. Document the reasoning so silence is not mistaken for acceptance.

Monitor vendor advisories, dependency feeds and services such as NCSC Early Warning where appropriate. Also track end-of-support dates. A product can become risky without a new CVE simply because future defects will not be corrected.

Maintenance requires a safe route to production

Teams delay patches when deployments are frightening. Automated builds, relevant tests, staged rollout, backups and rollback reduce that fear. The pipeline itself is privileged infrastructure and needs protected identities, reviewed changes and tamper-resistant artefacts.

Rollback is not always reversal. A database migration, external message or password reset cannot necessarily be undone by redeploying old code. Design compatibility and recovery before the urgent update.

Verify the production state after release. A green pipeline proves that automation completed, not that every instance restarted or that traffic reaches only corrected workers.

Backups and monitoring do different jobs

Monitoring should expose failed business journeys, unusual access and operational degradation. It must avoid placing secrets or excessive personal data in logs. Alerts need an owner and a response; dashboards nobody watches are documentation, not detection.

Backups protect recoverable state, but only restore tests prove usefulness. Recovery may also require infrastructure configuration, identity settings, certificates, package sources and external integrations. A database backup is not the whole application.

Agree recovery time and acceptable data loss with the business. These decisions influence architecture and cost, so they cannot be delegated silently to a hosting default.

What a maintenance agreement should answer

• Which applications, environments and components are covered?
• Who monitors runtime, package and provider advisories?
• What response targets apply by severity and exposure?
• Which updates are included and which require separate approval?
• Who can authorise emergency deployment or temporary shutdown?
• How are tests, rollback and live verification performed?
• Who investigates suspected compromise?
• How are access, backups and recovery tested?
• What happens when the agreement ends?

No agreement removes risk. It should make work, limits and escalation visible enough that the business can govern the remaining risk.

Decide who can act during an incident

Responsibility without authority fails under pressure. Name who can disable an integration, revoke privileged sessions, take a service offline, authorise emergency spend and communicate with affected stakeholders. Include deputies and out-of-hours contact routes.

The technical team should not make legal or regulatory notifications by inference, and executives should not direct evidence handling without technical advice. The incident plan connects those decisions while keeping accountable roles distinct. Obtain appropriate legal and specialist security advice where the event requires it.

Exercise a plausible scenario using the actual supplier and hosting contacts. A tabletop exercise often reveals expired phone numbers, inaccessible cloud accounts and contracts whose severity language does not match the business impact. Fixing those gaps is cheaper than discovering them during an intrusion.

After an incident or near miss, review why the control failed and why detection or recovery took the time it did. Avoid reducing the outcome to individual error. Queue pressure, unclear ownership and unsafe deployment processes are system conditions that will recreate the same mistake.

Give every security task an owner before it becomes urgent

The central question is not whether the supplier, host or customer is “responsible for security” in the abstract. It is who will perform and approve each action when a real advisory, access error or incident arrives.

Related guidance covers responding to the 2026 PHP vulnerabilities, dependency governance and designing beyond launch day.

Review responsibility when the system changes

A new integration, supplier, acquisition or hosting migration can move boundaries without updating the contract. Include security ownership in architecture and change reviews. Confirm that monitoring, support access and recovery still reach the right organisations. Remove obsolete access and escalation routes at the same time.

Review the matrix at least around material releases and supplier transitions. An accurate modest model is more useful than an elaborate responsibility chart describing last year's system.