Business Model and Technology Changes

To meet the COSO “Business Model and Technology Changes” requirement, you need a repeatable way to detect material business and technology changes, assess the risks those changes introduce to internal control, and document the resulting control updates before the change goes live. Build a change-to-risk workflow tied to product, IT, and third-party intake, with clear thresholds, owners, and evidence.

Key takeaways:

• Treat “new products, services, or technologies” as risk events that must trigger risk identification and internal control impact analysis (COSO IC-IF (2013)).
• Operationalize the requirement by connecting enterprise change management (product + IT + third party) to risk assessment, control design, and control testing.
• Auditors will look for consistency: defined triggers, documented assessments, and proof you updated controls (not just discussed risk).

Business model changes and technology adoption break controls in predictable ways: new revenue flows bypass approvals, data moves to new platforms without monitoring, and third parties introduce operational dependencies you did not account for. COSO expects you to treat these changes as inputs to your risk identification process, not as “business as usual” initiatives that happen outside of governance. The requirement is straightforward: identify the change, analyze how it affects internal control, and respond with updated controls and accountability (COSO IC-IF (2013)).

For a Compliance Officer, CCO, or GRC lead, the practical challenge is not understanding the concept. It’s building a reliable intake and decision trail across Product, Engineering/IT, Finance, Security, Procurement, and Internal Audit. The standard failure mode is a risk assessment that is periodic and static while the business changes weekly. Another failure mode is performing “risk reviews” that are not tied to decisions, so controls stay unchanged.

This page gives requirement-level implementation guidance: who must act, what triggers review, what steps to follow, what evidence to retain, and how to pass the “show me” questions in audits.

Regulatory text

Requirement (excerpt): “The risk identification process considers changes in the business model, including new products, services, or technologies that could significantly impact the internal control system.” (COSO IC-IF (2013))

Operator translation: You must have a defined process that (1) detects significant business model and technology changes, (2) evaluates the risks those changes create or amplify, and (3) updates internal controls accordingly. A risk assessment that ignores major initiatives, migrations, or new product launches does not meet the expectation, even if you run it on a calendar cadence (COSO IC-IF (2013)).

Plain-English interpretation (what the requirement means)

This requirement is about keeping internal control aligned with reality. Your internal controls were designed around a business model and technology stack that existed at the time. When either changes, controls can become incomplete, irrelevant, or bypassed.

Examples of “changes” that should trigger risk identification:

• Business model: entering a new market, changing pricing or billing methods, launching a new channel, offering credit/financing, moving from one-time sales to subscription, outsourcing a core process to a third party.
• Products/services: new customer-facing product, new fulfillment or claims process, new customer data types collected, new service tier with different SLAs.
• Technology: cloud migration, ERP replacement, new identity provider, adoption of AI models in operations, new payment processor, major API platform change, new CI/CD pipeline or infrastructure-as-code rollout.

Your goal is not to stop change. Your goal is to force risk identification and control impact analysis to happen early enough that management can choose controls and accept residual risk knowingly (COSO IC-IF (2013)).

Who it applies to (entity and operational context)

COSO is a framework expectation. In practice, this requirement applies wherever you rely on internal control for:

• financial reporting reliability,
• operational effectiveness,
• compliance obligations,
• safeguarding of assets and data (COSO IC-IF (2013)).

Roles commonly in scope

• Business owners / Product leadership: originate new products, pricing, customer journeys, and partnerships.
• Technology owners (CIO/CTO org): introduce platforms, architecture changes, and tooling.
• Finance/Controller: accountable for many control activities impacted by revenue, billing, and reporting changes.
• Security and privacy: own control domains that change with new tech, data, and third parties.
• Procurement / third-party risk management: manage changes that outsource functions or add technology providers.
• Internal Audit / Compliance / GRC: design the framework, challenge completeness, and validate evidence.

Operational contexts where this is frequently tested

• Product launch and go-to-market approvals
• IT change management and release governance
• Vendor onboarding and contract changes for critical third parties
• M&A integration and system consolidation
• Major process reengineering (order-to-cash, procure-to-pay, claims, KYC, onboarding)

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

1) Define “change events” and the trigger thresholds

Create a written standard that defines the events that must enter the risk identification workflow. Avoid vague language like “significant” without examples.

Practical trigger categories

• Business model changes: new revenue model, new regulated activity, new geographic footprint, new distribution channel.
• Material process changes: changes to approvals, reconciliations, handoffs, or segregation of duties.
• Technology changes: new systems in a critical process, major migrations, new authentication/authorization model, new data flows.
• Third-party changes: outsourcing a control-relevant function, switching critical providers, adding sub-processors for sensitive data.

Deliverable: Change-to-risk trigger matrix (one page) that maps change types to required assessments, owners, and required artifacts.

2) Build a single intake path (don’t rely on “someone will tell GRC”)

You need an operational choke point where changes show up consistently. Common anchors:

• Product lifecycle management (PLM) intake
• IT change management tickets
• Architecture review board (ARB)
• Third-party onboarding workflow

Minimum requirement: any one of these must automatically notify Risk/Compliance for defined trigger events. If you have multiple paths, make one the “system of record” for the risk decision.

Practical tip: If you run Daydream for third-party and change-related due diligence, configure your intake so new technology providers, sub-processors, and outsourcing arrangements automatically generate the right questionnaires, reviewers, and evidence requests, then link the results back to the change record.

3) Perform control impact analysis (CIA) for each triggered change

For each change event, require a short, structured assessment:

• What process/control objectives are affected (financial reporting, operational, compliance)?
• What changes in the flow of transactions or data?
• What new failure modes exist (fraud, error, outage, unauthorized access, incomplete logging)?
• What controls no longer work as designed (manual review removed, system report changed, access model changed)?
• What new controls are required (preventive/detective, automated/manual)?
• Who owns each control, and what is the testing approach?

Deliverable: Control impact assessment attached to the change record, with sign-offs.

4) Decide and document the response (accept, mitigate, transfer, avoid)

Risk identification is incomplete without a decision. Require one of:

• Mitigate: implement new or modified controls, update procedures, update monitoring.
• Accept: document rationale, residual risk, and approval by appropriate authority.
• Transfer: contract terms, insurance, or third-party obligations (still requires monitoring).
• Avoid: redesign the change.

Deliverable: Risk treatment decision with named approver and conditions (for example, “go-live contingent on logging control deployment”).

5) Update your control inventory and testing plan

If you maintain an internal control matrix, control library, or SOX-style mapping, update it:

• new/modified control description,
• frequency,
• evidence produced,
• system(s) involved,
• control owner,
• test steps.

Deliverable: Updated control documentation plus a testing plan update (even if testing is lightweight at first).

6) Verify go-live readiness and post-implementation validation

Controls often fail after deployment due to configuration drift and incomplete adoption. Require:

• pre-go-live checklist confirming required controls are implemented,
• post-go-live validation that evidence exists and the control operated at least once.

Deliverable: Go-live control readiness checklist and post-implementation review notes.

Required evidence and artifacts to retain

Auditors and examiners usually want a clean chain from change → risk identification → control update → proof of operation. Keep:

• Change request record (product/IT/procurement ticket) with dates, scope, systems, owners
• Trigger determination (why it did or did not require assessment)
• Completed control impact assessment
• Risk treatment decision and approvals
• Updated policies/procedures (if changed)
• Updated control inventory/control narratives/flowcharts (as applicable)
• Evidence of control implementation (configuration screenshots, IaC pull requests, access control configs, monitoring alerts)
• Evidence the control operated (reports, review sign-offs, logs, reconciliations)
• Third-party due diligence artifacts if a third party is involved (security/compliance review outputs, contract clauses, SOC reports if collected, ongoing monitoring notes)

Retention rule of thumb: keep artifacts in the same system that tracks the change, or link them with stable references. Fragmented evidence is a common audit failure.

Common exam/audit questions and hangups

Expect questions like:

• “Show me how you identify business model and technology changes that could impact internal control.” (COSO IC-IF (2013))
• “What changes in the last period triggered a risk assessment? Which did not, and why?”
• “How do you ensure a new product launch includes control updates before go-live?”
• “How do you assess risk when adopting new technologies, including third-party platforms?”
• “Where is the approval that accepted the residual risk for this change?”
• “Prove the updated control operated after implementation.”

Hangups that slow teams down:

• No shared definition of “significant change”
• Risk reviews done too late (after build, right before launch)
• Lack of ownership for cross-functional controls (for example, Engineering builds it, Finance “owns” it, nobody tests it)

Frequent implementation mistakes and how to avoid them

1. Calendar-based risk assessments only
   Fix: Add event-based triggers tied to product/IT/third-party workflows (COSO IC-IF (2013)).

2. Assessing risk without changing controls
   Fix: Require a control impact section that must conclude with “control change required: yes/no” and an approver.

3. Treating technology change management as purely operational
   Fix: Include GRC review criteria for changes affecting financial reporting processes, sensitive data, identity/access, or logging/monitoring.

4. Ignoring third parties as “technology changes”
   Fix: Classify new critical providers and sub-processors as trigger events; link third-party due diligence results to the change record.

5. No evidence of operation
   Fix: Build evidence expectations into the control design. If a control produces no artifact, redesign it or add monitoring output.

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this specific COSO point of focus. Practically, the risk is indirect: if your risk identification process does not capture business model and technology changes, control failures show up downstream as reporting errors, security incidents, operational disruptions, and audit findings. COSO’s expectation is that risk identification keeps pace with change (COSO IC-IF (2013)).

Practical execution plan (30/60/90-day)

First 30 days (stand up the mechanism)

• Inventory your existing change intake paths (product, IT, procurement/third party).
• Define trigger categories and thresholds; publish the trigger matrix.
• Pick the system of record for change-to-risk tracking; define required fields and approvers.
• Pilot the control impact assessment template with one product change and one technology change.

By 60 days (make it repeatable)

• Train Product, IT, Finance, Security, and Procurement on triggers and expectations.
• Embed the risk/control impact step into the change workflow so it cannot be skipped for in-scope changes.
• Update your control inventory format to capture “change-driven controls” cleanly.
• Start post-implementation validation for completed changes; capture evidence gaps.

By 90 days (make it auditable)

• Run a retrospective: pull recent changes and confirm each was either assessed or formally exempted.
• Tune thresholds based on false positives/negatives.
• Create a dashboard view: changes assessed, controls updated, open actions, overdue validations.
• If you use Daydream, standardize evidence collection and reviewer sign-offs so each change package has a complete audit trail without chasing files across tools.

Frequently Asked Questions

What counts as a “technology change” for this requirement?

Treat it as any change that alters how a key process runs or how data is captured, processed, stored, or reported. New platforms, migrations, authentication changes, and major integrations commonly affect internal control and should trigger assessment (COSO IC-IF (2013)).

Do we need a full enterprise risk assessment for every product launch?

No. You need a right-sized risk identification and control impact assessment that matches the change’s potential effect on internal control. The audit expectation is a consistent trigger-and-review process, not maximum paperwork (COSO IC-IF (2013)).

How do we handle agile releases where changes are continuous?

Use release trains or feature flags as the trigger point, and require control impact assessment for epics/features that meet your thresholds. Pair it with post-implementation validation to confirm controls operated after deployment.

Who should approve risk acceptance for a change that affects controls?

The approver should match the risk domain and materiality, typically the business process owner with oversight from Compliance/GRC, and Finance for financial reporting impacts. Document the approver and rationale in the change record (COSO IC-IF (2013)).

What evidence do auditors want to see for “considered changes”?

They want traceability: a list of changes, proof each was evaluated against triggers, the completed assessment for in-scope changes, and proof the control update was implemented and operated. Meeting notes alone rarely satisfy this.

How do third parties fit into “business model and technology changes”?

Adding or changing a third party can be both a business model change (outsourcing) and a technology change (new platform or sub-processor). Treat third-party onboarding and material contract changes as trigger events and attach due diligence results to the assessment (COSO IC-IF (2013)).