Deployment Models for Regulated Organizations: Sovereignty and Compliance Implications Compared

Regulated organizations face a structural problem when evaluating enterprise file sharing and content platforms: the question is never simply “which deployment model is most secure?” It’s “which deployment model gives us the sovereignty posture, certification coverage, and operational control our regulatory environment demands — and what exactly changes when we move between them?”

The answer is more complicated than vendors typically acknowledge. On-premises, private cloud, FedRAMP-authorized cloud, hybrid, and air-gapped deployments all use broadly similar underlying technology. But their compliance attestation coverage, data residency guarantees, customer operational control, and sovereignty implications differ in ways that matter enormously to procurement teams, DPOs, and security architects. A certification valid for one deployment model may not apply at all to another. An EU data residency commitment that holds for SaaS may require contractual negotiation in a different delivery mode.

This post maps those differences. It covers what each deployment model actually means for sovereignty, which certifications apply where, and what questions procurement teams need to ask to close the documentation gaps that most vendors leave open. The analysis is structured for teams evaluating platforms for regulated workloads — defence, financial services, healthcare, critical infrastructure — where deployment model selection is a compliance decision, not just an architectural preference.

Executive Summary

Main idea: Different deployment models carry materially different sovereignty and compliance implications — not just in theory, but in certification scope, data residency guarantees, and customer operational control. Procurement teams need a deployment-model-specific view of compliance coverage, not a single certification list that implies uniform applicability across all delivery options.

Why you should care: NIS 2, DORA, and frameworks such as BSI C5, IRAP, and G-Cloud 14 all place obligations on organizations to verify that the controls they rely on are actually attested for the specific deployment model they operate. A BSI C5 attestation for a managed cloud service does not automatically cover an on-premises appliance deployment, and vice versa. Closing this gap requires vendors to publish — and organizations to request — a parity matrix that maps certifications to deployment models. Most vendors currently don’t.

5 Key Takeaways

1. Deployment model selection is a compliance decision, not just an architecture decision. The model an organization chooses determines which certifications apply, what data residency is achievable, who bears operational control obligations, and whether the organization can produce audit evidence independently. These are regulatory questions that must be answered before the technical architecture is finalized — not after.
2. Certifications are not automatically portable across deployment models. A vendor holding BSI C5 Type 2, ISO 27001, and SOC 2 Type II may have earned those attestations for a specific managed cloud environment. The same vendor’s on-premises appliance may carry some, all, or none of those attestations depending on the scope boundary each certification body assessed. Procurement teams must ask explicitly: which certifications apply to which deployment model?
3. EU-only data residency is genuinely achievable with on-premises deployment — but requires due diligence for SaaS. An on-premises deployment on customer-owned infrastructure in an EU member state keeps data physically and legally within that jurisdiction, with no dependence on vendor infrastructure or routing. SaaS and private cloud models require contractual commitments to EU-only regions and verification that vendor operations, subprocessors, and support access do not create third-country transfers under GDPR‘s Chapter V.
4. Air-gapped deployments offer the strongest sovereignty guarantees but carry the highest operational overhead. No external connectivity means no cloud-based vendor access, no telemetry leaving the environment, and no automatic updates — which eliminates a class of sovereignty risk but places the full burden of patching, monitoring, and incident response on the customer. For defence and intelligence workloads, this trade-off is often non-negotiable. For most regulated enterprises, a hardened appliance with controlled connectivity is a more practical balance.
5. A consolidated certification parity matrix does not yet exist in the market — and its absence is a procurement risk. Most platforms publish compliance pages that list certifications globally without specifying which apply to which deployment mode. Procurement teams that accept a global certification list without mapping it to their specific deployment model may be relying on attestations that don’t cover the environment they’re actually running. The right procurement posture is to require a deployment-specific certification scope statement from every vendor under evaluation.

Understanding What Deployment Model Selection Actually Determines

Before comparing specific models, it’s worth being precise about what changes — and what doesn’t — when you move between deployment options for an enterprise file sharing platform. The distinction shapes which questions procurement teams need to ask and which claims vendors can and can’t legitimately make.

What Changes Across Deployment Models

Four things change materially when the deployment model changes: who controls the infrastructure, where data physically resides and can be routed, which certification scopes apply, and who bears operational responsibility for availability and security.

Infrastructure control determines whether the customer or the vendor makes decisions about patching cadence, configuration changes, hardware procurement, and physical access controls. Data residency determines where bytes are stored and whether they traverse networks subject to foreign legal jurisdiction. Certification scope determines whether the third-party attestations a vendor holds actually cover the operating environment the customer is using. Operational responsibility determines who is accountable — contractually and regulatorily — for uptime, incident response, and the controls that underpin those responsibilities.

These four dimensions don’t move together. A deployment that offers strong infrastructure control may have limited certification coverage. A highly certified managed service may offer weaker data residency guarantees than an on-premises alternative. Procurement teams need to assess each dimension independently rather than treating “deployment model” as a single binary variable.

What Stays the Same: The Core Platform

Kiteworks is built around a single hardened virtual appliance core that underpins all deployment models — on-premises, private cloud, FedRAMP-authorized cloud, and hybrid. This architectural consistency has a meaningful compliance implication: the hardened appliance configuration, the encryption stack, the access control framework, and the audit logging architecture are not different products with different security postures. They’re the same platform running in different operating environments.

That consistency matters because it means the controls a procurement team verifies during evaluation for one deployment model are substantively the same controls they’d be relying on in another. The variables are the operating environment, the certification scope, and the operational responsibility allocation — not the underlying security architecture.

On-Premises Deployment: Maximum Sovereignty, Maximum Operational Responsibility

On-premises deployment — specifically via a hardened virtual appliance running on customer-controlled hardware — represents the highest achievable sovereignty posture for enterprise file sharing. Understanding why requires understanding what sovereignty actually means in this context, and what it costs.

What On-Premises Deployment Gives You

When a regulated organization runs an on-premises deployment, the data never leaves the organization’s own infrastructure. There is no vendor cloud environment, no third-party data centre, and no vendor-operated network through which content is routed. Physical and logical access controls are entirely within the customer’s domain. The vendor cannot access the environment without explicit, auditable customer authorization.

For EU organizations with strict GDPR data residency requirements, this is the cleanest solution to the third-country transfer question under Chapter V. Data processed and stored on customer infrastructure in an EU member state remains subject to EU law — there is no dependence on vendor contractual commitments to EU regions or standard contractual clauses to achieve what the architecture achieves structurally.

Kiteworks’ on-premises deployment uses a hardened appliance that ships with a locked-down operating configuration. The appliance includes the full platform stack — content management, access control, cryptographic key management, audit logging — running as an integrated unit on customer hardware. Customers control the infrastructure layer beneath it entirely: server specification, physical location, network segmentation, backup architecture, and patching schedule for the underlying infrastructure (while Kiteworks provides appliance updates).

Certifications Applicable to On-Premises Deployment

Kiteworks holds the following certifications relevant to on-premises deployment contexts. Procurement teams should note that certification scope varies — some attestations cover the product architecture and security controls rather than a specific operating environment, while others are scoped to managed service delivery.

The honest position on this table: certification scope statements require direct engagement with Kiteworks and the relevant certification bodies. A consolidated, publicly available parity matrix mapping each certification to each deployment model does not currently exist. This is a documentation gap that procurement teams should raise explicitly — and that Kiteworks should be in a position to address given the shared appliance architecture across deployment models.

Source Code and Escrow for On-Premises

On-premises deployment creates a dependency that managed cloud delivery does not: what happens to the platform if the vendor is acquired, becomes insolvent, or discontinues the product? For regulated organizations running critical infrastructure on a hardened appliance, this question has regulatory and operational weight.

Kiteworks participates in software escrow arrangements as part of its commercial terms for on-premises customers. Source code escrow allows a third-party escrow agent to release the source code to licensees under defined trigger conditions. This provides a continuity backstop for organizations that need assurance beyond contractual terms alone.

Private Cloud Deployment: Customer Infrastructure, Customer Cloud

Private cloud deployment occupies the space between fully on-premises and vendor-managed SaaS. The Kiteworks appliance runs on cloud infrastructure — AWS, Azure, or GCP — that the customer procures and manages directly. The vendor operates the platform software; the customer operates the cloud environment it runs on.

Sovereignty Implications of Customer-Managed Cloud

The key distinction from managed cloud is control over the cloud account. When a regulated organization runs Kiteworks on its own AWS or Azure tenancy, it controls the network topology, the IAM policies governing who can access the underlying compute and storage, the region selection, and the egress routing. The vendor cannot make changes to the cloud environment without the customer granting access — which the customer controls and can audit.

For EU organizations, private cloud deployment allows EU-only region commitment to be enforced at the cloud infrastructure level — not just through vendor contractual commitments. An organization that deploys into an AWS eu-west or Azure West Europe region, with network policies that prevent data egress outside those regions, has a technically enforced residency posture rather than a contractually asserted one. That distinction matters for regulators examining third-country transfer risk under Schrems II.

The counterpoint is that private cloud deployment still involves dependence on the major hyperscalers — AWS, Azure, or GCP — each of which is a US-headquartered company subject to the US CLOUD Act. For organizations whose threat model includes government-ordered access by the US government to data held by US cloud providers, this creates a residual sovereign risk that on-premises deployment does not. This is an honest assessment of the trade-off, not a critique specific to Kiteworks — it applies equally to any regulated workload running on US hyperscaler infrastructure regardless of the EFSS layer on top.

Certification Coverage in Private Cloud Contexts

Private cloud deployment on customer-managed infrastructure creates a split certification responsibility. Certifications that Kiteworks holds for its platform software — ISO 27001, BSI C5 — cover Kiteworks’ product and, where applicable, its managed service operations. They do not cover the customer’s cloud account configuration, the network policies the customer has implemented, or the IAM governance the customer has applied to the underlying infrastructure.

This means a regulated organization running Kiteworks on its own AWS account needs to address two certification dimensions: Kiteworks’ platform-level attestations, and the organization’s own cloud infrastructure governance. AWS, Azure, and GCP all hold extensive certifications (including BSI C5 for AWS and Azure European regions, ISO 27001, and others), but those certifications cover the hyperscaler’s infrastructure — not the customer’s configuration of it.

Procurement teams should map these layers explicitly: platform software certifications (Kiteworks), infrastructure certifications (hyperscaler), and customer configuration governance (internal). None of these layers automatically certifies the others.

FedRAMP-Authorized Cloud: Highest US Government Standard

FedRAMP (Federal Risk and Authorization Management Program) represents the US federal government’s authorization framework for cloud services. The authorization levels — Low, Moderate, and High — reflect the impact classification of the data the service is permitted to process. FedRAMP High is the most demanding level, covering Controlled Unclassified Information (CUI) and other sensitive government data categories where unauthorized disclosure would cause severe harm.

What FedRAMP High In Process Means in Practice

Kiteworks has achieved FedRAMP High In Process status — meaning the authorization process is active and progressing, but the final Authorization to Operate (ATO) has not yet been granted. The marketplace listing is publicly verifiable at fedramp.gov/marketplace/products/FR2435353186/. Organizations evaluating Kiteworks for US federal procurement should check the marketplace listing directly for current status, as the authorization process has defined milestones and the status will update when the ATO is granted.

FedRAMP High authorization requires independent assessment by a Third Party Assessment Organization (3PAO) against NIST SP 800-53 controls at the High baseline — over 400 security controls covering access control, configuration management, incident response, system integrity, and supply chain risk management, among others. The authorization process also includes a sponsoring federal agency review. Achieving FedRAMP High In Process status means the package has cleared the initial review gates; the ATO represents final agency sign-off.

For non-US regulated organizations — particularly those in the EU, Australia, or the UK — FedRAMP High authorization is a meaningful signal of security maturity even if FedRAMP itself is not a required framework. The NIST 800-53 control set substantially overlaps with ISO 27001, BSI C5, and IRAP control requirements. Organizations using FedRAMP as a proxy for security rigour are on reasonable ground, though they should not treat it as a substitute for the frameworks their own jurisdiction requires.

Data Residency in FedRAMP Cloud

FedRAMP-authorized cloud deployments are operated by the vendor — Kiteworks — on infrastructure specifically configured for FedRAMP compliance. This means the customer does not manage the underlying infrastructure; Kiteworks does. Data residency in the FedRAMP context is US-bound: FedRAMP requires data to be stored in US-located infrastructure. This makes FedRAMP cloud deployment unsuitable as a data residency solution for EU organizations with GDPR Chapter V transfer restrictions — it is a US-specific compliance model.

EU procurement teams evaluating Kiteworks should not conflate FedRAMP High In Process with EU certification readiness. These are distinct frameworks serving distinct regulatory environments. The relevant EU frameworks are BSI C5 (Germany), the forthcoming EUCS (EU-wide cloud certification scheme under ENISA), and national certification schemes in EU member states. Kiteworks holds BSI C5 Type 2 — but EUCS readiness is unconfirmed at the time of this writing, and procurement teams evaluating for EUCS compliance should engage Kiteworks directly for current status.

Hybrid Deployment: Balancing Sovereignty and Operational Flexibility

Hybrid deployment combines on-premises or private cloud components with vendor-managed cloud capabilities. In practice, this typically means some workloads or data categories remain on customer-controlled infrastructure while others operate in the vendor’s cloud — with the platform managing the boundary between them.

Where Hybrid Makes Sense for Regulated Organizations

Hybrid deployment is most appropriate for organizations with differentiated data sensitivity across their workloads. An organization might keep its most sensitive regulated data — classified defence materials, patient health records, board-level financial documents — on-premises under full customer control, while running less sensitive collaboration workloads through the vendor’s managed cloud for ease of external sharing and partner access.

The sovereignty and compliance question for hybrid deployment is: which components handle which data categories, and what are the certification and residency implications of each? A hybrid architecture that routes high-sensitivity data through vendor-managed cloud infrastructure may inadvertently undermine the residency and sovereignty protections the organization intended to achieve through the on-premises component. Data flow mapping is essential — not just architecture diagrams.

Kiteworks’ hardened appliance core runs across all deployment modes, which means the platform security controls are consistent regardless of which component handles a given transaction. But certification scope for the hybrid boundary — the integration layer between on-premises and cloud components — requires explicit verification. Procurement teams should ask Kiteworks to specify which certification attestations cover the hybrid operating model specifically, not just the individual components in isolation.

Key Procurement Questions for Hybrid Configurations

Several questions are non-negotiable before deploying a hybrid configuration for regulated workloads. Does the platform provide policy-enforced routing that can guarantee specific data categories stay within the on-premises component? Can the customer verify, through audit logs, which component processed a given transaction? Do the certifications held by Kiteworks cover the integration points and data flows between components, or only each component individually? And — critically — does the vendor’s support model for hybrid deployment involve remote access to the on-premises component, and if so, under what authorization and audit controls?

Air-Gapped Deployment: Maximum Isolation for the Highest-Risk Environments

Air-gapped deployment is on-premises deployment with one additional constraint: no external network connectivity. The platform operates in a physically and logically isolated environment with no internet access, no vendor telemetry, and no remote update capability. This is the deployment model for classified government systems, certain defence and intelligence environments, and critical national infrastructure where the threat model explicitly includes network-based lateral movement and supply chain attacks.

What Air-Gapping Achieves — and What It Doesn’t

An air-gapped deployment eliminates an entire category of sovereignty risk: the risk that the vendor, a subprocessor, a compromised update mechanism, or a nation-state actor accessing vendor infrastructure can reach customer data over a network. Nothing can reach the environment remotely because there is no remote access by design. This is a structurally different security posture from one that relies on access controls to prevent unauthorized remote access — it removes the attack surface rather than defending it.

What air-gapping doesn’t address is the insider threat within the perimeter, the security of the physical facility, supply chain integrity of hardware and software components before installation, and the operational challenge of updates. In an air-gapped environment, offline update packages are delivered through customer-controlled secure transfer procedures. This creates a patching discipline challenge: organizations must maintain a rigorous process for identifying, testing, and applying patches without the automated update mechanisms that most platforms rely on.

Kiteworks supports air-gapped on-premises deployment for organizations operating in these environments. The hardened appliance architecture is designed to run without external connectivity. Customers in defence and intelligence contexts should engage Kiteworks directly to discuss update delivery mechanisms and support model constraints in air-gapped environments.

The Missing Parity Matrix: The Documentation Gap That Matters Most

The most significant procurement gap across the enterprise file sharing market — including Kiteworks — is the absence of a publicly available, deployment-model-specific certification parity matrix. This is not a criticism specific to any one vendor. It reflects a structural problem in how the market communicates compliance posture.

What a Parity Matrix Should Cover

A deployment certification parity matrix would map each certification held by the vendor against each deployment model, specifying the scope boundary of each attestation. A well-constructed version would include the following dimensions as a minimum:

Procurement note: The “Verify scope with Kiteworks” entries in this table are not evasions. Certification scope is a matter of documented fact — each certifying body issues a scope statement as part of the certification. Procurement teams should request these scope statements directly from Kiteworks, and Kiteworks should be able to provide them. Organizations that accept a vendor’s global certification list without mapping it to their specific deployment model are making an assumption that may not hold.

Two Questions That Should Be Standard in Every RFP

Given the absence of a publicly consolidated parity matrix, two questions should appear in every RFP for enterprise file sharing platforms used in regulated environments.

First: can the vendor produce a certification-status tracker — specifying BSI C5, ISO 27001, FedRAMP, IRAP, Cyber Essentials Plus, G-Cloud 14, SOC 2, and NIS 2 alignment — mapped explicitly to each deployment model the organization is evaluating? Not a global compliance page, but a model-specific scope statement for each relevant attestation.

Second: does the vendor publish architectural and data-flow documentation sufficient for an EU customer or regulatory auditor to independently verify sovereignty and transparency requirements? For organizations operating under the EU Cybersecurity Framework, the ability to verify — not merely trust — that the platform operates as described is a compliance requirement, not a nice-to-have. Architectural diagrams, data-flow documentation, and subprocessor disclosure are the minimum evidentiary standard.

How Kiteworks Approaches Deployment Sovereignty

Kiteworks’ differentiation in the deployment model space rests on three foundations: architectural consistency across deployment modes, a breadth of independent third-party certification, and honest acknowledgment of where documentation gaps remain.

The hardened appliance core — used across on-premises, private cloud, hybrid, and air-gapped deployments — means security controls are not re-engineered for each delivery model. The same encryption stack, the same access control framework, the same audit logging architecture that underpins the FedRAMP-authorized cloud is the architecture customers run on-premises. This is architecturally verifiable rather than asserted. Procurement teams can request the appliance configuration documentation and compare it against what’s described for each deployment mode.

On certification breadth, Kiteworks’ portfolio spans EMEA, Asia-Pacific, and US frameworks: BSI C5 Type 2, ISO 27001, Cyber Essentials Plus, IRAP PROTECTED, FedRAMP High In Process, and SOC 2 Type II. G-Cloud 14 listing on the UK government digital marketplace provides a public reference point for UK public sector procurement. This is a wider certification portfolio than most comparable platforms in the market, and the combination of EMEA-first frameworks (BSI C5, ISO 27001) with APAC government assessment (IRAP) and US federal authorization (FedRAMP) reflects genuine cross-jurisdictional engagement rather than US-centric compliance posture.

What Kiteworks has not yet done — and should be asked about — is publish a deployment-specific certification scope matrix. The certifications exist. The documentation mapping them to each deployment model does not yet exist in a consolidated, publicly accessible form. For procurement teams in regulated environments, closing this gap is a reasonable and legitimate request. Kiteworks’ shared appliance architecture should make this documentation tractable to produce; the question is whether it has been prioritized.

Source code escrow for on-premises customers provides a continuity mechanism beyond the operational certification portfolio — relevant particularly for defence, intelligence, and critical national infrastructure procurement where long-term platform continuity is a procurement requirement.

Conclusion

As regulatory frameworks mature — EUCS moving toward implementation, NIS 2 enforcement intensifying, DORA operational resilience requirements taking hold — the expectation that organizations can demonstrate, not just assert, compliance posture for their specific deployment model will only increase. The market will move toward deployment-specific certification transparency whether vendors lead or follow. Procurement teams that build deployment-model parity requirements into their RFPs now are positioning themselves ahead of that curve, rather than scrambling to backfill evidentiary gaps when regulators ask the questions that no one has answered yet.

Frequently Asked Questions