An engineering firm prescribed a SaaS CMMS-plus-GIS platform three years ago to a private industrial operator with a distributed infrastructure portfolio. The vendor has a solid product and a stable track record; the three years since have produced no relevant incidents. In a routine review by the client's IT department, the IT lead asks the vendor a question that had not come up before: how does the client access its own backup? The vendor answers, correctly, that there is a restore-on-request policy and that in case of an incident they can recover the data to the last hourly synchronization point. The IT lead's second question reveals the asymmetry: how can the client receive a periodic copy of the backup to hold in their own storage? The vendor answers honestly that the standard offering does not include this, that it could be considered as an additional service, and that in three years of contract the question had never arisen. The conversation between the operator and the engineering firm returns to the technical table: the asymmetry is not malicious on the vendor's part, it is architectural; and it was not negotiated in the RFP because the RFP did not include a clause that contemplated it.
The client backup is the least-negotiated link in a technical SaaS platform contract and, for that reason, the one that decides in practice who controls the data when the scenario shifts. Commercial policy changes, vendor acquisitions, vendor operational disruptions, or simply the client's strategic decision to move data into their own infrastructure: in all four cases, whoever holds the copy sets the tempo of the conversation. An engineering firm that prescribes a platform without negotiating the backup arrangement leaves the client with the weakest of the four possible negotiating positions.
The four backup arrangements ranked by client sovereignty
The first arrangement is vendor-only backup. The vendor stores the copies on its own infrastructure and offers restore-on-request in the event of an incident. The client does not see the backup, does not audit it, does not hold it. This is the default arrangement in many medium-scale technical SaaS platforms, and the one that grants the least sovereignty. Under an adverse scenario, the client's only path runs through the vendor's willingness and operational capacity.
The second arrangement adds visibility. The client accesses the vendor's portal and sees when the last copies were made, at what size and with what reported integrity. The client does not access the content of the copies but can supervise them. It is an improvement over the first, though in practice the exercise of supervising without the ability to act has a clear ceiling.
The third arrangement is periodic delivery to the client. The vendor deposits a copy of the backup, at a defined frequency — weekly, monthly, according to the agreed cadence — and in a structured format, into a channel the client can reach. The client keeps the copy in their own infrastructure and acquires the ability to restore it, migrate to another platform or simply audit it without depending on the vendor's operational window. This is a defensible arrangement and, for the majority of real scenarios, sufficient.
The fourth arrangement is a client-owned backup destination. The platform deposits the backup automatically into an S3, GCS or Azure Blob bucket the client controls, with access keys residing in the client's cloud. The operation is continuous, requires no periodic delivery, and the client has the backup at hand at any moment. This is the maximum sovereignty technically possible under a SaaS model, and the one an operator with a strategic orientation toward data should aim to negotiate.
What to specify in the technical RFP
An engineering firm that prescribes a long-duration technical platform should include in the RFP a specific backup clause with five concrete elements. The chosen arrangement — from the four above — with a preference for the third or the fourth. The frequency: weekly as the minimum defensible for most cases, daily for critical operations. The format: not a proprietary vendor dump but a structured, documented format — typically a SQL dump with published schema or a multi-table CSV export — accompanied by spatial layers in standard OGC format. Retention on the client side: how long each copy is kept and under what rotation policy. And the scope: what data the backup includes — full asset master, media attachments, work-order history, platform configuration, accumulated telemetry — because a backup that omits relevant pieces is not a useful backup for operational restoration.
The modular consequence
When the platform is designed with a modular architecture, each module can have its own backup arrangement tuned to its operational criticality. The common inventory can be backed up weekly to a client-owned destination; the corrective module with signed field capture can run a daily backup; sensor readings can back up hourly. The client tailors the backup strategy to the nature of the data in each module and avoids the monolithic arrangement that treats all data with the same frequency and destination regardless of operational value. This granularity is not a technical luxury: it is what lets the cost of custodial infrastructure be proportional to the value of the data, rather than a uniform lowest common denominator.
How Maptainer handles it
At Maptainer we support by design the client-owned backup destination with modular granularity. Each active module in the client's deployment can be configured with a specific frequency, format and destination; backups are deposited into the client's own storage via client-managed credentials; and the delivered file includes both the structured schema and the spatial layers in standard OGC format. The practical consequence is that the client can, at any point in the contract, mount a functional copy of their data in their own infrastructure without depending on our operational window. That is a technical commitment most comparable platforms do not include in their standard offering, and one that a serious engineering RFP can demand as a shortlist criterion.
The short clause that does the long work
A well-drafted backup clause in an engineering RFP resolves ninety percent of the vendor lock-in mitigation work that, without it, would need to be done at migration time — with all the burden of negotiating under pressure that moment carries. Vendors who can meet the clause enter the shortlist; those who cannot are filtered out before the first commercial meeting. The clause is short, technical, and it produces a filter that abstract conversations about data sovereignty rarely achieve. An engineering firm that systematically incorporates it into RFPs builds a reputation as a rigorous prescriber, and that is a commercial asset the client recognizes on the second project without the firm needing to defend it.