Risk Identification and Analysis

The Risk Identification and Analysis requirement means you must continuously identify internal and external risks that could prevent your organization from meeting its objectives, then analyze those risks to decide how to manage them. To operationalize it fast, tie risks to specific objectives, use a consistent scoring method, assign owners, document responses, and keep evidence that decisions are reviewed and updated. (COSO IC-IF (2013))

Key takeaways:

• Risk work starts with objectives; if objectives are vague, your “risk assessment” will not hold up. (COSO IC-IF (2013))
• You need a repeatable method: identify risks across the entity, analyze likelihood/impact, choose responses, and track owners and actions. (COSO IC-IF (2013))
• Auditors look for traceability: objective → risk → analysis → response → monitoring evidence.

Compliance teams often inherit “risk registers” that read like generic threat lists and don’t connect to what the business is trying to achieve. COSO’s Risk Identification and Analysis requirement fixes that by forcing a clean chain of logic: define objectives, identify risks that threaten them across the entity, analyze those risks, then decide how each risk should be managed. (COSO IC-IF (2013))

For a CCO or GRC lead, the operational goal is simple: you want a defensible, repeatable risk assessment process that produces decisions people actually execute. That means risk identification cannot be a once-a-year workshop, and risk analysis cannot be a subjective debate that changes every time the room changes. You need a consistent taxonomy, scoring rules, documented assumptions, and clear ownership.

This page gives requirement-level implementation guidance you can put in place quickly: who should participate, what artifacts to produce, what “good” analysis looks like, and what exam and audit teams typically challenge. Everything is written to help you demonstrate that your organization identifies and analyzes risks “across the entity” and uses that analysis to determine risk responses. (COSO IC-IF (2013))

Regulatory text

Requirement (excerpt): “The organization identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed.” (COSO IC-IF (2013))

What the operator must do

• Identify risks tied to objectives, across the entity. You need a structured approach to capture risks that could prevent the organization from meeting defined objectives, not just risks in one department or one system. (COSO IC-IF (2013))
• Analyze risks in a consistent way. You must evaluate risks so you can prioritize them and decide on responses. “Analyze” means more than listing; it requires an assessment method you can explain and repeat. (COSO IC-IF (2013))
• Use the analysis to determine management actions. The output should drive decisions (accept, mitigate, transfer, avoid) with accountability and follow-through. (COSO IC-IF (2013))

Plain-English interpretation (what “good” looks like)

A compliant program can answer, with documentation:

1. What are our objectives?
2. What could stop us from meeting them (across the entity)?
3. How big is each risk and why do we think that?
4. What are we doing about each risk, who owns it, and by when?
5. How do we know this stays current as the business changes? (COSO IC-IF (2013))

If you cannot show the link from risks to objectives, or if analysis doesn’t drive decisions, the requirement is not met even if you have a long risk register.

Who it applies to (entity and operational context)

Entity types

• Organizations implementing internal control and enterprise risk practices. (COSO IC-IF (2013))
• Internal Auditors and assurance functions evaluating whether risk assessment supports internal control effectiveness. (COSO IC-IF (2013))

Operational context (where it lands in real life)

This requirement typically sits with:

• GRC / ERM (process owner and methodology)
• Compliance (regulatory/compliance risks, issue management linkage)
• Information Security (cyber and technology risks, control environment inputs)
• Finance / Controllership (financial reporting risks, if applicable)
• Business unit leaders (operational risks, ownership of responses)
• Third-party risk management (TPRM) (risks introduced by third parties that affect objectives)

“Across the entity” means you should not treat third-party, IT, privacy, fraud, HR, and operations risks as separate universes with incompatible scoring and no roll-up. You can keep domain-specific detail, but the enterprise view must reconcile them. (COSO IC-IF (2013))

What you actually need to do (step-by-step)

1) Lock the objective set (the anchor for the entire process)

• Gather the organization’s top objectives (strategy, operations, reporting, compliance).
• Write them as outcomes with clear boundaries (what success looks like; what timeframe the objective covers).
• Assign an executive owner per objective.

Artifact: Objective inventory (approved list), with owners and definitions.

2) Define risk statement standards (so risks are comparable)

Require a consistent format, such as:

• If [event/cause], then [impact on objective], resulting in [harm]. This prevents “risk = controls are weak” entries, which are audit findings, not risks.

Artifact: Risk statement guidance plus examples of acceptable and unacceptable risks.

3) Run entity-wide risk identification (not just a workshop)

Use multiple inputs so you don’t miss “unknown knowns”:

• Prior incidents and losses
• Audit findings and open issues
• Compliance monitoring results
• KPI/KRI trends
• Business change intake (new products, new markets, new systems, M&A)
• Third-party lifecycle events (new critical third parties, renewals, concentration)

Practical approach: run short working sessions by domain (security, privacy, operations, finance, third party) and then reconcile into one enterprise register.

Artifact: Risk universe / risk register draft with source notes (where each risk came from).

4) Analyze risk consistently (inherent, residual, and confidence)

At minimum, define:

• Inherent risk (before controls)
• Control strength / effectiveness assumption (what you believe exists and works)
• Residual risk (after controls)
• Confidence level (how strong the evidence is behind the rating)

A simple scoring method can be acceptable if it is consistent, documented, and used to drive decisions. Avoid scores that are purely subjective. Document rating rationales in plain language.

Artifact: Risk scoring methodology (definitions for likelihood and impact, rating scales, and how to resolve ties or disagreements).

5) Determine risk responses and document the decision

For each material risk, choose and record one:

• Mitigate: implement/strengthen controls with an action plan
• Accept: document why it’s within appetite and who approved acceptance
• Transfer: insurance or contractual transfer (often relevant for third-party and operational risks)
• Avoid: stop the activity or redesign the process

Link each response to:

• Owner
• Key actions
• Dependencies
• How you will measure progress

Artifact: Risk treatment plans, including approvals for acceptance.

6) Operationalize review and change management

Your risk profile changes when the business changes. Add triggers such as:

• Major system releases
• New critical third party onboarding
• Regulatory change impacting an objective
• Material incident, breach, or outage
• Reorganization or leadership changes

Use a standing risk forum (or integrate with an existing governance committee) to approve updates and resolve disputes.

Artifact: Governance charter, meeting minutes, decision log, and change-trigger intake records.

7) Connect it to your control environment and testing

Risk analysis should drive:

• Which controls are “key”
• What gets tested first
• Where you focus monitoring
• Where internal audit spends time

If your testing plan ignores your top risks, you will struggle to defend that risk analysis “determines how risks should be managed.” (COSO IC-IF (2013))

Artifact: Traceability matrix mapping objectives → risks → key controls → assurance activities.

Required evidence and artifacts to retain (audit-ready)

Minimum set most teams should keep:

• Objective inventory with ownership and approval
• Risk assessment methodology (scoring, definitions, governance)
• Risk register with inherent/residual ratings and rationales
• Risk response decisions, including acceptance approvals
• Action plans with owners and status
• Meeting minutes and decision logs for governance forums
• Evidence of periodic refresh or trigger-based updates
• Traceability artifacts (risk-to-control mapping, testing plan alignment)
• For third-party risks: criticality tiering and how third-party risks roll up to enterprise objectives

If you want this to run cleanly, a system like Daydream can help centralize objective-to-risk mapping, keep decision logs with approvals, and maintain version history so you can prove how risk analysis changed over time without manual spreadsheet forensics.

Common exam/audit questions and hangups

Expect challenges like:

• “Show me the objectives your risk assessment is based on.” (COSO IC-IF (2013))
• “How do you know risks were identified across the entity, not just in IT or Compliance?” (COSO IC-IF (2013))
• “Explain the difference between inherent and residual risk in your register.”
• “Where is the rationale for this rating, and what evidence supports it?”
• “Which risks were accepted, and who approved acceptance?”
• “How does this risk assessment change your control testing or monitoring plan?” (COSO IC-IF (2013))
• “When was this last updated, and what triggers cause an out-of-cycle refresh?” (COSO IC-IF (2013))

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Listing threats without tying them to objectives

Fix: Require every risk to reference at least one objective and include a plain impact statement (financial, operational, compliance, reporting). (COSO IC-IF (2013))

Mistake 2: Mixing risks, controls, and issues in one list

Fix: Separate objects:

• Risks (uncertain events)
• Controls (responses)
• Issues (control failures) Then link them with traceability.

Mistake 3: Purely subjective scoring (“red because it feels red”)

Fix: Define rating criteria, require rationales, and add a confidence field so low-evidence ratings are visible and can be prioritized for validation.

Mistake 4: No governance for disagreements

Fix: Put a decision-rights model in writing: who proposes ratings, who challenges, and who has final approval.

Mistake 5: Risk acceptance by default

Fix: Treat acceptance as a documented decision with explicit owner approval and a review date tied to change triggers. (COSO IC-IF (2013))

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat enforcement risk here as indirect: weak risk identification and analysis often results in control gaps, missed obligations, and poor governance evidence. The practical implication is exam friction and adverse audit opinions because you cannot show how risk analysis drives management action. (COSO IC-IF (2013))

Practical 30/60/90-day execution plan

First 30 days (stabilize the foundation)

• Confirm objective inventory and owners; resolve duplicates and vague objectives.
• Publish risk statement standards and a scoring methodology draft.
• Build the first enterprise risk register skeleton (objectives, risk IDs, owners, required fields).
• Stand up governance: a recurring risk committee or add risk decisions to an existing forum agenda. (COSO IC-IF (2013))

Days 31–60 (run identification and analysis end-to-end once)

• Execute risk identification sessions across business units and key functions.
• Reconcile overlaps and normalize risk statements.
• Score inherent and residual risk; capture rationales and confidence.
• Produce initial risk response decisions for top risks, including action plans and acceptance approvals where needed. (COSO IC-IF (2013))

Days 61–90 (make it durable and auditable)

• Build traceability: objectives → risks → key controls → monitoring/testing.
• Define change triggers and an out-of-cycle update process.
• Pilot reporting to leadership: top risks, movements, overdue actions, accepted risks.
• Run an internal challenge session (internal audit or second-line review) to test whether decisions are defensible and evidence is complete. (COSO IC-IF (2013))

Frequently Asked Questions

What does “across the entity” mean in practice?

It means risks are identified from all major parts of the organization and rolled up into a single view that leadership can use. You can keep domain risk registers, but they must reconcile to enterprise objectives and use a consistent analysis method. (COSO IC-IF (2013))

Do we need inherent and residual risk ratings?

COSO requires that you analyze risks to determine how they should be managed, and separating inherent from residual is a practical way to show that controls change the risk. If you only keep one rating, document what it represents and how control strength is factored. (COSO IC-IF (2013))

How detailed do risk rationales need to be?

Detailed enough that a reviewer can understand why the rating is reasonable without redoing the assessment. Capture the key assumptions, the main drivers of likelihood and impact, and what evidence informed the view.

How do third-party risks fit into the enterprise risk assessment?

Treat third-party risks as sources or amplifiers of enterprise risks tied to objectives (for example, operational resilience, data protection, regulatory compliance). Keep third-party criticality and concentration as explicit factors in analysis where they affect impact. (COSO IC-IF (2013))

Who should approve risk acceptance?

The owner accountable for the affected objective should approve acceptance, with governance visibility for material risks. Document the rationale and the conditions that would trigger reconsideration. (COSO IC-IF (2013))

Can we use spreadsheets and still meet the requirement?

Yes, if you can maintain version history, approvals, traceability, and evidence of updates. Many teams move to a platform like Daydream once spreadsheet governance becomes the bottleneck for auditability and cross-entity consistency.