Risk, resilience and compliance · Multi-cloud · Exit planning · CPS 230
How to depend on cloud, SaaS and AI providers without being trapped by them: a provider register tied to critical operations, a portability layer you own, tested data export and a second-provider path for the services that matter most.
A reference architecture from EITSAA, not a named client system. Service limits, prices and product features change, so confirm current details before you commit to a design.
The register lists every service provider, the critical operations each supports, contract dates, data held, location, and the further parties the provider relies on. Concentration appears when several operations share one provider, one region or one fourth party.
Providers are tiered. Those that support a critical operation, or that would expose the entity to material operational risk, get the strictest due diligence, contract terms, monitoring and exit planning.
Applications call providers through an interface you own, using your data contracts and identifiers. Provider-specific features sit behind it, so switching changes an adapter, not every consumer.
Where the provider cannot be replaced quickly, the provider is asked for scheduled exports or you pull them through its APIs, in open formats and with the metadata needed to rebuild relationships.
Exports land in a store you control. Record counts, checksums and a sample restore prove the export is complete and usable. Failures raise an alert, because an untested export is not an exit.
Infrastructure and configuration are held as code in your repository, so a second environment can be created in another provider or region without relying on one vendor's console state.
The standby path restores the data into the second provider, either as a warm copy or as a documented rebuild, depending on the tolerance level of the operation it supports.
For specialist software or services with a small supplier, escrow arrangements define release conditions such as insolvency or abandonment, so code, configuration and documentation can be obtained.
The exit plan sets the triggers, decision rights, steps and timeframes for moving to the second provider or bringing the service in-house. A scheduled rehearsal confirms the steps still work.
| Component | What it does | Why this choice |
|---|---|---|
| Service provider register | System of record for providers, arrangements, contract terms, data, locations and fourth parties. | CPS 230 requires a register of material service providers, and the information must be maintained, not recreated each year. |
| Concentration risk dashboard | Shows which operations share providers, regions, cloud accounts or fourth parties. | Concentration is invisible in a spreadsheet of individual contracts. |
| Provider-neutral interface | Your API, events and data model in front of provider services. | Limits the blast radius of switching and makes substitution a bounded project. |
| Scheduled data export and verification | Regular exports in open formats with counts, checksums and restore tests. | Data ownership clauses mean little if the export has never been used. |
| Portable data store | Object storage holding exports in formats readable without the provider. | A neutral copy under your control is the base of every exit path. |
| Infrastructure and configuration as code | Declarative definitions of environments and settings. | Repeatable deployment into another account, region or provider. |
| Customer-held keys | Encryption keys managed by you, with a recovery plan. | Control of keys supports confidentiality and lets you revoke access during a dispute or exit. |
| Escrow agreement | Third-party holding of code or configuration with defined release conditions. | Protects against failure of a small supplier, with the limits that escrow content must be usable by your team. |
How much portability to build
Why. Portability costs engineering effort. Spread evenly, it is either too expensive or too thin.
Trade-off. Some providers will have exit plans that take weeks. The tolerance and the business case must accept that explicitly.
Multi-cloud or multi-region
Why. Multi-cloud adds complexity and skill needs, and can lower overall reliability if done casually.
Trade-off. A single-provider design keeps a provider-level concentration. Record it, justify it and monitor it.
Use of proprietary services
Why. Managed services reduce operational risk. Total avoidance is rarely rational.
Trade-off. Some rework on exit, accepted knowingly and recorded in the exit plan.
Contract position
Why. CPS 230 expects formal agreements for material arrangements covering rights, responsibilities, audit access and notification of other material providers relied on.
Trade-off. Large vendors use standard terms. Where you cannot negotiate, document compensating controls and the residual risk.
Testing
Why. Exit plans fail on small facts such as missing keys, unreadable formats or unknown dependencies.
Trade-off. Rehearsals cost time and may require the provider's cooperation.
Customer-held keys, least-privilege provider access, segregated accounts for exports and strong control of credentials given to providers.
Verified exports, a second environment path and monitored provider health for each operation that depends on them.
Interface adapters add latency of a few milliseconds. Cache provider reference data where appropriate.
Store exports in lower-cost tiers, restrict warm standby to critical operations and use rehearsals to avoid emergency spend.
Annual provider review, quarterly register review, and an event-driven review on provider incidents, acquisitions or material contract changes.
Keep exports compact and tiered, and retire unused providers and data copies.
Providers connect through private endpoints or allow-listed paths where available. Exports run from controlled accounts with limited outbound routes. The standby environment uses the same network design as production and is isolated until activated.
Provider access uses federation, MFA and named roles, with logging into your own audit store. Service credentials are short-lived or rotated, and the exit runbook lists who can revoke and replace them.
Maintain a data inventory by provider: what is held, classification, location, retention and format. Define export frequency from the data loss tolerance of the operation. Test that records can be read by someone with no provider tooling, and confirm deletion and return at end of contract.
| Control | How this design addresses it |
|---|---|
| Service provider management policy and register | Provider tiers, owners, contracts, fourth parties and review dates in one register. CPS 230. |
| Due diligence before material arrangements | Assessment of capability, financial and non-financial risk, geographic and concentration risk before contract. CPS 230. |
| Formal agreements | Service levels, data ownership and control, audit access, liability, sub-contractor notification and termination support. CPS 230. |
| Exit and substitution | Documented, tested plans for orderly exit or provider failure. CPS 230 and CPG 230. |
| Third-party information assets | Assessment of third-party security capability and notification flows. CPS 234. |
| Supplier relationships | Supplier security requirements, monitoring and change management. ISO/IEC 27001:2022 Annex A. |
Mappings show how the design supports each control. They are not certifications, and EITSAA does not claim IRAP assessment or compliance for any reference architecture.
| Failure mode | Mitigation |
|---|---|
| Provider outage or insolvency | Failover to the second path if configured, or invoke the exit plan using verified exports and escrow. |
| Export succeeds but cannot be restored | Restore tests on a schedule, and checksum and record-count validation on every export. |
| Unknown fourth party fails | Contractual notification of material sub-contractors, plus mapping of their regions and dependencies in the register. |
| Contract terms are not accepted by a large vendor | Document the gap and compensating controls, and escalate for board-level risk acceptance where it affects a critical operation. |
| Exit plan goes stale | Review triggers on provider change, annual rehearsal, and ownership by a named executive. |
| Lock-in discovered during crisis | Dependency scans of code and configuration, and review of proprietary services in architecture decisions. |
Second provider footprint, data storage and transfer, engineering effort for adapters and rehearsal time.
AWS · Azure · Continuous compliance
Turn point-in-time audits into continuous assurance. Cloud configuration, findings and policy results flow into one evidence store, are mapped to named controls across several standards, and reach owners and auditors through dashboards and read-only access.
Incident response · Regulatory notification
A detection and response design that starts the right notification clocks from one incident record: materiality assessment against tolerance levels, pre-drafted regulator forms, approvals, evidence capture and a post-incident review that feeds back into the risk register.
API security · Tokenisation · Zero trust
A controlled edge for partners, fintech suppliers and SaaS platforms that need regulated data. Each partner is authenticated, authorised per scope, rate limited and logged, sensitive fields are tokenised, and everything is encrypted with keys you hold.
Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.