Security & trust · Backup and recovery
Your records, protected in layers — and honest about what is proven.
What V5 Ultimate backs up, where the copies live, how long records are kept, and what each kind of failure means for recovery. Written so you can forward one link to your quality, IT and procurement reviewers.
- Four distinct copies: recovery points, daily independent copies, file captures and a long-term archive.
- Independent copies held with a different cloud provider (recorded 30 September 2026 in a US multi-region location).
- Contract commitments stay in the SLA; this page explains how the service runs.
Executive evidence summary
The short version for your reviewer
- Scope
- V5 Ultimate Cloud and Private Cloud. On-Premises is hosted and backed up by the customer.
- Where data lives
- EMEA and EU deployments run on servers in the Netherlands; deployments for the rest of the world run in Oregon, United States. The locations of your database, files and recovery copies are confirmed for your deployment.
- Copies kept
- Database recovery points (7 days configured), a daily independent full copy of database and files, 5-minute file captures, and an hourly archive for scoped records.
- Retention
- Rolling recovery copies at least 30 days; operational evidence 365 days; scoped records archived with a 15-year minimum setting.
- Latest recovery check
- 30 September 2026: the previous day's real copies restored into an isolated environment; tables, rows, available files, signature hashes and a sample of encrypted values checked.
- Status at 2 October 2026
- Backup and restore controls are documented, and a supplier assessment has been completed; it is provisional and under internal verification before external issue. Some controls are only provisionally in place. It is not a recovery qualification: complete end-to-end service recovery evidence, including measured restore time, is still required.
- Contract commitments
- Set by the S.G. Systems SLA (§5) and your Order — not by this page.
- Human response
- Severity 1: a person at S.G. Systems responds within 2 hours, 24/7/365. That is a response time, not uptime or a recovery time.
Summarised from S.G. Systems' internal backup and recovery policy and operating guide (current versions dated 30 September 2026) and the latest recovery check. Those documents are not published; summaries and test evidence are shared on request, usually under NDA. Last reviewed 2 October 2026.
What is protected
Four different copies, each with a different job
A database recovery point alone is not a full recovery: it does not contain file bytes. These layers are kept separate on purpose.
Database recovery points
Point-in-time recovery for the database, configured for 7 days.
Database rows only. It does not contain file bytes.
Independent full copies
A full independent copy of the database and files, taken every day.
Kept in Google Cloud Storage, a different provider from the primary database.
Separately captured files
Attachments and documents copied on their own 5-minute schedule.
Files only. The whole database is not copied every 5 minutes.
Long-term record archive
Scoped manufacturing and contract-signature records, with a 15-year minimum retention setting.
Archive transfers run hourly. Not locked, so not described as tamper-proof (WORM).
A usable recovery needs more than data
- User identities and permissions
- Attachments and documents
- Audit trail and e-signature links to their records
- Configuration and master data
- The keys needed to read encrypted values
- Separation between customer workspaces
Failure scenarios
What happens depends on what fails
Choose a scenario to see which copy is used, how old the recovered data could be and what has not yet been proven. These are working descriptions, not service commitments.
- App routing
- Database recovery points · used
- Independent full copies
- Separately captured files · used
- Long-term record archive
A bad change or corrupted data
Data is damaged while the database provider is still running.
- Copy used
- Database recovery points, plus file copies for attachments.
- How old the data could be
- Working objective of about 5 minutes for this scenario only. Still being qualified; not a guaranteed limit.
- Not yet proven / not covered
- A hosted point-in-time restore has not yet been proven in a recovery exercise.
| Scenario | Copy used | How old the data could be | Not yet proven / not covered |
|---|---|---|---|
| A bad change or corrupted data | Database recovery points, plus file copies for attachments. | Working objective of about 5 minutes for this scenario only. Still being qualified; not a guaranteed limit. | A hosted point-in-time restore has not yet been proven in a recovery exercise. |
| Lost or damaged files | Separately captured file copies and the daily independent copy. | Depends on when the file was last captured; ask for the evidence for your deployment. | Recovering a file is not the same as restoring the record links around it — those are checked separately. |
| An application server location has a problem | Application-level routing only, where configured. Current regions are confirmed on request. | No data is restored — the database is not involved. | Application routing does not provide failover for the database, sign-in, files or keys. |
| The primary database provider is unavailable | The latest independent copy in Google Cloud Storage. | The latest independent database copy can be up to about 24 hours old, plus the time taken to recover. | A full production takeover at another provider has not yet been exercised end to end. There is no automatic takeover. |
| You need an old record years later | The long-term record archive for scoped records. | Not a recovery-time question — it is about retention and retrievability. | Proving complete, readable historical records for the full period is still in progress. |
A data-age objective never permits silently losing acknowledged manufacturing or signature records. After any restore, people reconcile critical records before work resumes.
Retention vs backups
Backups are for recovery. Retention is for records.
Rolling backups let us recover recent service. Record retention keeps required records complete and retrievable, with their audit and signature context, for as long as they must be kept.
- Rolling recovery copies: at least 30 days. Not every nightly copy is kept for years.
- Scoped record archive: 15-year minimum retention setting for scoped manufacturing and contract-signature records. That was a specific internal requirement — not a legal retention period for every customer or record.
- Not WORM: the archive setting is not locked and can be changed by administrators, so we do not call it tamper-proof storage.
- Your schedule: your record retention schedule, when retention starts and any legal holds are yours to set (Commercial Terms §7.3). Exports remain available 90 days after termination (§5.4).
Geographic resilience
Separate places, separate providers — with clear limits
| Layer | Provider | Location |
|---|---|---|
| Application | Google Cloud Run | EMEA/EU deployments: the Netherlands. Rest of world: Oregon, United States. Confirmed for your deployment |
| Database, sign-in and file storage | Supabase, running on Amazon Web Services | United States — Oregon (as recorded 30 September 2026); confirmed for your deployment |
| Independent backup and archive copies | Google Cloud Storage | United States multi-region (as recorded 30 September 2026); confirmed for your deployment |
| Source code and deployment tooling | GitHub | Not a store of Customer Data |
- Keeping copies in another region and with another provider protects the data. It is not, by itself, a ready-to-run second copy of the whole service.
- Copies are replicated asynchronously, so the newest changes may not yet be in the independent copy when something fails.
- We do not offer automatic takeover by another region or provider. EMEA/EU deployments run in the Netherlands and the rest of the world in Oregon, US; where your database, sign-in, files and recovery copies sit is confirmed for your deployment.
Testing and evidence
What has been tested, and what is still required
Done
- 30 Sep 2026: isolated restore of the previous day's real copies; tables, rows and available files checked.
- Stored signature hashes verified and a sample of encrypted values decrypted.
- Application traffic rerouting test (about 79 seconds) — application only, not a database recovery or commitment.
- 2 October 2026: supplier assessment completed — provisional, under internal verification.
Still required
- A complete end-to-end service recovery, with measured time from incident to usable service.
- A hosted point-in-time restore and a full takeover at another provider.
- Sign-in, access denial, MFA and single sign-on after restore, plus every external dependency.
- Readable exports and reconciliation of critical records.
Our policy requires restore tests at least every 90 days and an annual regional or provider exercise. Technical checks such as hashes and integrity signatures are evidence; people authorize recovery and return to service, and independent review is separate from S.G. Systems operations. None of this is a whole-system compliance certification.
Shared responsibilities
Who does what, by deployment
V5 Ultimate Cloud
S.G. Systems
Hosting, backups, recovery copies and recovery exercises; SLA §5.1 commitments.
You
Intended-use validation, your retention schedule, user access decisions and approving return to use.
Private Cloud
S.G. Systems
A separate database and software instance in managed hosting; SLA §5.2 commitments. Backup timing is deployment-specific.
You
The same customer decisions, plus confirming deployment-specific evidence before relying on it.
On-Premises
S.G. Systems
The software, its documentation and support.
You
Hosting, backups, encryption keys, recovery and testing in your own environment.
Enterprise IQ/OQ and validation support; scope confirmed in your quote. Customer plans, runs and approves PQ and intended-use validation as applicable.
Questions buyers ask
Straight answers
How often is the database backed up?
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).
How long are backups and records kept?
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).
Commercial Terms §5.4 after terminationCommercial Terms §7.3 data retention
What is the Recovery Point Objective (RPO)?
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.
What is the Recovery Time Objective (RTO)?
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).
When was recovery last tested, and what did it show?
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.
Do you have a business continuity and disaster recovery policy?
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.
How is data encrypted?
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.
Where is our data stored geographically?
EMEA and EU deployments run on servers in the Netherlands; deployments for the rest of the world run in Oregon, United States. 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.
- A Netherlands server location does not by itself 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.
What happens in a critical outage, and is support 24/7?
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.
SLA §4.1 critical supportSLA §3 reporting an issueCommercial Terms §9.2 security incidents
Is there an uptime SLA, and how does it differ from a 2-hour response?
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.
SLA §4 response targetsSLA §5 hosted service levelsSLA §6 service credits
Need the detailed evidence for your review?
Policy summaries, recovery-test evidence and deployment-specific details are shared on request, usually under NDA. For contract terms, see the S.G. Systems SLA; for everything else, the Security & Trust page.