Research
Inherited-system takeover assessment
Concept
A concept for a standard assessment used before taking operational responsibility for a system someone else built.
- Updated:
- What it is
- A concept for a structured assessment, with fixed domains and outcomes, that establishes a supportable baseline before any service commitment for an inherited system.
- What it is not
- Not a tool, not an audit and not a security certification of the assessed system.
The question
When is it responsible to accept a service commitment for a system you did not build?
Assessment domains
- Ownership and access: code, infrastructure, accounts, domains, data, licences and administrative control.
- Architecture: services, dependencies, integrations, hosting and critical failure points.
- Code and quality: maintainability, tests, build process, known defects and technical debt.
- Security: authentication, access control, secrets, vulnerabilities, patching and incident history.
- Data: stores, backups, retention, privacy responsibilities and recovery expectations.
- Operations: deployments, monitoring, logs, alerts, incidents and release ownership.
- Documentation: runbooks, architecture records and business-critical knowledge.
- Service expectations: hours, criticality, planned changes and escalation routes.
Possible outcomes
- Accepted as it is.
- Accepted with conditions and a transition or remediation backlog.
- Assessment or engineering rescue required before service begins.
- Declined, where risk, access, legality, a capability gap or the commercial model make responsible support impossible.
Known limitations
This page describes a concept drafted from Vitalos's own delivery methods. It makes no claim about any implementation, results or client use; none are published here. The checklist depth, evidence standards and how findings convert into a transition backlog are not yet defined.