Data Recovery and Offboarding

Overview

Customers may need to recover, migrate, or offboard Ubiq-protected data when they deprovision an application, migrate an environment, replace a workflow, or decide to remove Ubiq from a system.

Ubiq does not store or host the customer’s underlying data. Protected data remains in the customer’s systems, databases, applications, files, data pipelines, or other data stores.

This means data recovery and offboarding are customer-run workflows. The customer retrieves protected data from its own systems, uses the appropriate Ubiq library or integration to decrypt or unprotect the data with authorized credentials, and writes the output back to the source system or to another customer-controlled destination.

Ubiq can support these workflows with sample scripts, implementation guidance, and experience from prior migration, deprovisioning, and offboarding projects.

Summary

Data Recovery Model

Ubiq is not the system of record for customer data. Ubiq does not store or host the customer’s underlying application, database, file, or workflow data.

Instead, Ubiq libraries and integrations are used by customer-controlled workflows to protect and unprotect sensitive data. The protected values are stored in the customer’s systems.

Because of this architecture, data recovery is performed from the customer’s environment against customer-controlled source systems.

A recovery or offboarding workflow generally follows this model:

1. The customer identifies where Ubiq-protected data exists.
2. The customer retrieves protected values from its own systems.
3. The customer calls the appropriate Ubiq library or integration using authorized credentials.
4. Ubiq decrypts or unprotects the protected values according to the authorized workflow.
5. The customer writes the output to the original system or to another customer-controlled destination.
6. The customer validates the recovered output before completing migration or offboarding.

Common Recovery and Offboarding Scenarios

Bulk decrypt/export workflows may be used in several operational scenarios.

Application deprovisioning

If an application or workflow is being retired, the customer may need to recover protected values before removing Ubiq calls or shutting down the system.

In this case, the customer can retrieve the protected data from the application’s source system, call Ubiq using authorized credentials, and write the decrypted output to an approved destination before completing deprovisioning.

Environment migration

If data is being moved from one environment to another, the customer may need to decrypt or export protected values as part of a broader migration plan.

This may include moving data between development, staging, production, cloud, on-premises, database, warehouse, or file-based environments.

Workflow replacement

If a workflow is being replaced by a new application, database process, API layer, data pipeline, or integration pattern, the customer may need to recover protected data and prepare it for the new workflow.

The customer can use a bulk decrypt/export process to produce validated output for the replacement workflow.

Migration away from Ubiq

If a customer decides to remove Ubiq from a workflow, the customer can perform a controlled bulk decrypt/export process.

This is a planned migration exercise, not a data-loss scenario. The customer remains responsible for retrieving its own data, running the authorized decrypt/export workflow, validating the output, and updating downstream systems.

Typical Bulk Decrypt / Export Process

A typical customer-managed bulk decrypt/export process includes:

1. Identify protected data locations
   Determine which systems, tables, fields, files, data pipelines, or datasets contain Ubiq-protected values.

2. Confirm scope and destination
   Decide whether decrypted output will be written back to the source system or to a separate customer-controlled migration location.

3. Confirm authorized credentials
   Identify the application, service account, script, or administrative workflow that is authorized to decrypt or unprotect the relevant data.

4. Retrieve protected data from the customer system
   The customer retrieves protected records from its own database, file store, application, pipeline, or other source system.

5. Call Ubiq using the appropriate library or integration
   The customer-run workflow calls Ubiq using authorized credentials to decrypt or unprotect the protected values.

6. Write output to the approved destination
   The customer writes the decrypted output back to the source system or to another customer-controlled destination.

7. Validate the output
   The customer validates record counts, field mappings, formatting, application behavior, and downstream workflow compatibility.

8. Complete cutover or deprovisioning
   Once validation is complete, the customer can update application logic, remove Ubiq calls, complete the migration, or decommission the original workflow.

Sample Scripts and Implementation Guidance

Ubiq can provide sample scripts and implementation guidance for bulk decrypt/export workflows.

These scripts are intended to help customers understand the pattern for retrieving protected data, calling the appropriate Ubiq library or integration, and writing decrypted output to an approved destination.

Customers are responsible for adapting sample scripts to their own systems, data models, credentials, access controls, and operational requirements.

Sample scripts may need to be adjusted based on:

• Source system type
• Data format
• Field mapping
• Record volume
• Batch size
• Error handling requirements
• Output destination
• Access-control requirements
• Logging and audit requirements
• Cutover approach

Large Dataset Considerations

For large datasets, customers should plan the decrypt/export workflow carefully before modifying production data.

Important considerations include:

• Batch size
• Retry behavior
• Error handling
• Logging and auditability
• Rate limits
• Checkpointing and restart behavior
• Validation of record counts
• Validation of decrypted output format
• Downstream application compatibility
• Rollback planning
• Whether to write output in place or to a separate migration location first

In many cases, customers may choose to write decrypted output to a separate customer-controlled migration location first. This allows the customer to validate output before modifying the source system or completing cutover.

In-Place vs. Separate Destination

A bulk decrypt/export workflow can be designed to write output back to the original source system or to a separate customer-controlled destination.

In-place output

In-place output may be appropriate when the customer wants to update the existing source system directly.

This approach should be planned carefully because it modifies the original data location. Customers should validate access controls, backups, rollback procedures, and downstream application behavior before running an in-place workflow in production.

Separate destination output

Writing decrypted output to a separate customer-controlled destination may be appropriate when the customer wants to validate results before cutover.

This approach can reduce operational risk because the customer can compare source and output datasets, confirm formatting, validate record counts, and test downstream workflows before modifying production systems.

Access Control and Authorization

Bulk decrypt/export workflows should only be run by authorized users, service accounts, applications, or administrative processes.

Customers should confirm that the credentials used for the workflow are authorized to decrypt or unprotect the relevant data.

Customers should also consider:

• Who is allowed to run the decrypt/export workflow
• Which data locations are in scope
• Where decrypted output can be written
• How credentials are stored and accessed
• How activity is logged
• How output is validated and approved
• Who approves cutover or deprovisioning

Recommended Offboarding Practices

For recovery, migration, or offboarding workflows, Ubiq recommends:

• Identify all protected data locations before starting.
• Confirm the authorized credentials or service account that will run the workflow.
• Use Ubiq-provided sample scripts and guidance where appropriate.
• Test with a representative sample before running against the full dataset.
• Use batching, retries, checkpointing, and error handling for large datasets.
• Write output to a separate migration location first when validation is required before cutover.
• Validate record counts, field mappings, formatting, and downstream workflow behavior.
• Apply appropriate access controls, logging, and approval steps.
• Maintain backups and rollback procedures before modifying production data.
• Document the final cutover, migration, or deprovisioning steps.

Related Key-Management Considerations

Some customers may have additional requirements around key ownership, key custody, key lifecycle, or long-term recovery planning.

For those requirements, Ubiq supports customer-controlled key-management options, including Customer Managed Key / BYOK and Bring Your Own HSM / BYOHSM.

Those options are covered separately in the Customer-Controlled Key Management documentation.

Key Takeaways

Ubiq does not store or host the customer’s underlying data. Protected data remains in the customer’s systems.

Customers can recover, migrate, or offboard Ubiq-protected data by retrieving protected values from their own systems and using the appropriate Ubiq library or integration to decrypt or unprotect the data with authorized credentials.

Ubiq can provide sample scripts and implementation guidance for bulk decrypt/export workflows.

Bulk decrypt/export should be treated as a planned data migration process with appropriate access controls, testing, logging, validation, and rollback planning.