Cloud vs On-Premises EDMS

Choose a supplier-operated cloud EDMS when the supplier can demonstrate the operational service you need and your team can govern the retained responsibilities. Choose a customer-operated deployment when a documented operational constraint requires it and you can resource the entire service. Neither hosting label establishes security, compliance or a lower total cost.

For a life sciences document system, the decisive question is what happens to an approved record when a server fails, an identity provider is unavailable, a release changes a workflow or the contract ends. Somebody must restore the document, its context and authorized access. “The vendor handles it” is not a complete operating model.

Assyro publishes this guide. We rechecked the primary sources on October 6, 2026. The responsibility schedule and scenarios below are buyer evaluation tools, not a report of hands-on testing or a claim about a particular supplier's contracted service.

Separate the service model from the server location

An electronic document management system, or EDMS, can be operated in several ways. A comparison of “cloud” with “on-premises” often mixes the application's operator, the infrastructure provider and the physical location.

NIST's cloud definition separates service models from deployment models. SaaS means using a provider's application without managing its underlying infrastructure. IaaS leaves the customer operating the deployed software and operating systems. NIST also allows a private cloud to exist on or off premises. Therefore, moving a customer-managed EDMS onto rented cloud infrastructure does not turn it into SaaS. NIST SP 800-145, September 2011.

Use these three descriptions when requesting proposals:

“Managed hosted” is a practical contracting description here, not an additional NIST service model. Its actual meaning comes from the responsibility schedule. A provider may manage the machines while your IT team still manages the database and application.

Product functionality need not determine location. For example, Ennov documents cloud and on-premises deployment options for Ennov Document. That product statement establishes an available choice; it does not establish identical commercial terms, operating services or a migration without effort. Ennov Document.

Before evaluating architecture, name the record families: controlled SOPs, regulatory source documents, specifications, approved reports or another defined set. Then identify authors, approvers, external collaborators and readers. A deployment proposal for document storage alone may omit the approval or retention behavior you are actually buying.

Hosting changes who operates controls, not whether they matter

AWS distinguishes infrastructure security from the customer's responsibilities for the selected services; its EC2 example leaves guest operating systems and applications with the customer. Microsoft similarly describes retained responsibilities for data, accounts and access, with the division changing by service model. These are infrastructure-provider models, not automatically the contract of the EDMS company using their infrastructure. AWS shared responsibility, Microsoft shared responsibility.

A useful procurement review follows the chain: your organization, the EDMS supplier, its managed-service partners and the infrastructure provider. Ask which party you contact, which party performs the repair and who confirms that the regulated process can resume. You should not have to discover that chain during an incident.

For security, compare evidence about the actual service boundary. Include privileged access, account removal, configuration management, monitoring, incident notification and recovery. An infrastructure certification can support supplier assessment, but it does not demonstrate that your document permissions or approval workflow are configured correctly.

On-premises ownership creates its own evidence requirements. A locked server room says little about an unpatched application, an overprivileged account or a backup that cannot be decrypted. Conversely, supplier-operated infrastructure does not prevent your administrators from sharing a record with the wrong group. Examine the relevant failure instead of treating the hosting label as its answer.

Apply the relevant record requirements

For FDA-regulated records, establish which underlying record requirements apply and whether the electronic records fall within Part 11's scope. FDA's August 2003 guidance explains its interpretation and enforcement approach while retaining the applicable predicate-rule obligations. It does not select an EDMS hosting architecture for you. FDA Part 11 scope and application guidance.

For systems used in EU GMP activities, Annex 11 addresses supplier agreements, application validation, infrastructure qualification, backup restoration, controlled changes and business continuity. The Commission's current index still lists the January 2011 revision. Apply that guidance to the relevant GMP use; do not treat it as a blanket rule for every life sciences repository. EudraLex Volume 4 index, Annex 11, revision 1.

Keep the applicability decision separate from the architecture decision. A system can support several record classes with different requirements. Document the intended use and decide which controls and evidence each class needs before accepting a generic “compliant cloud” or “validated server” statement.

For a fuller treatment of record scope, see our Part 11 guide. Use that work to inform your requirements, then test the proposed deployment against them.

Make the shared-responsibility schedule explicit

The following is a proposed contracting worksheet, not a claim that every vendor accepts these duties. Replace the role names with named organizations and accountable people. The customer retains responsibility for its records and must secure the ownership, access and export rights it needs in the agreement.

“Customer owner” means the person accountable for accepting the outcome. “Operator” means the party performing the task. Delegation to an operator does not eliminate the need for a customer owner.

For managed hosting, complete an additional operator column by negotiation. Never populate the whole column with “shared.” For example, the hosting company may restore a virtual machine, the software supplier may recover the application and your records owner may accept the recovered content. Those are three distinct actions.

Add an escalation owner wherever two organizations meet. An incident ticket passed between the application supplier and hosting company is still unresolved from the record owner's perspective. Your schedule should say who keeps responsibility for coordination until the service is accepted back into operation.

Test recovery at the record level

Recovery time objective, or RTO, states the maximum acceptable recovery time; recovery point objective, or RPO, describes the acceptable loss of recent data expressed as time. Define both against the business process and specify when the clock starts and stops. AWS's recovery guidance recommends defined objectives and recovery testing, rather than assuming that a backup operation proves recovery. AWS recovery objectives, AWS backup recovery testing.

For an EDMS, a successful file restore is only one part of that exercise. A representative test should include the approved document, relevant version history, metadata, approval or signature context, applicable audit information and the permissions needed to retrieve it. Include dependencies such as identity, configuration and encryption keys in the agreed recovery scope.

Run the exercise in an authorized, isolated environment or through an agreed supplier test. Do not make an unplanned destructive change to production. Ask whether the demonstrated recovery applies to your service and data model; a generic infrastructure test may leave the application-level acceptance work outstanding.

A worked recovery acceptance example

Consider an illustrative requirement of RTO no more than two hours and RPO no more than 30 minutes. These are example business targets, not regulatory defaults or vendor promises. All times in this exercise are UTC on the same day. The incident starts at 09:00, which the agreed procedure defines as the RTO starting point.

The recovery team restores a consistent record set from 08:45. Authorized users can retrieve it and the record owner completes the agreed acceptance checks at 10:40. The elapsed recovery time is 100 minutes, within the 120-minute target. The recovery point is 15 minutes before the incident, within the 30-minute target.

This exercise passes only if the required content and context are usable and the intervening activity is identified and handled under the agreed procedure. If the team opens the current PDF but cannot recover its required approval context, the exercise fails the completeness criterion even though the timing targets were met.

Now change one input: the last usable recovery point is 08:20. The 40-minute gap exceeds the example RPO. Another variation reaches acceptance at 11:10, producing a 130-minute recovery time and failing the RTO. A promised backup interval cannot override either observed result.

If nobody can identify the recovery operator or supply applicable restoration evidence, mark the deployment unresolved and do not approve the operating model. An unknown is not a successful test. Equally, a test exactly at an agreed inclusive limit passes the timing criterion but still needs every other mandatory criterion to pass.

Record timestamps with their time zone. A missing time or an inconsistent sequence is invalid evidence, not a zero-minute recovery. Correct the evidence before calculating the result.

Find the gap between infrastructure restoration and usable access

In a separate variation of the same fictional incident, the hosting company restores the server at 10:10 and the application specialist confirms the database at 10:25. The identity service remains unavailable until 11:05. The records owner finishes the required authorized retrieval and context checks at 11:15. Under the stated acceptance rule, recovery takes 135 minutes, so the two-hour RTO fails. Neither the server's 70-minute recovery nor the application's 85-minute recovery can stand in for the agreed end-to-end result.

Assign the identity-recovery action to its operator and the cross-provider escalation to one incident coordinator. Preserve the actual timestamps; then retest the complete path after the dependency or continuity arrangement changes. If identity restoration has no accountable operator, keep the operating schedule unresolved even when the application supplier's own work finishes on time. This is why the schedule needs both task owners and a person who owns the handoff between them.

Treat releases as changes to your working process

In supplier-operated software, find out who schedules releases, how much notice is provided, which changes are automatic and what testing opportunities exist. In a customer-operated system, name the person responsible for evaluating and deploying updates before the supported environment falls behind. Neither arrangement eliminates change assessment.

Use one example that affects an everyday document task: a new release changes an approval screen, permission rule or export format. Your operating schedule should identify who receives the notice, assesses impact, tests the affected workflow and communicates the approved procedure to users. Include the route for an urgent security update that cannot follow the ordinary timetable.

Ask specifically about rollback and forward recovery. Do not assume a SaaS tenant can be rolled back independently, or that an on-premises downgrade will preserve records written under the newer version. Require the actual supported recovery approach for the product and configuration you intend to use.

Supplier test material can be useful evidence, but your team must connect it to its intended use and configuration. Our computerized system validation guide provides a broader framework for that assessment. Hosting choice should feed the evidence plan, rather than stand in for it.

Examine location, jurisdiction and exit separately

A proposal naming a production data region does not answer every location question. Ask where backups, recovery environments, logs, support attachments and exported records can be stored. Separately identify where authorized support staff may access information and which subcontractors participate.

Record these details in the agreement and obtain the relevant privacy, legal and quality review for the actual information involved. Physical storage location and governing legal obligations are different questions; do not make a broad jurisdictional conclusion from a region selector. A customer-operated system can also involve remote support and external backup services.

Plan the exit before the first large migration. Define the export contents, format, costs, delivery period and available assistance. Test a sample that includes an obsolete document and historical approval context, not only the latest files. Confirm how records remain readable if the application or subscription is no longer available.

Set deletion after accepted transfer according to the applicable agreement and retention obligations. An export that has not been reconciled is not a reason to destroy the remaining usable source. Record ownership, operational custody and access rights should remain explicit throughout the transition.

Two scenarios with different preferred deployments

A distributed team without an infrastructure operations function

A biotech team authors and reviews regulatory source documents from several locations. It has a named records owner and quality support, but no team available to run the application platform and recovery service. Its requirements permit supplier hosting, and it can assess and govern a suitable service agreement.

Evaluate supplier-operated SaaS first. The operating model matches the work the organization is equipped to retain, provided the supplier demonstrates the required access controls, recovery and exit. This is a resource-allocation judgment, not evidence that every cloud offer is safe or that outsourcing removes internal work.

Change one condition: the supplier cannot provide an acceptable route to restore the required historical context. The proposed SaaS deployment fails regardless of its convenience. Consider another service or operating arrangement that can satisfy that requirement; do not waive recovery because the team lacks infrastructure staff.

A site with a defined local operational constraint

A manufacturing organization has a staffed, qualified IT operations function and a documented need to retrieve specified controlled instructions during a prolonged external network outage. It already maintains the local application dependencies and can demonstrate backup, recovery and change control.

Evaluate a supported customer-operated, on-premises deployment first, or an explicitly supported alternative that meets the local-access requirement. The decisive condition is demonstrated process continuity at that site. The recommendation would not follow merely from a preference to keep servers nearby.

Test loss of external identity and licensing dependencies as well as loss of the document connection. A local server that still requires an unavailable remote dependency may fail the very requirement used to justify it. If the customer cannot staff recovery or maintain the supported software stack, local hosting also fails the operating gate.

A supplier-operated system with a tested, controlled continuity arrangement may satisfy the same need. Compare that evidence before treating on-premises deployment as mandatory. Our cloud-based QMS guide discusses adjacent quality-system considerations; this EDMS decision should remain tied to the specific record-access task.

Approve a complete operating service, then compare cost

Request a common commercial scope: production and test environments, storage growth, backup retention, recovery exercises, releases, supplier support, internal staffing, integrations, migration and eventual exit. For customer operation, include the maintained platform and recovery capability; for SaaS, include retained administration, supplier oversight and any services outside the subscription.

Compare quotes in the same currency over the same term and record renewal assumptions. Avoid charging twice for a service already included in a bundle. Without scoped proposals and an internal resource estimate, this comparison cannot establish a dollar winner.

Before selection, complete one final acceptance record: exact deployment and location; record owner; named operator for every responsibility; required recovery targets; applicable test evidence; unresolved exceptions; commercial term; and the person approving the residual risk. A failed mandatory control means the proposal needs correction. Unresolved ownership or missing recovery evidence means the gate has not passed.

If you are evaluating a regulatory-document workflow with Assyro, bring that operating schedule to the discussion. Confirm the offered deployment, responsibilities and current capabilities against your requirements. Choose the service you can govern and recover, with records that remain usable throughout their required life.