Why Organisations Need a Risk Policy
Imagine two project managers in the same organisation. One classifies a AUD 200,000 potential cost overrun as "moderate" and decides to monitor it. The other classifies the same exposure as "high" and escalates it to the executive sponsor, triggering a formal response plan. Neither is wrong — they are simply operating without a common standard.
This is why risk policies and frameworks exist. They provide the organisation-wide rules of engagement for risk management: consistent definitions, clear accountability structures, agreed tolerance thresholds, and governance mechanisms that ensure risks are managed at the right level by the right people. Without them, risk management across an organisation's project portfolio becomes a lottery of individual judgment.
A risk policy is fundamentally a statement of how the organisation chooses to relate to uncertainty. It reflects the organisation's risk appetite, its governance structure, and its commitment (or lack thereof) to embedding risk management into daily operations.
What Is a Risk Policy?
A risk policy is a formal, documented statement of an organisation's approach to managing the risks it is exposed to. It varies across industries and, within an industry, from organisation to organisation based on the firm's capacity to absorb losses and the types of risk it faces.
Typical Structure of a Risk Policy
A well-constructed risk policy typically includes the following sections:
1. Introduction and Context — Sets out why the organisation requires a risk policy, the regulatory environment, and the strategic context in which risk management operates. 2. Aim and Intent — Defines what the organisation means by "risk," "risk management," and "enterprise-wide risk management." This section establishes the conceptual foundations that all subsequent processes will build upon. 3. Policy Objectives — Articulates what the risk policy is designed to achieve, such as protecting assets, ensuring regulatory compliance, supporting informed decision-making, and enabling strategic opportunity capture. 4. The Risk Management Process — Describes the organisation's adopted risk management approach, typically aligned to ISO 31000 or the PMBOK® Guide, including the sequence of risk identification, analysis, response planning, and monitoring. 5. Governance and Responsibilities — This is the most operationally critical section. It specifies who is accountable for what:
| Role | Responsibility |
|---|---|
| Risk/Audit Board | Strategic oversight of risk across the enterprise; sets risk appetite |
| Managing Director/CEO | Ultimate accountability for risk management effectiveness |
| Chief Financial Officer | Ensures financial risks are identified, quantified, and provisioned |
| Company Secretary | Maintains compliance with regulatory and governance requirements |
| Senior Management | Accountable for risk management within their divisions/portfolios |
| All Employees | Responsible for identifying and reporting risks within their scope of work |
How Risk Governance Works in Practice
The ALARP Principle: As Low As Reasonably Practicable
A central concept in risk governance — particularly in engineering, defence, and safety-critical industries — is the ALARP (As Low As Reasonably Practicable) principle. ALARP recognises that eliminating all risk is neither possible nor economical. Instead, risks should be reduced to a level where the cost of further reduction would be grossly disproportionate to the benefit gained.
In project risk management, ALARP translates into a practical governance rule: manage risks at the level in the project management structure where they can be controlled. A site supervisor should manage risks within their site authority. A project manager should manage risks within their project authority. Only risks that exceed the project manager's tolerance should be escalated to the programme or portfolio level.
Tolerance Thresholds and Escalation
Effective risk governance requires clearly defined tolerance thresholds that answer three critical questions:
Within the project: What are the tolerances in terms of cost, time, and quality? At what point must the project team escalate a risk to the project manager? Within the division: What is the division's tolerance for risks before they need to be escalated up the organisation? Within the enterprise: What is the organisation's overall risk appetite, and at what point does a risk require board-level attention?
| Risk Level | Cost Impact | Schedule Impact | Authority |
|---|---|---|---|
| Routine | < AUD 50K | < 2 weeks | Team Lead manages |
| Significant | AUD 50K – AUD 500K | 2–8 weeks | Project Manager manages |
| Major | AUD 500K – AUD 2M | 2–6 months | Programme Director escalation |
| Critical | > AUD 2M | > 6 months | Executive / Board escalation |
Note: Thresholds are illustrative. Each organisation must calibrate these to its specific risk appetite, project size, and industry context.
Risk Accountability vs. Risk Responsibility
A common source of confusion in risk governance is the distinction between accountability and responsibility: Accountability is singular and non-delegable. The accountable person answers for the outcome. In most frameworks, the project manager is accountable for overall project risk management. Responsibility is plural and delegable. Multiple people can be responsible for executing risk management tasks — conducting analyses, maintaining registers, implementing responses, and reporting status.
The Role of Organisational Culture
Risk policies exist on paper. Risk culture exists in behaviour. The gap between the two determines whether risk management actually works.
An organisation with a strong risk management culture has policies and procedures that require its workforce to go through disciplined risk planning, identification, assessment, and response throughout the project lifecycle. A mature organisation does not treat risk management as a separate process but rather embeds it into the entire project planning and control system. Risk becomes an integral part of how its people think.
The five competencies of a successful risk management organisation are: active training and development in risk planning; strong linkage between corporate and project planning; deep project experience in its industry; capacity to document and learn from project experience; and a workforce of strong functional managers who address quality as a risk reduction issue.
Conversely, organisations with poor risk cultures exhibit characteristic pathologies. Team members filter information to tell management what they think management wants to hear. "Unpleasant risks" are avoided in discussions. Risk registers are completed as compliance exercises rather than planning tools. Lessons learned are captured but never read.
Real-World Application: a large retail organisation Enterprise Risk Framework
Large Australian enterprises such as a large retail organisation align their organisational risk management practices with ISO 31000:2018, interpreted through an enterprise-wide risk management framework. The policy directive requires all business units — from store design through to end retail operations — to establish risk management practices within this framework.
The impacts of such a policy framework include an effective system for managing projects, protection of store assets from planned and unplanned events, reliable financial management with sound insurance practices, and the ability to identify risks at the earliest possible stage to minimise foreseeable costs.
This is a practical illustration of how enterprise-level risk policy cascades down to project-level risk management, providing project managers with both the authority to manage risks and the governance structure to escalate them when they exceed project-level tolerances.
The Pitfalls: Where Risk Policy and Governance Fail
Policy without enforcement. A beautifully documented risk policy that nobody follows is worse than having no policy at all — it creates a false sense of security. Over-centralised governance. If every risk must be escalated to the executive level, two things happen: executives become overwhelmed with minor risks, and project teams lose ownership of risk management. Under-specified tolerances. "Use your judgment" is not a tolerance threshold. Without clear, quantified thresholds for escalation, project managers either escalate everything (paralysing decision-making) or escalate nothing (until a crisis forces the issue). Confusing risk appetite with risk tolerance. Risk appetite is the broad level of risk an organisation is willing to accept in pursuit of its objectives. Risk tolerance is the specific, measurable boundary within a particular risk category. They are related but not identical. Ignoring the informal culture. Written policies describe the aspiration. Observed behaviours describe the reality. If the gap is large, the policy will be undermined.
Key Takeaways
- A risk policy is a formal statement of an organisation's approach to managing risk, typically structured around context, definitions, objectives, process, governance, and review.
- Risk governance establishes who is accountable for what, at what level risks should be managed, and when escalation is required.
- The ALARP principle (As Low As Reasonably Practicable) guides risk governance in engineering and defence contexts: manage risks at the lowest level where they can be controlled.
- Tolerance thresholds must be quantified and explicitly tied to escalation paths — vague thresholds produce paralysis or negligence.
- Organisational culture determines whether risk policies are lived practices or empty documents. The five competencies of a mature risk culture are training, corporate-project planning linkage, industry experience, organisational learning, and quality-focused functional management.
- Risk accountability is singular and non-delegable; risk responsibility is plural and delegable. Conflating them causes confusion.
The Risk Management Strategy: Embedding Risk in Business Systems
The Orange Book requires every organisation to have a risk management strategy that achieves two things:
- Establishes the principles by which risk will be managed
- Embeds those principles into the organisation's business systems — including strategy and policy setting processes
This is the difference between an organisation that has a risk management process (documented, filed, occasionally referenced) and an organisation that does risk management (integrated into every decision, every meeting, every project gate review).
For a heavy engineering project, this means risk management is not a standalone activity performed by a risk coordinator in isolation. It is woven into:
- Design reviews — where technical risks are assessed against acceptance criteria
- Gate reviews — where programme risks determine go/no-go decisions
- Daily stand-ups — where operational risks are surfaced and allocated
- Contract negotiations — where risk transfer and sharing arrangements are agreed
- Procurement decisions — where supplier risks inform sourcing strategy
What the Orange Book Teaches About Review and Reporting
Two Distinct Purposes
The Orange Book identifies two reasons for reviewing and reporting on risk management:
These are distinct activities, and neither substitutes for the other. A review that confirms all identified risks remain unchanged (Purpose 1) tells you nothing about whether the controls applied to those risks are actually effective (Purpose 2). Conversely, an assurance review that confirms controls are operating as designed (Purpose 2) does not detect new risks that have emerged since the last identification exercise (Purpose 1).
Three Requirements for the Review Process
The Orange Book specifies that review processes must:
- Ensure all aspects of the risk management process are reviewed at least once annually
- Ensure risks themselves are reviewed with appropriate frequency — with provision for both management's own review and independent review/audit
- Make provision for alerting the appropriate level of management to new risks or changes in identified risks, so that changes can be appropriately addressed
Why Review Completes the Cycle — and Why It Never Ends
The risk management cycle does not terminate after risks have been addressed. Controls degrade. New risks emerge. The external environment shifts. Stakeholder expectations evolve. The risk profile that was accurate six months ago may be dangerously outdated today. Review and reporting is the mechanism that closes the cycle, feeding insights back into identification, assessment, and control — and then the cycle begins again.
The Orange Book treats review not as an optional final step but as an integral, ongoing discipline that serves two purposes: monitoring whether the risk profile is changing, and gaining assurance that risk management is effective. These are complementary but distinct objectives. Knowing that risks have changed is not the same as knowing that your process for detecting and managing change is working. Both are essential.
For project managers in defence and heavy engineering — environments where programmes run for years, suppliers change, regulations evolve, and technologies mature or become obsolete — the review function is what prevents risk management from becoming a stale, historical document rather than a living management discipline.
Communication and Learning
Communication Is Not a Stage — It Is a Continuous Thread
The Orange Book is explicit: communication and learning is not a distinct stage in risk management. It runs through the entire process, from identification through to review, and serves multiple functions.
External communication: Horizon scanning depends on maintaining networks of contacts and information sources that enable early identification of changes affecting the risk profile. In defence, this includes intelligence about geopolitical developments, regulatory changes, supply chain disruptions, and technology evolution. Internal communication: Three internal communication requirements are identified:
Strategic alignment — everyone must understand the organisation's risk strategy, risk priorities, and how their role fits within that framework. Without this, risk management will not be consistently embedded and priorities may be inconsistently addressed.
Lesson transfer — when one part of the organisation encounters a new risk and devises an effective control, that lesson must be communicated to all others who may encounter the same risk. In manufacturing, a quality escape in one production cell must generate a lessons-learned bulletin for all cells performing similar operations.
Escalation and assurance — each level of management must actively seek and receive regular assurance about risk management within their span of control. This includes both routine reporting and mechanisms for rapidly escalating suddenly emerging risk issues. Stakeholder communication: Communicating with stakeholders about risk management gives them assurance about the organisation's governance and delivery capability, and manages their expectations about what the organisation can actually deliver.
Why the Orange Book Matters: From Whitehall to the Workshop Floor
Every organisation exists for a purpose — and every purpose is surrounded by uncertainty. In 2001, HM Treasury published a slim guidance document that rapidly became the foundational text for risk management across the entire UK public sector. Known simply as "The Orange Book," Management of Risk — Principles and Concepts established a framework so robust that its principles have been adopted far beyond Whitehall, influencing risk management practice in defence contracting, heavy engineering, infrastructure delivery, and project-based organisations worldwide.
For project managers operating in complex, high-stakes environments — armoured vehicle integration, naval shipbuilding, large-scale manufacturing facilities — the Orange Book provides something invaluable: a principles-based architecture for risk management that scales from strategic boardroom decisions down to operational shop-floor hazards. Unlike prescriptive standards that dictate exactly what you must do, the Orange Book establishes how to think about risk, then trusts organisations to adapt those principles to their specific circumstances.
This article — the first in a six-part series — unpacks the Orange Book's foundational model: what risk means in this framework, how the cyclical risk management process operates, and why the hierarchy of risk across strategic, programme, and operational levels is critical for organisations that need to integrate risk management vertically through every layer of decision-making.