Risk Transfer in Cybersecurity: Insurance, Contracts, Outsourcing and What Stays With You

Short answer: Risk transfer, called risk sharing in ISO/IEC 27005, is a risk treatment option that shifts part of a risk's consequences to another party through cyber insurance, contract terms or outsourcing. It can reduce your financial exposure, but accountability, regulatory duties and reputational harm stay with you, so some residual risk always remains.

Related guides:

• Risk acceptance: criteria, sign-off and form fields
• Risk avoidance: definition, examples and when to use it
• ISO 27001 risk treatment plan

Key takeaways

• Transfer moves consequences, not the risk itself. Likelihood is usually unchanged. What changes is who pays, or who runs the activity.
• There are three practical mechanisms: cyber insurance, contractual transfer (indemnities, limitation of liability clauses, BAAs and DPAs) and outsourcing to a managed provider.
• Accountability does not move. A HIPAA covered entity still owes breach notice to individuals, and a GDPR controller still has to demonstrate compliance, whatever the contract says.
• Every transfer leaves residual risk. Exclusions, liability caps, counterparty failure and reputational damage remain with you.
• Auditors want the paper trail. Expect to show the register entry, the policy or contract, owner approval and evidence that you monitor the counterparty.

What is risk transfer in cybersecurity?

Risk transfer is a decision to let another party carry some of the consequences of a risk you have identified, instead of carrying all of it yourself.

ISO frames this as risk sharing. ISO/IEC 27005:2022 defines it in clause 3.2.9 as a form of risk treatment "involving the agreed distribution of risk with other parties," and notes that it can be carried out through insurance or other forms of contract. The same standard lists treatment options including avoiding the risk, changing its likelihood, sharing it with another party and retaining it by informed decision. ISO/IEC 27001:2022 then requires you, in clause 6.1.3, to select appropriate treatment options and have risk owners approve the treatment plan and accept the residual risk.

NIST uses both words. The CSRC glossary entry for risk response, drawn from NIST SP 800-39, lists "accepting, avoiding, mitigating, sharing, or transferring risk." NIST IR 8286B-upd1 describes transfer as reducing risk "by sharing a portion of the consequences with another party," and warns that "there are often consequences that cannot be transferred, like the loss of customer trust."

What are the three main ways to transfer risk?

For SMB and HealthTech companies, risk transfer happens through insurance, contracts or outsourcing, often combined.

Mechanism	What can shift	What stays with you
Cyber insurance	Some financial losses, such as incident response, recovery or liability costs, within policy limits	Deductibles, excluded events, amounts above limits, reputational damage
Contractual transfer	Financial responsibility for defined failures by the other party, through indemnities and allocated liability	Losses above caps, losses the other party cannot pay, your own legal duties
Outsourcing to a managed provider	Day-to-day operation of a risky activity, such as payment handling, hosting or monitoring	Choosing and overseeing the provider, your side of shared responsibility

1. Cyber insurance. NIST IR 8286B-upd1 calls insurance "the most frequent example" of risk transfer and says it can offset financial impact. The treatment is only as good as the coverage, exclusions and conditions you actually bought. For how buyers and auditors view insurance alongside SOC 2, see SOC 2 and cyber insurance.

2. Contractual transfer. Contracts allocate who pays when something goes wrong:

• Indemnities commit one party to cover defined losses caused by the other, such as a vendor's data breach or IP infringement.
• Limitation of liability clauses cap what each side can recover. A low cap in your vendor contract limits how much risk you actually transferred.
• BAAs and DPAs set out what a business associate or processor must do with regulated data. HHS's cloud computing guidance says a cloud provider under a BAA is "both contractually liable for meeting the terms of the BAA and directly liable for compliance." These agreements share obligations, but as the next sections show, they do not hand over your own.

3. Outsourcing to a managed provider. NIST IR 8286B-upd1 gives "outsourcing some risky activity, such as handling payment card transactions" as another common example. Hosted payment pages, managed detection services and managed cloud databases all move day-to-day operation to a specialist.

Risk transfer examples for SMB and HealthTech teams

These are illustrative scenarios, not real companies. Each shows transfer combined with other treatments.

Example scenario A: ransomware at a 40-person B2B SaaS company. Extended downtime from ransomware is a high risk. The team keeps backups and endpoint protection (mitigation) and buys cyber insurance covering incident response and business interruption (transfer). The register notes the policy's waiting period and that lost customer trust is not covered, and the owner accepts that remainder in writing.

Example scenario B: a HealthTech startup hosting PHI on a cloud platform. The startup, a business associate to its clinic customers, uses a cloud provider's managed database under a BAA (outsourcing plus contractual transfer). The register lists what stays in-house: access control, configuration, logging and its own breach notice duties to customers.

Example scenario C: a telehealth app taking card payments. The app uses a payment provider's hosted checkout so card data never touches its servers (outsourcing), and the agreement includes a capped indemnity for the provider's security failures (contractual transfer). The register records the cap and notes that a tampered checkout link on the app's own site is still its problem.

What can you never transfer?

You cannot transfer accountability, legal obligations that the law assigns to you, or harm to your reputation and customer relationships.

ISO/IEC 27005:2022 defines a risk owner as the person or entity "with the accountability and authority to manage a risk." Sharing distributes the consequences, but the risk stays in your register under a named owner who must approve the treatment and residual risk under ISO/IEC 27001:2022 clause 6.1.3.

Regulation makes the same point more sharply. Under HIPAA:

• A business associate must notify the covered entity of a breach of unsecured PHI under 45 CFR 164.410, but the duty to notify affected individuals sits with the covered entity under 45 CFR 164.404.
• HHS's cloud guidance says "Both covered entities and business associates must conduct risk analyses," so signing a BAA with a cloud provider does not remove your own risk analysis duty.
• HHS's business associate fact sheet gives an example where OCR can act only against the covered entity, even though a business associate did the work.

The GDPR works the same way for controllers. Recital 81 says processing by a processor "should be governed by a contract or other legal act," and Recital 74 says the controller should "be able to demonstrate the compliance of processing activities." A DPA is how you show that; it does not make your processor the accountable party.

Loss of customer trust, NIST's own example, cannot be transferred either. For BAA clauses, see what a HIPAA business associate agreement must contain.

How much risk is left after a transfer?

Some residual risk always remains, so estimate it honestly instead of scoring the risk low because a policy exists.

NIST IR 8286B-upd1 says risk response "should result in residual risk levels that fulfill the risk appetite and risk tolerance directives," and that methods "may also need to be combined." ISO/IEC 27005:2022 also notes that "Risk treatment can create new risks or modify existing risks," and outsourcing does exactly that.

Check each transfer for these gaps before you rescore:

• Coverage gaps. Exclusions, sublimits, deductibles and waiting periods in the insurance policy.
• Caps. Limitation of liability amounts that are small relative to your realistic loss.
• Counterparty risk. Whether the insurer will pay or the vendor can pay when the event happens.
• Conditions. Insurance or contract terms that require you to maintain certain controls. Failing them can void the transfer.
• New third-party risk. The provider's own security, its subprocessors and concentration risk.
• Non-financial impact. Downtime for your customers, regulatory scrutiny and reputational harm.

Transfer mostly lowers the financial impact score. If your residual likelihood drops too, you are probably counting a mitigation control, so record it.

How do you record a risk transfer in the risk register?

Record it as a treatment decision on the original risk, with the mechanism, counterparty, supporting documents and the residual risk the owner accepted.

1. Keep the original risk. Do not delete or close it. Update its treatment to "transfer (share)," often alongside mitigate or accept.
2. Name the mechanism and counterparty. For example: cyber insurer, payment provider, cloud provider or a specific customer contract.
3. Link the evidence. Attach the policy schedule, contract clause, BAA, DPA or shared responsibility document.
4. Record limits and conditions. Coverage limits, liability caps, exclusions and any controls you must maintain.
5. List what stays with you. Notification duties, your side of shared responsibility and reputational impact.
6. Rescore residual risk. Explain which score changed and why.
7. Get owner approval. The risk owner approves the treatment and accepts the residual risk, in line with ISO 27001 clause 6.1.3.
8. Set review triggers. Policy renewal, contract renewal, vendor reassessment or a material change in the service.

For the wider structure of the register itself, see the risk register guide.

What evidence do SOC 2 and ISO 27001 auditors expect?

Auditors expect a deliberate, approved decision and ongoing checks on the counterparty, not just a policy or contract on file.

SOC 2. The Trust Services Criteria address this under CC9.1, which covers risk mitigation activities for business disruption and includes a point of focus on considering insurance to mitigate financial impact, and CC9.2, which covers vendor and business partner risk. In our experience, auditors test these through the risk assessment, vendor reviews and contracts.

ISO 27001. Auditors will trace the risk from the assessment through the treatment plan and Statement of Applicability, check that the risk owner approved residual risk under clause 6.1.3, and look at supplier controls in Annex A, such as 5.19 information security in supplier relationships, 5.20 addressing information security within supplier agreements and 5.22 monitoring of supplier services.

Have this evidence ready:

• Risk register entry showing transfer as the treatment, with residual risk and owner approval
• Current insurance policy schedule, or the relevant contract clauses, BAA or DPA
• Vendor due diligence for outsourced activities, such as a SOC 2 report or ISO 27001 certificate review
• Shared responsibility mapping showing which controls you still operate
• Evidence that conditions attached to the transfer are met
• Review records at renewal or reassessment

How SecureSlate helps

In SecureSlate, risk management lets you record transfer alongside mitigation and acceptance, link evidence and capture owner approval of residual risk. Vendor risk management tracks the providers you transfer risk to, such as cloud, payment and managed service providers, with due diligence and review dates. Multi-framework control mapping across SOC 2, ISO 27001, HIPAA and GDPR shows which controls stay with you, custom controls let you add checks such as insurance condition reviews, and audit management keeps the evidence together for your auditor. The trust center and security questionnaire automation help you answer buyer questions consistently.

Start your free SecureSlate trial

FAQ

Is risk transfer the same as risk sharing?

For practical purposes, yes. ISO/IEC 27005:2022 uses "risk sharing," while NIST glossaries list sharing and transferring side by side and NIST IR 8286B-upd1 groups them under transfer. Pick the term your methodology defines and use it consistently.

Does cyber insurance count as a risk treatment for ISO 27001?

It can. ISO/IEC 27005:2022 says risk sharing can be carried out through insurance. You still need the risk owner to approve the treatment and accept the residual risk under clause 6.1.3, and insurance usually covers only part of the impact.

Can a BAA transfer HIPAA liability to a vendor?

Only partly. A business associate is directly liable for certain HIPAA requirements and contractually liable under the BAA, but the covered entity keeps its own duties, such as notifying affected individuals of a breach under 45 CFR 164.404 and conducting its own risk analysis.

What is a common risk transfer example in cybersecurity?

Buying cyber insurance is the most common example, followed by outsourcing a risky activity such as card payment handling to a specialist provider. Both appear as examples in NIST IR 8286B-upd1.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.