Developing and Communicating IT Risk Policies and Standards (CGEIT Risk Optimization)
Introduction
Within the CGEIT domain of Risk Optimization, developing and communicating IT risk policies and standards is the step that turns the board's risk appetite into something people can act on. Governance sets direction, and policies and standards carry that direction through the organization. Without them, risk management becomes inconsistent, personality-driven and impossible to audit. This guide explains why the topic matters, what it covers, how it works in practice, and how to approach exam questions on it.
Why It Is Important
1. It turns risk appetite into rules people can follow. The board and executive management define how much risk the enterprise will accept in pursuit of value. Policies and standards convert that appetite and tolerance into concrete expectations, so day-to-day decisions stay within agreed limits.
2. It keeps practice consistent. Business units, IT teams and third parties all identify, assess, respond to and report risk the same way. This makes risk information comparable and lets it be aggregated into an enterprise view.
3. It establishes accountability. Policies define roles such as risk owners, control owners, the risk committee and the CIO. When something goes wrong, it is clear who was responsible.
4. It supports compliance and assurance. Regulators, auditors and stakeholders expect documented, approved and communicated policies. Policies give auditors the benchmark against which compliance is measured.
5. It protects value. In COBIT terms, governance aims at benefits realization, risk optimization and resource optimization. Well-communicated risk policies keep IT-enabled investments from destroying value through unmanaged risk.
6. It builds a risk-aware culture. A policy that nobody knows about does not exist in practice. Communication and awareness turn written rules into behavior.
What It Is
Key definitions:
- IT risk policy: A high-level statement of management intent and direction. It is approved by senior management or the board, rarely changes, and states what must be achieved and why. Examples include the enterprise IT risk management policy and the information security policy.
- Standard: A mandatory requirement that supports a policy by specifying what must be done in measurable terms. Examples are a minimum password length or a requirement to encrypt all data at rest.
- Procedure: Detailed, step-by-step instructions describing how to comply with standards.
- Guideline: Recommended, non-mandatory advice.
- Risk appetite: The broad amount of risk the enterprise is willing to accept in pursuit of its objectives.
- Risk tolerance: The acceptable deviation from risk appetite, usually expressed through measurable thresholds.
The policy hierarchy:
Enterprise risk management policy → IT risk policy → IT risk standards → procedures and guidelines.
Typical content of an IT risk policy:
- Purpose, scope and alignment with enterprise risk management (ERM)
- Risk appetite and tolerance statements, or references to them
- Roles and responsibilities, including the board, risk committee, CRO, CIO, risk owners, the three lines of defense and internal audit
- Risk assessment methodology and frequency
- Risk response options: avoid, mitigate, transfer/share, accept
- Escalation and reporting requirements, including thresholds and KRIs
- Exception handling and risk acceptance authority
- Compliance monitoring, enforcement and consequences
- Review cycle and ownership of the policy itself
How It Works
Step 1: Understand context and drivers. Start from business strategy, enterprise objectives, regulatory requirements, the existing ERM framework and stakeholder needs. IT risk policy must align with ERM rather than sit in a separate silo.
Step 2: Define risk appetite and tolerance. The board and executive management set these, often with input from the risk committee. The policy references and operationalizes them.
Step 3: Draft policies and standards. Use recognized frameworks such as COBIT (including the EDM03 Ensure Risk Optimization and APO12 Manage Risk processes), ISO 31000, ISO/IEC 27005 and the NIST frameworks. Use a common risk language and taxonomy. Keep policies high level and technology-neutral, and put technical detail in standards.
Step 4: Consult stakeholders. Involve business owners, legal, compliance, HR, IT and internal audit. Consultation creates buy-in and makes the policy practical.
Step 5: Obtain formal approval. Policies should be approved by senior management, the board or a delegated committee. Approval signals tone at the top and gives the policy authority.
Step 6: Communicate and train. Communication must be targeted and repeated. It should include:
- Publication in an accessible repository
- Role-based training, since executives, risk owners, developers and end users need different messages
- Awareness campaigns
- Acknowledgement or attestation by staff
- Inclusion in onboarding and in contracts with third parties
- Leadership messaging that reinforces importance
Step 7: Implement and enforce. Embed the policy in processes, controls, project lifecycles and procurement. Define the exception process, under which risk acceptance must be documented and approved by an authority appropriate to the size of the risk.
Step 8: Monitor, measure and report. Use KRIs, compliance metrics and audit findings, and report to the risk committee and board.
Step 9: Review and update. Review periodically, typically annually. Also review when triggered by significant change, such as new regulations, mergers, new technologies like cloud or AI, major incidents or a shift in strategy.
Success factors: board sponsorship, alignment with business objectives, clarity and brevity, a clear owner, measurable standards, consistent enforcement and a feedback loop.
Common pitfalls:
- Policies written by IT in isolation
- Overly technical policies
- No communication after approval
- No enforcement or exception process
- Outdated documents
- Inconsistency with ERM
- Confusing policies with procedures
Exam Tips: Answering Questions on Developing and Communicating IT Risk Policies and Standards
1. Think like a governance professional, not a technician. CGEIT rewards answers about direction, alignment, accountability and value. Prefer the strategic answer over a technical fix.
2. Alignment comes first. If asked what should be done FIRST when developing an IT risk policy, look for options such as aligning with business objectives, enterprise risk appetite or the ERM framework. Implementing tools or controls is rarely the first step.
3. The board or senior management approves policies. Policy approval and risk appetite setting belong to the board or executive management. IT management, the security manager and auditors are not the right approvers.
4. Know the hierarchy. Policies are high level and mandatory. Standards are mandatory and specific. Procedures describe how. Guidelines are optional. Questions often test whether a requirement belongs in a policy or a standard.
5. Communication and awareness are often the missing piece. If a scenario describes a good policy that is not followed, the best answer is usually effective communication, training and awareness, backed by accountability. Rewriting the policy is usually wrong.
6. Risk owners are business owners. Accountability for risk sits with the business, while IT supports and advises. Be wary of answers that make IT accountable for business risk acceptance.
7. Exceptions need formal risk acceptance. Deviations from a policy should be documented, assessed and approved by the appropriate authority, with expiry dates and periodic review.
8. Watch for review triggers. When a scenario mentions a merger, new regulation, a major incident or adoption of new technology, the best answer often includes reviewing and updating risk policies.
9. Internal audit provides independent assurance. Audit evaluates compliance and effectiveness but should not own or write policies, because that would impair its independence.
10. Read qualifiers carefully. Words like BEST, MOST, FIRST, PRIMARY and GREATEST matter. Eliminate answers that are true but tactical, then choose the one that is broadest in governance terms and closest to business value.
11. Know the frameworks. COBIT EDM03 is about governance and ensuring risk optimization. APO12 is about management and managing risk. A question about setting direction points to EDM, while one about executing points to APO.
12. Value measurability. Good standards and policies support monitoring through KRIs and metrics. Answers that enable measurement and reporting to the board are usually strong.
Sample Question Walkthrough
Q: An enterprise has a comprehensive IT risk policy, yet business units continue to make inconsistent risk decisions. What should the IT governance manager do FIRST?
A. Implement a GRC tool
B. Rewrite the policy in more detail
C. Assess how the policy was communicated and whether roles and accountabilities are understood
D. Ask internal audit to enforce the policy
Best answer: C. The policy exists, so the likely gap is in communication and understanding. A tool (A) is premature. Rewriting the policy (B) is unwarranted. Audit (D) does not enforce policy.
Summary
Developing and communicating IT risk policies and standards turns board-approved risk appetite into clear, mandatory and enforceable direction. The process runs through alignment, drafting, consultation, approval, communication, enforcement, monitoring and review. In the exam, choose answers that emphasize business alignment, senior management ownership, clear accountability, effective communication and continuous review over purely technical or tactical actions.
