Topics in this domain
- IT Governance vs. IT Management
- Board and Senior Management Roles
- IT Steering Committee
- IT Strategy and Business Alignment
- Balanced Scorecard
- COBIT
- ITIL
- ISO 27001/27002
- COSO: ERM and Internal Control
- Policies, Standards, Procedures, Guidelines
- IT Organizational Structure and Key Roles
- Segregation of Duties in IT
- Enterprise Architecture (Zachman, TOGAF)
- Risk Management Process
- Qualitative vs. Quantitative Risk Assessment
- Risk Responses: Mitigate, Transfer, Avoid, Accept
- Risk Appetite and Residual Risk
- Maturity Models (CMMI)
- KPIs and KGIs
- Outsourcing: Benefits and Risks
- Vendor Selection, Contracts, SLAs, Right to Audit
- Cloud and Offshore Governance
- Portfolio and Resource Management
- HR: Hiring, Training, Termination
- Legal and Regulatory Compliance
- Quality Management
Policies, Standards, Procedures, Guidelines
From “why” to “how”
Organisations write down how things should be done at four levels of detail. The higher the level, the shorter and more stable the document. The lower the level, the more specific it is, and the more often it changes.
| Document | What it is | Example |
|---|---|---|
| Policy | A high-level statement of management’s intent. Short, stable, technology-neutral | “Access to information is granted on a need-to-know basis.” |
| Standard | Mandatory, specific requirements that support a policy | “Passwords are at least 14 characters; MFA is required for remote access.” |
| Procedure | Step-by-step instructions for doing a task | “How to set up a new user in the HR system.” |
| Guideline | Recommendations where flexibility is fine | “Consider using a passphrase made of several words.” |
Think of keeping a house safe. The policy: “we keep the house secure”. The standard: “doors use deadbolts, and the alarm is set when everyone’s out”. The procedure: “last one out locks the back door, sets the alarm, locks the front door”. The guideline: “consider leaving a light on when you’re away”.
Policies, standards and procedures are mandatory. Guidelines aren’t. Each lower level must support the ones above it, with no contradictions.
Who approves what
| Document | Mandatory? | Typical approver or owner |
|---|---|---|
| Policy | Yes | Senior management or the board |
| Standard | Yes | Function head (CISO, CIO) |
| Procedure | Yes | Process owner |
| Guideline | No | Subject expert |
Top-down and bottom-up
- Top-down: policies come from business goals and corporate policy, then cascade down. Consistent and aligned across the organisation. This is the approach the exam prefers.
- Bottom-up: policies come from risk assessments of existing systems. Quicker and practical, but may be inconsistent and miss the bigger picture.
In practice, many organisations combine both.
Making policies work
- Write them from goals, risks and requirements.
- Approve them at the right level.
- Communicate them, with staff acknowledging they’ve read them.
- Implement them through standards and procedures.
- Enforce them: technical controls where possible, and consequences for breaking them.
- Handle exceptions formally: a business reason, a risk assessment, approval, compensating controls, and an expiry date. Untracked exceptions are a common finding.
- Review them regularly and after big changes.
Auditing policies
- Do the necessary policies exist, approved at the right level?
- Are they current?
- Have they been communicated, and do staff know them?
- Do standards and procedures support them?
- Are they actually followed? Test compliance; don’t just read the document.
Example. The security policy requires MFA for all remote access. The remote access standard, written later by the network team, exempts contractors. The auditor reports that the standard doesn’t support the policy, and that no exception was approved.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Who approves the information security policy? | Senior management (or the board) |
| Which document is not mandatory? | A guideline |
| Benefit of a top-down approach | Alignment with business goals and consistency |
| A policy exists but staff don’t know about it | Ineffective; communication and awareness are needed |
| The document specifying minimum password length | A standard |
In short
- Policies state management's intent; standards set mandatory specifics; procedures give step-by-step instructions; guidelines offer advice.
- Policies, standards and procedures are mandatory. Guidelines aren't.
- Policies are approved by senior management or the board; procedures are owned by process owners.
- Top-down development starts from business goals; bottom-up starts from risks in existing systems. Top-down ensures alignment.
- Policies must be communicated, acknowledged, enforced, and reviewed regularly.
- Lower-level documents must support the higher ones, with no contradictions.
Exam traps
- A policy that exists but isn't communicated or enforced is ineffective.
- Guidelines are optional; standards and procedures are mandatory.
- Policies don't name products or settings. That's a standard.
- The security policy is often the first document an auditor reviews in a security audit.
- Exceptions to policy must be formally approved, risk-assessed and time-limited.
Slides
Click the slide and use the arrow keys. F toggles full screen.
From 'why' to 'how'
Organisations write down how things should be done at four levels of detail. The higher the level, the shorter and more stable the document; the lower the level, the more specific and the more often it changes.
Top-down vs bottom-up