Before You Move Sensitive Data to a New Cloud: The Case for a TRA

The migration looks done. The risk just changed hands.

Moving sensitive data to a new cloud rarely feels like a privacy decision. It feels like an infrastructure project: pick a provider, stand up the environment, copy the data, cut over, decommission the old system. The runbook is full of technical milestones, and on the day the last record syncs, the work looks finished.

But that cutover is exactly the moment your risk profile changes. Records that used to sit behind your own firewall now live in a multi-tenant environment you don't control, reachable over the public internet, governed by someone else's access model and someone else's data-centre footprint. The data is the same. Everything around it is different.

A Threat Risk Assessment (TRA) is the discipline that catches those changes before they become incidents. It is a structured look at what could go wrong in the new environment, how likely each scenario is, what it would cost you, and which controls bring the risk down to something you can defend. This post makes the case for running one before the data moves, and shows what a credible TRA involves.

What a TRA actually is (and isn't)

A TRA is a security-focused risk assessment. It identifies the assets you are protecting, the threats those assets face, the vulnerabilities a threat could exploit, and the controls that reduce the resulting risk to an acceptable level. The output is not a pass or fail score. It is a documented, defensible decision about which risks you are accepting, which you are mitigating, and which you are transferring, for example to the cloud provider under a contract.

• Assets: the sensitive data and systems in scope, such as health records, financial data, government-held personal information, and the credentials and keys that protect them.
• Threats: who or what could cause harm, including external attackers, malicious or careless insiders, the provider's own staff, misconfiguration, and supply-chain compromise.
• Vulnerabilities: the weaknesses a threat could use, such as overly broad access roles, unencrypted backups, exposed storage buckets, weak tenant isolation, or missing logging.
• Controls: the safeguards that lower likelihood or impact, including encryption in transit and at rest, key management you control, network segmentation, monitoring, and contractual commitments.
• Residual risk: what remains after controls, plus an explicit sign-off from someone with the authority to accept it.

TRA vs PIA: related, not interchangeable

Teams often conflate a TRA with a Privacy Impact Assessment (PIA), and the confusion leads to gaps. A PIA asks whether you should be collecting, using, and disclosing the personal information at all: whether you have authority, whether the purpose is appropriate, and whether individuals' privacy rights are respected. A TRA asks whether the information is adequately protected against threats once you hold it.

A cloud migration usually triggers both. The PIA covers questions such as cross-border data flows, who can access the data and why, retention, and lawful basis. The TRA covers encryption, tenant isolation, breach detection, and recovery. They overlap at the edges, since data residency surfaces in both, but neither replaces the other. For a sensitive-data migration, the safest pattern is to run the PIA to confirm the move is appropriate and the TRA to confirm it is secure.

If you are working out which one your project needs, or whether you need both, our answer pages walk through the decision in detail.

Why "the provider is SOC 2 certified" isn't the answer

The most common reason teams skip a TRA is the provider's compliance badge. The reasoning goes: a major cloud provider has a SOC 2 report, ISO 27001, and a wall of attestations, so the data must be safe. That misreads how cloud security works.

Every major provider operates a shared responsibility model. The provider secures the underlying infrastructure: physical data centres, the hypervisor, and the network backbone. You remain responsible for how you configure your environment on top of it, including identity and access, encryption settings, network rules, logging, and the data itself. Cloud breaches frequently trace back to customer-side misconfiguration rather than a failure of the provider's audited controls.

• A provider's SOC 2 report tells you the provider's controls were operating effectively. It says nothing about whether your storage buckets are public.
• Certifications cover a defined scope, and the services and regions you actually use may sit partly outside it.
• Compliance attestations are a useful input to your TRA, not a substitute for it.
• The contract and the provider's documentation define where their responsibility ends and yours begins. Read both before you assume coverage.

What a cloud-migration TRA should examine

A TRA scoped to a migration is more focused than a general security review. It zeroes in on what changes when the data moves and what the new environment introduces.

• Data residency and sovereignty: where the data is physically stored and backed up, and whether that satisfies your obligations. This is particularly relevant for health and public-sector data under provincial rules such as British Columbia's FOIPPA, and for personal data under PIPEDA and Quebec's Law 25.
• Cross-border access: whether support staff, replication, or disaster-recovery sites place the data, or access to it, outside Canada, and whether that has been disclosed and authorized.
• Encryption and key management: encryption in transit and at rest, and, crucially, who holds the keys: you, the provider, or a shared arrangement.
• Identity and access: how access is granted in the new environment, whether least privilege is enforced, and whether multi-factor authentication is mandatory for privileged accounts.
• Tenant isolation and configuration: how your environment is separated from other customers, and which default settings need hardening before go-live.
• Logging, monitoring, and breach detection: whether you will know when something goes wrong, and how quickly.
• Data lifecycle: secure migration of the data itself, verified decommissioning of the old system, and the provider's deletion guarantees at end of contract.
• Exit and continuity: how you would get your data back and recover service if the provider fails or the relationship ends.

Timing: why before beats after

The value of a TRA collapses if you run it after cutover. Done early, while the architecture is still on a whiteboard, a TRA can change decisions cheaply: choosing a Canadian region, redesigning the key-management model, adding network segmentation, or negotiating contract terms before signatures dry. Done late, the same findings become expensive rework, awkward conversations with the provider, or risks you quietly accept because unwinding them costs too much.

Run the TRA when the target architecture is defined but still reversible. You want enough detail to assess real configurations and data flows, but enough runway that mitigations can still shape the build. For regulated data, treat a satisfactory TRA, with residual risk formally accepted, as a gate the migration must pass before production data moves, not a document you assemble afterward to satisfy an auditor.

Turning the assessment into action

A TRA earns its keep only if its findings drive decisions. The deliverable should hand decision-makers a clear, ranked picture of risk and a concrete plan, not a binder that gets filed and forgotten.

• A prioritized risk register, with each item rated by likelihood and impact.
• Recommended mitigations mapped to specific risks, with owners and target dates.
• A clear statement of residual risk and a named individual who accepts it.
• The contractual and configuration commitments the migration depends on, written down so they can be verified rather than assumed.
• A re-assessment trigger: when the provider, the data, or the regulatory landscape changes materially, the TRA gets revisited.

The bottom line

A cloud migration is one of the few moments when you can re-engineer how your most sensitive data is protected, and the moment when the cost of getting it right is lowest. A TRA is how you use that window. It converts a vague sense that the cloud is probably fine into documented, defensible decisions about real risks.

For sensitive health, financial, or government data, the question is not whether a TRA is worth the effort. It is whether you can defend the migration without one: to a regulator, to a client's security team, or to the people whose data you moved. If you are planning a move and are not sure where a TRA fits alongside a PIA, that is exactly the conversation we have with clients before the data goes anywhere.

Related reading

• Do you need a TRA before moving sensitive data to a new cloud
• PIA vs TRA which assessment do you need