Controls and audit evidenceالضوابط وأدلة التدقيق

A control (الضابط) is a step you put in place to reduce one specific risk, like two people approving every large transfer. Evidence (الدليل) is the record proving the control actually ran, as opposed to being written in a policy.

A sound control (الضابط) begins with a specific risk and ends with a record someone absent can understand.

Why does a control that worked perfectly a year ago fail?

This is what surprises teams in an audit: a well-designed control, running for months, discovered to have stopped protecting anything without anyone noticing a collapse.

Because controls decay, and they rarely decay loudly.

Picture a rule that holds any transfer above fifty thousand for manual review. It was set when your customers averaged three thousand. Then businesses joined your customer base and the average became seventy thousand. The rule still works exactly as written, and now it stops everything, so the team began approving without reading because the queue was impossible.

The control exists on paper and protects nothing on the ground.

The other decay patterns are familiar: someone left and their role was never reassigned, a new system replaced the old one and was never wired into the check, a temporary exception was granted to a large customer and then forgotten into permanence.

Which is why proving a control exists is not enough. You have to prove it still works. Hence periodic testing against a sample, rather than a design document written once.

The question to ask of every control you own: when did we last confirm it actually catches something? If the answer is "when we wrote it", you do not know its current state.

Connect risk to action

A control prevents or detects a defined problem. “Manager review” is too vague. “Prevent one employee creating and approving a payment above SAR 100,000” is testable.

Every control needs four parts: risk, action, owner, and evidence. Without risk you cannot test relevance. Without an owner it does not run. Without evidence operation cannot be proved.

Separate unauthorised payment, wrong amount, and wrong beneficiary. They may need different controls.

Prevent and detect

Preventive controls stop an error first: amount limits, permission checks, or second approval.

Detective controls find what passed: daily bank reconciliation, monthly access review, or unusual-payment alerts. They show whether prevention was incomplete.

Use both. A payment limit may fail or an employee may hold the wrong role. Reconciliation provides another chance to detect the result.

Separate sensitive duties

Segregation of duties (فصل المهام) means one person cannot complete a high-risk operation alone. Treasury creates a payment file and another manager checks beneficiary and amount.

Separation fails if staff share credentials or one can change the other's role. Accounts must be personal, approvals independent, and evidence explicit.

Prepare holiday and emergency coverage through approved temporary access with automatic expiry and later review.

Design evidence with the control

A manually saved screenshot is weak. It may precede completion or follow a filter change. Automated evidence should record input, result, actor, time, and rule version.

A daily check can produce the population examined, exceptions, and the person closing each one. An access review can preserve the before-list, decisions, and approver. Evidence proves operation and outcome, not merely that a button exists.

Store it where the operator cannot alter it without a trail. Apply retention and access rules without exposing customer data broadly.

Make the audit trail (أثر التدقيق) readable

An audit trail records who did what, when, and why. It should connect user identity, role, operation, and decision in language another employee can understand.

Record important values before and after a change. If a transfer limit moves from SAR 50,000 to 500,000, preserve both values, approver, and reason.

Block deletion and editing. Corrections should appear as additional events so history remains rebuildable.

Define frequency and threshold

State when the control runs: every payment, daily reconciliation, or annual supplier review. Frequency should match risk speed.

Define thresholds precisely. A SAR 100,000 rule must say whether it applies per operation, day, or beneficiary, and how currencies convert.

Give exceptions a response target. A reconciliation break may need one business day; unknown administrator access may need immediate suspension. An alert is not complete until resolved.

Test operation and design

A well-designed control can fail to run for two days. A control can run daily while missing a new channel. Test design and operation separately.

Choose an explainable sample rather than one selected only by the owner. Inspect successes, failures, and exceptions. Record gaps, impact, remediation, and retest.

Review after product, system, or supplier changes. A document describing email approval is obsolete if work moved into an app.

Maintain a control register

Keep risk, owner, frequency, system, evidence, and latest test in one register linked to real logs and reports.

Identify key controls relied upon by management and licensing. Their failure needs faster escalation. Calling every action key removes priority.

Answer from the trail

An auditor may choose one March payment and ask who created and approved it and whether it matched the bank. The payment identifier should lead to entries, approvals, and reconciliation without searching personal messages.

Do not say the team always performs a task. Show policy, automated enforcement, operating samples, and exceptions. If one day is missing, disclose impact and repair instead of manufacturing late proof.

Compliance becomes operable when evidence is built into the product. Staff know their roles, systems prevent conflicts, exceptions surface, and history survives. Audit week becomes a structured reading of reality rather than a rescue project.