Skip to main content
GullySystem
A practical guide

Where to store customer data: what to map and ask your adviser

Ganesh HSStrategy and Technology, GullySystem
Practical advice · 5 min read

In this guide 6 sections
The short answer

Before choosing a storage region, map where each record type lives, including copies, backups, logs and vendors. Then take specific questions to your adviser and your customer contracts. Only after that decide which record types move to a regional database and what the move would change in daily work.

Map every place a record lives

Make a grid. Down the side, list record types such as customer profile, order, invoice, support ticket, uploaded document and login log. Across the top, list regions where a copy could sit, including the primary database, replica, backup, search index and analytics export; unknowns are the useful part.

Fill each cell with yes, no or unknown. Mark them plainly. The unknowns matter most. A nightly backup copied to another continent or a log shipped to a monitoring vendor often goes unnoticed until a questionnaire asks.

Give each copy a vendor column naming who holds it; email service, payment processor, support desk and hosting provider each keep their own storage, under their own terms. Each has its own terms.

  • Primary database and read replicas
  • Backups and their retention period
  • Search indexes and analytics exports
  • Email, support and payment vendors

Separate what the customer asked from what the law says

Customer questionnaires and contracts are not the same as legal duties. They are different sources. A buyer may ask that data stay in a named region, while the law requires only a safeguard for transfers; both count, but they come from different places.

Sort every requirement into three piles: written in a contract, stated in a questionnaire, or cited from a law; note the source document and clause beside each. Your adviser will want this before offering an opinion. Write the clause number.

Do not treat any single answer as covering the whole business. Sector rules add more. Rules differ by sector and country, and health or finance records often carry extra conditions.

Questions to take to your adviser

Bring short, concrete questions. Vague ones draw vague answers. Ask which record types are covered, whether a copy for backup counts as storage, and whether remote access from another country counts as a transfer. Keep each question short.

Ask what the contract says about subprocessors. Exit terms matter. If a vendor adds a new one, are you obliged to tell your customer, and by when? Ask also what must happen on exit, such as deletion proof within a stated period.

Write down the reply, the date and the name, and file it with the signed contract and the vendor’s data processing terms. Rules and customer terms change. You will want the trail when they do. Dates matter too.

  • Do backups and logs count as stored data?
  • Does remote support access count as a transfer?
  • Which vendors must be disclosed to customers?
  • What must be deleted, and when, on exit?

What moving a record type into a regional database changes

Moving customer profiles and invoices into a database in another region is not a copy and delete. It is a rebuild of paths. Every query that joined that table now crosses a boundary; reports that span regions need a plan, such as running per region and combining totals only.

Expect changes in login, too. A user needs to be found in the right region on sign-in, and a support agent may see only their region’s records; roles and permissions must follow the data. Roles follow the data.

Latency, cost and failover also move. Test the restore. A regional database needs its own backup and its own restore test.

  • Cross-region reports and joins
  • Login lookup by region
  • Support access by role
  • Backup and restore per region

Decide with a small, reversible first step

Pick one record type with the clearest requirement, often the customer profile, and one region. Move that first. Measure what broke before moving the next. Small steps can be undone.

Keep a register of decisions: what moved, why, who approved and what the contract says. The register pays back quickly. A buyer’s questionnaire then becomes a copy from the register rather than a fresh hunt.

Your next step is the grid. Build it this week, mark the unknowns and book an hour with your adviser to work through them. Start with the grid.

Data location register

A one-page register with record types as rows and regions as columns, each cell marked held, not held or unknown. Extra columns hold the vendor, the contract clause, the adviser’s answer with date, the owner and the review date. A short block at the foot lists open questions.

Open a blank worksheet to print

Questions owners ask

Does data residency mean all data must stay in one country?

Not always. Some rules and contracts name a region for certain record types, others only require safeguards for transfers; Your adviser can tell you which applies to each type.

Do backups count?

Often yes, because a backup is another copy. Ask your adviser and check the customer’s wording, then list backup locations in the grid.

Can one database serve several regions?

Yes, if no rule or contract requires separation. When separation is required, a regional database with login lookup per region is the usual approach.

How often should the register be reviewed?

Review it whenever you add a vendor, open a market or sign a contract with data terms, and at least once a year.

Browse all guidesBack to top ↑
Next step

Have a specific situation to work through?

This article covers the general case. Tell us what you’re actually dealing with and we’ll respond directly.

Share Your Requirements