Policies, Standards & Procedures

Why this chapter matters

A bank's written control documents connect an obligation or decision to work that people and systems can perform. A policy can establish a principle while leaving an operator uncertain about what to do with an exception. A detailed procedure can be followed exactly while implementing an outdated requirement. The document hierarchy needs traceability in both directions: from authority to execution and from operating evidence back to the rule being satisfied.

This lesson follows an original privileged-access case at Malla Bank. Malla owns the service, Ramesh performs access administration, Gunaditya challenges the control design, and Sravanthi relies on accurate, protected account records. The case shows how a policy, standard, and procedure answer different questions, how a technology requirement is derived, and how operation is tested. Example review frequencies and expiry periods are internal training choices, not universal law.

Useful documentation reduces dependence on personal memory and informal conversations. It also preserves the authority for a decision when staff change. Its quality should be judged by whether the bank can operate consistently and explain its evidence, rather than by document length, signature count, or the number of files in a repository.

The plain meaning

A policy states the bank's approved direction, responsibilities, and boundaries. A standard defines more specific mandatory requirements within the bank's chosen hierarchy. A procedure describes how to perform an activity, including inputs, decisions, exceptions, and evidence. The exact naming convention varies between institutions; the important distinction is the authority and purpose of each document.

In the access case, the policy states that privileged access must be controlled and attributable. The standard defines the internal approval, authentication, logging, and review requirements for the relevant systems. The procedure tells an administrator how to request, provision, check, revoke, and investigate access. An implementation guide can explain a specific platform without becoming the authority for the underlying obligation.

Documents also need defined scope. A group access policy may apply to named entities and systems, while a platform procedure applies to one implementation. A scope gap should be visible rather than assumed away. An operator should know whether the instruction covers a supplier account, emergency access, or an account created through a different channel.

Current standards context

The Basel governance principles and 2024 Core Principles provide the international banking reference for governance and internal controls. Their relevance is clear responsibility and effective implementation; they do not impose the example document titles or review calendars below. Applicable local obligations and supervisory requirements need their own traceable interpretation. Basel governance principles; Basel Core Principles.

BCBS decisions have no supranational legal force. A bank should identify the binding requirement for the relevant jurisdiction and legal entity before presenting an international reference as law. An internal policy can add protection but cannot authorise noncompliance with an applicable obligation. Sources were reviewed on 2 October 2026. BCBS Charter.

The proposed access artifacts are original control-design illustrations. They do not claim that every bank must use one approval structure, retention period, or authentication implementation. A real design needs analysis of its systems, risk profile, contractual dependencies, and applicable information-security and privacy requirements.

Why written control documents exist

Documents establish what the bank expects, who has authority, and how exceptions are handled. They reduce inconsistent decisions across branches, shifts, and suppliers. A new administrator should not have to infer the access rule from the last person's email. A reviewer should be able to identify which requirement applied when an account was provisioned.

The document should also make ambiguity explicit. If different obligations appear to conflict, staff need a route to interpretation rather than permission to choose whichever is convenient. The interpretation record can state its scope, source version, reasoning, approver, and unresolved conditions. A procedure should implement the authorised conclusion without pretending the operator performed legal analysis.

Documentation supports continuity when key people are unavailable. An emergency access path needs an executable instruction and a subsequent review, not merely a policy statement that emergencies are permitted. The bank should test whether an alternate operator can follow the procedure with the information and authority available during the actual scenario.

Difference between policy standard and procedure

The policy answers why and within what boundaries the bank controls access. It identifies accountable management and the principle that sensitive changes require authorised, attributable activity. It should remain comprehensible to decision-makers and connected to risk appetite and obligations. Including every screen instruction makes it difficult to maintain that purpose.

The standard answers what must be satisfied for the defined systems. It can require a justified business need, approved privileges, separation of incompatible duties, protected credentials, recorded activity, and timely revocation under the bank's approved rules. Each requirement should be testable. Terms such as appropriate or strong need criteria or a route to judgement where they affect execution.

The procedure answers how the operator satisfies the requirements. It identifies request inputs, checks, tools, approval verification, provisioning steps, validation, evidence, and exception handling. The process should prevent an operator from confusing a received request with an authorised request. A platform manual can supplement the procedure, but the control checkpoints should remain clear if the interface changes.

Conflicts should be resolved by authority, not by document convenience. A procedure cannot silently weaken a standard, and a standard cannot silently rewrite the policy's boundaries. If implementation reveals an impractical requirement, the owner should propose a controlled change with risk analysis. Operating informally until the next scheduled review creates an unapproved policy in practice.

Policy ownership and approval

The owner maintains the policy's meaning, scope, implementation, and review. Contributors can include legal, compliance, risk, technology, and affected operations, but a list of consultees does not establish accountability. The approval authority should match the document's consequence and the bank's governance arrangements.

Approval should apply to a specific version. The decision record identifies significant changes, affected populations, implementation conditions, and disagreements requiring resolution. If a policy creates a requirement that systems cannot yet enforce, the approval should not be described as proof of compliance. The implementation plan needs owners, interim safeguards, and a realistic completion route.

The owner should monitor whether the policy remains relevant when products, systems, obligations, or organisational arrangements change. A calendar review is useful but does not replace event-driven review. An acquisition introducing a new access platform can create a scope or implementation gap long before the next scheduled policy cycle.

Link to law regulation and risk appetite

A requirements register can connect an obligation to the relevant internal policy clauses, standards, controls, and evidence. Each mapping should identify jurisdiction, legal entity, source, effective version, interpretation, and owner. An international standard can be recorded as a reference without being mislabelled a binding local requirement.

Risk appetite can inform choices above the legal floor. A bank might choose stricter access restrictions for a sensitive service because an inappropriate change is hard to reverse. That choice should be supported by risk reasoning and approved authority. It should not be presented as a legal requirement merely to make staff take it seriously.

A change in law can require changes across several documents and implementations. Updating the policy alone leaves the procedure, configuration, and training inconsistent. The impact assessment should follow the dependency chain and establish when the changed obligation applies. An internal waiver cannot postpone a binding effective date.

Procedure design for real operations

A usable procedure follows the actual workflow. For privileged access it begins with an identified requestor, system, role, business purpose, required duration, and relevant approvals. It then specifies how the administrator verifies authority, checks incompatible access, provisions the approved role, validates the result, and records evidence. The instructions should distinguish the requestor's assertion from an independently checked fact.

Exception paths are part of the process. The request may name an obsolete role, the approver may be unavailable, a supplier may need access urgently, or the tool may fail after partial provisioning. The procedure should identify safe stopping points and authorised routes to resolve uncertainty. Repeating the same command after an uncertain response can create unintended privileges if the operation is not understood.

The design should fit the working environment. Long instructions that cannot be followed during a short incident window need redesign, prepared capability, or an alternate controlled route. A procedure should not rely on access that the emergency operator does not possess. Testing with another operator can reveal hidden assumptions that the author overlooks.

Control mapping and evidence

A control map connects each significant requirement to an operating safeguard and the assertion it supports. Approval evidence supports authority; a role check supports privilege scope; a provisioning result supports implementation; activity records support attribution; revocation evidence supports removal. No single screenshot establishes all those facts.

The map should identify the control owner, trigger or frequency, population, action, evidence, exceptions, and dependencies. If a periodic review uses an incomplete account extract, it cannot support a conclusion about all privileged access. Population reconciliation is itself an important control assertion rather than an administrative detail.

Evidence should be sufficient and proportionate. An approval reference may establish who authorised access without copying sensitive customer data into the ticket. Logs need protection and usable retrieval. Retention and access rules depend on applicable requirements and approved policy; more retained material is not automatically better assurance.

Exceptions and waivers

An exception is a bounded departure from an internal requirement through approved authority. A waiver terminology may be used differently by banks, so the framework should define it. The record should state which requirement is affected, why the departure is needed, the exposure, duration, compensating safeguards, owner, and reassessment trigger.

The approver needs authority over the internal requirement and information about consequences. A business sponsor cannot grant access contrary to a binding legal restriction by labelling it urgent. Where a local obligation is unclear, the bank needs appropriate interpretation rather than an internal exception that assumes the obligation away.

Repeated exceptions can indicate that a standard is impractical, implementation is inadequate, or management is avoiding a deliberate policy change. Reporting should show their aggregate exposure and ageing. An expired exception is not silently renewed because the same person continues using the access. The owner should revoke, remediate, or seek an authorised reassessment.

Version control and change communication

Documents need a unique version, effective date, owner, approval history, and clear availability of the current instruction. Superseded versions can remain accessible for historical reconstruction while being clearly separated from operational use. A search result should not lead an administrator to a procedure that no longer applies.

A change notice should explain the operational difference, affected users, required actions, and implementation timing. Saying policy updated does not tell staff whether an approval route changed or an old exception must be reviewed. Material changes should connect to revised training, system configuration, and evidence requirements.

Historical evidence should identify the version used. An access request completed last month should be assessed against the obligation and internal rules applicable then, with appropriate consideration of later findings. Silently editing the old procedure destroys the bank's ability to reconstruct the decision and distinguish noncompliance from a subsequent change in requirements.

Training and attestation

Training should enable people to perform the decisions their role requires. An administrator can practise recognising incomplete approval, incompatible access, and uncertain provisioning. An approver can practise determining whether a requested privilege is necessary. A general awareness presentation cannot substitute for the operating skills needed at a consequential control step.

Attestation records what the person confirms. Reading a document is different from demonstrating competence or confirming effective operation. A statement that all staff completed training supports the completion assertion; it does not prove that every access request was handled correctly. Operating evidence and targeted testing are still needed.

Questions and failures during training can improve the procedure. If several operators misinterpret the same instruction, the bank should examine wording, interface design, and workload rather than assume individual carelessness. Feedback should lead to a controlled revision and a check that the revised instruction resolves the ambiguity.

Technology requirements from policy

A policy principle becomes a testable technology requirement through a defined assertion. Attributable privileged changes may lead to individual identities, controlled role assignment, recorded actions, protected logs, and an approved emergency path. The design should state what happens when identity, logging, or approval services are unavailable.

Requirements need negative and boundary tests. A valid authorised request should succeed; an unapproved request should fail; an expired privilege should no longer work; a partial failure should produce a known status and recovery route. Testing only successful provisioning leaves the most consequential control behaviour unexamined.

Configuration should remain aligned with the approved requirement after release. A default role introduced by a platform update can bypass the intended restrictions. The bank needs change controls and monitoring for material drift. A policy does not enforce itself because its name appears in a system specification.

Testing and auditability

Testing should establish design and operation over a defined population and period. The reviewer can trace a sample request from business need and approval through provisioned privileges to activity and eventual removal. They should also reconcile the privileged account population and test important exception routes. Convenient successful tickets alone give a narrow view.

A finding should identify the assertion not supported by evidence. If 12 accounts are absent from the review extract, the problem is population completeness, even if every included account was reviewed accurately. Sampling more included accounts does not fix it. The owner needs to identify the omitted route, correct the extraction, and reassess the affected population.

Independent assurance can examine the whole hierarchy: whether applicable requirements were interpreted, documents remained consistent, implementation matched them, and monitoring identified drift. Its scope and limitations should be explicit. A document-quality review should not be reported as assurance over live access operation.

Common document failures

A policy can remain technically approved but operationally obsolete after a system change. A procedure can contain a role that no longer exists or assume a report that has been retired. The owner should test important instructions against the actual operating environment, particularly after material changes.

Duplicated requirements can diverge. If several procedures copy the same standard verbatim, a future change may update only one. Referencing the authoritative requirement and retaining necessary local execution detail can reduce that risk. The link must remain accessible and clear enough for the operator to use.

An undocumented exception can become the normal workflow. Staff may use a shared emergency account because the ordinary access process is slow, then describe the practice as temporary for years. The response needs a usable controlled process and an assessment of exposure, rather than an instruction to read the same impractical procedure again.

Worked teaching story

Ramesh extracts 120 privileged accounts for the fictional servicing platform. Ninety are employee accounts, 20 supplier accounts, and 10 emergency accounts. The sum is 120. The current periodic review report includes only the 90 employee accounts, so it covers 75 percent of the population and omits 30 accounts. This is a training completeness calculation, not a universal review ratio.

The policy requires controlled privileged access across the service. The standard includes supplier and emergency access within its scope. The procedure's extract step is incomplete because it selects only employee records. Reviewing all 90 included accounts carefully would still not satisfy the full internal requirement.

Gunaditya asks for a population reconciliation and the omitted accounts' approval, privileges, activity, and expiry evidence. The team finds five supplier accounts past their internally approved expiry. It does not assume that all 30 omitted accounts are unauthorised, nor that the five necessarily caused misuse. The response separates known noncompliance with the internal expiry condition from uncertainty about activity and consequences.

Malla authorises the appropriate containment and remediation through the bank's fictional arrangements. The owner revises the extraction procedure, tests all three account types, communicates the change, and reviews the previously omitted population. The standard remains unchanged because its scope was already correct. An independent reviewer tests whether the revised process now supports the required assertions.

Learners should identify which document needs correction, what evidence supports population completeness, and why training completion would not resolve the extract defect. They should also write a bounded emergency-access instruction with subsequent review and explain which parts depend on applicable local requirements.

Common failure scenarios

A regulation changes, the policy is updated, but the platform continues using the old rule. The impact assessment should trace from the changed obligation through procedures, technology, training, and evidence. A new policy version alone does not demonstrate implementation.

An exception ticket contains an approval but no expiry or affected requirement. The bank cannot assess the departure or know when to reconsider it. The record needs a bounded decision and appropriate authority, not another signature on an incomplete request.

A reviewer concludes that access is well controlled because every document is present. The conclusion exceeds the evidence unless operation was assessed. Document presence, design adequacy, implementation, and continuing effectiveness are separate assertions.

Practical closing view

The hierarchy should connect approved intent with testable requirements and executable work. Each document needs clear authority, scope, ownership, and change control. Evidence should show that the intended control operated over the relevant population, including exceptions.

The access case demonstrates why a correct standard and a diligent review can still fail through an incomplete procedure. Trace the requirement to the activity and back to the evidence before concluding that the bank has met its internal or external obligation.

Official reference sources

The Basel governance principles, April 2024 Core Principles, and BCBS Charter support the international governance context. The access hierarchy, sample control artifacts, population, and example review choices are original teaching applications. No internal expiry, approval, or review frequency is presented as a universal regulatory requirement.