When Nayax announced it wouldn't pay the ransom after its recent data breach, it sparked a debate: Should companies ever pay? This question persists because certain myths have embedded themselves in incident response planning. These misconceptions don't just shape decisions; they create compliance blind spots that leave your organization exposed.
Ransomware operators have framed the conversation around a false binary: pay and recover, or refuse and suffer. Your compliance obligations are more complex than that.
Myth 1: Paying the Ransom Is Always Illegal
Reality: The legality depends on who's demanding payment.
OFAC doesn't prohibit all ransom payments. It prohibits transactions with sanctioned entities. If the threat actor is on the SDN List or operates from a sanctioned jurisdiction, payment violates sanctions law. But if the actor isn't sanctioned, the payment itself isn't automatically illegal.
This distinction matters for your incident response plan. You can't make a real-time legal determination during an active breach. Your plan should include a sanctions screening protocol that triggers immediately when you receive a ransom demand. This means maintaining current SDN List access, understanding which cryptocurrency addresses are linked to sanctioned groups, and having outside counsel on standby who specializes in OFAC compliance.
Document the screening process. If you pay, OFAC expects you to demonstrate due diligence in determining the recipient wasn't sanctioned. If you refuse, that documentation protects you from claims that you should have paid to prevent customer harm.
Myth 2: Refusing to Pay Protects You from Regulatory Penalties
Reality: Your decision to pay or not pay is separate from compliance failures that enabled the breach.
Nayax's refusal to pay doesn't shield the company from regulatory scrutiny of how the breach occurred. Payment card brands will still assess fines for Account Data Compromise if cardholder data was exposed. State attorneys general will still investigate notification timing. Your acquiring bank will still require forensic evidence that you've fixed the vulnerabilities.
Regulatory exposure stems from control failures, not the ransom decision. If you failed to implement MFA on remote access (PCI DSS Requirement 8.4.2), segment your Cardholder Data Environment properly (Requirement 1.3), or maintain an accurate asset inventory (Requirement 12.5), those violations exist whether you pay $50,000 or $5 million to recover encrypted files.
Focus your compliance strategy on preventing the breach, not on optimizing the response to extortion. Your QSA won't ask whether you paid the ransom during your next assessment. They'll ask how the attacker gained initial access and why your monitoring didn't detect the exfiltration.
Myth 3: Payment Guarantees Data Recovery and Deletion
Reality: You're negotiating with criminals who have no enforcement mechanism and every incentive to lie.
Even when operators provide a decryption key, it often fails to decrypt all files or corrupts databases during recovery. Threat intelligence firms report functional decryption rates around 60-70% for major ransomware families, meaning payment leaves you rebuilding systems anyway.
The deletion promise is even less reliable. You can't verify that the attacker deleted all copies of your data. They may retain it for future extortion, sell it to other criminals, or simply lose track of where they stored it. Some operators maintain the data specifically to re-extort victims who pay once.
Your incident response plan should assume payment doesn't guarantee recovery. This means your backup strategy must work independently of ransom negotiations. Test your backups under realistic conditions: Can you restore the CDE from backups without paying? How long does full restoration take? Do your backups include the configuration data and encryption keys needed to make restored systems functional?
Myth 4: Insurance Coverage Means You Should Pay
Reality: Cyber insurance creates incentives that may conflict with your broader risk management strategy.
Insurers often prefer payment because it's cheaper than covering months of business interruption, forensic investigation, and system rebuilding. Their coverage may even include ransom payment as a line item. But the insurer's financial calculus isn't your compliance calculus.
Payment may violate your organization's risk appetite statement, conflict with your ethical obligations to customers, or undermine your threat intelligence sharing agreements. Some information sharing communities explicitly ask members not to pay because payment funds future attacks against the entire sector.
Review your cyber insurance policy before you need it. Does it require you to pay if the insurer recommends it? Can you refuse payment and still claim business interruption coverage? Does payment affect your premiums or future insurability? These aren't questions to answer during an active incident.
Myth 5: Refusing to Pay Sends a Strong Message to Attackers
Reality: Individual refusals have negligible impact on attacker economics or targeting decisions.
Ransomware operators run businesses with diversified revenue streams. One refusal doesn't bankrupt them or deter future attacks. They'll simply move to the next target. Your refusal might generate positive press coverage, but it won't materially change the threat landscape.
The decision to refuse should be based on your specific circumstances: Do you have working backups? Can you afford the recovery time? Will the business interruption cause customer harm that outweighs the ransom cost? These are operational and ethical questions, not strategic deterrence questions.
Don't refuse payment to "send a message" if refusal means you can't meet payroll, process transactions, or fulfill regulatory obligations. And don't pay because you think it'll make the problem go away. Make the decision based on your recovery capabilities and compliance obligations.
What to Do Instead
Build incident response capabilities that make the ransom decision less critical:
Maintain offline backups that you test quarterly. Your backup restoration process should be documented, timed, and validated by someone other than the person who created the backups.
Implement network segmentation that limits lateral movement. PCI DSS Requirement 1.3 isn't just about compliance; it's about ensuring that a breach in your corporate network doesn't compromise your CDE.
Establish a cross-functional crisis team before the incident. Include legal counsel familiar with OFAC sanctions, a forensics retainer, and communication protocols that don't rely on potentially compromised systems.
Document your decision framework now. What factors will you consider? Who has authority to authorize payment? How will you verify the attacker isn't sanctioned? You can't build this framework during an active breach.
The question isn't whether paying ransoms is right or wrong. It's whether your organization can survive and meet its compliance obligations without paying. Build that capability, and the moral debate becomes much simpler.
