Choose cloud when fast deployment, remote access and transferring day-to-day administration to the vendor matter. Choose on-premise when a specific legal, network or operational requirement calls for a client-controlled environment, and you have a team that can maintain it. If neither option meets RTO, RPO, connectivity or security requirements, the result should be “no-go” until the architecture changes.
In short
- “Cloud” and “on-premise” describe where responsibility sits, not the security level.
- Start with failure impact, RTO, RPO, connectivity and the alarm procedure.
- On-premise without updates, backups and on-call support gives formal control, but may increase operational risk.
- SaaS still requires account management, integration, the contract and an exit plan on the client side.
- No-go is the correct decision if the platform is meant to replace local real-time protection.
This is not a server dispute. It is a split of responsibility
NIST SP 800-145 defines cloud computing as on-demand network access to a shared pool of configurable resources that can be rapidly provisioned and released. In the SaaS model, the user consumes the application while most of the technical stack remains on the vendor side. On-premise means that the software runs in infrastructure controlled by the client or an operator indicated by the client.
RTO (recovery time objective) is the target time to restore a service after disruption. RPO (recovery point objective) is the acceptable point of data loss expressed in time. They matter more than the hosting label, because they answer two business questions: how long can we be without the platform, and how much recent data can we lose.
For structural monitoring, a third question must be added: what happens in the field when the platform or the connection is unavailable? If the measuring device stores data locally and sends it later, a temporary loss of the panel has different consequences than in an architecture that loses measurements without a link. If a signal must trigger an immediate machine shutdown, the remote application should not be the only protection layer; appropriate local logic and a procedure designed by the right specialists are needed.
That is why the question is not “is the facility critical?”. It is: which functions must work locally, which can return within RTO, where data are buffered, who is responsible for updates, and how we will prove recovery.
Cloud / on-premise / no-go matrix
The table is for initial screening. A single answer does not settle the whole matter, but a red field should become a blocking condition or an architectural task.
| Condition | Cloud/SaaS | On-premise | No-go until change |
|---|---|---|---|
| Access for a team from multiple locations | Natural fit | Requires secure remote access | No approved access path |
| The facility link is sometimes unavailable | Works with buffering at the field edge | Also requires field buffering | Data disappear without internet |
| Ban on storing data outside the client environment | Usually not a fit | Natural fit | No compliant deployment option |
| No 24/7 administration team | Vendor maintains the service stack | High operational risk | No one owns the incident |
| Very short start-up time | Usually better | Depends on the client’s IT process | The deadline skips security testing |
| Required integration with an isolated OT network | Requires a controlled gateway | May fit a local segment | Prohibited and undocumented boundary |
| Required own maintenance windows | Agreed in the service SLA | Full client control | No update process |
| Required scaling across many facilities | Natural fit | Client plans the capacity | No capacity planning owner |
| RTO and RPO confirmed by test | Depends on the vendor contract | Depends on the client team | They are only declarations |
| Real-time safety function | Not as the only layer | Only with the right architecture | The platform is meant to replace protection |
“Natural fit” does not automatically mean requirement met. The SaaS vendor must show the scope of backup and recovery. The on-premise client must demonstrate the same level of detail through its own process. In both variants, the proof is a test, not the location of the server cabinet.
Five decision areas: from failure impact to exit plan
1. Business function and impact of unavailability
List separately: ingest of measurements, storage, display, calculations, alarms, alarm acknowledgement, export and administration. For each function, define the maximum tolerated outage. The panel may be unavailable for an hour, but the data may not disappear. A report may wait a day, but the duty operator must be informed of lost transmission sooner.
This analysis prevents buying “high availability” for the whole application when only two paths are critical. It also helps identify a function the platform should not perform, for example direct local shutdown of a process device.
2. IT/OT flow and identity
NIST SP 1800-32 shows, for industrial IoT, the importance of communication integrity, network monitoring, authentication, access control and secure edge-to-cloud flow. It is not a ready-made pattern for structural monitoring, but it is a good catalogue of boundary questions.
Draw the path from sensor to user: device, logger, field network, telecom operator, gateway, API, database, browser and notification channel. At each boundary, specify the protocol, authentication, the owner of certificates or secrets, and how they are rotated. On-premise does not remove these boundaries; it often adds VPN, reverse proxy and dependence on the client’s identity directory.
3. Operations, updates and vulnerabilities
In SaaS, the vendor usually updates the application and infrastructure, but the client is still responsible for its own accounts, alarm recipients, devices and configuration. In on-premise, updates must be assigned for the operating system, database, containers, libraries, certificates and backups. “IT department” is not the owner until a specific service enters its catalogue, monitoring and on-call duty.
Also define maintenance windows and the procedure for critical patches. Full version control on the client side is an advantage only when the organisation actually installs patches, tests them and can react quickly.
4. Continuity, backups and recovery test
NIST SP 800-34 Rev. 1 organises continuity planning as part of risk management and the system life cycle. For a monitoring platform, you need at least an inventory of dependencies, function priority, RTO, RPO, recovery procedure, incident communication and a recurring test.
Ask whether the backup includes only measurements, or also configuration, accounts, thresholds, audit data and files. Test the restoration of a full project in an isolated environment. A backup that has never been restored is a hypothesis.
5. Cost and exit
SaaS has a visible subscription fee, while on-premise hides part of the cost in infrastructure time, administrators, cybersecurity, backups and updates. Compare the same five years and the same RTO/RPO. Add data transfer, SMS messages, test environment, monitoring, certificates, audit, support and migration.
In both variants, define the format of the full data handover, the deadline, the cost and the support. 12 clauses on data ownership help here. A server located at the client’s site does not guarantee portability if the database uses a closed schema and only the vendor knows the configuration.
Fifteen questions for IT/OT before choosing hosting
Function and availability
- Which functions must work during loss of the facility link?
- What are the RTO and RPO for each critical function?
- Do the devices store data for later transmission?
- Is the remote platform informational, or does it control the process?
Data and integrations
- What data classes are created and where may each of them be located?
- How do data cross IT/OT boundaries, and who approves the connection?
- Is integration with an identity directory, SIEM or archive needed?
Security
- Who grants, reviews and revokes accounts and roles?
- Who rotates secrets, certificates and device access credentials?
- How is an incident detected, reported and handled?
Maintenance
- Who updates each layer, and in which window?
- Who monitors the service 24/7, and who receives the technical alarm?
- When was the full project last restored from backup?
Contract and exit
- What is the five-year TCO at the same service levels?
- How will we retrieve the data, configuration and audit trail after the cooperation ends?
Each answer should contain a person or team, evidence and a deadline. If the answer is “it depends on the vendor”, the requirement belongs in the request. If the answer is “the client will do it”, it must be included in the client’s operating model and budget.
Illustrative example: a facility with unstable connectivity
Illustrative example. A remote facility has periodic transmission outages. The team assumes that an on-premise installation at headquarters will solve the problem. It does not, because the same link still operates between the facility and headquarters. The application has moved, but the field resilience has not changed.
The function analysis shows that the logger must keep measurements locally and send them after connectivity returns, using the original timestamps. The platform should accept the history without creating duplicates. Separately, it must be defined when the lack of fresh data triggers the NO_DATA state and who reacts.
After these conditions are met, both SaaS and on-premise may be technically possible. The decision is then determined by organisational requirements, security, maintenance cost and exit. The numbers and times in a real project must come from risk analysis; the scenario is for illustration only.
What this looks like in Inclify
Inclify is delivered by default as an online service accessible through a browser. The platform technically operates as a set of containers, so a client-infrastructure variant can be discussed, but it requires individual agreement and is not a standard offer. Do not assume on-premise compatibility without confirmation of scope, responsibilities, updates and support in the specific contract.
Measurements reach the platform via HTTP/JSON with UTC time. Measurements are not deleted automatically, and older history is compressed. Raw device request and response logs have a separate, configurable retention period, seven days by default. Access is divided between three organisational roles, and customer data are isolated. Export covers CSV for tabular data, chart image and XLSX for dynamic analyses; there is no PDF export.
Before choosing the deployment model, the team should agree RTO, RPO, responsibility for devices and links, and the technical method of data handover. Broader functional requirements are organised by the platform selection checklist. The platform itself should not be treated as a local real-time safety controller.
Hosting decision checklist
- [ ] We mapped functions, not just infrastructure components.
- [ ] Every critical function has an RTO, RPO and owner.
- [ ] We know what happens to a measurement during a link loss.
- [ ] The remote platform is not the only real-time protection.
- [ ] We have a data flow and IT/OT boundary diagram.
- [ ] Data location and data classes are approved.
- [ ] Device, user and service identity has a lifecycle process.
- [ ] Client and vendor roles are written down for each layer.
- [ ] Critical updates have a path beyond the normal window.
- [ ] Backups include measurements, configuration, audit data and files needed for recovery.
- [ ] Full recovery has been tested.
- [ ] Five-year TCO includes people, tools and security.
- [ ] Export and exit have been checked on a sample.
- [ ] On-premise requirements were confirmed by the vendor, not assumed.
- [ ] We can say “no-go” if the architecture does not meet a critical condition.
If the decision “we will build it locally” appears as an alternative to buying, also read build, buy and hybrid comparison. Hosting is only one axis of it.
Limitations: when a separate analysis is needed
This matrix does not replace a cybersecurity risk analysis, information classification, sector-specific requirements or a functional safety design. For facilities and organisations subject to special regulations, legal review and the involvement of teams responsible for OT, business continuity and data protection are needed.
NIST SP 1800-32 concerns a specific industrial IoT example in the energy sector. We use it as a catalogue of patterns, communication integrity, network monitoring, authentication, access control, not as a declaration that a structural monitoring platform complies with the reference solution.
Public product pages show that the market offers different models. Bentley describes iTwin IoT as a web application and a cloud-native product, and Sixense states for Beyond Monitoring SaaS in the cloud and an on-premise variant for sensitive facilities. This does not mean equivalence of scope, safeguards or contractual terms. These must be compared in the current offer.
FAQ
Is on-premise safer than cloud?
Not by definition. On-premise gives the client more control over the environment, but also responsibility for updates, accounts, backups, monitoring and incidents. Cloud shifts part of these tasks to the vendor, but requires assessment of the vendor’s safeguards and contract. Security comes from architecture, process, people and tests, not from the physical location of the server.
Does critical infrastructure always require local installation?
Such a universal rule cannot be assumed. Requirements depend on the sector, data class, specific function, threat model and applicable regulations or organisational policies. Some functions may require local deployment, while others can operate remotely. The decision should be documented by risk analysis and approved by the relevant legal and IT/OT teams.
Will monitoring work without internet?
That depends on the entire architecture, not on the hosting model of the platform. The key point is whether the device or logger stores measurements during the outage and sends them later with the original time. Access to the remote panel and notifications may then be unavailable. The required behaviour should be tested on the actual device and connection.
How do you define RTO and RPO for a monitoring platform?
Start with the business impact: how long can you do without seeing data, and how much historical loss is acceptable. Set the values separately for ingest, alarms, the panel, reports and administration. Align them with the measurement cadence and the response procedure. Then verify whether the architecture and contract allow the targets to be met, and confirm them with a recovery test.
Who is responsible for security in SaaS?
Responsibility is shared. The vendor usually maintains the application and the service infrastructure. The client still manages its own users, notification recipients, devices, configuration correctness, data classification and the use of exports. The exact boundary must be written into the contract, including incidents, subcontractors, notification times and the method of data retrieval.
When should you choose “no-go” instead of compromise?
When an unresolved condition may prevent safe operation: no buffer with unstable connectivity, the platform as the only real-time protection, unacceptable data location, no update owner, or untested recovery at the required RTO. No-go does not have to end the project. It means the architecture or scope must change first.
Sources and further reading
- NIST SP 800-145 – The NIST Definition of Cloud Computing, NIST.
- NIST SP 1800-32 – Securing Distributed Energy Resources: An IIoT Cybersecurity Example, NIST.
- NIST SP 800-34 Rev. 1 – Contingency Planning Guide, NIST.
- iTwin IoT – official product page, Bentley Systems.
- Beyond Monitoring – official platform page, Sixense.
- NIST SP 800-218 – Secure Software Development Framework, NIST.
Next step: bring requirements, not a hosting preference
In a short meeting, we will go through RTO, RPO, the IT/OT flow, retention, roles and exit. On that basis, we will assess the standard online service and whether there is justification for an individual discussion about a client environment. Book an implementation requirements review - the result may just as well point to a no-go condition.