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
Business Process Review: Ownership and Criticality
Why processes come first
A server failing only matters because of what stops when it fails. Business process review links IT assets to the work they support, so the risk practitioner can judge impact in business terms rather than technical ones.
The review step by step
Rating criticality
Criticality depends on the impact of failure on objectives, customers, finances and legal duties. It isn’t the same as technical complexity.
Hidden dependencies
- End-user spreadsheets in critical calculations.
- A single expert who knows how a system works.
- Suppliers and cloud services in the chain.
- Shared infrastructure such as identity and DNS.
Example. A logistics firm’s dispatch process looked well protected until mapping showed it relied on a route-planning spreadsheet maintained by one analyst. It became a top risk overnight.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| BEST basis for rating IT asset importance | Criticality of the business processes it supports |
| Who owns a business process | A named business manager |
| Purpose of mapping dependencies | Find what each process relies on, including hidden items |
| Output used for | Scenarios, BIA, continuity and the risk profile |
In short
- IT risk is felt through business processes, so understanding processes comes before assessing IT risk.
- Every key process needs one accountable business owner.
- Criticality depends on the impact of the process failing on objectives, customers, finances and legal duties.
- Mapping dependencies shows which systems, data, suppliers and people each process relies on.
- Process reviews feed risk scenarios, the BIA, continuity planning and the risk profile.
Exam traps
- Rating systems by technical importance instead of the processes they support.
- Assuming IT owns the process because it runs the system.
- Missing hidden dependencies such as spreadsheets, suppliers or key individuals.
- Reviewing processes once and never updating after change.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The review step by step
Rating criticality
1 / 8