# Managed Lifecycle Responsibility: What It Actually Covers Every operations vendor says "we'll run it for you." Fewer can say what that means when a customer's auditor asks for specifics, and fewer still can say it in a way that distinguishes them from a consultancy that places engineers. Swiss federal procurement for IT operations services draws the line explicitly, because buyers there need to tell the two apart before they sign. It separates platform processes into two categories: ones any firm supplying engineers by the hour can perform, and ones that require a bounded area of responsibility, with clear system boundaries, that stays with one operator over the life of the contract. The second category is what "managed lifecycle" means, and it is the shape of what VSHN sells when it operates your product. ## Two categories of work, not two tiers of skill The distinction is not about seniority or technical depth. A contracted engineer can be excellent at a task and still structurally unable to take on the second category, because that category requires continuity the engagement itself does not provide. **Delivery, staffing and project work**, the kind any competent firm can bid on a time-and-materials basis: - Implementing a specific feature or configuration change inside your product - Running a defined migration or upgrade project - Providing engineers who work inside your own team and tooling, under your own direction **Lifecycle responsibility**, which requires standing commitment to your running product rather than a task inside it: - Maintaining the configuration model and the record of what is actually deployed for each of your customer instances, not just what was last requested - Controlling and tracking configuration information over time, including license management for the platform underneath your product - Assessing, recording and evaluating changes as they happen, including handling emergency changes under pressure, for every customer instance you have, not just the one that is currently loudest - Assessing risk from disaster scenarios before they occur, not reconstructing a response after one of your customers is already affected - Identifying compliance requirements your customers' auditors will ask about, defining the measures that satisfy them, and running the reviews that prove it - Developing and maintaining the operational competencies your product needs over years, not for the duration of one ticket - Setting the strategic direction for the platform your product runs on: what it needs to become, not only what was asked for today A firm placing engineers into your team can be asked to do any one of these once. What it cannot do is be the party accountable for all of them continuously across every one of your customer instances, because accountability for a running product requires staying with it, and staffing engagements end when the contract does. ## Why this distinction is procurement's own, not ours This is not VSHN's framing of itself. It mirrors how large buyers already separate platform service management into five management process categories, Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement, and classify the supporting processes beneath them by whether each one requires standing platform ownership. Swiss public-sector IT operations tenders use exactly this structure to decide which bidders can take on a "Managed Lifecycle" engagement, defined as responsibility for a bounded platform or product area including service levels, operations, stabilization and continuous improvement, and which can only supply staff into someone else's. For an ISV, the same test applies to your own supplier choice. A consultancy can deliver a well-built feature. Whether it can also be the party your regulated customer's auditor holds accountable for configuration control, change management, disaster-risk assessment and compliance evidence, year after year, across every customer instance you run, is a different question, and it is the one this page answers for VSHN: yes, continuously, for the duration of the engagement. ## What VSHN actually operates under that responsibility The day-to-day detail, patching, backups, monitoring, documented deployments, and the Swiss/on-premises hosting that carries it, is already on this page under [what VSHN operates below your code](/#included). This section is about the accountability structure that detail sits inside, not a second description of the same list. ## What this changes about the objection "we'll just hire engineers" Hiring engineers gives you staffing capacity. It does not by itself give you lifecycle responsibility for your product's operations, because that responsibility is a function of continuity and accountability structure, not headcount. A team that rotates, that reports to a project rather than to the running product, or that has no mandate to maintain the configuration model between tickets, is doing delivery work even if every person on it is skilled, and it leaves the standing accountability with you. VSHN operates each customer instance of your product as lifecycle responsibility: one party accountable for configuration, change management, disaster-risk posture, compliance evidence and long-term operational direction, with [ISO 27001 certification](https://www.vshn.ch/wp-content/uploads/2026/08/ISO-27001-certificate-VSHN-2026.pdf) and named Swiss references across finance, healthcare and government. ## Where this sits next to our other content This page explains the shape of the commitment. [Sovereignty](/sovereignty/) covers who holds it and under what law, and [Partners](/partners/) covers how we work alongside the consultancy that builds your product. ## Get a lifecycle responsibility assessment Comparing a staffing proposal against an operations proposal and the two numbers don't look like they are pricing the same thing? They probably are not. [Contact us](#contact) and we'll walk through which category of work each line item actually falls into.