Information Security Policy and Governance
Governance is the direction and control exercised over information security at the top of the organisation; policy is management's written expression of intent. This domain tests the document hierarchy, who owns what, and how exceptions are handled. Questions often ask which document type a given statement belongs in, or who must approve something.
The document hierarchy
- Policy: management intent and mandatory rules - the what and why. Short, stable, approved at executive level.
- Standard: mandatory specific requirements implementing policy, such as a minimum password length.
- Baseline: minimum settings applied to a class of system or device.
- Procedure or work instruction: step-by-step guidance on how to perform a task.
- Guideline: recommended but non-mandatory advice.
Governance essentials
- Top management is accountable; the CISO sets direction and operates the ISMS; the asset owner classifies the asset and accepts risk for it; the custodian implements controls; users comply.
- Lifecycle: draft, consult, approve, publish and communicate, implement, monitor, review at least annually or after major change, then retire.
- A policy states purpose, scope, roles, rules, exceptions and consequences, plus owner, version, approval date and next review date.
- Exceptions are documented, risk-assessed, time-limited, approved by the risk owner and supported by compensating controls.
- Segregation of duties and least privilege are governance principles before they are technical settings.
- ISO/IEC 27001 requires leadership and commitment (clause 5), an information security policy (5.2), and continual improvement across clauses 4 to 10.
Worked example
A developer needs local administrator rights to test software. Refusing outright is wrong; silently granting rights is worse. The correct route is a documented exception naming the business need, the risk and the duration, a risk assessment, compensating controls (isolated test machine, time-limited account, logging), sign-off by the risk owner, entry in the exception register, and removal at expiry. One scenario demonstrates policy, ownership and auditability together.
Traps that cost marks
- Writing policy as a step-by-step procedure; the exam rewards the hierarchy.
- A policy with no owner, approval or review date - an automatic audit finding.
- Assuming a signed exception makes the risk disappear; residual risk stays on the register.
- Believing the IT department alone owns information security, rather than the business and top management.