Topics in this domain
- Exam Technique: Thinking Like a Risk Practitioner
- Aligning IT Risk Management with Business Strategy
- Organisational Structure, Roles and Decision Rights
- Risk Ownership and Accountability
- Segregation of Duties
- Risk Culture and Tone at the Top
- Ethics and Professional Conduct
- Policies, Standards, Procedures and Guidelines
- Policy Lifecycle, Exceptions and Enforcement
- Business Process Review: Ownership and Criticality
- Identifying and Valuing Organisational Assets
- Embedding Asset Management into Risk Governance
- Enterprise Risk Management: Purpose and Principles
- The Risk Practitioner's Role in ERM
- The Three Lines Model and Risk Oversight
- Risk Management Frameworks: ISO 31000, COSO ERM, NIST and COBIT
- Applying a Framework: the Risk Management Life Cycle
- Risk Appetite, Tolerance and Capacity
- Establishing and Maintaining the IT Risk Profile
- Making Risk-Based Business Decisions
- Legal, Regulatory and Contractual Requirements
- Connecting Governance to Risk Outcomes
Policies, Standards, Procedures and Guidelines
The hierarchy
What goes where
| Document | Example | Mandatory? |
|---|---|---|
| Policy | Access is granted on a need-to-know basis | Yes |
| Standard | MFA for all remote access; 14-character passwords | Yes |
| Procedure | How to request and approve access in the HR system | Yes |
| Guideline | Consider a password manager | No |
Policies carry risk appetite
When the board says it has a low appetite for data loss, the policy framework is how that becomes real: a data protection policy, encryption standards and handling procedures. Without it, appetite stays a statement on paper.
What makes a good policy
- Approved by senior management.
- Short, clear and technology-neutral, so it stays stable.
- A named owner and a review date.
- Realistic: people can actually follow it.
- Supported by standards, procedures and an exception process.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Who approves policy | Senior management or the board |
| Where specific technical requirements belong | Standards |
| Which document is advisory | Guidelines |
| Why keep policies high level | So they stay stable as technology changes |
In short
- Policies state management's intent and are approved by senior management; standards, procedures and guidelines support them.
- Policies, standards and procedures are mandatory; guidelines are advice.
- Policies should be high level and stable; technology-specific detail belongs in standards.
- The policy framework is how risk appetite and control requirements reach everyday work.
- Policies need owners, review dates and an exception process to stay useful.
Exam traps
- Putting technical settings in the policy, so it needs constant re-approval.
- Treating guidelines as mandatory.
- Having policies approved by IT staff instead of senior management.
- Writing policies that can't realistically be followed.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The hierarchy
1 / 8