Name the accounts and owners
List the domain registrar, hosting, code repository and third-party services. Confirm who owns each account, who pays recurring costs and how authorised staff get access. Store credentials in an approved password or secret-management system rather than a shared document.
- Domain and DNS ownership.
- Source-code and deployment access as agreed in the contract.
- Named owners for email, payments and other integrations.
Ask how recovery works
A backup is only part of a recovery process. Identify what is backed up, how often it runs, who can restore it and which data a restore would replace. Ask for evidence of a restore test appropriate to the system rather than relying on an untested “backup enabled” checkbox.
- Separate application code from database and uploaded files.
- Agree recovery responsibilities and acceptable interruption.
- Document safe rollback and incident contacts.
Make support understandable
Before launch, agree what support includes, how an incident is reported and what happens after a maintenance period ends. Confirm training and operating notes for the people who will use the system. Ownership terms should be in the written agreement, not inferred from a sales conversation.
- Document routine operations and known limitations.
- Confirm training for each important role.
- Agree access removal when a team member or supplier leaves.
Questions, answered
Does every software contract include source-code ownership?
No. Licensing and ownership vary. Confirm the agreed rights in writing.
Is a server backup enough?
Not by itself. Confirm coverage and test how the business would restore the required data and service.
Should developers use a shared owner password?
Prefer named accounts and appropriate permissions, with recovery access controlled by the business.