A policy that describes something the technology does not enforce is a statement of intent that will be quoted back at you after an incident.
Security policy has one job: to say what the organisation requires, in terms somebody can comply with and somebody else can verify. Most policy sets fail at one of three points, and none of them is the writing. They are unenforceable, unread or unmaintained.
- EnforceableOr it is a statement, not a policy
- ReadableWritten for the people bound by it
- OwnedA named owner per document
- GovernanceThe function added in CIS Controls v8.1
Eight things that separate a policy set from a folder of documents.
It says what is required, not what would be desirable
A policy that uses should throughout is a set of preferences. Where something is required, the policy says so and the organisation is prepared to enforce it. Where it is guidance, it belongs in a standard or a guideline rather than a policy. Conflating the two produces a document nobody can be held to and nobody can be measured against.
Every requirement is enforceable by something
Either a technical control enforces it, or a process detects breaches of it, or somebody accepts that it is unenforced and records that. A requirement with none of the three is a statement of intent that will be produced after an incident as evidence that the organisation knew what it should have been doing and was not.
It is written for the people bound by it
An acceptable use policy is read by everybody in the organisation and should be written accordingly. A cryptographic standard is read by three engineers and can be technical. Writing every document in the same register produces one set nobody outside IT reads and another that lacks the specificity engineers need.
Each document has a named owner and a review date
Policy decays silently. Systems change, obligations change, people leave, and the document continues to describe an organisation that no longer exists. A named owner and a review date on the front page is unglamorous and it is the mechanism that prevents a policy set from becoming historical.
The structure separates policy from standard from procedure
Policy states the requirement and rarely changes. A standard states how it is met and changes when technology does. A procedure states the steps and changes constantly. Collapsing all three into one document means the whole thing needs approval every time an operational detail changes, so it stops being updated.
Anything touching people is reviewed by the right functions
Acceptable use, monitoring, disciplinary consequence and communication supervision all have employment and privacy dimensions. Microsoft describes its own message review capability as built with privacy by design, with usernames pseudonymised by default, role-based access controls built in and investigators opted in by an administrator. Policy in this area needs legal and HR involvement rather than technical drafting alone.
Exceptions are a process, not an absence
Every policy set generates exceptions and pretending otherwise means they happen informally and invisibly. A documented exception process, with a named approver, a stated reason and an expiry date, converts an unavoidable reality into a governed one and gives you a record of where the requirements are not being met.
It supports the obligations you actually have
Policy is frequently the artefact an auditor, a regulator or a customer asks for first. Where the policy set maps to the obligations the organisation is measured against, that request is answered in one exchange. Where it does not, the same request produces weeks of mapping work under time pressure.
A policy is a commitment. An aspirational one is worse than no policy at all.
This is counterintuitive and it is the single most important thing to understand before commissioning a policy set.
- A policy stating that all systems are patched within thirty days, in an organisation that does not achieve that, has created a documented standard the organisation demonstrably fails. That document will be produced during an incident review, and its existence makes the position worse rather than better.
- The same is true of monitoring commitments nobody performs, review cycles nobody runs, and encryption requirements applied to some systems. Each is a statement that the organisation knew what was required and did not do it, which is a materially worse position than not having stated it.
- The correct response is not to avoid writing policy. It is to write requirements the organisation will meet, enforce what can be enforced technically, detect what cannot, and record deliberately where a requirement is aspirational and by when it becomes real.
- That produces a shorter and less impressive policy set, and a defensible one. We would rather deliver eight documents an organisation genuinely complies with than twenty that describe an organisation somebody hoped it would become.
Four things that make a policy set defensible rather than impressive.
We only write requirements you will meet
For each requirement we ask what enforces it, what detects a breach of it, or who accepts that it is unenforced. A requirement with none of those three either gets a control, gets a detection, gets an accepted exception with a date, or gets removed. That test alone shortens most draft policy sets substantially and improves all of them.
We separate policy from standard from procedure
Policy states the requirement and should rarely change. A standard states how it is met and changes with the technology. A procedure states the steps and changes constantly. Keeping them separate means an operational change does not require re-approving the policy, which is the mechanism that keeps a set current.
We write each document for whoever actually reads it
Acceptable use is read by everybody, so it is short, plain and specific about consequences. A cryptographic standard is read by engineers and can be technical. A policy set written entirely in the register of an auditor is complied with by nobody outside the function that wrote it, which is most of the organisation.
We build the exception process before it is needed
Exceptions are inevitable. Without a process they happen informally, invisibly and permanently. With one, each has a named approver, a stated reason and an expiry date, which means you have a live record of where your requirements are not being met and an obligation to revisit each one rather than forget it.
Six UAE situations where the policy set becomes the priority.
A regulated firm whose regulator asks for policy first
Policy is frequently the first artefact requested, and it is read carefully. Where the set maps to the obligations, the request is answered in one exchange. Where it was written from a generic template, the mapping exercise happens under time pressure and every gap between the document and reality is visible in the same reading.
A business responding to customer security questionnaires
Almost every enterprise questionnaire asks whether named policies exist, when they were last reviewed and who owns them. Those three questions are answerable in a sentence each when the set is governed properly and are uncomfortable when the review dates on the documents are several years old.
An organisation pursuing a certification
Management system standards are satisfied by demonstrable operation rather than by documentation alone, which makes an aspirational policy set actively counterproductive. The right approach is a set the organisation genuinely complies with, with evidence of operation, rather than a comprehensive one it aspires to.
An operator introducing monitoring of any kind
Monitoring policy has employment and privacy dimensions that technical drafting does not address. Microsoft describes its own message review capability as built with privacy by design, with usernames pseudonymised by default, role-based access controls, and investigators opted in by an administrator. Policy in this area needs legal and HR in the drafting rather than in review.
An organisation with a policy set nobody has updated in years
The most common engagement. The documents are competent, they describe systems that were replaced, and the review dates lapsed before the current team arrived. Refreshing is usually better than rewriting, because a set people half-recognise is adopted more readily than a new one nobody has seen.
A group standardising policy across several entities
A group policy set with entity-level standards underneath is usually the workable structure, because the requirement can be common while how it is met varies by jurisdiction, system and scale. Attempting one identical set across entities with genuinely different obligations produces documents that fit none of them.
How UAE organisations handle security policy.
| Feature | Enforceable and maintained | A comprehensive set, unmaintained | No formal policy |
|---|---|---|---|
Requirements stated clearly | Yes | Yes | No |
Requirements actually enforced | Yes | Partly | Not applicable |
Written for the intended reader | Yes | For an auditor | Not applicable |
Named owner per document | Yes | Rarely | No |
Review dates observed | Yes | No | Not applicable |
Policy, standard and procedure separated | Yes | Conflated | Not applicable |
Exception process exists | Yes | No | No |
Legal and HR involved where needed | Yes | Sometimes | No |
Maps to actual obligations | Yes | Partly | No |
Position if quoted after an incident | Defensible | Damaging | Weak |
Twelve documents, and what each one is actually for.
| Document | What it establishes | |
|---|---|---|
| Information security policy | The overarching commitment, ownership and how the rest of the set fits together | |
| Acceptable use | What people may and may not do, written for everybody rather than for IT | |
| Access control | How access is granted, reviewed and removed, and what privileged means | |
| Asset management | What counts as an asset, who owns it and how it is tracked | |
| Data classification and handling | The categories, and what each requires in storage, transit and disposal | |
| Data retention and disposal | How long things are kept and what is deleted, which reduces attack surface as well as cost | |
| Change management | What requires approval, from whom, and what emergency change means | |
| Incident response | Declaration, authority, escalation and notification obligations | |
| Business continuity and recovery | Objectives, responsibilities and the testing commitment | |
| Supplier and third-party security | What is required of suppliers and how it is assured | |
| Remote and mobile working | What is permitted, on which devices, and under what conditions | |
| Monitoring and privacy | What is monitored, by whom, under what safeguards and with what oversight |
Five steps, and the enforceability test happens during drafting.
- 1
Establish the obligations and the current position
What the organisation is actually required to meet, from regulation, contract, certification or customer demand. Then what policy exists today, what it says, who owns it and when it was last reviewed. Refreshing an existing set is usually preferable to replacing it, because familiarity aids adoption.
- 2
Agree the structure and the document set
Which documents are needed, how policy, standard and procedure are separated, and what each one covers. More documents is not better. The right set is the smallest one that covers the obligations and leaves nothing an auditor or customer will ask about unaddressed.
- 3
Draft, testing each requirement for enforceability
For every requirement, what enforces it technically, what detects a breach of it, or who accepts that it is unenforced and until when. Requirements failing all three are removed or downgraded. This test is applied during drafting rather than at review, because it changes what gets written rather than what gets deleted.
- 4
Review with the functions that need to see it
Legal and human resources for anything touching acceptable use, monitoring, privacy or disciplinary consequence. Business functions for anything affecting how they work. Technical review for the standards. A policy set reviewed only by IT and approved by IT binds only IT.
- 5
Publish, govern and set the review cycle
A named owner and a review date on each document, an approval route for changes, a documented exception process with approvers and expiry dates, communication to the people bound by it, and acceptance recorded where that matters. Then the first review scheduled rather than intended.
What organisations ask about security policy.
Fifteen questions to ask about the policies you already have.
Is it real
- Pick three requirements. Are they enforced?Technically, or by detection.
- Is there a requirement you knowingly fail?That is the risk.
- Does it say should where it means must?Preferences are not policy.
- Does it reference systems you still run?Policies outlive platforms.
- When was each document last reviewed?Check the front page.
Is it read
- Can a non-technical employee understand it?Acceptable use especially.
- How do new joiners receive it?And is acceptance recorded.
- How is a change communicated?Silent updates are not changes.
- Is it findable?Including when systems are down.
- Is it the right length?Length correlates with non-readership.
Is it governed
- Does each document have a named owner?A role, and a person.
- Who approves a change?And at what level.
- Is there an exception process?With approver, reason and expiry.
- Are current exceptions recorded?They exist whether or not they are.
- Does it map to your obligations?That is what an auditor asks.
Pick three requirements from your policy set and ask what enforces each.
If the answer for any of them is nothing, that requirement is a documented commitment with no mechanism behind it. Finding those before somebody else does is the entire point of reviewing a policy set.
Related Services
Explore more solutions that work great with this service
Virtual CISO Dubai
Security governance and accountability, not more tools
CIS Controls Assessment
Eighteen controls, assessed and re-assessed
Compliance as a Service
Keeping the position true between assessments
IT Risk Assessment
A short register with an owner against every risk
Incident Response Plan
Written, exercised, and findable when the network is not
ISO 27001 Certification UAE
The 2022 edition, and whether you should certify at all
UAE PDPL Compliance
Federal Decree-Law 45 of 2021 readiness and operations
IT Audit Services Dubai
Assessment, technical test or certification, scoped properly