Learn
Most guidance about compliance documentation assumes a single working language. Gulf entities rarely have one. The policy that binds staff is written in Arabic, the evidence that proves the policy operates comes out of systems in English, and the assessor may ask for either. This article is about running that arrangement deliberately rather than discovering it during an assessment.
Decide which language binds
The first decision is which version of a policy is authoritative. If an Arabic policy and an English policy both exist and they drift, an assessor will find the difference and you will have no answer about which one staff were expected to follow.
Two workable models. Either one language is authoritative and the other is a published translation carrying a note saying so, or each policy is authoritative in exactly one language and the set is split by policy rather than duplicated. The second is usually less work, because it avoids maintaining two copies of the same document.
What does not work is two full sets maintained in parallel by different people. They separate within a year, and the separation is invisible until someone compares them.
Evidence does not need translating
There is a persistent belief that everything given to a regulator has to be in Arabic. In practice, configuration exports, system logs, screenshots of an administrative console and third-party audit reports are usually accepted in the language the system produced them in, because translating them would reduce their reliability rather than increase it. A translated log is a retyped log.
What does need to be in the language the assessment is conducted in is the material the entity authored: the policy, the risk methodology, the treatment plan, the assessment report. That distinction saves a large amount of unnecessary translation work, and it is worth confirming with your assessor early rather than assuming either way.
Keep the terminology fixed
The most common quality problem in bilingual compliance documentation is not grammar. It is inconsistent terminology: the same control concept translated three ways across three documents, so a reader cannot tell whether the documents are describing the same requirement.
Fix the vocabulary once. Write down the Arabic term you will use for control, risk, evidence, treatment, owner and residual risk, publish it with the policy set, and hold translators to it. This costs an afternoon and removes an entire category of assessment question.
Where a framework publishes official Arabic terminology, use that rather than your own. Regional frameworks issued in Arabic carry their own vocabulary, and an assessor reading your documents will be matching against it.
Make the pairing visible
The practical arrangement that works is per-document language with both languages visible in one list, so that a control shows its Arabic policy and its English evidence together rather than hiding one behind a language switch.
When you evaluate tooling, the test is simple: open a control, attach an Arabic policy and an English evidence file, then switch the interface language and confirm both are still visible. Platforms that filter content by interface language fail this, and the failure is easy to miss in a demo conducted entirely in one language.
What to agree with your assessor before you start
Three questions, asked early, remove most of the uncertainty: which language the assessment will be conducted in, whether authored documents are required in that language, and whether system-generated evidence is accepted as produced. The answers vary by regulator and sometimes by assessor, and getting them in writing at the start costs nothing.
