They should look for three signals: verification decisions are repeatable, enhanced due diligence triggers are documented and defensible, and periodic reviews happen when risk changes. If the programme cannot show when identity evidence was refreshed, it is relying on static onboarding rather than continuous governance.
Why This Matters for Security Teams
customer due diligence is only useful if it produces decisions that are consistent, explainable, and refreshed when risk changes. In practice, that means firms need evidence that verification is not just a one-time onboarding exercise but a controlled process with triggers, review cycles, and escalation paths. For identity-heavy programmes, this also intersects with NHI governance because credentials, service accounts, and automated workflows often carry the same trust assumptions as customers once they are accepted into downstream systems. NHI Mgmt Group notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that static trust is brittle. The control question is whether the programme can prove it adapts. Guidance from FATF Recommendations — AML and KYC Framework and NIST SP 800-53 Rev 5 Security and Privacy Controls supports a model where customer risk is reassessed, not assumed to remain constant. In practice, many firms discover weak due diligence only after fraud, sanctions exposure, or account abuse has already shown the process was not keeping pace with risk.
How It Works in Practice
Effective due diligence programs work as a chain of evidence, not a single approval event. A firm first establishes what evidence is required for onboarding, then defines which signals should trigger enhanced due diligence, then documents how reviews are repeated and by whom. That creates a defensible record of why a customer was accepted, restricted, escalated, or exited. The practical test is whether a reviewer can reconstruct the decision from the file without relying on tribal knowledge.
A strong programme usually checks for:
- Repeatability, meaning different reviewers reach the same outcome from the same evidence set.
- Risk-based triggers, such as ownership changes, adverse media, geolocation shifts, unusual transaction patterns, or entity structure changes.
- Evidence freshness, so identity data, beneficial ownership details, and source documents are revalidated on a defined schedule or event basis.
- Escalation discipline, where exceptions are recorded and approved rather than handled informally.
This is where identity governance and lifecycle control matter. The logic is similar to the control expectations in the Ultimate Guide to NHIs: if access and trust are not periodically revalidated, organisations end up relying on stale assertions. For firms that use automation in onboarding or monitoring, governance should also cover model or ruleset changes so that screening logic itself is auditable. Current guidance suggests aligning this work with documented control families in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around assessment, accountability, and continuous monitoring. These controls tend to break down when customer records are fragmented across multiple business units because no single team owns the full review history.
Common Variations and Edge Cases
Tighter due diligence often increases onboarding friction and review workload, requiring organisations to balance fraud prevention against customer experience and operational capacity. That tradeoff becomes more visible in correspondent banking, platform ecosystems, and cross-border relationships where beneficial ownership is opaque or source documentation varies by jurisdiction. There is no universal standard for this yet, so firms should be explicit about where judgment is allowed and where it is not.
Edge cases usually involve customers that are low-risk at sign-up but become high-risk later through ownership changes, transaction anomalies, or exposure to higher-risk geographies. In those cases, the question is not whether the original file was complete, but whether the programme detected the shift quickly enough to reopen due diligence. For NHI-linked workflows, the same issue appears when an automated customer lifecycle process depends on long-lived service accounts or API keys; those technical identities must be governed separately, or the customer record may look current while the underlying access path is stale. The NHIMG research base in the Ultimate Guide to NHIs highlights how often organisations lack full visibility into those identities, which makes stale trust harder to detect.
A useful maturity test is simple: if a firm cannot show when evidence was refreshed, who approved the decision, and what changed since the last review, then the programme is performing paperwork rather than due diligence.
Related resources from NHI Mgmt Group
- How can teams tell whether front-channel logout is actually working across applications?
- How can teams tell whether data classification is actually working?
- How can teams tell whether access governance is actually working?
- How can organisations tell whether SOX access governance is actually working?
