VCF 9.1 Fleet & Multi-Fleet Design Under Regulatory Compliance A Multi-Jurisdiction Field Guide

This is Part 24 of the series — the first article past the Upgrade Series (Parts 19–23), opening a new thematic block on the cross-cutting concerns that increasingly shape VCF architecture: regulatory compliance, data sovereignty, operational resilience obligations, and the cross-border data flow constraints that follow from them.

In my engagements over the last 24 months, the centre of gravity in Fleet design conversations has shifted. Performance, scale, and total cost of ownership are still on the table, but the conversation now opens with jurisdiction. APRA CPS 230 in Australia. DORA in the EU. PRA SS1/21 in the UK. MAS TRM in Singapore. RBI guidelines in India. FFIEC and state privacy laws in the US. Hosting Certification Framework for Australian public sector. Critical Third Party regulations emerging globally. These frameworks aren’t background context anymore — they are now first-order Fleet design drivers.

The architect’s job has expanded. It’s no longer enough to design the cleanest Fleet topology and let the compliance team review afterwards. The compliance posture must be architected in from the start — because retrofitting jurisdictional separation, identity federation, key management custody, and operational personnel jurisdiction into a Fleet that wasn’t designed for it is significantly more expensive than getting it right the first time.

This article walks through the jurisdictional landscape, the seven design pressures that regulation creates on Fleet topology, the Single-Fleet versus Multi-Fleet decision framework, the VCF 9.1 capabilities that map to common compliance controls, and the design questions architects need to answer before committing to a Fleet structure.

Why compliance is now a primary Fleet design driver

Three trends have converged to push compliance from background concern to primary design driver.

First, operational resilience regulation has matured. APRA CPS 230 (effective July 2025 in Australia), DORA (fully applicable in the EU from January 2025), PRA SS1/21 (UK), FFIEC operational resilience guidance (US), MAS TRM revisions (Singapore) — all of these now explicitly cover ICT and third-party cloud services, with specific requirements on outage tolerance, recovery, and supervisory access. These aren’t advisory; they’re enforceable, and they push designs toward demonstrable resilience patterns rather than aspirational ones.

Second, data sovereignty has hardened. Post-Schrems II in the EU, post-DPDP enactment in India, post-PIPL in China, and with the ongoing tightening of state-level privacy laws in the US (CCPA, CPRA, and the cascade of similar laws across other states), the question of where data physically lives — and who has legal jurisdiction over it — now drives concrete design decisions, not just risk-register entries.

Third, Critical Third Party regulation is emerging globally. The UK PRA / FCA / Bank of England Critical Third Party regime, the EU’s DORA designation of Critical ICT Third-Party Service Providers, APRA’s heightened expectations under CPS 230 and CPS 234 — all of these treat material cloud providers as supervised entities. The implications cascade down into Fleet design: the cloud provider may need to demonstrate operational resilience to the regulator directly, which changes what designs the regulator will accept.

The combined effect: an architect who designs a Fleet without explicit jurisdictional thinking is now designing a Fleet that may fail audit on Day 1, or worse, on the day of an incident when the regulator asks specific questions about data location, operational control, and recovery jurisdiction.

The seven design pressures regulation creates

Regulatory frameworks vary in detail by jurisdiction, but the design pressures they create on VCF Fleet topology cluster into seven categories. An architect who can name these seven pressures and design for them across all jurisdictions in scope is operating at the right level of abstraction.

1. Data residency. Where the data physically lives. Drives Workload Domain placement (which physical region hosts the workload), Instance placement (which Instance hosts the Workload Domain), and ultimately Fleet structure (whether a single Fleet can span jurisdictions or whether separate Fleets are required).

2. Data sovereignty. Who has legal jurisdiction over the data and platform. Distinct from residency — data may reside in country A but be controlled by an operator subject to country B’s laws. Drives operator selection, partner contracting, and operational personnel jurisdiction — who has admin access from which country.

3. Cross-border data flow control. What can move where, under what controls, with what notification, with what right of objection. Drives replication topology (vSAN Protection multi-source patterns from Part 18), DR topology (which sites can be paired), and backup target selection.

4. Operational resilience obligations. Outage tolerance windows, recovery time objectives, recovery point objectives, supervisor notification timelines, ability to demonstrate testable recovery. Drives DR topology, IRE design (Isolated Recovery Environment from Part 18), backup architecture, and the testing cadence.

5. Identity and access controls. Who can access what, from where, with what authentication, with what audit trail. Drives Identity Broker federation strategy (Part 17), MFA enforcement, privileged access management integration (CyberArk, BeyondTrust, etc.), and conditional access policy.

6. Encryption and key management. Data-at-Rest encryption mandates, Data-in-Transit encryption mandates, and — critically — key custody jurisdiction. Some regulators require keys to be held within the jurisdiction by an operator subject to that jurisdiction’s laws. Drives KMS selection, HSM placement, and the encryption boundary topology.

7. Logging, audit, and supervisory access. What’s logged, where logs live, how long they’re retained, whether they’re immutable, who can access them under what process, whether the regulator has direct access. Drives VCF Operations for Logs deployment, log retention configuration, immutability via WORM-capable storage, and the operational process for supervisory queries.

These seven pressures don’t operate independently. A single regulatory framework typically activates several of them simultaneously. DORA, for example, hits operational resilience (pressure 4), supervisory access (pressure 7), and via its Critical ICT Third-Party Service Provider regime, indirectly affects pressures 1, 2, and 5. APRA CPS 230 combined with CPS 234 hits pressures 4, 5, 6, and 7. The architect’s job is to map every framework in scope to the pressures it activates, then design once for the combined surface.

The jurisdictional landscape — frameworks by region

A working architect’s reference for the major frameworks and their primary design implications. Not exhaustive — frameworks evolve, jurisdictions add new ones, and specific provisions require legal review on every engagement. Use this as the starting inventory.

Australia. APRA CPS 230 (operational risk management, effective July 2025) and CPS 234 (information security) are the dominant frameworks for regulated financial institutions. The Privacy Act 1988 (currently undergoing reform) and the Australian Privacy Principles apply broadly. The Information Security Manual (ISM) and the Hosting Certification Framework govern Australian public sector hosting. IRAP assessment is the standard for cloud services entering government workloads. APRA’s heightened scrutiny of material service providers means architects should expect the regulator to ask specific questions about Fleet topology, operational personnel jurisdiction, and recovery testing.

European Union. GDPR remains the dominant data protection framework. DORA (Digital Operational Resilience Act, fully applicable from January 2025) is now the operational resilience framework for EU financial services, with explicit ICT third-party provider provisions. NIS2 (Network and Information Systems Directive 2) extends cybersecurity obligations across additional sectors. The EU Data Act and EU AI Act add further dimensions. Post-Schrems II implications constrain transfers to jurisdictions without adequacy decisions, including the US under certain interpretations.

United Kingdom. UK GDPR (post-Brexit equivalent of GDPR), the Data Protection Act 2018, PRA SS1/21 (operational resilience), FCA SYSC requirements, and the emerging Critical Third Party regime from the Bank of England, PRA, and FCA. The UK’s position on data adequacy with the EU and with various non-EU jurisdictions evolves; architects designing UK-EU flows should monitor.

United States. Federal sector: HIPAA for healthcare, FedRAMP for federal government workloads, CMMC for defence supply chain, SOX for public company financial controls, GLBA for financial services. State-level privacy laws are proliferating: CCPA / CPRA in California, plus equivalents now enacted or pending in many states. FFIEC issues operational resilience guidance for financial services. The patchwork makes US compliance design unusually fragmented.

Singapore. MAS TRM (Technology Risk Management) Guidelines for financial services, the PDPA for personal data, the Cybersecurity Act 2018 for designated critical information infrastructure. MAS Notice 644 and the broader MAS outsourcing framework are particularly relevant for cloud architecture.

India. The Digital Personal Data Protection (DPDP) Act 2023, with rules in active development. Reserve Bank of India guidelines on outsourcing, cloud computing, and data localisation for regulated entities. The Information Technology Act 2000. India’s data localisation expectations for certain financial and payment data are particularly demanding.

Hong Kong. Personal Data (Privacy) Ordinance (PDPO), HKMA Supervisory Policy Manual provisions for banking, and the SFC requirements for securities firms. Cloud computing guidance from the HKMA evolves through specific circulars.

Middle East. UAE PDPL (Personal Data Protection Law), Saudi Arabia’s PDPL and the National Cybersecurity Authority’s Essential Cybersecurity Controls (ECC), Qatar’s PDPPL. Multiple jurisdictions in the region have data localisation expectations for sensitive sectors.

Other major jurisdictions. Brazil’s LGPD; Canada’s PIPEDA and OSFI B-13 for federally regulated financial institutions; Japan’s APPI; South Korea’s PIPA; China’s tripartite CSL / DSL / PIPL framework with significant cross-border transfer constraints.

For multinational customers, the practical exercise is to enumerate every jurisdiction in which the customer operates or stores regulated data, identify the applicable frameworks per jurisdiction, map each framework to the seven design pressures, and synthesise the combined surface into a Fleet topology design.

Single-Fleet versus Multi-Fleet — the decision framework

The dominant Fleet-versus-Multi-Fleet question in compliance-driven designs: does the customer maintain a single global Fleet, or separate Fleets per jurisdictional boundary?

Single-Fleet option. One Fleet spans regions and jurisdictions. Multiple Instances within the Fleet, each placed appropriately. Central VCF Operations, central VCF Automation, central Identity Broker (where permitted), unified lifecycle policy. Simpler operational model, but with sovereignty risks if metadata, identity material, telemetry, or operational personnel cross jurisdictional boundaries.

Multi-Fleet option. Separate Fleets per jurisdictional boundary. Each Fleet operates with its own VCF Operations, VCF Automation, Identity Broker, lifecycle policy. Cleaner sovereignty story, no cross-border metadata or telemetry flows by default, simpler regulator narrative. Costs significantly more in operational overhead, capability duplication, and licensing.

Hybrid Fleet option. Regional Fleets for jurisdictional boundaries combined with a controlled central observability or analytics layer where regulation permits. The central layer can be a sanitised aggregator of metrics and alerts without ingesting regulated content. Common in multinationals with strong central operations functions and a few high-control jurisdictions.

The decision factors:

• Data sovereignty obligations — some jurisdictions (China is the most explicit example) effectively force separate Fleets. Others (most of the EU under most workloads) permit a single Fleet with appropriate controls

• Operational personnel jurisdiction — if regulators require platform operators to be subject to local law, the operating Fleet must have operational personnel in that jurisdiction

• Identity material custody — if Identity Broker tokens or service account credentials are considered regulated material in a jurisdiction, separate Identity Broker deployments may be required

• Telemetry and operational metadata flow — metrics, alerts, configuration data flowing through VCF Operations may or may not cross sovereignty boundaries cleanly

• Lifecycle policy divergence — if different jurisdictions impose different patching windows, change management requirements, or approval workflows, separate Fleets simplify

• Audit narrative simplicity — regulators ask cleaner questions of a per-jurisdiction Fleet than of a single multi-jurisdiction Fleet. The cleaner story may be worth the operational overhead

• Cost — separate Fleets carry meaningful duplication cost. The Management Services Cluster (12 IPs, 4 FQDNs, 92 vCPU / 344 GB vMEM — from Part 14) is non-trivial to duplicate per jurisdiction

In my engagements, the trend over the last 24 months has shifted toward Multi-Fleet and Hybrid Fleet topologies for genuinely multi-jurisdiction customers. The cost is real but the audit narrative and sovereignty defensibility are worth it. Single global Fleets remain appropriate for customers operating in a single jurisdiction or a tight cluster of jurisdictions with mutual adequacy recognition.

VCF 9.1 capabilities that map to compliance controls

VCF 9.1 includes a substantial set of capabilities that map directly onto the controls regulators expect to see. The architect’s job is to know which capabilities map to which controls, and to design the Fleet so the right capabilities are deployed in the right places.

Identity Broker federation. Federated identity (Azure AD / Entra, Okta, Ping, ADFS, OIDC) with conditional access, MFA, and centralised group-to-role mapping (Part 17). Maps to identity and access controls under almost every framework — GDPR Article 32, APRA CPS 234 control objectives, DORA Article 9, MAS TRM identity controls, PRA operational resilience identity provisions. Per-jurisdiction deployment supports sovereignty.

Advanced Cyber Compliance (ACC) and Security Posture Management (SPM). SPM provides continuous configuration benchmarking against VCF security baselines and PCI DSS. The on-premises IRE (Isolated Recovery Environment) pattern is the cyber resilience control that DORA, APRA CPS 230, FFIEC, and MAS TRM expect to see. ACC + IRE is foundational for the operational resilience pressure (pressure 4) and the supervisory access pressure (pressure 7).

vDefend with Security Services Platform. Lateral security controls — distributed firewall on distributed Virtual Port Groups, IDPS Turbo Mode, Self-Service Lateral Security, VKS CNI integration. Maps to network segmentation controls in PCI DSS, NIS2 segmentation expectations, APRA CPS 234 network control objectives, and the lateral movement controls expected in most frameworks post-major-breach cycles.

Data-at-Rest Encryption with KMS choice. vSAN DaR encryption with external KMS integration (Thales, Entrust, Fortanix, HashiCorp Vault, AWS / Azure / GCP KMS). The KMS choice is a compliance decision — key custody jurisdiction must align with sovereignty requirements. For some jurisdictions, on-premises HSM-backed KMS is the only acceptable pattern.

Data-in-Transit Encryption. vSAN DiT encryption and NSX overlay encryption for cross-rack and cross-site flows. Maps to encryption-in-transit requirements common across all frameworks.

VCF Operations for Logs with immutable retention. Centralised log aggregation with retention policies aligned to jurisdiction-specific retention requirements. Immutable storage targets via WORM-capable backends. Maps to logging and audit requirements (pressure 7) under almost every framework.

Configuration Drift Management. Captures the baseline configuration and surfaces drift over time. Maps to change management controls in APRA CPS 234, DORA Article 6, PCI DSS Requirement 11, and similar frameworks. The drift baseline becomes audit evidence of controlled change.

vSAN Protection multi-source replication. Fan-in, fan-out, heterogeneous source replication patterns (Part 18). Maps to operational resilience pressure (4) by enabling jurisdiction-appropriate DR topologies — e.g., in-jurisdiction replication for sovereignty constraints, out-of-jurisdiction replication where permitted for resilience.

HTTP Offline Depot. Air-gapped patch and image distribution. Maps to environments classified for highly sensitive workloads where direct internet connectivity is prohibited — Australian PROTECTED+, US FedRAMP High and above, certain financial sector classifications.

VCF Operations Collectors and the Fleet Latency Diagram. The latency-bound topology (≤ 50ms to managed components, ≤ 300ms back to central VCF Operations, from Part 14) shapes what designs are physically possible. Compliance constraints often align with these latency budgets — in-jurisdiction collectors aggregating to a central operations plane.

Programmatic licence management. Centralised, automated licence usage reporting via VCF Operations. Maps to material service provider reporting requirements under Critical Third Party regimes — the customer’s ability to demonstrate consumption to the regulator.

Cross-border data flow patterns

Even with Multi-Fleet topologies, some cross-border flows are operationally necessary. The patterns I see most often:

• Sanitised observability flows — metrics, alerts, and configuration metadata aggregated centrally without including regulated data content. VCF Operations supports adapter-level filtering and field-level redaction

• DR cross-border replication — permitted where adequacy decisions exist or where Standard Contractual Clauses and supplementary measures are accepted. vSAN Protection with encryption-at-rest using jurisdictionally-controlled keys

• Identity federation across jurisdictions — federating to a central IDP where the central IDP’s jurisdiction is acceptable, or federating to per-jurisdiction IDPs and using cross-IDP trust where required

• Centralised security operations — SIEM aggregation of telemetry for global SOC visibility, with care taken on what telemetry crosses borders. NDR data and DFW logs often warrant sanitisation

• Support and operations follow-the-sun — the most contentious pattern. Operational personnel jurisdiction is now a regulator-asked question. Where follow-the-sun crosses jurisdictional boundaries, the customer needs to defend the pattern explicitly

Each cross-border pattern should have a documented basis — adequacy decision, SCC plus supplementary measures, derogation, explicit consent, or jurisdiction-specific framework provision. The architect surfaces the flow; the customer’s privacy and compliance teams document the basis. Don’t design flows without a documented basis on file.

The compliance design questions for every Fleet engagement

Before committing to a Fleet topology, the questions I work through with the customer:

• Which jurisdictions does the customer operate in, and what data resides where?

• Which regulatory frameworks apply per jurisdiction, and what design pressures do they each activate?

• Are there any jurisdictions with effective hard data-localisation requirements (China, India for certain financial data, parts of the Middle East for sensitive sectors)?

• Does the customer fall under any Critical Third Party regime, or rely on a provider that does?

• What’s the operational personnel jurisdiction — who has admin access from which country, and is that acceptable under each applicable framework?

• What’s the key custody strategy — where are encryption keys held, by whom, under whose jurisdiction?

• What’s the log retention and supervisory access pattern — who can read what, from where, under what process?

• What’s the DR topology — cross-border permitted, in-jurisdiction only, hybrid?

• Is a single Fleet topology defensible, or does the jurisdictional surface force Multi-Fleet?

• Where does centralised observability fit — fully centralised, jurisdictionally separated, or sanitised aggregation?

• What’s the audit narrative? Can the customer explain the design to a regulator in a paragraph?

• Are there exit clauses and portability obligations the design must accommodate?

Closing

Regulatory compliance has moved from background concern to primary Fleet design driver. Architects who design topology without explicit jurisdictional thinking are designing topology that may not survive its first audit, and certainly won’t survive its first incident.

The good news: VCF 9.1 has a substantial set of capabilities — Identity Broker federation, ACC + SPM + IRE, vDefend, jurisdictionally-aware encryption with KMS choice, immutable logging, Configuration Drift Management, vSAN Protection multi-source replication — that map directly to the controls regulators expect to see. The platform is more compliance-aware than ever before. The architect’s work is to map customer obligations to capabilities, choose the right Fleet structure (Single, Multi, or Hybrid), and design defensible cross-border patterns where they’re needed.

This is the design conversation worth investing time in early. Retrofitting compliance into a Fleet that wasn’t designed for it is expensive. Getting it right the first time, with an architecture narrative the customer can explain in a paragraph to a regulator, is the deliverable that matters.

Part 25 in the series will pick up the adjacent theme — designing VCF Fleets for FinOps and cost transparency under similar multi-jurisdiction constraints. Where compliance shapes what topology is permitted, FinOps shapes what topology is sustainable. Both pressures, applied at the same design point, define the modern Fleet.

A note on scope: this article describes design patterns and the pressures they respond to. It is not legal advice. Every engagement requires the customer’s privacy, compliance, and legal teams to validate the specific provisions and adequacy of any design against the actual obligations in scope. Architects surface; lawyers decide.

Sources

• Broadcom — Announcing VCF 9.1

• Broadcom — Scale, Simplify, and Secure VCF 9.1

• Broadcom TechDocs — VCF 9.1 Management Services Models

• William Lam — VCF 9.1 Updated Design Blueprints and Fleet Latency Diagrams

• APRA — Prudential Standard CPS 230 Operational Risk Management

• APRA — Prudential Standard CPS 234 Information Security

• European Commission — DORA (Digital Operational Resilience Act)

• Bank of England / PRA / FCA — Critical Third Party regime

• Monetary Authority of Singapore — Technology Risk Management Guidelines

• Australian Government — Hosting Certification Framework