How to Evaluate Self-Hosted Backup for Data Sovereignty

Quick Answer

Evaluating self-hosted backup for data residency control requires a different framework than standard backup evaluation. The standard evaluation focuses on features — backup frequency, restore granularity, compliance certifications. The data residency evaluation focuses on architecture — where does data actually go during processing, who has access to it during transit, which jurisdiction governs the vendor's access to your data, and what happens to your backup infrastructure if the vendor changes pricing, discontinues a product, or is acquired. This guide provides the step-by-step framework for evaluating bring-your-own storage and self-hosted backup models against these criteria.

Why standard backup evaluation criteria are insufficient for data residency requirements

Standard backup evaluation criteria — backup frequency, restore granularity, compliance certifications, pricing — are necessary but insufficient for organizations where data residency is a compliance requirement rather than a preference.

A backup platform with five-minute backup intervals, field-level restore precision, SOC 2 Type II certification, and competitive annual pricing may still fail a data residency evaluation if its architecture routes backup data through vendor-managed infrastructure in an unverified jurisdiction. The features are real. The compliance documentation is genuine. But the architecture creates data processor obligations under GDPR, Business Associate Agreement requirements under HIPAA, and jurisdiction exposure under national data sovereignty laws — regardless of the feature quality.

The evaluation framework for self-hosted backup adds a layer of architectural scrutiny that standard evaluation skips. Before evaluating any feature, the framework verifies the fundamental architecture: does this platform actually process and store data inside our own environment, or does it route data through vendor infrastructure and call it "self-hosted" because the destination storage is customer-owned?

This distinction matters because the market for backup platforms uses "customer-controlled storage," "bring-your-own storage," and "self-hosted" in ways that are not always consistent with what the terms mean for data residency compliance. Some platforms that market "bring-your-own storage" still process data on vendor servers before writing it to customer storage — creating the data processor relationship that data residency requirements seek to avoid.

The evaluation framework below tests actual architecture rather than accepting vendor claims at face value.

Step 1: Define your data residency requirements before evaluating any platform

The evaluation framework starts with requirements definition — before contacting vendors, before scheduling demos, before reviewing pricing. Requirements defined after demo exposure are influenced by what vendors showed — requirements defined before demos are driven by actual compliance obligations.

Identify the regulatory frameworks that impose data residency obligations on your backup data. GDPR's Chapter V restricts transfers of personal data outside the EEA without adequate legal mechanisms. HIPAA's security perimeter obligation requires ePHI to remain within the covered entity's own security controls. National data sovereignty laws in India, Brazil, China, and other jurisdictions impose geographic processing requirements for specific data categories. Document which frameworks apply to which categories of your backup data.

Define the geographic processing requirement for each data category. For each regulated data category, document the required processing jurisdiction — EU for GDPR-regulated personal data, US for US government contractor data subject to data classification requirements, within national borders for data subject to localization laws. This geographic requirement constrains which cloud regions or on-premise locations are acceptable for backup processing and storage.

Define the vendor access requirement. Some data residency requirements are satisfied by geographic storage location alone. Others — particularly under national sovereignty laws and HIPAA security perimeter obligations — require that vendor systems not have access to the data during processing, regardless of geographic location. Document whether your requirements allow vendor infrastructure in the processing chain with appropriate legal mechanisms, or whether they require vendor infrastructure to be excluded from the processing chain entirely.

Define the vendor independence requirement. Document the organization's risk tolerance for vendor dependency on backup infrastructure. Organizations that have experienced vendor pricing changes, product discontinuations, or acquisition-related disruptions to backup infrastructure have a concrete basis for defining vendor independence requirements. Organizations that have not experienced these events should assess the risk based on their backup infrastructure's criticality and the cost of an unplanned migration.

With requirements documented, every platform evaluation can be assessed against specific criteria rather than general impressions from vendor demos.

Step 2: Verify the actual processing architecture

The most important evaluation step is verifying where backup data is actually processed — not where it is stored, not what the vendor's marketing materials say, but where the vendor's systems touch your data during backup and restore operations.

Ask the direct question. During initial evaluation conversations with every vendor, ask directly: "At any point during backup extraction, processing, or restore operations, does your infrastructure have access to our data?" This question should be asked verbally in a recorded meeting and confirmed in writing. Cloud-hosted platforms will answer yes. Genuine self-hosted platforms will answer no.

Request a data flow diagram. Ask every vendor to provide a detailed data flow diagram that shows every system the backup data passes through from source to destination — including any intermediate processing, transformation, or quality check stages. Review the diagram with your legal and compliance teams before accepting the vendor's characterization of their architecture as self-hosted.

Test the network behavior directly. During a proof-of-concept deployment, monitor outbound network connections from the backup software during active backup and restore operations. Use your network monitoring infrastructure to capture all connection destinations. Confirm that connections go to your source systems — Salesforce, NetSuite, on-premise databases — and your destination storage, without any connections to vendor infrastructure during data processing.

For Sesame Software, this test produces a clean result — during normal backup and restore operations, no connections go to Sesame Software's infrastructure. The software runs inside your environment and connects only to your source systems and your destination storage. This is verifiable through your own network monitoring rather than through vendor assurance.

Verify the software update mechanism. Even platforms that process data inside the customer's environment may route data through vendor infrastructure during software updates if the update mechanism has access to customer data. Ask every vendor to describe exactly how software updates are delivered and installed, and whether the update mechanism has any access to customer backup data during the update process.

Step 3: Evaluate bring-your-own storage implementation

Bring-your-own storage means the backup data is written to storage the organization owns and controls — your own cloud storage accounts or your own on-premise storage. But bring-your-own storage implementations vary significantly in how they work, and some implementations that market as BYOS still create data residency exposure.

Distinguish between BYOS and vendor-processed BYOS. A genuine BYOS implementation writes data directly from the backup software running in your environment to your storage account — the vendor's servers are never in the data path. A vendor-processed BYOS implementation processes backup data on the vendor's servers and then writes the result to your storage account — the vendor's servers have had access to your data during processing, even though the final storage location is yours.

For data residency compliance, vendor-processed BYOS creates the same data processor relationship as fully vendor-hosted backup — the vendor's systems touched your data during processing. Genuine BYOS — where the backup software runs in your environment and writes directly to your storage — keeps the vendor out of the processing chain.

Verify storage account ownership and access controls. Confirm that your storage account — the S3 bucket, the Azure Blob container, the on-premise NFS share — is owned and managed by your organization, not by the vendor. The vendor should not have standing access to your storage account during normal operation. Ask the vendor to document what access, if any, their systems have to your storage account and under what circumstances they would access it.

Confirm encryption key ownership. For backup data that is encrypted at rest — which it should always be — confirm that the encryption keys are owned and managed by your organization, not by the vendor. Vendor-managed encryption keys create a key dependency that compromises storage sovereignty — if the vendor's key management infrastructure is unavailable, your backup data may be inaccessible. Customer-managed encryption keys keep storage access fully within your control.

Test data residency by monitoring write destinations. During a proof-of-concept, execute a backup operation while monitoring where backup data is written. Confirm that the write destination is your storage account in your designated region — and that no intermediate write occurs to vendor storage before the data reaches your account.

Step 4: Assess deployment model flexibility

Self-hosted backup platforms vary in how flexibly they can be deployed — on-premise only, cloud account only, hybrid, or any combination. The deployment flexibility requirement depends on your infrastructure mix and your data residency obligations.

Map your infrastructure to deployment requirements. Most enterprise organizations have a mix of on-premise infrastructure for legacy systems and cloud accounts for modern workloads. The backup platform needs to support backup operations for all source systems regardless of where they run — and needs to write backup data to storage that satisfies the residency requirement for each data category.

Evaluate on-premise deployment capability. For organizations with strict data residency requirements that mandate on-premise processing, evaluate whether the backup platform can be installed and operated on on-premise servers without requiring cloud connectivity during normal operation. Some "self-hosted" platforms require cloud connectivity for license validation, telemetry reporting, or update management — which creates connectivity dependencies that on-premise-first organizations may not have or want.

Evaluate cloud account deployment capability. For organizations whose residency requirements are satisfied by deployment in their own cloud accounts in specific regions, evaluate whether the platform supports deployment on VMs or containers in your AWS, Azure, or GCP accounts. Confirm that the deployment runs entirely within your account — not in a vendor-managed cloud environment within your account, and not as a SaaS service that happens to write to your storage.

Evaluate hybrid deployment capability. For organizations with mixed on-premise and cloud infrastructure, evaluate whether a single backup platform instance can protect both on-premise and cloud-hosted sources while writing backup data to your designated storage — or whether separate deployments are required for each infrastructure type.

Sesame Software supports deployment on Windows and Linux servers in any environment the customer controls — on-premise data centers, VMs in the customer's own cloud accounts, or hybrid combinations. A single Sesame Software deployment can protect Salesforce, NetSuite, Oracle on-premise databases, and SQL Server instances simultaneously, writing all backup data to the customer's designated storage without separate deployments for each source type.

Step 5: Evaluate compliance evidence production within your environment

Data residency compliance requires not just that backup data stays within your environment — it requires that the compliance evidence documenting your backup operations is also produced and stored within your environment. An audit evidence package that requires vendor assistance to compile is not fully within your control.

Assess audit log storage location. Verify that backup job logs, restore operation logs, access logs, and schema change logs are stored within your own environment — not on vendor servers. If your audit evidence is stored on vendor infrastructure, producing it for a regulatory audit requires vendor cooperation — which creates a dependency at exactly the moment when your compliance posture is under external scrutiny.

Assess evidence production capability without vendor assistance. During a proof-of-concept, attempt to produce a compliance evidence package — backup job logs for a defined period, restore operation records, access logs showing who performed which operations — using only the platform interface and your own data access. If producing this evidence requires contacting vendor support, requesting a data extract, or waiting for vendor assistance, document that dependency as a compliance risk.

Assess data subject access request support. For GDPR compliance, evaluate whether the platform supports data subject access requests — the ability to locate all backup data related to a specific data subject and produce or delete it on request. This capability needs to be executable by your compliance team without vendor involvement.

Assess GDPR erasure workflow support. For GDPR right to erasure compliance, evaluate whether the platform supports targeted deletion of specific data subject records from backup storage — with documented evidence of the deletion execution. The erasure workflow should be executable by your compliance team and should generate an audit trail of the deletion that can be produced to a supervisory authority.

Step 6: Evaluate vendor independence and lock-in risk

Vendor independence — the ability to maintain, migrate, or replace backup infrastructure without the vendor's cooperation — is the operational dimension of data sovereignty that is most frequently underweighted in backup evaluations.

Assess data portability. Verify that your backup data is stored in a format that is accessible without the vendor's software. If your backup data is stored in a proprietary format that requires the vendor's restore tool to read, you are dependent on the vendor's continued operation and pricing cooperation for access to your own backup data. Ask every vendor directly: if we cancel our contract tomorrow, what format is our backup data in, and can we restore from it without your software?

Assess migration path independence. If you decide to switch backup platforms in two years, what does the migration look like? A platform that stores data in accessible formats and provides a clear data export mechanism enables migration without vendor cooperation. A platform that requires vendor-managed migration services creates a switching cost that effectively locks you into the vendor relationship.

Assess pricing model exposure. Volume-based and consumption-based pricing models create commercial lock-in that compounds as data volumes grow. As backup data accumulates over multi-year retention periods, platforms that charge per row, per record, or per gigabyte of storage create cost escalation that makes switching more attractive but migration more expensive — a combination that traps organizations in vendor relationships that no longer serve them well.

Sesame Software's predictable connector-based annual pricing charges a fixed annual fee regardless of data volume — no per-row charges, no consumption-based billing, no cost escalation as backup data accumulates over six-year or seven-year retention periods. The backup data is stored in your own storage in accessible formats. If you switch platforms, your backup data remains in your storage, accessible to you, in a format that does not require Sesame Software's software to read.

Step 7: Conduct proof-of-concept verification against your requirements

After completing the architecture verification, BYOS assessment, deployment evaluation, compliance evidence review, and vendor independence assessment, conduct a structured proof-of-concept that tests each requirement against your actual environment — not the vendor's demo environment.

Test with your actual Salesforce org. Connect the backup platform to a sandbox copy of your production Salesforce org — not the demo org the vendor provides. A platform that performs correctly against a demo org with 50,000 records may behave differently against your production org with 10 million records across complex custom objects. Test schema discovery, backup frequency, API consumption, and restore performance against your actual data model.

Test restore scenarios that match your actual incident types. The restore scenarios most relevant to your organization depend on your history of data incidents. If you have experienced bulk import errors, test field-level restore precision against your actual Salesforce objects. If you have experienced configuration incidents, test metadata backup and restore. If you have experienced delayed discovery of data loss, test restore of records deleted 30, 60, and 90 days ago to confirm deleted record retention.

Measure actual recovery time against your RTO. Measure actual restore time for each restore scenario — from initiation to completion — and compare it to your documented Recovery Time Objective. Measure this with your actual data volumes, not the vendor's demo data. Restore time that satisfies your RTO against a small demo dataset may not satisfy it against your production record volumes.

Verify network behavior under production-like load. During the proof-of-concept, execute a backup cycle that processes a representative volume of your production data while monitoring all outbound network connections from the backup software. Confirm that no connections go to vendor infrastructure during the processing of your backup data.

How Sesame Software satisfies the self-hosted backup evaluation framework

Sesame Software satisfies every evaluation criterion in this framework as a fundamental property of its architecture — not as a configurable option or a premium tier.

Processing location: all backup operations run inside the customer's own environment — Sesame Software's servers are never in the data path. BYOS implementation: backup data writes directly from Sesame Software running in your environment to your designated storage — no vendor-processed intermediate stage. Deployment flexibility: deploys on Windows or Linux on-premise, in the customer's own cloud accounts in any region, or in hybrid combinations. Compliance evidence production: all audit logs stored within the customer's own environment, producible without vendor assistance. Vendor independence: flat annual pricing that does not scale with data volume, backup data stored in accessible formats in your own storage.

With 23+ years of enterprise data management expertise, 15 proprietary patents, 20+ actively maintained connectors covering Salesforce, NetSuite, Oracle, Microsoft Dynamics, SQL Server, PostgreSQL, and all major cloud data warehouse destinations, and a customer base that includes Procter & Gamble, Bank of America, and the U.S. Government — Sesame Software provides the self-hosted backup infrastructure that data residency compliance requires without compromising on capability or operational sustainability.

Talk to a Sesame Software data expert today.

---

Data Sovereignty Frequently Asked Questions

What is the difference between self-hosted backup and cloud-hosted backup for data residency?

Self-hosted backup runs inside the organization's own infrastructure — the backup software processes data on the organization's servers and writes to the organization's storage. Cloud-hosted backup runs on vendor-managed servers — the vendor's infrastructure processes backup data and may write to customer storage as an optional feature. For data residency compliance, the distinction is whether vendor infrastructure has access to backup data during processing. Self-hosted backup keeps vendor systems out of the data processing chain. Cloud-hosted backup, even with bring-your-own storage, places vendor systems in the processing chain.

What does "bring-your-own storage" actually mean for data residency?

Genuine bring-your-own storage means backup data is written directly from backup software running in your environment to your storage account — with no vendor infrastructure processing the data between your environment and your storage. Some platforms marketed as BYOS still process backup data on vendor servers before writing it to customer storage — creating the same data processor relationship as fully vendor-hosted backup. Verify the actual data flow by monitoring outbound network connections during backup operations and confirming that no connections go to vendor infrastructure during data processing.

How do I verify that a backup platform is genuinely self-hosted?

Ask the vendor directly: at any point during backup or restore operations, does your infrastructure have access to our data? Request a detailed data flow diagram. During a proof-of-concept, monitor all outbound network connections from the backup software during active operations and confirm that no connections go to vendor infrastructure. Test the software update mechanism to confirm it does not have access to customer data during updates. Document the results as the architectural verification record for your evaluation.

What compliance frameworks impose data residency requirements on backup data?

GDPR requires that backup copies of personal data satisfy the same geographic processing and storage requirements as production data. HIPAA requires that ePHI in backup storage remain within the covered entity's own security perimeter. National data sovereignty laws in India, Brazil, China, and other jurisdictions impose geographic processing requirements that may apply to backup data depending on the data categories and operational footprint. All of these frameworks require that the backup architecture — not just the storage location — satisfies their specific requirements.

How does vendor lock-in affect data residency compliance?

Vendor lock-in in backup infrastructure creates two categories of data residency risk. Pricing lock-in — where volume-based pricing makes migration increasingly expensive as data accumulates — traps organizations in vendor relationships where compliance posture depends on the vendor's continued appropriate behavior. Data format lock-in — where backup data is stored in proprietary formats that require the vendor's software to read — creates data accessibility dependency that undermines the organization's ability to migrate, audit, or independently verify its backup data. Self-hosted backup with flat annual pricing and accessible data formats eliminates both categories.

How does Sesame Software satisfy data residency evaluation criteria?

Sesame Software's customer-hosted architecture processes all backup operations inside the customer's own environment with no Sesame Software infrastructure in the data path. Backup data writes directly from Sesame Software running in your environment to your designated storage — on-premise, in your own cloud accounts, or hybrid. All audit logs are stored within your environment and producible without vendor assistance. Flat connector-based annual pricing does not scale with data volume. Backup data is stored in accessible formats in your own storage. The processing architecture is verifiable through your own network monitoring — no vendor assurance required.

---

Found this post helpful? Share it with your network using the links below.