Multi-Office Law Firm Permissions and Governance Guide

Definitions

Practical workflow

1. Establish one global identity record

   Choose the authoritative identity source and stable person identifier. Link office, practice, employment status, professional role, manager, location, and system accounts to that identity. Prevent duplicate local accounts from becoming an alternate route around suspension, recertification, or ethical-wall controls.

2. Define the permission hierarchy

   Separate firm-wide capabilities from office, practice, matter, record, and action scopes. Document which roles may discover, view, edit, share, export, delete, approve, report, or administer each class of record. Start from deny-by-default or minimum necessary access and make inheritance visible.

3. Map office, practice, and matter roles

   Define the difference between an office role, practice-group role, and matter role. A person may belong to one office, support another, and work on matters led by a third. Test how conflicting memberships resolve, which scope wins, and whether a role grants visibility without granting edit or export rights.

4. Separate global identity from matter confidentiality

   Keep person identity and employment facts globally authoritative while applying matter-specific confidentiality, client, party, and ethical-wall restrictions at the matter or record layer. Verify that global search, directory displays, notifications, reports, APIs, and exports do not reveal protected matter content.

5. Design ethical walls and conflict restrictions

   Define the trigger, protected population, excluded population, restricted records, notification behavior, approval authority, review date, and evidence for each wall. Test discovery, search, previews, downloads, shared links, email filing, reports, integrations, administrator access, and changes to the matter team or wall status.

6. Enable controlled cross-office collaboration

   Create an approved collaboration pattern for matters spanning offices or practices. Identify the matter owner, participating teams, permitted data, client or engagement limits, reporting scope, and end date. Make collaboration explicit rather than relying on broad firm-wide visibility or copied documents.

7. Govern local exceptions

   Allow local rules only where a documented business, professional, regulatory, client, or contractual reason exists. Require an accountable approver, affected scope, compensating control, start and expiry dates, review owner, and evidence. Preserve the default policy and original role so exceptions can be removed cleanly.

8. Control external-user access

   Give clients, co-counsel, experts, auditors, and service providers separate external identities and matter-scoped permissions. Require identity proofing or an approved invitation process, explicit content selection, authentication, expiry, revocation, download and sharing controls, notification review, and a test that one external user cannot pivot into another matter.

9. Run joiner, mover, and leaver workflows

   Connect HR or identity events to provisioning, approval, role changes, office transfers, leave, suspension, and departure. Recalculate inherited and direct grants when a person moves, preserve matter handoff evidence, disable sessions and tokens when required, and confirm that former users cannot retain access through shared links, delegated accounts, or integrations.

10. Protect privileged administration

    Separate day-to-day work from policy and platform administration. Use individual administrator identities, strong authentication, just-in-time or time-bound elevation where practical, separation of duties, approval for high-impact changes, restricted support access, immutable or protected logs, and regular review of administrative actions.

11. Define emergency access

    Specify the events that justify emergency access, who can approve it, which minimum scope is available, how long it lasts, what the user must record, and how the access is reviewed afterward. Test a real emergency path and a denied request, including notification, evidence capture, expiry, and investigation of any use outside the approved reason.

12. Recertify access and review audit evidence

    Set review cadences for firm, office, practice, matter, external, and privileged access. Send managers, matter owners, records or risk owners, and system owners the grants they must confirm. Record decisions, removals, exceptions, non-responses, evidence, and follow-up. Review access changes, denied attempts, exports, privilege elevation, and emergency use for anomalies.

13. Assign governance RACI and change control

    Name the accountable owner for identity, role design, ethical walls, local exceptions, matter access, external users, privileged administration, audit, incident response, and recertification. Require change requests to identify impact, affected jurisdictions, testing evidence, approvers, communication, rollback, and the date for post-change review.

14. Test the complete permission model

    Use an authorization matrix and representative accounts to test allowed, denied, inherited, direct, exceptional, expired, suspended, and emergency paths. Cover office and practice changes, ethical walls, cross-office matters, external users, administrator actions, search and notifications, APIs and exports, audit records, and recovery after a failed change.

Comparison

Limitations and exceptions

• The ABA Model Rules are model rules, not a universal code that automatically applies to every lawyer or firm. State, federal, tribal, national, provincial, and professional-body rules may differ or impose additional duties.
• SRA standards and guidance apply in the context of solicitors and firms regulated by the SRA in England and Wales. They should not be treated as a substitute for the rules of another jurisdiction.
• An access-control configuration does not decide whether a conflict exists, whether an ethical wall is sufficient, whether privilege applies, or whether a disclosure is permitted. Qualified professionals must make those decisions.
• A global identity model must account for local employment, licensing, data-protection, labor, client, court, and records requirements. Central administration does not remove local accountability.
• Role-based access is only one layer of control. Shared links, search indexes, notifications, exports, integrations, backups, support access, devices, and copied files can create alternate disclosure paths.
• Emergency access can protect continuity but can also bypass ordinary separation. It requires a narrow scope, explicit reason, attributable approval, short duration, protected logs, and retrospective review.
• Recertification confirms a decision at a point in time; it does not prove that every rule, integration, inherited grant, or downstream copy enforced the decision continuously.
• NIST frameworks and control catalogs are adaptable security references, not legal standards or a security certification. The firm must choose controls proportionate to its risks and obligations.
• This guide is an access-governance framework and case-management evaluation aid, not legal advice, a professional-responsibility opinion, or a guarantee that a particular software configuration will satisfy a jurisdiction.

Primary sources

Methodology

Start with the firm operating model and the decisions that access must support: who may work on a matter, who may supervise or approve, who may collaborate across offices, who may act externally, who may administer the system, and what evidence is needed after an access event. Build a permission matrix with rows for identity, role, office, practice, matter, record type, action, external status, lifecycle state, and exception state. Distinguish direct grants from inherited grants, and distinguish global identity attributes from matter-specific confidentiality. Define default roles, ethical-wall rules, collaboration patterns, local exceptions, emergency access, privileged operations, joiner-mover-leaver triggers, recertification cadence, audit events, and RACI ownership before configuring software. For each rule, record the source policy, jurisdiction or client constraint, approver, expiry or review date, compensating control, and expected evidence. Test ordinary, denied, inherited, changed, expired, suspended, external, emergency, and administrator paths using representative offices, practices, matter types, parties, documents, reports, notifications, APIs, and exports. Review false allows and false denies separately, reconcile the permission matrix to actual grants, sample audit logs, and require sign-off from legal, information security, operations, records, and accountable matter owners. Pilot high-risk workflows first, monitor exceptions and failed lifecycle events after launch, and update the model when the firm, system, clients, professional rules, or jurisdictions change. This is an organization-designed governance method, not a universal legal rule or certification test.

FAQs

Related CaseDocker capabilities

Related guides and resources

• Case management portfolio
• Legal case management information
• Legal workflow playbooks
• Law firm ethical walls and audit logs guide
• Law firm client portal security checklist
• Legal systems access recertification checklist