Because the provider can change availability, retention, routing or output behaviour without the buyer controlling that lifecycle. Security teams need repeatable controls and defensible evidence, so any hidden dependency that can change the result undercuts governance. The risk is concentration, not just outage.
Why external model dependencies create governance risk
External model use turns part of your security posture into a dependency you do not fully operate. The buyer may set policy, but the provider still controls service availability, data handling, routing, retention, and sometimes the model version or safety layer. That means governance has to cover not only the application, but the upstream service relationship that can alter results and exposure.
That is why the risk is not limited to outages. A model dependency can change silently, and a change in response quality, retention policy, or routing path can affect evidence, auditability, and the consistency of security decisions. If you cannot explain who can change those conditions, you do not fully control the control environment.
Where concentration risk appears in practice
Concentration risk shows up when one external provider becomes a shared control point for multiple workflows. If that provider degrades, throttles, reconfigures, or changes terms, the impact can spread across approval flows, detection workflows, support automation, or analysis pipelines. The security issue is that the organisation inherits correlated failure, not just a single point of service disruption.
Governance also weakens when the dependency is opaque. Teams often know the model name, but not the exact route a request takes, the subprocessor chain, the retention behavior, or the conditions under which outputs are logged or reused. The NIST Cybersecurity Framework 2.0 is useful here because it forces ownership, supplier visibility, and recovery thinking into the control conversation.
The same concern appears in vendor assurance work. If a provider’s availability or confidentiality commitments are central to a security workflow, then evidence has to show what the provider actually promised and what the buyer can verify. For that reason, the SOC 2 Trust Services Criteria often becomes a practical reference point for third-party governance expectations.
Why change control and evidence matter more than trust
Security governance depends on repeatability. If a model provider can alter output behavior, availability, or retention without the buyer having a clear change signal, then prior approvals, testing, and risk decisions may no longer be valid. That creates a governance gap because the organisation is relying on a moving target while still presenting the dependency as if it were stable.
This is especially important where the model output influences access, triage, content filtering, or incident analysis. A hidden dependency can turn a technical variation into a policy failure, because the control outcome is no longer deterministic enough to defend. The reader should think in terms of evidence, not intention, and treat the dependency as part of the governed system boundary.
For broader security program structure, the Identity Security Programme Guide helps frame how ownership, policy, and operating model decisions stay coherent when a third party participates in the control path. For governance maturity, the NHI Governance Maturity Model provides a useful lens on inventory, ownership, access, and lifecycle discipline where external dependencies are part of the operating surface.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 sets the technical controls, while SOC 2 (AICPA) and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-01 — Cybersecurity Supply Chain Risk Management Strategy | External model providers are upstream suppliers that can alter service risk and control outcomes. |
| GV.SC-04 — Suppliers and Third-Party Partners Are Managed | The question is about governance risk from an external provider dependency. | |
| GV.RM-01 — Risk Management Processes Are Established, Managed, and Approved | The issue is concentration risk and control drift from a governed external dependency. | |
| Recommendation — Document supplier change triggers, evidence requirements, and fallback paths for model dependencies. Define ownership, monitoring, and escalation for the model provider relationship. Include external model dependencies in risk review, approval, and reassessment cycles. | ||
| SOC 2 (AICPA) | CC9.2 — Risk Mitigation | Third-party model dependencies require mitigations for availability, retention, and behavior change risk. |
| Recommendation — Assess provider-driven change risk and retain evidence for mitigation decisions. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | External model dependencies are supplier relationships that can affect security controls and evidence. |
| Recommendation — Set security requirements and review obligations for the model supplier. | ||
Practitioner Guidance
What to verify: Verify whether the provider can change model versioning, retention, routing, logging, or safety behavior without a change notice that your team can evidence. If the answer is unclear, treat the dependency as an unmanaged control input rather than a standard service dependency.
Decision rule: If the model influences security decisions, approval paths, or compliance evidence, require documented owner, fallback path, and review triggers before it is accepted into production use. If you cannot explain how a provider change would be detected and assessed, the dependency is too opaque for governance comfort.
What good looks like: Good governance means the team can prove who owns the dependency, what was approved, what behavior is expected, and how drift will be detected. The objective is not zero external dependency, but bounded dependency with auditable control over the parts that matter.
Practitioner takeaway: External model risk is a governance problem when the provider can change the control outcome faster than your review, evidence, or rollback process can react.
Related resources from NHI Mgmt Group
- Why do single-model security review workflows create governance risk?
- Why do model upgrades create new security governance risk?
- Why do direct model to tool connections create governance and security risk as AI agents scale?
- Why do AI coding tools create governance and cost risk when they connect directly to external model providers?