Most law firms scrutinize their core practice management platform carefully before signing a contract. They ask about encryption, data residency, and uptime. What gets far less attention is everything plugged into that platform afterward: the e-signature tool, the calendar sync, the billing export, the client portal widget. Each of those integrations opens a new door into the firm's data, yet many firms have never sat down and mapped out who actually holds the keys.
This isn't a theoretical concern. Practice management systems like Clio, MyCase, PracticePanther, and similar platforms offer APIs and integration marketplaces specifically so third-party tools can connect to them. That connectivity is a major part of their appeal, and it's also a category of risk that tends to get less scrutiny than the core platform itself.
In Australia, firms running platforms such as LEAP, Actionstep, or FilePro face an added layer to this picture: obligations under the Privacy Act's Notifiable Data Breaches scheme, where the firm's size or activities bring it within scope, and AML/CTF Tranche 2 obligations that commenced on 1 July 2026 for firms providing designated services such as conveyancing or managing client money and other assets. Managing software integrations alongside these requirements is part of why some firms bring in a legal-sector IT specialist rather than a general provider. Kmtech.com.au is one example of a managed IT provider that works with Australian legal practices on this kind of integration and compliance overlap.
Why Integrations Receive Less Scrutiny
When a firm evaluates its core software, security review is usually part of procurement. When a paralegal installs a document-scanning add-on or connects to a calendar app to save five minutes a day, that same scrutiny often doesn't apply. The integration gets approved with a click rather than a formal risk assessment.
The gap tends to widen over time. A firm that has used the same practice management system for six or seven years can accumulate a dozen or more connected apps, some of which nobody currently on staff remembers approving. A departing employee's account authorizations, or the integrations tied to them, can remain active if access isn't formally revoked. Trial integrations installed for a single case sometimes stay connected long after the case closes, each retaining whatever access it was originally granted.
Where Permission Scopes Quietly Expand
Many integrations authenticate through OAuth, which asks the user to grant a set of permissions once and then operates silently afterward. Scope requests can end up broader than the integration strictly needs. For example, a tool built primarily to sync calendar entries could end up requesting read access across an entire document library rather than a narrower scope limited to scheduling data.
Firms rarely revisit what was actually granted once an integration is live. A connector approved two years ago for a narrow purpose may still hold standing access to client files, billing records, or trust account data long after anyone remembers why. If that vendor's own systems are compromised, an attacker may not need to touch the law firm's network directly. Depending on how access is configured, they could exploit the credentials or tokens the integration already holds.
Subcontractor Risk: The Vendor Behind Your Vendor
A firm's direct software vendor is rarely the only company touching client data. Practice management platforms rely on subcontractors for cloud hosting, analytics, customer support tooling, and payment processing. Each of those subcontractors is a link in a chain the firm typically has little visibility into and no direct say over.
This kind of fourth-party exposure is part of the reasoning behind the American Bar Association's Cybersecurity Legal Task Force Vendor Contracting Project: Cybersecurity Checklist, built to help lawyers negotiate stronger cybersecurity terms into vendor contracts. The underlying idea, that a firm's security posture is shaped by its most exposed connected supplier, is a useful lens for thinking about practice management integrations specifically, even where a vendor's own subcontractors sit outside the firm's direct control.
Practice Management Blind Spots Worth a Second Look
A few categories of integration tend to carry more risk than firms expect. Document and e-signature tools often need write access to case files, not just read access, since they push signed documents back into the system. Billing and accounting exports frequently move data outside the practice management platform's own security controls, into spreadsheets or third-party accounting software governed by its own separate set of protections.
Client-facing portals present a related concern. Built to make communication easier, they can become a direct path into case data if their own authentication is weak. Calendar and email connectors carry a subtler risk: access to metadata revealing opposing counsel, case timing, and settlement schedules, information that can be valuable to an attacker even without touching a single document.
None of these tools are inherently unsafe. The risk comes from firms not knowing which ones are active, what they can access, and whether that access still matches a current need.
What a Compromised Integration Can Cost a Firm
When an integration becomes an entry point for a breach, the damage doesn't always stay contained to that one tool. Attackers who compromise a connected app's credentials may use them to move further into the core practice management system, since that's usually where the more valuable data sits. From there, exposure can include privileged client communications, trust account details, and case strategy documents protected by legal professional privilege.
Beyond the direct data loss, firms can face notification obligations, regulatory scrutiny, and a harder conversation with clients about why a third-party calendar plugin had access to their confidential files in the first place. Rebuilding that trust can take longer than rebuilding the technical environment.
Closing the Gap: A Practical Integration Review
Treating integrations as an ongoing risk category, rather than a one-time approval, changes the equation. A useful review starts with ownership: every connected app should have a named internal person responsible for its continued use, rather than existing as an orphaned connection nobody is accountable for. From there, OAuth scopes deserve a fixed review schedule instead of an assumption that original grants are still appropriate, and each integration's business need should be confirmed before its access is renewed.
Vendor assurance matters just as much as internal housekeeping. Firms should request independent security assurance, such as a SOC 2 report, ISO 27001 certification, or comparable evidence, from integration vendors, not just the core platform provider, and should revoke tokens immediately for departed staff and discontinued tools rather than leaving that access dormant. Monitoring deserves the same clarity: someone specific should own detecting and responding to unusual activity tied to a given integration, not just the core platform as a whole.
The NIST Cybersecurity Framework 2.0, organized around the functions of Govern, Identify, Protect, Detect, Respond, and Recover, offers a useful structure for this kind of review, and it applies as well to a firm's integration stack as it does to its broader network.
Firms looking for a broader model of how this discipline is applied elsewhere can look at how organizations are formalizing vendor risk management as a distinct practice, covering vendor inventories, prioritized remediation, and contractual security requirements, principles that apply just as directly to a law firm's software integrations as they do to any other regulated industry.
The tools connected to a practice management system are rarely the problem on their own. It's the accumulated, unexamined access they quietly hold that can turn a convenience feature into the weakest link in a firm's defenses.
