A Norwegian organisation procuring cloud-hosted software should ask the supplier to demonstrate how the application can be recovered and how the buyer can leave the service. Request an export that another environment can use, an inventory of dependencies and a controlled recovery exercise. A hosting location alone does not answer those questions.
There is a relevant local distinction. Nkom's data-centre registration guidance, dated 1 June 2026, describes the registration obligation introduced in January 2025 and explicitly says registration is not an approval or licensing scheme. A buyer should therefore avoid treating a supplier's reference to registration as proof of application resilience.
This article proposes an engineering acceptance method, not a determination of regulatory obligations. TuniCyberLabs serves Norwegian buyers remotely. The fictional service organisation below helps distinguish what the hosting provider, application supplier and customer must each demonstrate.
Start with the work that must continue
Imagine an equipment-service company using a hosted scheduling application. Staff need to see open jobs, assign technicians and retrieve the documents required for a visit. Losing a dashboard is inconvenient; losing the ability to identify an urgent open job has a different business consequence.
List the minimum information and actions needed during an interruption. Decide which tasks may pause and which need a manual or alternative process. The business owner should make this decision before the supplier proposes recovery targets.
Avoid accepting a general promise that the platform is backed up. Ask what is backed up, how the backup is accessed when the main account is unavailable and which dependencies must also work to restore the service.
Separate three events that vendors may call recovery
Restoring deleted data, recovering after an infrastructure failure and moving away from a supplier are different exercises. A backup useful for one may not solve the others.
For the scheduling example, point-in-time data restoration should address an accidental deletion. Infrastructure recovery should establish a usable service after a hosting problem. Supplier exit should let the buyer obtain its records and operate an agreed replacement or receiving process.
Write a separate acceptance question for each. This prevents a successful database restore from being presented as evidence that the complete application is portable or that the business can continue through a provider dispute.
Inventory the dependencies that travel with the application
Ask for a map covering the database, object storage, background jobs, identity service, email provider, monitoring, domain and third-party APIs. Identify which accounts the buyer controls and which are supplied under the vendor's service.
For each dependency, record the information and access needed by a receiving team. An application image is not enough if its document storage or authentication configuration remains inaccessible. Equally, an export of tables may omit attachments and the meaning of internal identifiers.
Include licences and operational assumptions in the review. The buyer's commercial and legal reviewers should confirm the rights needed to use delivered components and data. The engineering partner should explain the practical consequences of those arrangements.
Buy an export someone can actually use
Choose representative records containing relationships, history and attachments. Export them using the process promised in the proposal, then give them to a receiving engineer who did not build that exporter.
The acceptance exercise should establish:
- ▸Whether the export includes the agreed records and files.
- ▸How identifiers preserve relationships between records.
- ▸Whether timestamps, statuses and units are understandable.
- ▸Which configuration is necessary to interpret the data.
- ▸How missing or corrupted records are reported.
- ▸Whether the process works without privileged vendor intervention.
- ▸How the organisation can verify the export is complete enough for its purpose.
Keep the scope explicit. A usable data export does not automatically recreate a proprietary application. Agree whether exit means operating delivered source code, importing into a replacement product or retaining a readable archive.
Rehearse recovery with the receiving team
Use a controlled environment and an approved test plan. Have the team restore a representative dataset, start the required services and complete a real business task. Record the observed sequence, interruptions and unresolved dependencies.
Measure the exercise rather than copying an aspirational target into a report. If restoration requires a supplier employee to locate an undocumented key, that is a finding to resolve. Repeat the affected step after the handover material is corrected.
Also review what changed outside the restored database. Documents uploaded later, notifications already sent and actions completed in connected systems may need reconciliation. The recovered application should not repeat a business action merely because its local history is older.
Ask what the geographic claim covers
A proposal may mention a Norwegian facility or cloud region. Request a service-by-service description of where application data, backups, support access and connected processing occur. Review the actual configuration and contractual scope rather than relying on a country flag on a sales page.
The appropriate locations and access arrangements depend on your organisation's requirements. A remote engineering team can work within an agreed access model, but the model needs to be specified and verifiable.
Keep facility matters separate from application matters. Ask the relevant provider about its responsibilities, and ask the software supplier about deployment, records, credentials and recovery. No single label should silently stand in for that responsibility map.
Make exit a maintained capability
Agree what triggers another export or recovery exercise: a major schema change, replacement of a managed service or a transfer of operational responsibility. A one-time demonstration becomes less useful if the application later acquires undocumented dependencies.
Name an owner for the runbook and the accounts needed to execute it. The handover should let the buyer locate the most recent evidence, known limits and escalation contacts without asking the original project manager.
Use the software handover and ownership guide to prepare the receiving team and the vendor scorecard to compare proposals.
Explore software engineering services and request a Norwegian cloud exit review. Bring your application boundary, current providers and the business task a recovery exercise must restore.