Who is accountable when a regulated business fails to apply the required identification and due diligence checks?

Why This Matters for Security Teams

When a regulated business fails to apply required identification and due diligence checks, the issue is rarely just a process gap. It becomes a governance failure, a regulatory exposure, and often a records problem. Outsourcing onboarding or verification does not transfer accountability, because regulators assess who was responsible for the control outcome, not only who executed the task. That distinction matters across AML, KYC, privacy, and broader identity assurance obligations.

Security and compliance leaders should treat the question as one of control ownership, evidence, and oversight. Under the NIST Cybersecurity Framework 2.0, governance and risk management are not optional add-ons; they are part of how an organisation proves control accountability. The same logic applies when third parties, platforms, or managed service providers support the workflow. If the business cannot show who approved the process, which rule set applied, and how exceptions were handled, it will struggle to defend the control decision later.

In practice, many security teams encounter this only after a regulator, auditor, or fraud event has already exposed the missing evidence trail, rather than through intentional control testing.

How It Works in Practice

Accountability should be assigned at three levels: the business owner, the operational control owner, and the independent assurance function. The regulated entity remains responsible for the outcome, but named individuals or roles should own the design, operation, and monitoring of the identification and due diligence process. That includes verifying what checks are required, defining thresholds for escalation, and documenting when enhanced due diligence is triggered.

Practically, this means the onboarding workflow needs to be mapped to the applicable regulation, not just to internal convenience. Controls should identify what data is collected, how identity is verified, how sanctions or risk screening is performed where relevant, and what happens when information is incomplete or inconsistent. Evidence should show not only that checks exist, but that they are consistently applied and reviewed.

• Document the legal or regulatory basis for each check and the jurisdiction it applies to.
• Assign a control owner for policy, a process owner for execution, and an approver for exceptions.
• Retain audit evidence showing completion, escalation, and remediation decisions.
• Test samples regularly to confirm the control works in live operations, not just in design documents.
• Track third-party dependencies so outsourced activity is still subject to oversight and challenge.

For implementation discipline, align identity and access governance with control baselines such as NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access to customer data, onboarding systems, or approval functions needs tighter control. In organisations handling digital onboarding at scale, this can also intersect with non-human identities, workflow automation, and API-based verification services, which still require ownership and logging even if no human operator touches each case. These controls tend to break down when onboarding is fragmented across multiple teams and vendors because no single owner can evidence end-to-end control performance.

Common Variations and Edge Cases

Tighter due diligence often increases onboarding friction and operational cost, requiring organisations to balance customer experience against regulatory defensibility. That tradeoff becomes more acute in high-volume or cross-border businesses, where different jurisdictions impose different identification thresholds, retention rules, and escalation criteria. There is no universal standard for this yet, so current guidance suggests that firms should prioritise clear control ownership and documented decisioning over informal judgment.

Edge cases usually appear when the regulated business relies on a third party for identity proofing, document validation, or screening. In those cases, the vendor may perform the task, but the business still needs evidence that it selected an appropriate method, validated the vendor’s output, and retained the right to challenge failures. The same issue arises when a group-level policy exists but local operations apply it differently. If exceptions are allowed, they should be formally approved and periodically reviewed, not handled as operational shortcuts.

For teams building stronger assurance, the right question is not whether checks were outsourced, but whether the organisation can prove effective oversight. That is the point at which governance, operational resilience, and identity assurance intersect most clearly.

Related resources from NHI Mgmt Group

• Who is accountable when wallet-based customer due diligence fails?
• Who is accountable when enhanced due diligence fails to catch a high-risk relationship?
• How should security teams make NHI best practices usable across the business?
• Who is accountable when segregation of duties fails in regulated systems?