Shared responsibility in a contract

Make responsibility executable

Replace 'the vendor handles it' with verbs, owners, and evidence.

Shared responsibility is not a disclaimer to place at the end of a contract. It is an operating design. For each important outcome, procurement should be able to identify what the provider performs, what TDE performs, how the parties exchange information, and what proves the activity occurred.

Broad words such as security, backup, support, or compliance often hide multiple tasks. A provider may back up service infrastructure while TDE must enable a feature, select retention, test restore, preserve exports, and decide how the business continues during an outage.

Follow the service lifecycle

Ask what happens before, during, and after normal service.

Feature availability is only the beginning. Contract language should support onboarding, routine operation, change, incident response, recovery, renewal, and exit. A support target is useful only if the right TDE role can open a case and the escalation path is known.

Published terms and product pages may inform evaluation. They do not prove the purchased plan, a negotiated commitment, or the internal workflow required to use it. Confirm the executed agreement and order form, then connect them to named TDE owners.

• Service scope: plan, region, limits, dependencies, exclusions, and change notice.
• Data: ownership, location, subprocessors, retention, deletion, export, legal hold, and return.
• Security and access: roles, administrative controls, notification, assurance access, and offboarding.
• Reliability: availability measure, exclusions, maintenance, support targets, escalation, and remedies.
• Recovery and continuity: backup scope, restore capability, testing, provider failure, and TDE workarounds.
• Exit: export format, timing, assistance, deletion evidence, transition period, and surviving obligations.

Close the owner gaps

Unassigned work remains a TDE risk even when the contract is signed.

A responsibility matrix should name provider, platform, application, operations, security, data, and procurement roles where relevant. If a required action has no named owner, record the gap instead of assigning it to 'shared.'

The current Ember support direction uses the City IT Service Desk for intake, IT Operations for triage and provider-ticket coordination, Engineering for platform escalation, and application owners for application context and recovery decisions. The supporting standard remains draft and must not be presented as approved policy.

• Who can open a provider case under the purchased plan?
• Who receives provider notices and status updates after hours?
• Who decides an application workaround, restoration priority, or business communication?
• Who verifies that service credits, corrective actions, data export, or deletion occurred?