Evaluating Hosted App Providers: Questions to Ask Before They Hold Your Data

A provider promises simpler operations for a legacy line-of-business application. During procurement, details are unclear: who actually hosts the environment, what controls are included, which licenses remain your responsibility, and how hard it is to leave later.

The right response is not "never use hosted services." It is to ask structured questions early and get written answers before technical and contract decisions lock in.

Data ownership is the most critical boundary in any hosting agreement. You must clarify who owns the customer data, the associated metadata, and the operational logs generated by the service. Without explicit ownership terms, you may find yourself in a position where your own business records are held hostage during a dispute or transition.

Exit rights and portability are equally important. Before signing, define the export formats available and the specific tools required to use that data elsewhere. You should also document the expected timeline for a full data return and any associated exit costs, such as transition support fees or early termination penalties. Knowing these terms up front prevents expensive surprises when it is time to move on.

Backup scope often varies significantly between providers. It is essential to understand exactly what is being protected: is it just the raw data, or does it include application configurations, identity mappings, and audit logs? You should also verify the controls around these backups, ensuring they are immutable or stored offline to protect against ransomware and internal threats.

Testing is the only way to verify a backup strategy. Ask the provider how often they perform restore tests and what evidence they can provide for your review. If the provider's native backup strategy does not meet your internal recovery point objectives (RPO) or recovery time objectives (RTO), you may need to maintain your own customer-controlled backup strategy for critical datasets.

Related: Backup & DR testing.

Visibility into the hosted environment is a common blind spot for SMB teams. You must confirm whether your existing security monitoring workflows can consume meaningful telemetry from the provider. This includes support for SSO, MFA, and role-based access control, as well as the ability to export logs to a central SIEM for investigation and compliance evidence.

The shared responsibility model defines the boundary between provider-owned and customer-owned controls. If these boundaries are not explicit, critical security tasks are often assumed by both parties but implemented by neither. Ensure you understand how administrative access is controlled and logged, and who is responsible for patching the underlying operating system versus the application itself.

If responsibilities are not explicit, critical controls are often assumed by both parties and implemented by neither.

Contractual obligations during an incident can make or break your recovery. Your agreement should specify clear notification timelines and provide a direct path to escalation contacts. Beyond simple notification, the provider should be obligated to provide investigation details and log evidence to support your own forensic and regulatory requirements.

Commercial remedies should also be reviewed for adequacy. While service credits are a common starting point, they rarely cover the full business impact of a significant disruption. Additionally, ensure the provider discloses any third-party subprocessors or hosting dependencies, as these represent additional links in your supply chain that must be managed.

Not every capability is portable one-to-one. That can be acceptable, especially for specialized managed security tooling. The goal is to define portability boundaries clearly before purchase so you can make an informed risk decision.

Core business data, audit-relevant records, and ownership metadata must always be transferable in a usable format. However, provider-specific detection logic or proprietary workflows may not transfer directly. The key is to determine if this non-portability is operationally tolerable and whether it has been priced and managed as part of your overall risk acceptance strategy.

Provider name:
Service scope:
Business owner:
Technical owner:

1) Data custody and exit
- Who owns data, metadata, and logs?
- Export format and completeness documented? (yes/no)
- Export tools/support included? (yes/no)
- Exit timeline defined? (days)
- Exit fees defined? (yes/no)

2) Backup and recoverability
- Backup scope documented? (yes/no)
- Retention and RPO/RTO defined? (yes/no)
- Restore test evidence available? (yes/no)
- Customer-managed backups allowed? (yes/no)

3) Security integration
- SSO/MFA supported? (yes/no)
- RBAC/admin controls documented? (yes/no)
- SIEM/log export supported? (yes/no)
- Shared-responsibility matrix provided? (yes/no)

4) Incident and commercial obligations
- Incident notification timeline in contract? (yes/no)
- Investigation/log support obligations defined? (yes/no)
- Subprocessor/hosting chain disclosed? (yes/no)
- Remedies beyond credits understood? (yes/no)

Decision:
- Approve
- Approve with conditions
- Accept risk with exceptions
- Reject

Notes / required contract edits: