Everyone believes they are prepared for a security incident until it happens. You walk in, jiggle your mouse, and BAM! Up pops a ransom note. Maybe it demands millions of dollars. Maybe it directs you to a tor site (often a .onion site) where, after some back and forth, the demand comes out. Who are these threat actors, why might you pay them, and why should your team have a policy around that before your data is being held for ransom?
Simply put, sometimes a decryptor is needed and payment is unavoidable. The situation that’s more complicated to address is this–most businesses, or business leaders, have some piece of data embarrassing enough to cloud their judgment when they’re faced with the possibility of that data being shared with the world. Read on to learn how ransoms work, what breach response looks like, and how preexisting policies can prevent embarrassment from becoming your company’s motivation during a security incident.
What is a “ransom” in cybersecurity?
One of the most common kinds of security incidents is a “ransomware attack.” In a ransomware attack, a threat actor (sometimes called a “TA”) locks your computer files or steals your company data using malicious software (called “malware” or “ransomware”). The TA then demands money either to unlock the files, to provide software so that you can unlock them (often called a “decryptor”), or for something called “data suppression,” meaning that the TA agrees that they will not publicly post stolen data in exchange for a payment.
Intelligent readers already see the problem. How can you trust that criminals will actually abide by an agreement not to post stolen data? They’ve already broken into your system. You have no reason to trust that the TA won’t simply take the payment and post the data anyways, or turn around and sell the data to another TA group with whom you have no such agreement.
However, when the data stolen is sensitive, embarrassing, or possible evidence of criminal behavior, negotiation becomes more likely. If you don’t have a plan around what to do when the data looks bad, you should anticipate conflict, delayed decision making, and less money in limits for remediation.
Who are these Threat Actors?
Get the image of a hooded loner hacker out of your head. Today’s TA groups are the product of a sophisticated, sometimes government-supported, criminal supply chain with specialists at every level. At the top sit ransomware-as-a-service operators, who build and maintain the encryption software, run the leak sites where victims are named, and handle payment infrastructure. They license that toolkit to affiliates, who carry out the actual intrusions and typically keep the larger share of any ransom. Feeding both are initial access brokers, who do nothing but harvest stolen credentials and footholds in corporate networks and sell them on. Around this core is a support economy of negotiators, money launderers, and call-center-style crews who phone help desks and impersonate employees to reset passwords.
TA groups often operate from jurisdictions that do not extradite to the US or EU. Thus, arrests are rare and takedowns tend to scatter a group rather than end it. Members regularly rebrand and reappear under new names after law enforcement action, so the roster of "active" groups changes far faster than the underlying business model does. A small number of state-linked actors, most notably North Korean units raising revenue for the regime, use the same tooling, but the overwhelming majority of what a mid-sized company will encounter is ordinary organized crime that has found software to be a more profitable line of work than smuggling.
What happens after a ransomware attack?
These days, it’s likely that your organization has some sort of incident response plan. You call the designated people, they put cyber insurance and/or legal on notice, and, if you’ve done this properly, a team of TA communications, forensics, remediation, notification, and legal vendors assembles. The appropriate vendor will reach out to the TA group, usually through a dark web chat portal set up by the group for this purpose, and assess the situation. The TA likely encrypted your data, and may be demanding money in exchange for a decryptor. The TA may also be threatening to expose the data that was exfiltrated, and ask you to pay them not to.
While remediation vendors assess whether your backups are sufficient or if you need a decryptor, the TA communications vendor will talk to the TA to evaluate their conduct. Can they actually prove that the data was exfiltrated? Can the TA actually read the data they took?
Meanwhile, forensics and remediation vendors are securing your system and checking for backups to determine whether you can restore your environment without paying for a decryptor. Often, organizations can get back to business without the threat actor’s decryptor. This reality has led TA groups to position themselves to capitalize on fear rather than just work.
The Suppression Question
Best practices recommend not paying for data suppression. Unlike a decryption key, which can be tested, a promise to delete stolen files is unverifiable. When you pay for data suppression, you have no way to confirm that copies do not remain with the threat actor themselves, the affiliate who ran the intrusion, the access broker who sold the foothold, or on infrastructure the operators keep offline. Likewise, you have no recourse should the TA simply accept your payment (often provided through cryptocurrency transfers) and then post the data.
Victims who pay are also disproportionately likely to be approached again. Sometimes, paying victims are approached by the same TA group under a new name. Sometimes the new threat is posed by a different group that acquired the data from the original breach. TA groups commonly accept payment from victims not to post on their leak sites, and then sell the data to other TA groups instead. Sometimes, a new threat is simply a TA group that heard that the victim company pays.
Payment does not discharge any legal obligation either. If regulated data left your environment, notification duties under contract, state breach statutes, HIPAA, or GDPR are triggered by the exfiltration, not by whether the files eventually appear on a leak site. There are sanctions issues to consider as well, since transferring funds to an entity on a designated list can create liability for the victim and for anyone who facilitates the transfer. Accordingly, ransom policies should include provisions ensuring that payment decisions must be approved by counsel and, if applicable, the insurer, rather than with the incident-response team alone.
Likewise, paying cybercriminals is unlikely to help you mount a stronger defense in a data privacy lawsuit, many of which are filed after notifications go out. Those suits generally turn on what you did before the intrusion, not after it. Whether you maintained reasonable security safeguards, honored your own published privacy commitments, and retained no more personal data than you needed is far more persuasive than whether you paid an untrustworthy actor for an unverifiable suppression promise. Thus, a ransom payment does nothing to improve that record.
If anything, a ransom payment can complicate the picture. Plaintiffs must show they suffered a concrete injury, and a company that paid to suppress a leak has effectively conceded that sensitive data left its network and had real value to the people who took it. The payment itself, along with the negotiation transcript and any internal debate about whether to pay, is potentially discoverable, and an assurance from a criminal group that it deleted your files is not evidence a court will credit. Regulators and insurers add their own friction, from sanctions exposure when the recipient sits on a restricted-parties list to policy language that limits reimbursement.
The practical takeaway is that ransom payment is a business-continuity decision with a narrow purpose, buying back access or buying time, and it should not be mistaken for a legal strategy.
Why People Pay
None of this makes the calculus easy for a company staring at a countdown timer, and organizations do sometimes pay anyway. But how does that happen?
Even a well-run organization with excellent insurance, current backups, and no need for a decryptor can get into trouble when it, or one of its members, has something to hide. Paying for data suppression starts to look attractive when the stolen data contains litigation notes, evidence of unmet obligations, or just plain unflattering content. What began as an incident-response question owned by IT and security migrates to a small circle of executives and counsel, and the criteria shift with it, moving from "can we restore operations?" to "what surfaces if this gets posted?"
Extortion crews understand this dynamic and lean on it. They read what they steal, price the demand against what they find, and, often, they contact board members, customers, and regulators directly to make sure the people with the most to lose are the ones taking the call. The company then pays for a promise it cannot audit, from a counterparty whose only real product is silence, and which retains a perfect copy of the leverage it just sold back.
Make Policy Now Instead of Debating Later
Many of these issues are mitigated by writing a ransom payment policy before a breach. The heated, high stakes environment of breach response is the worst possible time to address the sensitive dynamics surrounding ransom payments. A policy takes the place of accusations and negotiations when reputations are at stake alongside company interests.
Writing your ransom payment policy pre-breach does three things the countdown clock will not allow. First, it fixes decision rights in advance: who must be in the room, who has authority to authorize a payment, and, critically, who is recused from a payment decision. A rule written on a quiet Tuesday that says any executive whose own private conduct or correspondence appears in the stolen data set steps out of the decision is uncontroversial. The same rule proposed mid-incident is an accusation.
Second, it sets the criteria before anyone knows which criteria will be convenient. This commits the organization in advance to weighing operational recovery, legal exposure, and sanctions risk rather than reputational discomfort, and to requiring that any payment be approved by the board or a designated committee rather than the people closest to any applicable embarrassment.
Third, it establishes the process guardrails that make the decision defensible later. Policies often require appropriate insurance, counsel engaged from the outset, a qualified negotiator rather than an improvising executive, sanctions screening of the recipient before funds move, insurer and law enforcement notification on a defined timeline, and a documented record of the reasoning. That record matters. Regulators and plaintiffs will eventually ask how the decision was made, and "we followed the policy the board approved in March" is a substantially better answer than a reconstructed narrative assembled after the fact.
Policy will not make the choice for you. What it does ensure is that the choice gets made by the right people, against the right standard, for reasons the organization is willing to have read aloud.
Victoria J. Cvitanovic helps organizations get cyber security, data privacy, and AI governance in order before the money is on the table. A Certified Information Privacy Professional and Certified AI GovernanceProfessional through the IAPP, Victoria serves as Data Privacy Officer for Rudick Law Group and as fractional Data Privacy Officer for clients across technology, healthcare, wellness, and emerging markets. Her practice covers the full arc this article describes: multi-jurisdictional compliance planning, consent and data provenance, AI governance programs, SOC 2, HITRUST, and ISO27001 audit preparation, vendor and customer contracts built to scale across regimes, and incident response readiness. As a former prosecutor and litigator, she also knows how these questions look from the other side of a dispute, and she'll use that knowledge to help you navigate them.
.webp)
