How we protect the records auditors read.

They are different measures. Uptime measures how much of the month a hosted service is available. A response target measures how quickly a person at S.G. Systems starts working on your issue. For critical (Severity 1) issues that is 2 hours, 24/7/365. It is not uptime, automated recovery or a guaranteed fix time.

• Uptime, backups, RPO/RTO and service credits apply only to V5 Ultimate Cloud and Private Cloud, under the S.G. Systems SLA (§5 and §6).
• Severity 1 (critical): a person from S.G. Systems responds within 2 hours, 24/7/365, for every supported deployment, including V5 Classic and on-premises. Hosted services also keep a 1 business hour target during business hours. Other severities run in business hours.
• A response time is when a person starts working on the issue. It is not a fix time, an automated recovery, an uptime figure or a recovery objective.

Terms: SLA §4 response targets · SLA §5 hosted service levels · SLA §6 service credits. Link to this answer

A Severity 1 incident gets a human initial response from S.G. Systems within 2 hours, 24/7/365, whether you bought directly or through a reseller, and is worked with engineering until service is restored. You can always report directly to S.G. Systems; the clock starts when your report reaches the S.G. Systems support channel.

• The commitment is set in the S.G. Systems SLA §4.1. Severity 2 to 4 targets run in business hours (09:00-18:00 local, weekdays) unless your Order says otherwise.
• Orders that accepted MSA V1.24 keep their accepted support terms until renewal on the new documents.
• Security incidents follow the notification commitment in Commercial Terms §9.2.

Terms: SLA §4.1 critical support · SLA §3 reporting an issue · Commercial Terms §9.2 security incidents. Link to this answer

The V5 Ultimate application runs on Google Cloud Run. The database, sign-in and file storage run on Supabase, which operates on Amazon Web Services. Independent backup and archive copies are kept in Google Cloud Storage. Source code and deployments are managed in GitHub.

• This describes the V5 Ultimate application. The public marketing website is hosted separately and holds no Customer Data from the application.
• Operating servers in more than one location does not by itself provide failover for the database or for a whole provider.
• The sub-processors that process Customer Data are listed on the Sub-processors page.

Terms: Sub-processors. Link to this answer

The V5 Cloud application runs in two locations, the Netherlands and Oregon (United States), and traffic is shared between them, so a visitor may be served from either. The database, sign-in and file storage remain in Oregon, United States, so EU-only data storage is not implied. The locations of your database, files and recovery copies are confirmed for your deployment.

• As recorded on 30 September 2026, the database, sign-in and files were in Oregon (AWS, via Supabase) and independent backup copies in a Google United States multi-region location. Which of these apply to your deployment is confirmed in your Order.
• Running the application in the Netherlands does not mean every part of the service, or every backup, is held in the EU. Ask us to confirm each layer for your deployment.
• On-Premises customers keep data in their own environment.

Terms: On-Premises specification. Link to this answer

Contractually, the S.G. Systems SLA sets an RTO of 8 hours for Severity 1 incidents on Cloud and 4 hours on Private Cloud. Internally we work to a 4-hour target for restoring the complete service, but that target is provisional and has not yet been proven in a full recovery exercise.

• The internal 4-hour figure is an objective, not a tested result, and does not replace the contract.
• A complete takeover of production at another provider has not yet been exercised end to end (see Latest recovery test).

Terms: SLA §5.1 Cloud · SLA §5.2 Private Cloud. Link to this answer

Contractually, the S.G. Systems SLA sets an RPO of 24 hours on Cloud and 12 hours on Private Cloud. How much data could be lost in practice depends on what fails: if data is corrupted while our database provider is still running, we aim to recover to within about 5 minutes; if the provider itself is unavailable, the latest independent database copy can be up to about 24 hours old, plus the time taken to recover.

• The 5-minute figure is a working objective for that one scenario and is still being qualified. It is not a guaranteed data-loss limit for the whole service.
• Private Cloud backup timing is deployment-specific. Ask for the evidence for your deployment before relying on a figure other than the SLA.

Terms: SLA §5.1 Cloud · SLA §5.2 Private Cloud. Link to this answer

Point-in-time recovery is switched on for the database, and a full independent copy of the database and files is taken every day. Files are also copied on a separate 5-minute schedule, and archive transfers run hourly.

• Point-in-time recovery is configured for 7 days. The history actually available varies and has recently been slightly under 7 days, so we do not promise an uninterrupted 7-day window.
• The 5-minute schedule applies to files only. The whole database is not copied every 5 minutes.
• The S.G. Systems SLA commitment for Cloud is encrypted backups every 24 hours (§5.1).

Terms: SLA §5.3 disaster recovery. Link to this answer

Rolling recovery copies are kept for at least 30 days and operational evidence for 365 days. Scoped manufacturing and contract-signature records are also archived with a 15-year minimum retention setting. No automatic deletion of archives is currently enabled.

• The archive retention setting is not yet locked, so it can be changed by administrators. We do not describe it as tamper-proof (WORM) storage, and proving that complete, readable historical records can be produced for the full period is still in progress.
• Backup retention is separate from your contract rights. After termination, Customer Data is retrievable on request for 90 days under Commercial Terms §5.4 (MSA §5.4 for prior Orders), then deleted from active systems subject to the DPA, legal holds and backup rotation. You remain responsible for your own regulatory record retention (§7.3).

Terms: Commercial Terms §5.4 after termination · Commercial Terms §7.3 data retention. Link to this answer

On 30 September 2026 we restored the previous day's real backup copies into an isolated environment. The database tables, rows and available files were checked, stored signature hashes were verified, and a sample of encrypted values was successfully decrypted.

• Not yet proven: a full production takeover at another provider, a hosted point-in-time restore, restoring original passwords, MFA and single sign-on, every external dependency, and end-to-end service timings.
• A separate test showed application traffic rerouting in about 79 seconds. That was an application-only routing test, not a database recovery and not a service-level commitment.
• Our policy requires restore tests at least every 90 days and an annual regional or provider exercise.

Link to this answer

We have a documented backup and recovery policy and operating guide (current versions dated 30 September 2026). A summary and the latest test evidence are available on request, usually under NDA. We do not currently publish a separate, broader business continuity plan, and we don't claim one beyond what those documents cover.

• The infrastructure programme behind the policy closed with recorded exceptions. That is not a blanket compliance approval.
• An approved assessment (rev 3, 25 September 2026) covers the V5 Ultimate 5.10 manufacturing technical controls. It does not cover the QMS or QC areas and is not a disaster-recovery certification.
• The S.G. Systems SLA §5.3 commits to a disaster recovery plan and periodic recovery testing.

Terms: SLA §5.3. Link to this answer

The Commercial Terms (MSA V1.24 for prior Orders) commit to encryption for hosted services and encrypted backups. Connections from users to the service use TLS. We are confirming the exact algorithms and scope for each layer, and share that confirmation on request rather than publish unverified detail.

• One internal connection, between the database connection pooler and the database, is still being confirmed. For that reason we don't claim end-to-end encryption.
• On-Premises customers manage their own encryption and keys.

Terms: Commercial Terms §7.3 · Commercial Terms §9.1 security. Link to this answer

Without undue delay and in any event within 72 hours of becoming aware of a Security Incident, followed by a detailed report within 3 business days. The clock runs from awareness, not from later confirmation. Any shorter period required by law or the DPA applies.

Terms: Commercial Terms §9.2. Link to this answer

Yes. You can export using the software's standard export methods during the subscription and for 90 days after termination on request. Standard exports are not charged as migration services. Custom formats or extra work need a separate written agreement.

• Standard exports keep records linked to their audit trail and e-signature information as far as the export format allows.

Terms: Commercial Terms §12.5 data export · Commercial Terms §5.4 after termination. Link to this answer

We don't publish insurance limits. Ask us for current certificates and we will share them through the document request below.

Link to this answer

Payment and deposit terms are set in your Order and the applicable commercial terms. Requests to change them are reviewed by our commercial team; nothing is agreed until it is confirmed in writing.

Terms: Commercial Terms Section 6 fees and payment. Link to this answer

The current Commercial Terms (§17) limit total liability to the fees paid under the applicable Order in the 12 months before a claim, subject to its agreed terms and exceptions. Requests to change the cap are reviewed by our commercial team and apply only once agreed in writing.

Terms: Commercial Terms §17.1. Link to this answer