Secondary sanctions risk is the possibility that a non-U.S. person or institution will face consequences for continuing business with sanctioned actors. In practice, it matters when foreign firms keep processing transactions for designated parties and may then be denied access to the U.S. financial system or broader correspondent relationships.
Expanded Definition
Secondary sanctions risk describes exposure that arises when a non-U.S. person, bank, processor, or commercial partner continues dealing with designated actors after those actors have been sanctioned. The core issue is not only direct violation of sanctions law, but the possibility that a jurisdiction with extraterritorial reach may restrict access to its financial system, clearing channels, or correspondent banking relationships. Definitions and enforcement thresholds vary across regimes, so organisations should treat the term as a compliance and operational risk concept rather than a single legal rule.
In practice, the risk is most visible where cross-border payments, trade finance, shipping, insurance, or cloud service provisioning touch restricted counterparties, intermediaries, or ownership structures. A useful way to frame it is through exposure management: who is being served, who benefits, and whether a transaction creates downstream access to a sanctioned network. For governance alignment, the NIST Cybersecurity Framework 2.0 is helpful for structuring risk ownership, third-party oversight, and response discipline, even though it does not define sanctions law itself. The most common misapplication is treating secondary sanctions risk as identical to direct sanctions breach, which occurs when organisations screen only named parties and ignore ownership, control, payment paths, and counterparties further down the chain.
Examples and Use Cases
Implementing secondary sanctions controls rigorously often introduces friction in onboarding, payments, and partner management, requiring organisations to weigh business continuity against the cost of deeper due diligence and delayed transactions.
- A regional bank reviews a foreign correspondent relationship after detecting repeated transfers involving a designated shipping intermediary, then escalates the account for sanctions counsel review.
- A fintech blocks settlement for a merchant because its beneficial ownership chain links to a restricted entity, even though the merchant itself is not explicitly listed.
- An insurer pauses coverage for cargo routed through a high-risk jurisdiction until sanctions screening confirms the vessel operator, charterer, and cargo owner are not exposed to designated parties.
- A cloud provider reassesses a reseller agreement when a sanctioned organisation appears in the payment flow, support chain, or ownership structure, creating downstream access concerns.
- A compliance team uses screening and case management aligned to U.S. Treasury sanctions guidance and internal policies to document why a counterparty was accepted, rejected, or exited.
Why It Matters for Security Teams
Secondary sanctions risk matters because it can convert a routine business relationship into a strategic access issue, affecting payment rails, vendor continuity, and customer trust. For security and risk teams, the key challenge is that the risk often hides behind third parties, resellers, agents, and ownership layers rather than appearing in a simple sanctions list check. That makes supplier due diligence, identity validation, transaction monitoring, and escalation paths part of the same control surface. Where organisations rely on outsourced operations, digital onboarding, or automated approvals, weak entity resolution can leave a sanctioned nexus undetected until a regulator, bank, or platform partner intervenes.
In governance terms, the right response is to pair sanctions screening with documented escalation, adverse-action decisions, and evidence retention. Cross-functional ownership is essential because legal, compliance, security, and procurement often see different slices of the same exposure. The concept also intersects with identity assurance when beneficial ownership, authorised signers, or agent access must be verified before a relationship is approved. Organisations typically encounter the operational reality of secondary sanctions risk only after a payment is rejected, an account is frozen, or a banking partner exits, at which point the term becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, while ISO/IEC 27001:2022 and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Risk management governance supports oversight of third-party sanctions exposure. |
| NIST SP 800-53 Rev 5 | SA-9 | External system services control aligns to managing third-party exposure in payment and service chains. |
| ISO/IEC 27001:2022 | A.5.19 | Supplier relationship controls support due diligence over sanctions-linked partners. |
| NIST SP 800-63 | IAL2 | Identity proofing helps validate counterparties and signatories before risk acceptance. |
| DORA | Operational resilience obligations intersect with third-party and payment disruption from sanctions actions. |
Plan for partner interruption, account restriction, and transaction failure in resilience testing.
Related resources from NHI Mgmt Group
- How should crypto businesses handle sanctions screening when wallet risk changes over time?
- Why do crypto exchanges create AML and sanctions risk beyond direct customers?
- How should organisations handle sanctions risk when crypto is used for cross-border payments?
- Who is accountable for monitoring secondary-market stablecoin risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
