|
|
| Document ID |
ISMS-PRO-001 |
| Version |
0.1 |
| Status |
Draft |
| Classification |
Internal |
| Owner |
Information Security Officer |
| Approved by |
Managing Director |
| Approval date |
pending |
| Effective from |
pending |
| Next review |
pending — annually, or on material change |
| Implements |
Backup Policy; Annex A.8.13, A.5.30 |
This procedure governs every restore of customer data performed by
BackupExperts, whether triggered by a customer request, by an internal
incident, or by scheduled restore testing. It ensures that restores are
authorised, executed correctly, verified, and recorded.
Applies to:
- Restores to original location or to an alternate location.
- File / object level, system / image level, and full DR-class
restores.
- Test restores performed for the purposes of Backup Policy section 7.
It does not apply to BackupExperts' internal restore of its own
non-customer systems, which follow the same control principles but are
recorded against ISMS internal records rather than customer-facing
ones.
| Term |
Meaning |
| Requester |
The party asking for the restore. May be the customer, BackupExperts on the customer's behalf during incident response, or the Information Security Officer for a test. |
| Authorised contact |
An individual at the customer recorded in the customer onboarding document as authorised to request a restore. |
| Operator |
The BackupExperts technician executing the restore. |
| Reviewer |
A second BackupExperts staff member who verifies authorisation and (for high-impact restores) the result. |
| High-impact restore |
A restore that overwrites live customer data, restores ≥ 100 GB, restores credentials or authentication material, or is performed during an active incident. |
The Operator shall not initiate any restore until the following are
confirmed and recorded.
- Ticket exists. The restore is captured as a ticket with a unique
ID, the requester, and the requested scope (which data, point in
time, target location).
- Requester is authorised. The requester appears on the customer's
list of authorised contacts, recorded in the customer's onboarding
document under /customers/<slug>/onboarding (authored per
customer, not centrally). If the requester is not on the list, the
Operator stops and escalates per Incident Response Policy
— an unauthorised restore request is treated as a potential security
event.
- Identity is verified by callback. Restore requests typically
arrive by phone. Identity is verified by calling the requester
back on the recorded telephone number from the customer's
onboarding document — never on a number provided in the inbound
call itself. For requests arriving by other channels (email,
ticket), the same out-of-band callback is performed before any
action. The verification method, the contacted person, and the
number used are recorded in the ticket.
- Scope is unambiguous. The data set, the point-in-time, and the
target location are stated in writing. If any of these is
ambiguous, the Operator obtains written clarification before
proceeding.
- Reviewer sign-off (high-impact restores only). For a high-impact
restore, a second BackupExperts staff member confirms in the ticket
that authorisation and scope have been verified. The Reviewer must
not be the same person as the Operator.
- Source backup exists and is intact: the catalogue resolves the
requested point-in-time, and an integrity check (where the backup
technology supports one) passes.
- Target capacity is sufficient. Free space on the target equals
or exceeds the restored data plus a 20% margin.
- Overwrite check. If the restore overwrites existing customer
data, the Operator confirms in the ticket that the customer has
explicitly requested overwrite. Where feasible, the Operator first
restores to an alternate location and then promotes, rather than
overwriting in place.
- Credentials. The Operator uses the credentials designated for
restore operations, not personal credentials and not the
credentials used for routine production access. MFA is required.
- Announce. The Operator notes start time in the ticket and, for
customer-impacting restores, notifies the customer that execution
has begun.
- Execute the restore per the technology-specific instructions
referenced from the backup configuration runbook
(planned) for this customer.
- Monitor for failure. The Operator does not leave the restore
unattended. Errors and warnings are captured verbatim in the
ticket.
- Pause on anomaly. If the restore produces an error, an
unexpected size delta of more than 10%, or any indication of
integrity loss, the Operator stops, captures evidence, and
escalates before proceeding further.
- Technical verification. Operator confirms that the restored
data is present at the target and matches expectation:
- File / object: file count and total size match the source
catalogue within tolerance; spot-check by checksum where the
backup technology provides them.
- System / image: system boots (or equivalent for the platform);
core services start; sample data is readable.
- Credentials / secrets: never restored to a location accessible
to staff outside the operator-and-reviewer pair; rotated
immediately after restore unless the customer instructs
otherwise in writing.
- Customer verification. For customer-requested restores, the
customer is asked to confirm the restore meets their need before
the ticket is closed. The confirmation is captured in the ticket.
- Update the backup test log (planned)
if the restore was a scheduled or ad-hoc test. Required fields:
- Customer, data set, backup tier
- Date / time / operator / reviewer
- Test class (file / system / DR)
- Outcome (pass / partial / fail) and verification method
- Any nonconformity raised
- Update the incident register (planned)
if the restore was triggered by an incident, linking the ticket
and the post-mortem.
- Update the change log (planned) if
the restore changed the live customer environment.
¶ 9. Failure handling
If the restore cannot complete:
- The customer is informed without delay.
- The cause is investigated and treated as a security event under
Incident Response Policy if
there is any indication of integrity loss, tampering, or
ransomware.
- A nonconformity is opened in Audits → Nonconformities
(planned) if the failure indicates a control weakness rather than
a one-off operational issue.
- A post-mortem is written for any incident-class failure or any
customer-impacting test failure.
Restore tickets, the backup test log entries they generate, and any
linked incident records are retained in line with the retention rules
in the Statement of Applicability
(planned) — at minimum three years, longer where law or the
customer contract requires.