1. Continuity approach
Paulioskos plans for loss of cloud services, hosting, identity, communications, equipment, connectivity, working locations, suppliers and key personnel. Recovery is prioritised by business impact, security dependency and the need to communicate with affected clients.
Know what matters first. Identify critical activities, information, systems, people and dependencies.
Design for recovery. Use controlled configuration, backups, exportability, version history and documented recovery steps.
Keep administration controlled. Use named identities, multi-factor authentication and restricted recovery access.
Communicate clearly. Assign an incident owner, record facts and use available alternative channels.
Test rather than assume. Validate recovery procedures and improve them after tests, disruptions and near misses.
2. Recovery priorities
| Priority | Service or activity | Reason |
|---|---|---|
| P0 | Incident command, safety, containment and evidence preservation | Recovery must not overwrite evidence or restore an active compromise. |
| P1 | Microsoft Entra identity and secure administrative access | Secure access is a dependency for Microsoft 365 and protected administration. |
| P1 | Microsoft 365 email, shared mailboxes and client communications | Provides the primary route for enquiries, coordination and client updates. |
| P1 | Cloudflare, DNS, public website and enquiry service | Restores public presence and the ability to receive new enquiries. |
| P1/P2 | Backup access and protected recovery copies | Enables safe recovery of the website and business records. |
| P2 | BookStack and controlled documentation | Provides runbooks, governance evidence, client and supplier information. |
| P2 | GitHub source control and deployment definitions | Enables controlled application rebuild and rollback. |
| P3 | Accounting and non-urgent administration | Recovered after immediate security, access and communication needs. |
3. Current recovery arrangements
| Service | Recovery approach | Working objective and owner |
|---|---|---|
| Identity and administration | Primarily relies on Microsoft cloud resilience, named identities, MFA and documented access configuration. Alternative communication is used during provider outages. | Internal target: secure administrative access or an approved workaround within four business hours, subject to provider availability. Owner: Paul. |
| Microsoft 365 communications | Provider-managed resilience with telephone, SMS, website notices and approved public updates as alternative channels. Independent Microsoft 365 backup is not currently evidenced. | Alternative communication route within four business hours. Owners: Dianne for communications; Paul for administration. |
| Public website and enquiry service | Daily Veeam Agent protection, Git-controlled source and pre-change PostgreSQL/configuration copies for material releases. | Working internal RTO: four hours; working RPO: up to 24 hours. Not a contractual SLA. Owner: Paul; technical deputy: Edward. |
| Cloudflare and public routing | Provider-managed service and account controls; critical DNS and configuration changes are documented. | Restore routing or establish a temporary alternative within four business hours, subject to provider and registrar availability. Owner: Paul. |
| BookStack documentation | Application revision history and planned protected exports/backups. Full backup and restore assurance is being formalised. | Working RTO: one business day; target RPO: 24 hours once verified. Content owner: Dianne; technical owner: Paul. |
| GitHub source control | Approved source is held in GitHub and additional controlled Git clones. Production data and secrets are excluded. | Controlled source checkout within four hours. Owner: Paul; deputy: Edward. |
| Assurance limitation. Repository retention, encryption, immutability, failure-domain separation and a complete isolated Veeam restore remain formal evidence actions. Equivalent independent backup assurance has not yet been confirmed for every Microsoft 365, BookStack or endpoint record. |
|---|
4. Most recent recovery validation
The most recent recovery-related validation was performed during the version 6.6 production deployment on 18 July 2026. It verified the latest daily backup status, creation and integrity of a compressed PostgreSQL backup, protected configuration copies, preservation of production data and secrets, container and database startup, authentication, enquiry submission and mail workflows.
This was a valid backup-integrity and service-validation exercise, but not a complete isolated Veeam bare-metal or full-machine restore. A complete isolated website/VPS recovery test is scheduled no later than 17 August 2026.
5. Alternative working arrangements
Device loss. Use another approved managed device; revoke affected sessions and access; do not use shared or unmanaged computers for privileged work.
Location loss. Work from an alternative safe location using approved devices and secure remote access.
Internet loss. Use approved mobile connectivity, alternative broadband or another secure working location; telephone and SMS remain available for urgent coordination.
Identity or Microsoft outage. Use valid existing sessions only where safe, check provider status, move communications to independent channels and do not expose an insecure local login for convenience.
Key-person loss. Paul is the principal technical owner; Edward supports authorised website, source-control and technical tasks; Dianne owns communications, privacy, compliance and records. Controlled documentation reduces reliance on one person.
Specialist capacity. Approved independent specialists may be engaged under confidentiality, access and client-approval controls.
6. Incident communication
Communication depends on which services remain available. If the website fails, email and telephone are used. If Microsoft 365 fails, the website, telephone, SMS and an approved public status update may be used. If both fail, priority clients and partners are contacted using the restricted continuity contact list and a temporary public route may be established where practical.
Paul acts as technical incident owner unless another owner is assigned. Dianne coordinates client, privacy and compliance communications. Edward provides technical status to the incident owner but does not issue unapproved public or client statements. Material communications and decisions are recorded.
7. Testing and review
Quarterly review of access, backup status, recovery readiness, critical contacts and material suppliers.
Quarterly technical recovery testing, rotating through database, file, application, access or configuration recovery.
Annual broader continuity exercise covering people, communications, technology, suppliers and decision-making.
Additional review after material change, failed backup, incident, unsuccessful test or newly accepted client commitment.
A Microsoft 365 loss, alternative-communications and key-person tabletop exercise is scheduled by 30 September 2026.
8. No implied 24/7 service commitment
“24/7 recovery mindset” describes a design philosophy: systems should be engineered with failure, protection and recoverability in mind. It does not create a staffed 24-hour service desk, continuous monitoring, guaranteed out-of-hours response, restoration target or contractual SLA. Any support hours or service levels must be expressly agreed in a contract or statement of work.
Contact
| Route | Details |
|---|---|
| General and client communications | [email protected] |
| Security incidents | [email protected] |
| Compliance enquiries | [email protected] |
Reference framework
These references explain the legal and good-practice framework used when preparing this document. They do not represent certification, accreditation, endorsement or legal advice.