Mobile Apps, SDKs,
And The Quiet Leakage
Most Firms Never Review.

Every mobile application installed on a partner's phone is a subprocessor relationship the firm has never reviewed. Modern apps do not ship as standalone software. They are assembled from third-party software development kits — SDKs — that handle analytics, advertising attribution, crash reporting, location services, and user identity. A typical consumer app contains a dozen or more of these embedded components, with recent industry estimates placing the average well above that figure. Each one routes data to a vendor the user has never heard of and the firm has never vetted.

When an attorney uses a free PDF scanner to capture a settlement letter, or a CPA opens a tax research app during a client meeting, or a wealth advisor reviews positions in a portfolio tracker between flights, metadata about that activity moves. Device identifiers, location, network context, the timing and frequency of access, sometimes content adjacencies — all of it flows through analytics and advertising intermediaries operating under their own data-sharing arrangements.

This is not a theoretical concern. The Federal Trade Commission spent 2024 building an enforcement record that names the mechanism directly: SDK-based collection embedded inside otherwise innocuous third-party apps, monetized downstream through data brokers, advertising networks, and in at least one case, government contractors.

The pattern is consistent across professional services firms. Staff install convenient tools to do legitimate work. The tools function as advertised. The leakage is invisible because it operates one layer below the user interface, inside the SDK stack the app developer assembled to ship the product.

In June 2024, the FTC finalized a separate $16.5 million settlement against Avast — a security software company that, through its subsidiary Jumpshot, had collected and sold detailed, re-identifiable browsing data from its own customers for years. The mechanism differed; the principle did not. Trusted software was monetizing user data downstream, and the agency demonstrated it would impose financial and operational penalties for it.

Mobile SDK leakage does not affect every regulated profession identically. The legal duty, the regulator, and the closing exposure differ. The underlying mechanism is the same.

For Law Firms

• Model Rule 1.6(c) Requires reasonable efforts to prevent unauthorized disclosure of information relating to representation. Reasonableness presumes the lawyer knows where the information goes. SDK-routed metadata is, by design, opaque to the user — and therefore difficult to defend as reasonably understood.
• ABA Op. 477R Directs lawyers to understand how client communications are transmitted and where client data resides. A mobile application stack assembled from a dozen-plus third-party SDKs frustrates that obligation unless someone has actually inventoried the data flows. Most firms have not.
• Malpractice exposure If a client surfaces evidence that confidential information moved through an unreviewed third-party pipeline because of an app on a partner's phone, the firm faces a defense problem that is not theoretical. The discovery posture is bad. The reputational posture is worse.

For CPA Firms

• FTC Safeguards Rule Tax preparers fall within the definition of "financial institution" for purposes of the Safeguards Rule. The rule requires a written information security program covering all service providers that touch customer information. Embedded SDKs inside apps used to handle client data are service providers under any honest reading of that definition.
• IRS Pub. 4557 Imposes data-protection requirements on practitioners handling federal tax information. The publication is increasingly invoked by IRS during practitioner investigations following data incidents. A breach involving mobile app pipelines that were never assessed will not read well in that context.
• AICPA standards Professional conduct rules carry their own confidentiality obligations independent of federal regulation. State boards of accountancy have begun citing technology-related lapses in disciplinary proceedings.

For Wealth Management Firms

• SEC Reg S-P Amended in 2024 to require written incident response programs and customer notification within thirty days of a covered incident. The definition of covered information includes data held by service providers — which, again, includes embedded SDKs that receive client-correlated data from advisor devices.
• FINRA obligations Member firms are expected to supervise associated persons' use of technology in client-facing work. Mobile applications used during the workday are within that supervisory scope, whether the firm has acknowledged it or not.
• Fiduciary exposure The duty of care extends to how client information is handled. A client harmed by a data leak traceable to an unreviewed app on an advisor's phone has a fiduciary claim that does not depend on regulatory action to proceed.

Most professional services firms have a mobile device policy. Most of those policies were written to address device theft, password complexity, and remote wipe. They do not address the data-flow problem at issue here. Common gaps:

• App-level review BYOD and MDM policies typically govern device access and configuration. They rarely require any review of what specific apps installed on a device do with data once permission is granted.
• Subprocessor scope Vendor risk assessments and DPAs name the app publisher. They almost never extend to the embedded SDKs the publisher integrated, even though those SDKs are the actual data destinations.
• Ad ID hygiene Most policies do not require staff to disable mobile advertising identifiers, reset them periodically, or limit cross-app tracking — the very identifiers FTC enforcement actions repeatedly named as the linkage between collected data and identifiable individuals.
• Installation discipline Few firms maintain an approved-app list for devices used in client work. The default posture is that any partner can install any app at any time, with no record made and no review conducted.
• Training scope Security awareness training emphasizes phishing and password reuse. It rarely covers app selection as a confidentiality decision — even though, from a data-flow perspective, installing a free PDF scanner is functionally a vendor procurement event.

None of these gaps are unusual. They are the standard posture across small and mid-sized professional services firms. They are also the posture that, after a 2024 of named enforcement, is harder to defend than it was a year ago.

Closing this exposure does not require new software, an MSP retainer, or an enterprise mobility platform. It requires the firm to treat mobile devices the way it already treats vendors: with an inventory, a written standard, and a periodic review.

1. Inventory the mobile devices used to handle client information — firm-issued and BYOD — and identify which applications on each device are used in client work. The list is almost always longer and more varied than firm leadership expects.
2. Establish an approved-app list for any device that touches client information. Apps outside the list are not prohibited from existing on the device, but they are prohibited from being used in client matters. The distinction is enforceable through policy and audit.
3. Disable or reset mobile advertising identifiers on client-handling devices. On iOS, ensure App Tracking Transparency is enforced and that cross-app tracking is denied by default. On Android, regularly reset or delete the advertising ID and consider opting out of personalized advertising at the OS level.
4. Conduct an SDK-level review of each approved app at intake and annually thereafter. This means reading the privacy disclosures, identifying named third-party recipients, and confirming what data categories leave the device. Where the publisher will not disclose, the app does not belong on a client-handling device.
5. Update vendor questionnaires and engagement DPAs to require disclosure of embedded subprocessors for any mobile application the firm relies on in delivering services. The legal definition of "subprocessor" extends to SDKs receiving data from the app; the questionnaire should reflect that.

The point is not to eliminate every theoretical exposure on every device. The point is to be able to describe — in writing, to a regulator, a client, or an insurer — what the firm's phones are doing and why. Firms that can answer that question have a defensible posture. Firms that cannot are operating on the hope that no one will ask.