A policy states how an institution intends to govern a subject. A control is an action designed to prevent, detect or address a defined risk. The two are connected, but they are not interchangeable. An approved policy can exist for years without anyone being able to show whether its key requirements operate in daily work.
Banks and NBFCs need a practical link between requirements, procedures, responsibilities and evidence. That link allows staff to act consistently and reviewers to assess whether the intended protection exists. It also makes change easier: when a requirement changes, the institution can identify the controls and instructions affected.
This article describes a method for translating policy into observable practice. The examples are control-design illustrations, not a replacement for institution-specific legal or regulatory requirements.
Define the purpose of each document
Separate policy, procedure, standard and working instruction where doing so helps users. A policy usually establishes principles, authority and boundaries. A procedure explains the sequence of work. A technical standard may define specific requirements, while a working instruction helps staff perform a particular task.
Avoid placing every operational detail in a board-level policy. Excessive detail makes routine changes cumbersome and can leave the approved document inconsistent with actual practice. Conversely, a policy that contains only broad aspirations gives staff little guidance on important decisions.
State the document's owner, approving authority, effective date, review basis and related documents. Users should know which version governs their work and where to find the procedures that implement it.
Translate requirements into control objectives
Begin with the risk or obligation being addressed. For example, a reporting policy may require complete and accurate submissions. The related control objectives could include complete source populations, approved definitions, reconciled figures and independent review of material judgements.
A control objective should describe the result the institution needs, not prescribe a vague activity. “Review the report” does not explain what the reviewer must establish. “Confirm that material balances reconcile to approved sources and unresolved differences are escalated” is more informative.
The Basel operational-risk principles provide background on governance, change and control environments. [1] Their practical value lies in treating controls as part of how work is managed, rather than as a separate collection of statements maintained only for assurance reviews.
Write controls that someone can perform
A useful control description identifies who acts, what they examine, when they act, the criteria they apply and the evidence retained. It should also explain what happens when the result is unsatisfactory. Missing any of these elements can make a control difficult to operate consistently.
Consider a payment approval. The description should identify the authorised approver, the information checked, relevant limits and the treatment of exceptions. A generic statement that “payments are approved” cannot establish whether the approval addresses the actual risk.
Keep descriptions proportionate. A simple control does not need a lengthy narrative, but it does need enough precision for a qualified replacement to perform it. The test is operational clarity, not document length.
Separate control design from operating effectiveness
Design effectiveness asks whether the control could address the identified risk if performed as intended. Operating effectiveness asks whether it actually ran as intended over the relevant period. A control can fail either test.
For example, a reviewer may consistently sign a report after submission. The control operates regularly, but its timing cannot prevent an incorrect filing. Conversely, a well-designed pre-submission review may fail because the assigned reviewer lacks time or access to the supporting data.
Testing should therefore examine purpose, population, timing and evidence. Counting signatures alone can miss both design weaknesses and incomplete operation. Record the basis of the conclusion so another reviewer can understand what was tested.
A worked example: an access-review control
Suppose a hypothetical lender's policy requires appropriate access to sensitive customer records. The initial control says that managers review access quarterly. In practice, managers receive a list of current users but cannot see their roles, recent transfers or privileged permissions.
The control needs better inputs. A revised process combines the user list, role definitions, employment changes and relevant exceptions. Managers record specific decisions, and the access administration team confirms that required removals or changes occurred.
The review is not complete when the spreadsheet is signed. Completion includes resolving the identified changes and retaining evidence. The example shows how a broad policy requirement becomes a sequence of testable actions with separate responsibilities.
Manage exceptions without normalising them
An exception should identify the requirement affected, the reason, the risk, the approving authority and the period for which it applies. Where appropriate, specify a compensating control and the condition for returning to the standard process.
Internal approval cannot waive an external legal or regulatory obligation. The exception process must distinguish a permitted deviation from an internal standard from a situation requiring another response under applicable rules. That distinction should be visible to the approver.
Review recurring and expired exceptions. A temporary arrangement renewed repeatedly may indicate that the standard is unrealistic, the underlying process is under-resourced or management has not resolved a material issue. Treat the pattern as a governance question rather than routine administration.
Control the policy lifecycle
Maintain a register that shows ownership, approval, effective dates, review triggers and dependencies. Scheduled review is useful, but material regulatory or business changes may require earlier revision. Link policy updates to the change-management process.
When a policy changes, assess related procedures, system rules, templates and training. Publishing a new PDF does not update those dependencies automatically. An implementation plan should identify which operational artefacts need revision and how consistency will be checked.
Withdraw obsolete versions from ordinary use while preserving history. Staff should reach the current approved document easily, and reviewers should still be able to establish which version applied to an earlier decision.
Make evidence useful and proportionate
Evidence should show that the control addressed its objective. A meeting invitation proves scheduling, not that a review occurred. A screenshot may show a configuration at one time, but not whether it operated throughout a period. Choose evidence that supports the specific conclusion.
Avoid retaining excessive personal or confidential data merely to demonstrate that a control ran. Where possible, use controlled references, summaries or restricted evidence locations. Access to assurance records should reflect their sensitivity.
Define retention and retrieval responsibilities. A control is harder to defend if its evidence exists only in an employee's mailbox or a temporary folder. The institution should be able to retrieve the relevant record without depending on the original operator.
Test changes and overlapping controls
Controls can become ineffective when products, systems or organisational responsibilities change. Include control impact in change assessments. A system migration may remove a report on which a manual check depends, even if the new system performs its primary business function correctly.
Also examine overlap. Several teams may believe another team checks the same issue, while none actually does. Alternatively, repeated reviews may consume time without addressing additional risk. Map responsibility and evidence to identify both gaps and unnecessary duplication.
The Basel compliance guidance recognises that effective arrangements can differ between institutions. [2] The objective is a coherent control environment that works for the institution's risks and responsibilities, rather than the largest possible control catalogue.
Allocate testing effort proportionately
Not every control requires the same testing frequency or sample size. Consider the consequence of failure, degree of automation, transaction volume, recent change and evidence from previous reviews. Document the reason for the testing approach so it can be challenged and updated.
A stable automated validation may need assurance over configuration and change controls, while a judgement-heavy manual review may need closer examination of individual decisions. Treating both with the same checklist can waste effort and miss their different weaknesses.
Also consider control dependencies. A manual review based on an unreliable system report may fail even when the reviewer follows the instructions. Testing should therefore examine the quality of important inputs, not just the final sign-off.
Proportionate testing makes assurance more useful by directing attention to how a control can actually fail.
Report weaknesses in a way that supports action
A control deficiency should state the risk, the observed condition, the cause and the proposed response. Distinguish a missing control from a failure to perform an existing one. They require different remediation.
Assign an owner and a testable completion criterion. If the action is to introduce a reconciliation, closure should include evidence of its operation and review, not only an updated procedure. Material changes may need a period of observation before effectiveness can be assessed.
Good policy management creates a continuous connection between written intent and observable behaviour. Clear objectives, executable controls, proportionate evidence and honest testing allow banks and NBFCs to see whether their policies are working, where they are failing and what needs to change.
PRIMARY REFERENCES
Sources & further reading
Primary-source references checked on 12 October 2026. Follow the relevant authority’s current text for applicability, amendments and commencement dates. International standards provide context and are not automatically identical to domestic requirements.