Approval and SLA Records: A Backup and Retention Case

A service team that runs approvals and SLA tracking in custom software should settle three things before signing the contract: who owns every record type, how long each is kept, and how fast it must come back after a failure. In the planning case below, that meant a written retention schedule by record type, a 4-hour recovery point target, a quarterly restore test and an export clause that works without the vendor's help.

This project case is written by Singapore-based AV and IPTV integrator Prestige Solutions, which also scopes custom software management systems for facilities and service operations. The scenario is a composite built from typical requirements we see during scoping, not a named client: a 40-person facilities service team replacing spreadsheets and email approvals with a system that routes work orders through an approval matrix and reports response and resolution times on an SLA dashboard. Figures are planning targets as of 2026, not measured results.

The starting situation in this case

The team's records were scattered across four places, and none of them had an owner. Approvals lived in email threads, SLA timings were calculated by hand in a shared spreadsheet, photos of completed work sat on technicians' phones, and contractor quotations were attached to whichever email the supervisor happened to reply to. When a client disputed an SLA breach, the team needed half a day to reconstruct what happened and could not prove when an approval was actually given.

The procurement brief therefore started with data, not screens. The service team lead listed every record the new system would create, then asked the same four questions of each: who owns it, who may change it, how long must it exist, and what happens to it when the contract ends.

Record inventory and ownership

Each record type got one business owner and one technical custodian, and the two roles were kept separate. The business owner decides retention and access; the custodian, usually the software vendor or hosting provider, operates backups and restores under instruction. Writing this down early stopped the common assumption that "the vendor owns the database, so the vendor owns the data".

The last row matters more than it looks. When an SLA dispute arises months later, the team must show which approval thresholds were in force on that date, so matrix changes are versioned with an effective date rather than overwritten.

The retention schedule the team adopted

Retention periods were set per record type, because a single "keep everything for seven years" rule over-retains personal data and under-plans storage. In Singapore, the Personal Data Protection Act 2012 requires organisations to stop retaining personal data once the purpose is no longer served, while business and tax records are generally kept for at least 5 years. The schedule below is the planning draft the team took to its own compliance and finance colleagues for confirmation; it is not legal advice.

Two features were written into the requirement so the schedule could actually run: a legal-hold flag that suspends disposal for records linked to a dispute or insurance claim, and a monthly disposal report listing what was deleted, by rule, so the team can prove it followed its own policy.

Backup targets: RPO, RTO and the 3-2-1 rule

Backup requirements were stated as numbers the vendor had to quote against, not as "daily backups included". The team worked out what an outage would cost in practice: after four hours without the system, supervisors revert to phone approvals and the SLA clock loses integrity. That set the targets.

The immutable copy was included because ransomware now commonly targets backups first. A backup that an attacker with administrator credentials can delete is not a recovery plan.

Restore test: the acceptance criteria

A backup counts only after it has been restored, so the contract required a restore test at go-live and every quarter. The team defined pass criteria in advance so that the result could not be argued:

1. Restore the most recent backup to a separate environment, not over production.
2. Record the start and finish time; the total must fall within the 8-hour RTO.
3. Open 10 randomly chosen work orders and confirm notes, photos and approval history are complete.
4. Confirm the SLA dashboard for the previous month reproduces the same breach count as the production report.
5. Confirm the approval matrix version shown for a sample record matches the version in force on that record's date.
6. Confirm the newest record in the restore is no older than 4 hours before the backup timestamp.
7. File a one-page restore report signed by the vendor and the service team lead.

Step 4 is the one most often skipped, and it is the one that proves the SLA figures presented to clients can be rebuilt from backup.

Exit and export: owning the data in practice

Data ownership is only real if the team can leave. The procurement brief therefore asked every bidder to describe the export before the award, and the chosen contract included:

• A full export on request and at contract end, in CSV or JSON for records and original files for attachments, delivered within 10 business days.
• A data dictionary explaining every field, status code and SLA pause reason, so the export is readable without the application.
• Approval history exported with user, timestamp and matrix version, not only the final status.
• Written confirmation of deletion from production and backups after exit, once the team confirms the export is complete.
• No additional fee for one full export per year; further exports at a rate stated in the contract.

The team tested the export clause during user acceptance by requesting a one-month export and loading it into a spreadsheet. If the service team cannot read its own data without the vendor, it does not yet own it.

What the procurement package contained

The final tender package added four data documents to the usual functional specification: the record ownership table, the retention schedule, the backup target table and the restore acceptance criteria. Bidders priced against these, which made quotes comparable and exposed which suppliers treated backup as an add-on. The team also kept a short decision log explaining why each retention period was chosen, so the next reviewer does not have to reverse-engineer the reasoning. More on how we scope operations software and AV systems together is on the Prestige Solutions home page.

FAQ

Can we keep SLA summaries after deleting the underlying work orders?

Yes, if the summaries contain no personal data. Monthly counts of requests, breaches and average response times can usually be kept for trend analysis after the detailed records are disposed of under the schedule.

What should happen to data from a technician who leaves the team?

Disable the account rather than delete it, so approval and job history stay attributable. Records follow the normal retention schedule; the departure itself does not trigger deletion.

How often should the retention schedule be reviewed?

Review it once a year and whenever a new record type is added, such as a new form or integration. A schedule that no longer matches the system's actual data is where over-retention starts.

Recommended next step

Contact Prestige Solutions to review your site drawings and current operating pattern. Call +65 8010 2337, message us on WhatsApp, or email sales@prestigesolutions.com.sg. You can also browse the full product range before the site walk.