The Audit Gap That Cost Morgan Stanley $35M (Auditor Won't Flag)

In September 2022, Morgan Stanley Smith Barney paid the SEC $35 million for failing to safeguard customer information. The case was about hard drives. About 15 million customers' personally identifiable information ended up on the open market because a contractor without data-destruction expertise sold thousands of unsanitized drives at online auction. The encryption capability existed in the devices. It was never activated firm-wide. The asset inventory was incomplete.

It was the largest financial-sector data-security fine in SEC history at that time.

Most bank CFOs have heard about this case. Most bank CISOs and Compliance Officers have read about it. What none of them ask is the obvious follow-up: the same physical-asset class, with the same residual-data property, sits in every branch and back office of every U.S. financial institution. The multifunction printer.

If you ask a bank CISO whether their MFP fleet has the same Morgan Stanley problem, the most common answer is "we don't know." The second most common is "our auditor never flagged it."

That second answer is the load-bearing one. Why didn't the auditor flag it? Why didn't the pen tester flag it? Why didn't the SOC 2 audit catch it? Why didn't the FFIEC examiner ask?

The honest answer is that this is a structural gap, not a negligence gap. It exists for four reasons, none of which involve anyone doing their job badly.

The regulator gap

Federal financial-services regulations require encryption in transit. They use principle-based language. They do not enumerate device classes.

The GLBA Safeguards Rule, codified at 16 CFR 314.4(d), requires institutions to encrypt all customer information both in transit over external networks and at rest. The text does not specify which devices. The term "external networks" is not defined to include MFP-originating SMTP traffic explicitly.

The FFIEC IT Examination Handbook Information Security booklet was last substantially updated in 2016. It addresses email transmission and assumes email clients with configurable encryption, not network-attached devices with embedded mail functionality. Section 4.3 (Email) discusses TLS for email but does not specifically call out scan-to-email as a discrete data-transport class. When the booklet was written, scan-to-email volume was a fraction of what it is today.

NY DFS Part 500 § 500.11(c) mandates encryption in transit. Section 500.13 requires asset inventory. Neither names MFPs.

The auditor reading these texts is correctly interpreting principle-based regulatory language. The auditor has not been ignoring a specific requirement. The requirement exists; the device specificity did not.

The audit scope gap

A typical financial-institution penetration test follows NIST SP 800-115, OWASP PTES, or CREST methodology. All three define scope as a risk-prioritized exercise. A bank pen-test budget covers, say, 100 workstations and 20 servers in 40 hours.

A multifunction printer making 5 to 15 scans a day is three orders of magnitude lower in transaction volume than a workstation. A pen tester deciding where to spend the next four hours of testing time correctly chooses the workstation. The MFP gets a port scan and a banner-grab; that is what the budget allows.

SOC 2 audits scope to a defined system. If the system is "payment processing systems hosted on AWS," the MFP is out of scope because the MFP is not in that system. AICPA Trust Services Criteria CC6.6 and CC6.7 are principle-based. The institution defines the control register. The auditor tests what is registered.

Most institutions did not register MFP scan-to-email as a control because the prior-year exam findings did not cite it, and the current-year WISP is built from those prior findings. The control was never registered. It was never failed.

The pen-test scope was rational. The SOC 2 register was rational. Both were correct given what they had.

The vendor-promise gap

This one is the easiest to see and the easiest to miss. Copier OEMs (HP, Xerox, Ricoh, Konica Minolta, Canon, Lexmark, Sharp, Kyocera, Brother, Toshiba) market security features under brand names like "Secure Pull Print," "Follow-Me Print," "HP Wolf Pro Security," "Xerox SmartSecurity Suite," and "Ricoh Managed Print Security." These features are real. They solve documents sitting in the output tray, hard-drive sanitization on decommissioning, and secure boot.

They do not encrypt scan-to-email. The print path and the scan-to-email path are different code paths in the device.

When a bank reads "enterprise security" in the copier brochure, the brochure is technically accurate. It is just not explicit about the distinction between print-path security and scan-path security. Quocirca's 2024 Print Security Landscape research surveyed 500 IT decision makers (including a substantial financial-services subset) and found that just 16 percent of organizations are completely confident in their print security while 67 percent suffered a print-related breach in the past year. That is a gap between confidence and breach reality.

The vendor was not deceptive. The customer did not know to ask "and the scan path?" Neither party was negligent. The marketing language did its job; the question went unasked.

The control-design gap

This is the deepest of the four. SOC 2 auditors test what is on the institution's control list. If "MFP scan-to-email encryption" is not on the list, it is not tested. If the audit passes, the institution and the auditor both correctly conclude that the registered controls were operating effectively.

The next FFIEC IT exam does not flag the gap because the FFIEC InfoBase does not enumerate it. Next year's WISP is built from this year's findings. The loop closes without scan-to-email encryption ever being added to the control register.

This is the textbook control-design-versus-control-test gap in audit practice. The auditor cannot test what is not registered. The control was never failed. It was never present.

What is changing in 2024 to 2026

The structural gap is closing now. Three independent signals are converging.

First, the regulators clarified. NIST published SP 1800-29 in April 2024, the first federal publication to explicitly name printers and MFPs as IoT-adjacent devices requiring firmware verification, default credential detection, and configuration hardening. The FTC's 30-day breach-notification rule under the GLBA Safeguards Rule (effective May 2024) is forcing institutions to detect scan-to-email exfiltration faster. SEC Reg S-P 2024 amendments (effective for large entities December 3, 2025; smaller entities June 2, 2026) expanded the definition of customer records and the required customer-notification window.

Second, the analyst data is in. Quocirca 2024: 67 percent of enterprises had a print-related breach in the past year, average cost roughly $1.28 million, up 38 percent year over year. Wolf & Company PC, Cornerstone Advisors, and ICBA started adding print security to their 2025-2026 audit checklists.

Third, the insurers are asking. Cyber insurance underwriters are adding scan-to-email encryption to 2026-2027 renewal questionnaires. Banks answering No are seeing premium adjustments and sub-limit exposures. The carrier-side pressure flows back to the institution's audit and risk programs.

The conversation with your auditor

If you are reading this because your bank or credit union has been thinking about this risk, the conversation with your existing auditor is the most important meeting in the project. The right script is dignity-preserving. It places the discovery in your voice, not the auditor's. Something like:

"I appreciate how thoroughly you've reviewed our email security and data transmission controls. One thing I realized while prepping for your exam is that we scan documents from our MFPs and email them as PDFs, and I'm not sure we documented the same encryption and audit standards for that workflow as we do for our main email system. It is not a compliance gap necessarily, because scan-to-email did not exist in the same form when the FFIEC handbook was written. But it is probably worth us documenting together: what are our encryption, credential, and data-retention standards for MFP-generated emails?"

That language preserves the auditor's prior work, acknowledges the structural framework, and invites collaboration. It works because the auditor is not the problem. The framework is.

What to do this week

Three concrete actions.

First, ask your audit team a single question: is MFP scan-to-email encryption registered as a discrete control in our written information security program? If the answer is no or unclear, that is the structural gap.

Second, read the auditor page on this site for the full four-part frame in the language your audit firm and your examiner will recognize. Send the link to your audit team.

Third, run the trace template on three devices in your fleet. The template captures SMTP authentication mode, encryption status, credential storage in device configuration backup, and address-book LDAP query mode. It runs locally; no data leaves your network.

The audit gap closes on its own timeline if you do nothing. Or you close it on your own timeline ahead of that.