How Secure Managed File Transfer Reduces GLBA, SOX, and NYDFS Non-Compliance Risk

Financial services firms operate under more overlapping regulatory obligations than almost any other industry, and a growing share of those obligations depend on something most compliance programs don’t examine closely: how files actually move between people, systems, and outside parties. The Gramm-Leach-Bliley Act (GLBA), the Sarbanes-Oxley Act (SOX), and New York’s cybersecurity regulation for financial services (23 NYCRR 500, commonly called NYDFS) each approach data protection from a different angle, but all three eventually ask the same practical question: who accessed or moved this file, when, and under what authorization. This post looks at what each regulation requires, where common file transfer practices fall short, and how a secure managed file transfer (MFT) approach helps close the gap.

Executive Summary

Main idea: Secure managed file transfer turns three separate sets of regulatory obligations — under GLBA, SOX, and NYDFS — into a single, auditable control layer for how financial data moves between people, systems, and third parties.

Why it matters: Each of these regulations treats file transfer as an examination point in its own right. A gap here can surface as an FTC enforcement action, a SOX control deficiency, or an NYDFS violation, regardless of how strong an institution’s other security controls are.

Key Takeaways

1. File transfer is a shared audit point across GLBA, SOX, and NYDFS. Each regulation asks a version of the same question — who accessed or moved a file, when, and under what authorization — which makes unmanaged transfer methods a single point of failure across three separate exams.
2. GLBA’s amended Safeguards Rule made technical controls, not policy documents, the standard. Encryption, multi-factor authentication, and access restriction are now specific requirements for how customer financial information is protected in transit and at rest, not general guidance.
3. SOX compliance depends on proving who touched financial reporting data, not just that controls exist on paper. Section 404 assessments require evidence, such as audit trails and version history, that reporting files weren’t altered outside an approved control.
4. NYDFS increasingly holds firms accountable for their vendors’ file handling practices. Third-party service provider provisions mean a firm’s compliance posture now depends on how partners and vendors handle shared files, not only on its own internal systems.
5. Consolidating file transfer onto one governed platform simplifies exam preparation. Instead of assembling separate documentation for each regulator, a single control layer can produce access logs and encryption evidence relevant to all three frameworks from one place.

Why File Transfer Is Where Compliance Programs Actually Break Down

Financial services firms typically invest heavily in securing where data is stored — core banking systems, document repositories, data warehouses. The moment a file leaves that environment, however, visibility often drops sharply. A spreadsheet attached to an email, a report dropped into a personal cloud folder, a batch file pushed through an unmanaged SFTP script: these are the moments regulators focus on, even though none of the three regulations discussed here name “file transfer” specifically.

The Common Requirement Underneath Three Different Regulations

Despite covering different subject matter, GLBA, SOX, and NYDFS converge on a similar set of underlying controls. The table below summarizes each regulation’s primary concern and the file transfer control it implies.

GLBA: Protecting Customer Financial Information in Every Transfer

The Gramm-Leach-Bliley Act’s Safeguards Rule governs how financial institutions protect customers’ nonpublic personal information. Amendments that took effect in 2023 shifted the rule from general guidance toward specific, testable technical requirements, several of which point directly at how files move.

What the GLBA Safeguards Rule Requires

The amended rule asks covered institutions to build a written information security program around a set of concrete controls, including:

• A written risk assessment and a designated Qualified Individual responsible for the security program
• Encryption of customer information in transit and at rest, or a documented, approved alternative control where encryption isn’t feasible
• Multi-factor authentication for any individual accessing systems that contain customer information
• Access controls that limit information to authorized users on a need-to-know basis
• An incident response plan and ongoing oversight of service providers that receive customer information

Where File Transfer Practices Commonly Fall Short of GLBA

In practice, gaps tend to show up in predictable places: customer NPI attached to unencrypted email, files sent to a vendor without confirming the vendor applies equivalent safeguards, transfer points that sit outside the MFA perimeter applied to core systems, or files sent with no record of who on the receiving end actually opened them.

Best Practices for GLBA-Aligned File Transfer

• Encrypt NPI in transit and at rest by default, rather than as an exception applied to sensitive files
• Enforce MFA at every point where customer data can be accessed or transferred, not only at core system logins
• Apply role-based access controls so only authorized staff can view, send, or receive NPI
• Retain logs of file access and transfer activity so the institution can produce evidence during an examination
• Extend safeguards contractually and technically to any vendor or service provider that receives customer files

SOX: Maintaining an Audit Trail for Financial Reporting Data

Sarbanes-Oxley doesn’t regulate file transfer directly, but Sections 302 and 404 create an evidentiary burden that touches nearly every file feeding a public company’s financial statements.

What Sections 302 and 404 Require

Section 302 requires a company’s CEO and CFO to personally certify, on a quarterly basis, that financial reports are accurate and that disclosure controls are effective. Section 404 goes further, requiring management to assess the effectiveness of internal control over financial reporting annually, with an external auditor attesting to that assessment. Neither section prescribes file transfer controls by name, but both depend on being able to demonstrate that reporting data wasn’t altered outside an approved process.

Where File Transfer Practices Commonly Fall Short of SOX

Common gaps include board packages and reporting workbooks exchanged over email without version history, auditors granted ad hoc access to shared drives with no record of what they viewed, and no reliable way to show that a file wasn’t modified between finance sign-off and filing.

Best Practices for SOX-Aligned File Transfer

• Maintain immutable audit trails for any file supporting financial reporting
• Use versioned, access-controlled repositories rather than email attachments when exchanging files with external auditors
• Restrict edit access to reporting-related files once a reporting period closes
• Retain access and transfer logs long enough to support both quarterly certifications and the annual control assessment

NYDFS 23 NYCRR 500: Third-Party and Access Risk for Regulated Entities

New York’s Department of Financial Services cybersecurity regulation applies to a broad range of entities licensed, registered, or chartered under New York banking, insurance, and financial services law. Amendments finalized in late 2023 expanded the original 2017 rule considerably, with several changes centered on access management and third-party oversight.

What the Amended Regulation Requires

The amended rule broadens requirements around multi-factor authentication, formal IT asset inventories, and — notably for file transfer — third-party service provider risk management, under which regulated entities must assess and manage the cybersecurity practices of vendors that access their systems or data. It also introduces independent audit obligations for larger entities and requires senior officer certification of compliance.

Where File Transfer Practices Commonly Fall Short of NYDFS

Typical gaps include vendors and counterparties given file access without any cybersecurity vetting, MFA enforced on core systems but not on every file transfer point, and no clear inventory of where sensitive financial data physically travels once it leaves internal systems for a partner or vendor.

Best Practices for NYDFS-Aligned File Transfer

• Enforce MFA universally across file transfer points, not selectively based on system type
• Maintain visibility into every third party that receives files containing regulated data
• Build cybersecurity requirements into vendor contracts and verify them technically, not only contractually
• Centralize file transfer activity to reduce the number of systems that must be inventoried and audited

The Business, Financial, and Reputational Risks of Non-Compliance

The cost of treating file transfer as someone else’s compliance problem tends to surface later — during an exam, an audit, or a breach investigation — rather than at the moment a file is actually sent.

Financial Risk

Regulatory findings can lead to enforcement penalties, mandated remediation spending, and the cost of forensic investigation if an incident occurs. If a SOX control failure is severe enough, it can also contribute to the cost and disruption of a financial restatement.

Reputational Risk

Financial services relationships run on trust. A publicized data exposure or examination finding can prompt clients, correspondent banks, or institutional counterparties to reassess a relationship, independent of whether any funds were ultimately affected.

Business and Operational Risk

Examination findings can trigger mandated remediation plans, consent orders, or closer ongoing supervision, any of which can delay licensing decisions, partnership approvals, or M&A activity. Internally, teams often lose time to manual evidence-gathering for exams instead of higher-value compliance work.

How Kiteworks Helps Financial Services Firms Manage GLBA, SOX, and NYDFS Risk

GLBA, SOX, and NYDFS approach financial data protection from different angles, but all three come back to the same practical need: knowing exactly how sensitive files move, who can access them, and being able to prove it. Kiteworks for financial services is built around that shared requirement rather than treating each regulation as a separate project.

• Secure managed file transfer: Kiteworks MFT Server runs as a hardened, purpose-built appliance for automating file transfer workflows, with governance controls and audit logging built into every transfer rather than added on afterward.
• Granular access governance: Kiteworks’ Data Policy Engine combines role-based access controls with attribute-based policies, so administrators can define exactly who is authorized to view, send, or receive specific data.
• Audit logging and compliance reporting: Every file transfer, access event, and workflow execution is logged in a unified stream that compliance and security teams can query, filter, and export as exam-ready evidence.
• Encryption in transit and at rest: Data moving through Kiteworks is protected using AES-256 encryption and FIPS 140-3 validated cryptographic modules.

A platform is one part of a broader compliance program — it doesn’t replace the legal analysis, policy work, or examiner relationships that GLBA, SOX, and NYDFS compliance ultimately depend on. What it can do is remove file transfer as the weak link in that program. To see how this applies to your institution’s specific regulatory footprint, schedule a custom demo.

Additional Resources

• Blog Post 6 Reasons Why Managed File Transfer is Better than FTP
• Blog Post Secure Managed File Transfer: Which Solution is Best for Your Business?
• Blog Post Data Privacy Protection: Safeguarding Information through Secure File Transfer
• Blog Post 10 Best Secure File Transfer Practices for Regulatory Compliance
• Blog Post Eleven Requirements for Secure Managed File Transfer