Paperwork-only programs usually fail because auditors look for execution, not just written intent. If policies are not linked to actual checks, escalations, and evidence retention, firms cannot show that risk decisions were made consistently. The control gap becomes visible in onboarding, transaction review, and issue remediation. A policy without operating procedures is usually just a liability on paper.
Where Paper Compliance Programs Fail Under Tranche 2 Review
A Tranche 2 program breaks the moment written policy stops being a living control system. In practice, the weakest point is usually not the policy text itself but the absence of routine checks that prove the policy is being followed at onboarding, during transaction review, and when issues are escalated. Regulators and auditors tend to look for evidence of execution, not just statements of intent, because a paper control cannot reliably demonstrate consistent decision-making or timely remediation. For financial crime and conduct programmes, that gap quickly turns into a credibility problem across the whole control environment.
The practical issue is that paperwork can describe who should approve, review, or escalate, but it does not show that those steps happened on the right cases, at the right time, with the right exceptions recorded. If a compliance team cannot produce logs, sampling results, review outcomes, and remediation trails, then it may be unable to show that the programme operated as designed. NIST Cybersecurity Framework 2.0 reinforces the broader principle that governance only works when it is translated into measurable operating practices, not static documentation. In practice, many firms discover this only after a reviewer asks for proof that the control was actually used, not merely written down.
Because Tranche 2 programmes often sit between policy, oversight, and frontline operations, the failure is usually structural: the control owner believes the document is the control, while the reviewer expects evidence of control performance.
How the Gap Shows Up in Daily Operations
A paperwork-first compliance programme usually breaks in the same places that day-to-day work creates exceptions. Onboarding is the first pressure point, because the team must prove that customer, counterparty, or employee checks were completed before access, approval, or release. Transaction review is the second, because monitoring needs defined thresholds, analyst actions, escalation triggers, and case notes that show why one item was cleared and another was held. Issue remediation is the third, because findings must be tracked to closure with owners, deadlines, and follow-up evidence.
When these activities are not embedded into operations, controls become improvisational. Analysts may know the policy, but not the exact trigger for escalation. Managers may approve exceptions, but not retain the rationale in a retrievable form. Audit trails may exist in scattered emails or spreadsheets, but not in a way that supports consistent review. That is why a written standard is not enough on its own: the organisation needs procedures, evidence capture, and supervisory review that make the control observable.
- Policies define the rule.
- Procedures define the step-by-step action.
- Evidence proves the step happened.
- Supervision confirms exceptions were handled consistently.
ISO/IEC 27001:2022 is relevant here because it treats governance as an operating system of documented processes, accountability, and continual review rather than a static policy file. The same logic applies to compliance programmes that must survive sampling, challenge, and repeat testing. NIST SP 800-53 Rev. 5 also aligns with this operational view by pairing control intent with assessment, monitoring, and evidence expectations. Where these elements are missing, the programme may still look complete on paper, but it will fail under testing because the organisation cannot prove control performance end to end.
The guidance breaks down when the organisation treats evidence collection as a retrospective cleanup task instead of a normal output of the workflow.
When Policies Are Real, and When They Are Just Decoration
Tighter compliance design often increases operational overhead, so organisations have to balance procedural discipline against speed and analyst workload. That tradeoff is genuine: the more complex the control path, the more important it is to separate meaningful approvals from bureaucratic noise.
There are a few common edge cases. First, a mature policy can still fail if the underlying process is too manual to generate reliable evidence at scale. Second, a control may exist in one business unit but not another, creating uneven execution that is hard to spot from policy documents alone. Third, a team may believe it has a control because it performs occasional reviews, but if the reviews are not scheduled, documented, and repeatable, the control is not operationally dependable. There is no consensus that more documentation improves assurance; in many programmes, better instrumentation and clearer ownership matter more than thicker policies.
For compliance areas tied to AML and KYC, the FATF Recommendations are a useful reminder that supervision, customer due diligence, and recordkeeping are expected to function as operational obligations, not aspirational text. That distinction matters most where reviewers need to see who did what, when, and on what basis. A policy can support the programme, but it cannot substitute for the control itself. Where the organisation cannot demonstrate repeatable execution, the usual result is a finding about control design, control effectiveness, or both.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST IR 8596 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC — Organisational Context | Tranche 2 controls must reflect actual operating context, not paper intent alone. |
| GV.RM — Risk Management Strategy | Paper-only programmes fail when risk decisions are not embedded in daily execution. | |
| Recommendation — Define control ownership and operating context so policy maps to real business processes. Align compliance controls to risk decisions that teams must execute and evidence. | ||
| CIS Controls v8 | 8 — Audit Log Management | Execution evidence depends on logs, review trails, and retained control artefacts. |
| 6 — Access Control Management | Day-to-day control failure often shows up where approvals and exceptions are unmanaged. | |
| Recommendation — Retain review and escalation evidence so control operation can be independently verified. Enforce approvals and exception handling through operational access control processes. | ||
| NIST SP 800-63 | 1.2.1 — Identity Proofing | Onboarding breakdowns often expose the gap between written procedure and actual checks. |
| 1.2.2 — Identity Verification | If verification steps are only documented, compliance cannot show consistent execution. | |
| Recommendation — Perform and record identity checks before granting onboarding-dependent approvals. Verify and retain proof of identity checks within the operational workflow. | ||
| NIST IR 8596 | 1.3 — Monitoring and Detection | Operational monitoring is needed to prove controls are active, not merely drafted. |
| Recommendation — Use monitoring to confirm controls are operating and to flag missing execution. | ||
Practitioner Guidance
What to prioritise: Treat the most failure-prone processes first, usually onboarding, exception handling, transaction review, and remediation closure. Those are the places where a policy-only programme most quickly exposes whether decisions are actually being made and recorded.
What to verify: Ask whether each key obligation has three things: a named owner, a defined operating step, and durable evidence that the step occurred. If any one of those is missing, the control is not yet operationally trustworthy.
Common mistake: Teams often confuse policy approval with control effectiveness. Approval proves the document exists; it does not prove the business is using it consistently or that exceptions are being managed in a way a reviewer can test.
Practitioner takeaway: A Tranche 2 programme becomes defensible only when policy, workflow, and evidence are designed as one system; if those layers are separated, the programme will usually fail at the first serious challenge.
Related resources from NHI Mgmt Group
- What breaks when boards rely on spreadsheet based access reviews instead of automated controls for Provision 29?
- Why do non-human identities create compliance risk even when policies exist?
- What breaks when compliance is based on policies instead of proof?
- What breaks when privacy compliance relies on consent banners instead of runtime enforcement?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
