How Financial Services Firms Protect Files Shared With Outside Advisors and Counterparties

A private equity firm shares a confidential information memorandum with a potential LP. A regional bank sends loan documentation to an outside counsel's deal team. An investment manager transfers quarterly performance reports to an institutional client's custody bank. An insurance company shares actuarial models with a reinsurance counterparty.

In each case, the file left the sending organization's environment. In each case, the organization's internal security controls — the DLP policies, the SharePoint permissions, the SIEM — were doing their jobs perfectly when the file went out. And in each case, the protection those controls provided ended the moment the file landed on the other party's system.

Financial services is the industry where files go the most places. The deal pipeline, the advisor network, the counterparty relationships, the regulator submissions, the audit packages — the nature of the work requires sharing sensitive files with parties outside the institution's perimeter, constantly, across every business line. The result is a security model in which the most sensitive information the firm holds is also the information with the least persistent protection.

This post covers how that gap forms, what the regulatory requirements actually say about it, and what a file sharing architecture that closes it looks like.

Why Standard File Sharing Controls Fail at the Counterparty Boundary

The controls most financial institutions rely on for file security are container-based: permissions within SharePoint or Google Drive, access controls on VDR platforms, DLP policies that monitor movement across monitored channels. These controls work well for data that stays inside the institution's managed environment.

The moment a file crosses to an outside advisor or counterparty, the container changes. The outside counsel's DMS is not your SharePoint. The LP's internal document repository is not your VDR. The reinsurer's actuarial platform is not your system. Whatever permissions and policies applied to the file on your side of the boundary have no authority on theirs.

What typically protects that file on the counterparty's side is the counterparty's own security posture — which you cannot audit, cannot control, and cannot verify in real time. You have the NDA and the confidentiality clause in the engagement letter. You do not have visibility into whether the outside advisor's IT team has patched their file server, whether a junior analyst at the LP has forwarded the CIM to a colleague at another fund, or whether the reinsurer's system is subject to data access requirements under a foreign jurisdiction you weren't aware of.

Your blast radius isn't a choice you made — it's an architecture you inherited. In financial services, the architecture of counterparty file sharing has, by default, extended your blast radius to every organization your files touch.

What the Regulatory Requirements Say

Financial services firms operate under layered regulatory requirements, several of which address the protection of files shared externally.

The FTC Safeguards Rule (16 CFR Part 314) applies to financial institutions under Gramm-Leach-Bliley and requires encryption of customer financial information in transit and at rest. The Safeguards Rule's April 2024 enforcement phase is explicit about scope: encryption requirements apply to customer financial information wherever it is stored, and however it is transmitted. Files shared with outside advisors and counterparties carry the same encryption obligation as files stored on internal servers. The transmission encryption that satisfies the in-transit requirement does not satisfy the at-rest requirement for files landing on the counterparty's system.

SEC Regulation S-P requires registered investment advisers, broker-dealers, and transfer agents to protect customer records and information, including safeguards against unauthorized access. The SEC's 2024 amendments to Reg S-P expanded the breach notification requirements and made explicit that covered institutions must assess the security of their service providers — including outside advisors who receive customer financial data. The file-sharing architecture is part of the Reg S-P service provider security assessment.

FINRA Rule 4370 (business continuity) and the broader FINRA supervision framework require broker-dealers to have controls over customer data that account for third-party access. FINRA's cybersecurity examination program routinely examines how firms manage data shared with outside parties.

The FFIEC examination framework for bank examiners specifically reviews file-level encryption as a distinct control from disk encryption and transmission security. Examiners now routinely ask about per-file encryption and access controls for sensitive financial data shared externally. Container-level controls without persistent file-level protection are a common finding.

The Specific Counterparty Scenarios That Create the Most Risk

Outside legal counsel: The files shared with outside counsel in deal execution, litigation, and regulatory matters are among the most sensitive in any financial institution: term sheets, transaction models, communications that carry privilege, regulatory examination materials. These files land in law firm document management systems that the institution cannot audit and whose security may not match the institution's own standards. A law firm breach that exposes a client's deal materials is a client breach, regardless of where the files came from.

Private equity and M&A advisors: Confidential information memoranda, management presentations, data room documents, and buy-side due diligence materials circulate across advisor networks, potential acquirer teams, and portfolio company management teams. Each recipient is a node where the document exists outside your control. In contested processes, these files travel to parties who are ultimately not awarded the transaction — meaning they retain documents for which the protection is your confidentiality agreement alone.

Institutional counterparties in securities transactions: Prime brokerage relationships, repo counterparties, and securities lending relationships involve sharing trading strategies, portfolio positions, and financial models with counterparties whose own risk management requires them to hold and analyze these files. The files are material non-public information in many cases and carry regulatory obligations around handling that the counterparty may not be applying in their own environment.

Auditors and regulators: Audit workpapers, examination materials, and regulatory submissions travel to external auditors and regulatory bodies. While regulators maintain their own security standards, external audit firms are frequent targets of sophisticated attacks precisely because they hold sensitive data from across their client base. A Big Four audit firm breach reaches every client who submitted sensitive files.

Reinsurance counterparties: The actuarial and underwriting data shared with reinsurance counterparties includes individual insured risk profiles, pricing models, and claims data. These files travel to counterparty systems globally, including to counterparties operating under jurisdictions with data access requirements that may conflict with the originating firm's regulatory obligations.

What a Persistent File Protection Architecture Looks Like

The architecture that closes the counterparty file sharing gap has three properties that container-based security does not provide:

Protection that persists after delivery: File-level encryption applied before the file leaves the institution means the encryption travels with the file to the advisor's DMS, the LP's document repository, the auditor's working paper platform. The file is ciphertext on arrival. The counterparty opens it through an access policy enforced by the sending institution, not by a password or a shared link. If the counterparty's system is compromised, the attacker gets encrypted files they cannot open.

Access policy controlled by the sender: The institution defines who at the counterparty can open each file, under what conditions, and for how long. When the deal closes, and the outside counsel's engagement ends, the institution revokes access to the deal files — not by retrieving the files (they're on the law firm's system) but by revoking the decryption authorization. The files remain on the counterparty's system and remain permanently ciphertext from that moment forward. This is the access control that NDA provisions try to create contractually. File-level encryption creates it technically.

Audit telemetry across the counterparty boundary: Every access event generates a log entry the institution can review: which file, which user at the counterparty, at which time, from which device. This telemetry exists regardless of whether the access happened inside the institution's environment or on the outside advisor's system. When a regulator asks how the institution knows who accessed a sensitive document package, the answer is not "we sent it securely and trust the counterparty" — it's a file-level access log.

The FTC Safeguards Rule Calculation

The FTC Safeguards Rule penalties are structured per violation per day: currently $43,792, compounded for ongoing failures. For financial institutions sharing customer financial information with outside advisors under file-sharing arrangements that lack persistent encryption, each day is a potential ongoing violation. The cost of per-file encryption deployment is a one-time implementation; the cost of a Safeguards Rule enforcement action is open-ended.

The FTC's 2024 enforcement actions under the Safeguards Rule have specifically targeted gaps in third-party vendor and counterparty security assessments. The examination question is not only whether the institution encrypts internally — it's whether the institution can demonstrate that customer financial information shared externally is protected after it arrives at the external party. Container-level controls at the sending institution do not answer that question. File-level persistent encryption does.

FAQs: Secure File Sharing for Financial Institutions