Choosing how much cloud and supplier concentration to accept and what exit readiness to maintain

Authority disclaimer. This page is an executive narrative. It does not establish requirements; the linked corpus governs. It is provided to support understanding, discussion, and decision-making by the governing body and accountable executive leadership (board, ELT, or senior management, as applicable). It creates no obligation, control, or assurance by itself. Its publication approval is an editorial act only and confers no authority over any corpus document. Where it differs from a corpus document, the corpus document prevails.

Cloud and supplier reliance concentrates. Each consolidation onto a single provider buys capability and simplicity while deepening a dependency, and the same question returns to leadership each time: for this concentrated reliance, does the organization accept it as it stands, reduce it while the relationship continues, fund the readiness behind a reversible exit, or end it? This page organizes that choice as four positions, in increasing order of distance from the provider.

1. Accept the concentration. The reliance stands as it is, under a formal, recorded, time-bound risk acceptance.
2. Treat while staying. The relationship continues while the treatment options the corpus defines are applied to the exposure.
3. Invest in exit readiness. The relationship continues, and the organization funds the contract rights, exit plans, and testing behind a practical exit.
4. Exit. The relationship ends.

These are positions taken per concentrated dependency, not one enterprise posture: the corpus's recording grain is the individual concentration finding (the concentration risk register records one finding per row, across the six concentration dimensions its Concentration dimensions section defines, one of which, service-class concentration, flags single-provider reliance in a critical service class such as cloud infrastructure). The four position names are this page's framing, not corpus vocabulary; the treatment options and controls that give each position its content are the corpus's, and the next section points to them. The framing is a composite claim, acknowledged in the limitations.

The choice is also wider than any one provider. The register's dimensions include the shared sub-tier dependency: separately contracted suppliers standing on the same underlying platform, so that a portfolio that looks diversified is concentrated one layer down. Visibility of that layer is a dependency of this decision, and the fourth-party and nth-party risk procedure defines the identification record for that layer (its Step 1).

• A register of concentration findings. The concentration risk register defines a concentration as multiple critical or material dependencies sharing a common attribute, records each finding with a treatment status and owner (its Register schema), and carries the operating expectations that route the highest-rated findings to the executive role it names and feed the supplier risk report to the governing-body level (its Operating expectations). Its Treatment options table is the corpus vocabulary for what can be done, from diversification through strengthened contingency and contractual protections to formal acceptance and exit.
• A ceiling and a monitoring floor. The third-party and supply chain risk standard places visibility of concentration risk across the supplier portfolio with the executive role its section 6.2 names, keys any single Tier 1 supplier's reliance in a service category to a concentration threshold approved at the level that section names, and requires technology concentration to be documented and managed (the same section). The supplier resilience monitoring standard feeds resilience signals into concentration analysis (its section 6) and names signals that breach materially and durably as an input to the exit decision (its section 5).
• Contract rights for exit. The cloud exit and data portability standard states as its purpose that the organization is not locked into any single cloud provider without a documented exit path (its section 1), and requires the four contract provisions its section 4 lists to be present before signature; a contract without them routes through the exception path its section 8 defines.
• Exit plans for a practical exit. The same standard requires an exit plan for every cloud service hosting the asset tiers its section 5 names, documenting the five elements that section lists, including the last date the plan was tested or validated, reviewed on the cadence it sets. Its section 7 names the triggers on which an exit plan must be activated.
• An impact basis for the choice. The business impact analysis procedure maps dependencies including cloud services (its Step 3) and records the recovery objectives against which a concentrated failure would be measured (its Step 5). The third-party standard makes the supply chain continuity assessment part of that analysis and escalates a sole-source Tier 1 supplier with no identified alternative to the level its section 7 names.
• An execution path when exit is chosen. The supplier exit and data return procedure defines the exit trigger types and a seven-step path from the exit decision through data return, deletion, access revocation, contract closure, and lessons learned; its step 2.7 applies the cloud-exit standard's requirements to cloud and SaaS suppliers. The supplier and cloud governance framework carries exit commitments as a contracting-stage obligation and exit as a lifecycle stage with its own evidence classes (its Supplier lifecycle table), and lists concentration risk and exit complexity among its risk classification criteria.
• A recorded route for acceptance. The risk appetite statement template defines the tolerance boundaries beyond which a risk requires escalation and treatment or formal acceptance at the level its Part 3 names. The risk acceptance procedure places acceptance of each residual-risk level with the authorities its Approval guidance names and bounds every acceptance in time under its Duration and renewal limits. The exception and risk acceptance policy governs approval (its section 4.2), duration and renewal (its section 4.3), and register tracking (its section 4.5); the register's own treatment-status vocabulary records an accepted concentration with a cross-reference to the exception register (its Register schema).

Each option takes one position on one concentrated dependency; a portfolio holds different positions on different dependencies at once.

• Accept the concentration. Acceptance is a recorded act, never a default: the corpus's route is a formal risk acceptance at the authority the risk acceptance procedure's Approval guidance names for the residual level, time-bound under the exception and risk acceptance policy's section 4.3, and cross-referenced from the register row's treatment status (the concentration risk register's Register schema). That recorded, expiring form is a prevention against acceptance by inaction. Acceptance changes the record, not the exposure: continued monitoring under the supplier resilience monitoring standard remains a dependency of the position staying sound, and the register's review cadence returns the acceptance for review.
• Treat while staying. The register's Treatment options table defines the corpus vocabulary this position draws on, including diversification, decoupling a shared sub-tier, strengthened contingency, geographic redistribution, and contractual protections. Each treatment carries the owner, plan, and target review date the Register schema requires, and the resilience signals the monitoring standard collects are evidence that a contingency claimed on paper holds in operation. The register's own structure carries the consequence: what is genuinely untreatable routes to acceptance or exit, never to silence.
• Invest in exit readiness. Readiness is a contribution to each of the other positions, because the exit option is only as real as the plan and the contract rights behind it, and an acceptance made with a practical exit path is a smaller decision than the same acceptance made without one. The cloud exit and data portability standard's contract provisions are a dependency of signature for new cloud contracts (its section 4). A current exit plan, complete against its section 5 elements and carrying its recorded last-tested-or-validated date, is a prevention against a forced stay when one of its section 7 triggers occurs. The consequence is a recurring cost: plans are maintained and reviewed whether or not an exit ever runs, and the plan's recorded last-tested-or-validated date is what the reader weighs against the corpus's review requirements.
• Exit. The register names exit as the treatment for a concentration that is unacceptable and untreatable, and the supplier exit and data return procedure governs its execution across its seven steps, with the supplier and cloud governance framework's exit stage naming the closure evidence. The consequences to weigh sit in the business impact analysis procedure's dependency map: the downstream systems, integrations, and processes a migration touches. Which position is right for any dependency remains entirely with the reader's organization.

Each question resolves against a corpus source already cited above; none introduces a new claim.

• Which findings does the concentration risk register record for the dependency in question, on which of the six dimensions its Concentration dimensions section defines, and are any rated at the levels its Operating expectations escalate to the executive role it names?
• Has the concentration threshold the third-party and supply chain risk standard's section 6.2 keys any single Tier 1 supplier's service-category reliance to been approved at the level that section names, and is the current reliance within it?
• Do the affected contracts carry the provisions the cloud exit and data portability standard's section 4 requires, and is every absence covered by an exception approved through its section 8 path?
• Does a current exit plan exist for each in-scope service, complete against the five elements the standard's section 5 lists, and what does each plan's last-tested-or-validated date show?
• What do the business impact analysis procedure's dependency map and recovery objectives record for the services concentrated on this provider, and has any sole-source Tier 1 supplier with no identified alternative been escalated per the third-party standard's section 7?
• Which shared sub-tier dependencies stand behind apparently separate suppliers, per the fourth-party and nth-party risk procedure's identification record?
• Where acceptance is proposed: who holds the acceptance authority for this residual level per the risk acceptance procedure's Approval guidance, and how does the acceptance stay time-bound under the exception and risk acceptance policy's section 4.3?

Each item below is an evidence class leadership can call for from management, and each is evidence for a named control or outcome.

• The concentration register extract for the dependency: its rows, dimensions, ratings, treatment status, and treatment owner, as evidence that the concentration is identified and under a recorded disposition, per the concentration risk register's Register schema.
• The supply chain concentration risk report the third-party and supply chain risk standard's section 10 routes to the governing-body level, on the cadence that section sets, as evidence that portfolio-level concentration reporting operates.
• The contract control schedule for each affected service, as evidence that the provisions the cloud exit and data portability standard's section 4 requires are present, or that each absence is under a section 8 exception, per the supplier and cloud governance framework's contracting-stage evidence class.
• The exit plan for each in-scope service, with its last-tested-or-validated date, as evidence for the exit-readiness control the cloud-exit standard's section 5 defines.
• The resilience-signal summary the supplier resilience monitoring standard's section 5 requires, as evidence that the dependency is monitored and that breaching signals reach the exit decision.
• The business impact analysis record for the services on the provider, as evidence for the dependency map and recovery objectives the decision rests on, per the business impact analysis procedure's evidence requirements.
• The risk-acceptance record and its exception register entry, where a concentration is accepted, as evidence that the acceptance is authorized at the level the risk acceptance procedure's Approval guidance names and tracked under the exception and risk acceptance policy's sections 4.3 and 4.5.
• The offboarding evidence record for any completed exit, as evidence that access removal, data return or destruction, and clean closure occurred, per the supplier offboarding evidence template.

• This page creates no compliance, prescribes no outcome, and imposes no requirement. The linked corpus documents govern; where this page differs from a corpus document, the corpus document prevails.
• This page carries composite claims. The four-position framing (accept, treat while staying, invest in exit readiness, exit) is this page's synthesis: the corpus defines the underlying register, treatment options, and controls but does not itself group them under these four names. The adopting organization validates the framing, and the authorities it implies, against its own governance and committee structure.
• The corpus documents carry the specific content this page refers to: the concentration dimension definitions, the contract provision terms and export formats, the exit-plan elements, the concentration thresholds and their approvers, the monitoring and review cadences, and the acceptance authorities, durations, and renewal ceilings. This page routes to that content rather than restating it.
• A register row, a contract term, an exit plan, or an acceptance record is evidence that a control exists or that a gate operated on a recorded date. Nothing on this page should be read as stating that a control operates effectively in any organization today, that an exit could be completed within any particular time or at any particular cost, or that a chosen treatment leaves no residual exposure.
• This page states no jurisdiction's legal or regulatory requirements. Sector regimes that supervise ICT concentration and exit obligations impose requirements of their own; the linked register's and templates' framework-alignment sections point to them, and organizations subject to such regimes validate their obligations with legal or compliance advice, which may exceed anything described here.
• This page makes no likelihood, frequency, or statistical claim, and none of its statements should be read as one.