Put ownership in writing
List the domain, hosting, source repository, databases and third-party accounts. Record which belong to the business and which remain licensed services. Give the authorised people access through role-based accounts rather than a shared password spreadsheet. Agree the handling of vendor access when the engagement ends.
Ask for an operational walkthrough
Have the delivery team demonstrate deployment, rollback, data export and restoration using the documented process. Identify any steps that depend on one person's machine or private account. Confirm where credentials are managed without including their values in ordinary documentation.
| Handover item | Evidence to request |
|---|---|
| Deployment | An authorised person can follow the release process. |
| Backup | A restoration has been tested with agreed recovery expectations. |
| Monitoring | The responsible team can see and triage a failed process. |
| Data export | Records can be exported in an agreed usable format. |
| Access removal | A departing staff or vendor account can be revoked. |
Define support before an incident
Separate an incident, a defect and a new feature request. Agree contact routes, supported hours and response expectations in the actual agreement. Identify who owns external service failures and communicates with the business. Avoid treating an uptime statement as meaningful unless the measurement method, exclusions and responsibilities are clear.
Maintain the system after acceptance
Plan dependency updates, access reviews, restore checks and review of provider changes. Security verification should match the system's risk and be supported by concrete tests; mentioning a standard is not a certification. Keep an issue and release record so future maintainers can understand why the system behaves as it does.