Evaluating Hosted App Providers: Questions to Ask Before They Hold Your Data
Note: This is general information and not legal advice.
On this page
Executive Summary
- Hosting convenience can hide lock-in and operational blind spots.
- Backup and uptime claims are easy to market and hard to verify without evidence.
- SMB teams are often forced into expensive transitions when exit terms are vague.
- Data ownership and export terms are explicit before signature.
- Restore testing and incident obligations are evidence-backed, not implied.
- Portability boundaries are known: what must transfer and what may not.
The pattern SMB teams keep running into
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.
1) Data custody and exit rights
- Ownership: Who owns customer data, metadata, and logs?
- Export format: If you leave, what data is exportable and in what format?
- Tooling: What tools or services are required to use exported data elsewhere?
- Exit costs: What fees apply for export, transition support, or early termination?
- Timeline: How long does full data return take after notice of termination?
2) Backup, restore, and resilience reality
- Scope: What exactly is backed up (data only, app config, logs, identity mappings)?
- Controls: Are backups immutable/offline where needed? Who can delete or alter backups?
- Retention: What retention windows and recovery points apply?
- Testing: How often are restores tested, and what evidence can you review?
- Customer backups: Can you maintain your own backup strategy for critical datasets?
Related: Backup & DR testing.
3) Security integration and shared responsibility boundaries
- Visibility: Can your SIEM/logging workflows consume meaningful telemetry?
- Identity: Does the service support SSO/MFA and role-based access control?
- Boundary: Which controls are provider-owned vs customer-owned?
- Access: How are provider/admin support accesses controlled, approved, and logged?
If responsibilities are not explicit, critical controls are often assumed by both parties and implemented by neither.
4) Incident obligations and commercial terms
- Notification: What are incident notification timelines and escalation contacts?
- Response support: What investigation detail and log evidence will be provided?
- Remedies: Are remedies limited to service credits, or do terms cover broader impact?
- Subprocessors: Are third-party hosting/operations dependencies disclosed?
Portability nuance: what must transfer vs what may not
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.
- Must transfer: business data, audit-relevant records, core configuration documentation, ownership metadata.
- May not transfer directly: provider-specific detection logic, proprietary workflows, or platform-only features.
- Decision test: Is non-portability explicit, operationally tolerable, and priced/managed as part of risk acceptance?
Hosted provider due-diligence checklist (copy/paste)
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:Common Questions
Do we need full portability for every hosted service?
Not always. Some managed security tooling and platform-specific capabilities are not portable one-to-one. The key is to define portability boundaries up front: what data, logs, configs, and documentation must be exportable, what format they come in, and what transition support and costs apply.
What is the biggest hidden risk with third-party hosting offers?
Unclear lifecycle terms: who owns your data, how restores are validated, what happens during incidents, and what it costs to leave. If these are vague before signature, they become expensive after go-live.
Can we rely on provider backups alone?
Only if scope, retention, testing cadence, and restore responsibilities are explicit and proven. Many teams also keep customer-controlled backup options for business-critical data and evidence paths.
What should we ask about incident handling?
Ask for notification expectations, response responsibilities, forensic/log support boundaries, and contractual remedies. Service credits alone may not cover your real impact if operations are disrupted.
How do we evaluate total cost realistically?
Break out all components: platform fees, required bring-your-own licenses, storage/egress costs, support tiers, backup add-ons, migration labor, and offboarding/exit charges.
Related resources
Sources & References
Need help pressure-testing a hosted provider before you sign?
We can help you run a practical due-diligence review focused on data custody, recoverability, and exit clarity.
Contact N2CON