Entity-Level Risk Identification

Entity-level risk identification is the front door of an effective risk and control program. If your organization misses risks at the entity level, downstream controls, audits, and third-party due diligence often become reactive and fragmented. COSO’s expectation is straightforward: your risk identification process must consider both internal and external factors, not only what is happening inside your operations but also what is changing around you (COSO IC-IF (2013)).

For a CCO, Compliance Officer, or GRC lead, operationalizing this requirement means building a repeatable way to (1) gather signals, (2) structure them into a consistent risk taxonomy and set of risk statements, (3) assign ownership and accountability, and (4) connect risks to controls, compliance obligations, and reporting. Examiners and internal auditors rarely fail you for having the “wrong” risk list; they fail you for having a risk process that is informal, not repeatable, not evidenced, or disconnected from decision-making. This page gives you requirement-level implementation guidance you can execute quickly, with concrete steps, artifacts to retain, and audit-ready talking points aligned to COSO Principle 7’s point of focus (COSO IC-IF (2013)).

Regulatory text

COSO requirement (excerpt): “Risk identification considers internal factors (such as infrastructure, personnel, technology, processes) and external factors (such as economic, environmental, regulatory, technological changes).” (COSO IC-IF (2013))

Plain-English interpretation You must maintain a documented process that identifies risks to achieving objectives by scanning both:

• Internal risk drivers: infrastructure, personnel/skills, org changes, technology stack, processes, data quality, governance, incentives.
• External risk drivers: market/economic shifts, regulatory change, environmental events, geopolitical factors, and technology ecosystem changes (including dependencies).

What the operator must do

1. Define what “entity-level risk” means in your organization (enterprise objectives and material operational/compliance outcomes).
2. Run a structured identification process that explicitly covers internal and external factors.
3. Convert findings into a controlled output (risk register and supporting analysis) that drives action: control design changes, compliance priorities, and monitoring.

Who it applies to (entity and operational context)

This applies to any organization using COSO as its internal control framework reference point and to teams responsible for risk, compliance, or internal audit activities (COSO IC-IF (2013)). In practice, you should treat it as enterprise-wide and cross-functional:

Common ownership models

• First line inputs: business unit leaders, IT, security, finance, product, operations, HR, procurement/third-party management.
• Second line coordination: compliance/GRC/risk management (you).
• Third line challenge: internal audit (independent assessment).

Where it shows up operationally

• Annual planning (audit plan, compliance plan, control testing plan)
• Major change events (M&A, new product launch, new markets)
• Third-party onboarding and critical third-party reviews (external dependency risk)
• Incident postmortems (feeding new risks back into the register)

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

Step 1: Set scope and objectives (make it auditable)

Create a short Entity-Level Risk Identification Standard (a few pages) that defines:

• Scope: enterprise objectives, covered legal entities/business lines, in-scope risk types (operational, compliance, financial reporting, technology, third party).
• Roles: who proposes risks, who approves, who owns mitigation.
• Frequency and triggers: a scheduled cycle plus “trigger events” (examples below).
• Output: risk register fields, required metadata, and linkage requirements (controls, policies, KRIs, issues).

Practical tip: If you cannot explain your risk identification process on one page to internal audit, it is not operational yet.

Step 2: Build a factor checklist mapped to COSO’s internal/external split

Use a consistent checklist so you can prove you considered COSO’s categories (COSO IC-IF (2013)).

Internal factors checklist (starter)

• Infrastructure: data centers/cloud regions, network architecture, resilience patterns, physical access.
• Personnel: key-person risk, staffing adequacy, turnover in control-critical roles, training gaps.
• Technology: legacy platforms, privileged access model, SDLC, dependency management, identity and access.
• Processes: change management, incident response, financial close, customer onboarding, third-party onboarding, data handling.
• Governance: committee coverage, policy exceptions, incentive misalignment.

External factors checklist (starter)

• Regulatory: new or changing rules, regulator guidance themes, cross-border requirements.
• Economic: customer concentration shifts, inflation/interest rate exposure, cost pressures affecting controls.
• Environmental: location-based disruption risk, severe weather exposure for sites/critical suppliers.
• Technology change: new attack patterns, material SaaS changes, EOL software, critical upstream outages.
• Third-party ecosystem: concentration in key providers, subcontractor layering, geopolitical exposure.

Step 3: Collect inputs with a repeatable workflow

Your goal is a predictable “intake-to-register” pipeline.

Input methods that work in real teams

• Structured interviews with executives and control owners (scripted to your checklist).
• Workshops by domain (technology, compliance, operations, finance).
• Intake from existing sources: incident tickets, audit findings, control test failures, compliance monitoring results, third-party assessments, business continuity exercises.

Trigger events (define in your standard) Examples: significant org restructure, new regulator inquiry, major system migration, material outsourcing decision, launch into a new jurisdiction, serious incident. When a trigger occurs, open an “event-driven risk identification” cycle and log it.

Step 4: Translate signals into well-formed risk statements

Require risk statements in a consistent structure:

• If/when [driver/event], then [impact], because [root cause/control gap], affecting [objective].

Example:

• If a critical third party changes a key service feature without notice, then customer transactions may fail, because change notification and contingency plans are incomplete, affecting service availability objectives.

Step 5: Rate and prioritize risks (and document the rationale)

Define a simple rating approach you can defend. Keep it consistent across the enterprise:

• Inherent impact and likelihood (before controls)
• Residual impact and likelihood (after controls)
• Velocity (how quickly impact could materialize)
• Confidence (how strong your evidence is)

Audit hangup to avoid: teams record scores but cannot explain why. Require a short “rating rationale” field tied to evidence (incidents, audit issues, architecture notes, regulatory change summaries).

Step 6: Map risks to controls, owners, and action plans

For each material entity-level risk, assign:

• Risk owner (accountable leader)
• Key controls (prevent/detect/correct)
• Gaps/issues (open items from audits, incidents, control tests)
• Mitigation plan with due dates and dependencies
• Monitoring: KRIs, thresholds, and reporting path

This is where many programs fail: a risk register becomes a list, not a management tool.

Step 7: Establish governance and reporting

Create a documented review and escalation path:

• Working-level review (GRC + control owners)
• Management review (risk/compliance committee)
• Board or senior leadership reporting for top risks

Meeting minutes should show decisions: acceptance, mitigation funding, control redesign, or policy changes.

Step 8: Operationalize continuous updates

Entity-level risk identification is not a one-time project. Maintain:

• A change log of risk additions/closures and rating changes
• Evidence of external scanning (regulatory tracker, technology dependency reviews, third-party concentration reviews)
• Post-incident “risk register update” step in your incident management playbook

Required evidence and artifacts to retain

Keep artifacts that prove both coverage (internal + external factors) and execution (it ran, it drove action):

Core artifacts

• Entity-Level Risk Identification Standard (scope, roles, cadence, triggers)
• Risk taxonomy and definitions (even if lightweight)
• Risk register with required fields (owner, ratings, rationale, control mapping)
• Workshop/interview records: agendas, attendance, notes, outputs
• External factor scans: regulatory change log entries, third-party dependency list updates, technology lifecycle/EOL notes
• Governance artifacts: committee decks, minutes, decisions, approvals
• Change log: when risks were added/changed and why

If using Daydream Daydream can help by standardizing intake questionnaires across functions, maintaining evidence links inside each risk record (interview notes, tickets, third-party assessments), and generating audit-ready exports that show internal/external factor coverage without chasing attachments.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me how you identify risks at the entity level and how you ensure you consider external factors.” (COSO IC-IF (2013))
• “What triggers an out-of-cycle risk refresh?”
• “How do you ensure completeness across business units and critical third parties?”
• “Which risks changed this cycle, and what caused the change?”
• “How do identified risks drive control changes, testing priorities, or compliance monitoring?”

Hangups auditors often raise

• External factors were discussed but not evidenced.
• Risks exist, but no owner is accountable.
• Ratings appear arbitrary or unchanged despite incidents and environmental changes.
• No link between entity-level risks and key controls.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	How to avoid it
Treating risk identification as an annual workshop only	External and internal conditions change faster than annual cycles	Define trigger events and require event-driven updates with a change log
Mixing issues with risks	Issues are known failures; risks are forward-looking uncertainties	Keep both, but link issues to the risk(s) they inform
No explicit external scan	Violates the point of focus emphasis on external factors (COSO IC-IF (2013))	Maintain a simple external scan record: regulatory, technology, third-party ecosystem
Risk register doesn’t drive action	Looks like “paper compliance” in exams	Require mitigation plans, control mapping, and governance decisions
Overly complex scoring model	Teams stop maintaining it	Use a simple approach and demand rating rationale tied to evidence

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Practically, weak entity-level risk identification increases the chance you miss emerging compliance obligations, underestimate third-party concentration risk, and fail to anticipate control failures triggered by organizational or technology change. That gap tends to surface during audits, regulatory exams, and major incidents, when leadership asks why the risk was not identified earlier.

A practical 30/60/90-day execution plan

First 30 days: Stand up the minimum viable process

• Publish the Entity-Level Risk Identification Standard (draft is fine; approve through your governance).
• Define the internal/external factor checklist aligned to COSO.
• Create the risk register template with required fields and evidence-link expectations.
• Pilot one workshop with technology + compliance + operations and produce an initial top risk list.

Days 31–60: Expand coverage and make it governable

• Run structured interviews across each business unit and control-critical function.
• Add external scan inputs (regulatory change log entries, key third-party dependency review outputs).
• Assign risk owners and confirm acceptance criteria for risk ratings.
• Present top risks and proposed actions to the risk/compliance committee; capture decisions in minutes.

Days 61–90: Make it durable and exam-ready

• Connect top risks to key controls and testing/monitoring plans.
• Implement trigger-event workflow (e.g., “new jurisdiction,” “material outsourcing,” “major incident”).
• Set a routine reporting package (dashboard + narrative) and a change log discipline.
• Run an internal audit-style self-check: pick a risk and trace evidence from identification to mitigation to monitoring.

Frequently Asked Questions

What qualifies as an “entity-level” risk versus a process-level risk?

Entity-level risks threaten enterprise objectives or cut across multiple functions (e.g., governance, major technology dependencies, regulatory change readiness). Process-level risks sit within a single process and are usually managed inside that control environment, but they should roll up if they become systemic.

How do we prove we considered “external factors” without a large research function?

Maintain a lightweight external scan record tied to your risk cycles: regulatory change log entries, summaries of key technology dependency changes, and third-party ecosystem updates. The exam goal is evidence of a repeatable method aligned to COSO’s external factor expectation (COSO IC-IF (2013)).

Who should own the entity-level risk register?

GRC or Compliance typically administers it, but each risk needs a business owner with authority to fund and enforce mitigation. Administration without accountable ownership is a common audit finding.

How does entity-level risk identification connect to third-party risk management?

Third parties are a major external dependency, so concentration, substitutability, and subcontractor layering often belong in the entity-level register. Your third-party assessments should feed new risks or update ratings for existing ones.

Can we reuse our annual enterprise risk assessment (ERA) to satisfy this?

Often yes, if your ERA explicitly covers internal and external factors and produces evidence, ownership, and action tracking consistent with COSO’s point of focus (COSO IC-IF (2013)). If the ERA is mostly narrative without traceable artifacts, tighten the workflow and retention.

What’s the minimum evidence set to keep auditors moving?

A documented standard, a current risk register with owners and rationales, proof of internal/external factor consideration, and governance minutes showing review and decisions. Add traceability for at least a few top risks from identification through mitigation.