Viewee resilience pack: Backup & Restore Policy and Incident Response Plan

Status: DRAFT v0.1 - 16 September 2026 - prepared for founder review. Both policies are grounded in NCSC and ICO guidance (sources at the end of each part).

Context: Viewee is an early-stage SaaS for UK adult social care providers. It collects and stores feedback from residents, families and staff, plus actions and evidence of change. Some of this data will be special category data (health and care circumstances of identifiable people), so backup and incident handling must assume UK GDPR obligations from day one. Stack direction: Astro front ends, an application plus API, cloud hosting in a UK/EEA region.

Reading the markers: anything that depends on an infrastructure decision not yet made is tagged [TBD - infra decision]. Those lines are policy intent, not commitments, until the hosting platform, database and storage choices are final.

Part 1 - Backup & Restore Policy (DRAFT)

1.1 What gets backed up

1.2 Redundancy and location

• Primary data and backups stay in UK/EEA regions, matching Viewee's data-residency commitment to care customers.

• Backups are replicated to a second UK/EEA region, separate from the primary region [TBD - infra decision: region pair].

• At least one copy is logically separated from production: different credentials, no write path from the application, and immutability/object-lock where the provider supports it. This follows the NCSC principle that attackers actively target backups during destructive attacks, and that backups must be protected from deletion as well as from failure.

1.3 Encryption

• At rest: provider-managed encryption (AES-256) for database, backups and object storage. Customer-managed keys are optional and deferred [TBD - infra decision].

• In transit: TLS 1.2 or higher for all traffic, including backup replication and restore operations.

• Backups inherit the same encryption as primary data; restore tests (section 1.6) confirm restored data is readable and intact.

1.4 Recovery targets

Viewee holds feedback and compliance evidence, not life-critical monitoring data. Targets below suit a care-sector pilot; tighten them as the customer base grows.

1.5 Restore procedure

1. Declare the restore need and start a restore log entry (format in 1.6). One founder drives; the other reviews before any production cutover.

2. Provision a clean environment (fresh database instance or clean schema). Never restore over the only copy of live data.

3. Fetch the required backup: latest good snapshot, or the point-in-time position just before the incident if PITR is available.

4. Restore the database. Verify: table row counts against the backup manifest, spot-check 10 known records, run the app's migration/integrity checks.

5. Restore or re-link uploaded files; verify a sample of attachments opens.

6. Smoke test the application against restored data: login, view a feedback record, view evidence trail.

7. Cut over (re-point DNS/config) only after verification passes. Record the actual RPO and RTO achieved.

8. Keep the pre-restore state for at least 7 days before disposal.

1.6 Restore testing: schedule and evidence log

Restores must be tested, not assumed. An untested backup does not count as a backup; the NCSC makes regular testing and monitoring of backup health a core part of a ransomware-resistant backup regime.

• Monthly: restore one database backup to a staging environment and verify a sample of records. Under 1 hour of effort.

• Quarterly: full drill: restore database plus uploads from the second region into a clean environment, run smoke tests, time the whole exercise against RTO.

• After any infrastructure change (provider, database version, storage layout): repeat the quarterly drill once.

Evidence log format (one row per test; keep in a spreadsheet in this Drive folder):

Restore-test evidence doubles as due-diligence material for care customers and their CQC inspections: Viewee can show recovery works, not just that backups exist.

1.7 Sources

• NCSC, Ransomware-resistant backups: https://www.ncsc.gov.uk/collection/ransomware-resistant-backups

• NCSC, Offline backups in an online world: https://www.ncsc.gov.uk/blog-post/offline-backups-in-an-online-world

• NCSC, Mitigating malware and ransomware attacks: https://www.ncsc.gov.uk/guidance/mitigating-malware-and-ransomware-attacks

• NCSC, Understanding SaaS security: https://www.ncsc.gov.uk/guidance/understanding-software-service-saas-security

Part 2 - Incident Response Plan (DRAFT)

2.1 Purpose

A one-page operational plan for a two-person founding team responding to security and availability incidents, including personal data breaches under UK GDPR. It follows the NCSC Small Business Guide: Response & Recovery and the ICO's 72-hour breach guidance.

2.2 Severity levels

2.3 Detection sources

• Uptime and error monitoring on the app and API [TBD - infra decision: monitoring stack]

• Cloud provider security and abuse alerts, routed to both founders' email and phone

• Database and access-log anomaly alerts [TBD - infra decision]

• Customer reports to the support email

• Founder observation (either founder can declare an incident; no approval needed)

2.4 First-hour actions

1. Acknowledge and declare (0-15 min). Whoever spots it declares the incident, sets a severity level (re-rate later if wrong), and opens the incident log. Per ICO guidance, start the log immediately: what happened, when it was discovered, who is involved, what has been done. The 72-hour clock runs from discovery, not from when the incident happened.

2. Contain (15-30 min). Stop the bleeding first: revoke compromised credentials and sessions, block malicious IPs, take the affected component offline if needed, preserve logs before anything rotates. Do not wipe or rebuild anything until evidence is captured.

3. Assess (30-60 min). What data is affected, does it include personal data, how many people, is the incident still live. Assign roles (2.5) and agree the time of the next update.

4. Escalate. If a cyber attack is in progress, call the NCSC 24/7 line 0300 123 2040. If personal data is involved, start the ICO decision path (2.6c) now, not at hour 71.

2.5 Roles (two-person team)

• Either founder can hold either role; the first responder takes Incident Lead until the other joins.

• External help: hosting provider support channel [TBD - infra decision]; consider a small incident-response retainer or named contractor once pilot customers are live [TBD].

2.6 Communication templates

(a) Internal update

Incident [ID], SEV [level], opened [time discovered]. Status: [contained / investigating / restoring]. What happened: [2 sentences]. Data affected: [none / personal data: who and roughly how many]. Actions so far: [bullets]. Next update at [time]. Incident Lead: [name].

(b) Affected customer (care provider)

Subject: Important security notice about your Viewee data. We are contacting you about an incident affecting the Viewee service your organisation uses. What happened: [plain description]. What data is involved: [what, and whether any resident, family or staff personal data is affected]. What we have done: [containment steps]. What you should do: [e.g. reset passwords, watch for phishing, nothing at this time]. We will update you by [time/date]. If your organisation needs this information for its own records or regulator duties, this notice and our incident reference [ID] are yours to use. Contact: [email].

Send promptly once facts are stable, because care providers may have their own CQC and safeguarding duties that depend on knowing early. Do not wait for the full investigation.

(c) ICO 72-hour breach notification decision path (UK GDPR)

1. Is it a personal data breach? Personal data lost, destroyed, altered, disclosed or accessed without authorisation. If no, log the incident and stop.

2. Is there a risk to people's rights and freedoms? Consider safeguarding risk to residents, identity theft, distress. Given Viewee's data, assume risk unless clearly trivial (e.g. encrypted data with uncompromised keys). If no real risk, record the breach in the internal log with the reasoning; no ICO report needed, but keep the record either way.

3. If risk exists: report to the ICO within 72 hours of discovery. Report online via the ICO breach-reporting service. Partial information is fine: the ICO says report on time and follow up with more detail later. Include what happened, categories and approximate number of people, likely consequences, and containment measures.

4. Is the risk high? If yes, also tell the affected individuals without undue delay, in plain language, with steps they can take. For resident data this will usually run through the care provider as the joint contact point; agree who tells residents and families.

5. Unsure? Use the ICO self-assessment tool or call the ICO personal data breach advice line: 0303 123 1113.

(d) Regulator and others

If attackers are still active, report to the NCSC (0300 123 2040) and consider Action Fraud. Viewee's customers own their own CQC notifications; our job is to inform them fast and accurately (template b).

2.7 Post-incident review

• Hold within 5 working days of closing a SEV 1 or 2 incident; blameless and written.

• Cover: timeline from the log, root cause, what worked, what did not, and whether detection could have been earlier.

• Every action gets an owner and a date. Feed changes back into this plan and the backup policy (including extra restore tests after relevant fixes).

• Close the loop in the incident log, which is also the UK GDPR accountability record.

2.8 Incident log fields

One row per incident (spreadsheet in this Drive folder): incident ID, date discovered, discoverer, severity, description, personal data involved (Y/N, categories, approx. count), timeline, containment actions, ICO decision and reasoning, ICO report reference if filed, individuals informed (Y/N/date), customers notified, review date, status.

2.9 Sources

• NCSC, Small Business Guide: Response & Recovery: https://www.ncsc.gov.uk/collection/small-business-guidance--response-and-recovery

• NCSC, Plan your cyber incident response processes: https://www.ncsc.gov.uk/collection/incident-management/cyber-incident-response-processes

• ICO, 72 hours: how to respond to a personal data breach: https://ico.org.uk/for-organisations/advice-for-small-organisations/personal-data-breaches/72-hours-how-to-respond-to-a-personal-data-breach/

• ICO, Personal data breaches: a guide: https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breaches-a-guide/

• ICO, Report a breach: https://ico.org.uk/for-organisations/report-a-breach/

Change log