Common signs include repeated client delays, missing training materials, disconnected communication, and uncertainty about who owns each onboarding task. If the firm cannot describe its current process clearly, it usually cannot automate it safely. Weak process visibility often means the firm is digitising confusion rather than improving it, which creates more operational risk than efficiency.
How to tell onboarding is not ready for digitisation
If a law firm still relies on people remembering the sequence, chasing updates by email, or re-explaining the same steps to every new matter team, the process is not yet stable enough to digitise. The strongest warning sign is inconsistency: when different partners, assistants, and practice groups handle the same onboarding activity in different ways, automation will only preserve that variation faster.
A process is usually not ready when the firm cannot name the trigger, the owner, the handoff, and the completion criteria for each step. That lack of clarity shows up as repeated delays, rework, and exceptions that staff resolve informally. Digitisation depends on process visibility first, otherwise the firm is encoding ambiguity instead of control.
Another sign is that onboarding depends on tacit knowledge rather than documented decision points. If the team cannot tell which tasks are mandatory, which are conditional, and which are approval-dependent, then the workflow is not yet deterministic enough for reliable automation. That is especially important where access, document handling, or client data handoffs are involved, because uncontrolled variation creates avoidable operational exposure.
Where the process breaks down first
The earliest failure points are usually not technical. They are missing ownership, incomplete input data, unclear prerequisites, and duplicated communication across teams. When the firm asks the same client or internal stakeholder for information more than once, it often means the process has no single source of truth and no clean intake path.
Disconnected communication is another common indicator. If onboarding information lives in inboxes, chat threads, shared drives, and verbal updates, staff will spend time reconciling versions instead of progressing work. That fragmentation is a sign the process has not been standardised enough to support digital routing, status tracking, or task automation.
Training gaps are equally important. If new starters or support staff need frequent clarification on basic onboarding steps, the process is probably too dependent on memory and local habit. A process that cannot be taught consistently usually cannot be digitised consistently, because the digital version needs clearer rules than the manual one.
What readiness looks like before you automate
Readiness is less about having a tool and more about having a well-bounded workflow. The firm should be able to describe the onboarding journey from intake to completion, identify the exceptions, and show where approvals or client confirmations are required. If that map does not exist, the first investment should be process design, not software.
The practical test is whether the firm can produce a current-state workflow that survives challenge from the people who do the work. If each stakeholder gives a different version, the problem is usually not tooling but governance. A digitisation project should start only when the workflow is stable enough that the firm can define ownership, approvals, and access decisions clearly across the process.
That same discipline matters for handoffs and lifecycle events. When onboarding creates accounts, permissions, client records, or other persistent records, the firm needs a clean joiner-mover-leaver style model for tasks and responsibilities. A useful reference point is the Joiner-Mover-Leaver (JML) Guide, because it shows why vague ownership and weak offboarding logic usually produce the same control weaknesses that make onboarding hard to automate.
For teams that want a broader operating model, IAM and IGA Basics is useful because it frames the difference between simply doing the work and governing it well. In onboarding, that distinction matters whenever a workflow includes account creation, approvals, or entitlement changes that must be repeatable.
Risk and Threat Considerations
When a firm digitises an unclear onboarding process, it can turn minor friction into systematic error. The main risk is not just inefficiency, it is that the digital workflow may hard-code broken assumptions, duplicate mistakes at scale, and make exceptions harder to detect.
Failure mechanism: Missing process definition, unclear ownership, and informal workarounds create a workflow that automation cannot interpret consistently, so delays, omissions, and misrouted tasks become repeatable.
Impact: The firm may experience slower client onboarding, higher rework, weaker auditability, and greater exposure to access, confidentiality, or operational mistakes if the same ambiguity drives downstream systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Onboarding needs a defined baseline before automation can be reliable. |
| PM-9 — Risk Management Strategy | The decision to digitise should follow a clear risk-based assessment of process maturity. | |
| Recommendation — Document the current onboarding workflow before automating it. Gate digitisation on a documented risk assessment of workflow maturity. | ||
| ISO/IEC 27001:2022 | A.5.8 — Information security in project management | Digitising onboarding is a change project that needs process control and governance. |
| Recommendation — Treat onboarding digitisation as a governed change, not a tooling exercise. | ||
| CIS Controls v8 | CIS-5 — Account Management | Onboarding often creates accounts and access, so lifecycle discipline matters. |
| Recommendation — Standardise account-related onboarding steps before automating them. | ||
| NIST CSF 2.0 | GV.PO-01 — Policy Establishment | Clear policy and ownership are prerequisites for repeatable onboarding workflows. |
| Recommendation — Define onboarding policy and ownership before introducing automation. | ||
Practitioner Guidance
What to verify: Before digitising, verify that every onboarding step has a named owner, a single trigger, a defined input, and a clear completion test. If any step still depends on tribal knowledge, leave it manual until the rule is documented.
Decision rule: If the current process cannot be described in one consistent workflow without staff disagreement, treat digitisation as a process-design project first. Only automate once the firm can show that exceptions are understood, not just tolerated.
What good looks like: A ready process has fewer handoff surprises, fewer follow-up emails, and a visible queue of tasks that matches how the firm actually works. The best signal is not speed alone, but whether the firm can explain and measure each delay.
Practitioner takeaway: Digitisation is safest when it clarifies an already-disciplined onboarding process, not when it is used to hide uncertainty, ownership gaps, or inconsistent practice.
Related resources from NHI Mgmt Group
- What are the signs that a microfinance onboarding process is failing its identity checks?
- What are the signs that an onboarding verification process is failing?
- What are the signs that a bank's onboarding process is failing customers?
- What are the signs that an onboarding process needs stronger identity verification controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
