Business Continuity Policy

Mintstone Ltd, Internal and Customer-Facing
Version 1.0  ·  Effective: 9 April 2026  ·  Owner: Technical Director  ·  Review: Annually

This policy describes Mintstone's approach to business continuity and disaster recovery. It is provided to customers as part of vendor due diligence. Mintstone's recovery commitments to customers are also set out in the Master Services Agreement and applicable Service Level terms.

1. Purpose and Scope

This Business Continuity Policy ("BCP") sets out how Mintstone Ltd will respond to disruptions that could affect the availability, integrity, or confidentiality of the Mintstone platform and customer data. It applies to:

2. Recovery Objectives

ObjectiveTargetDefinition
RTO (Recovery Time Objective) 4 hours Maximum time to restore core platform functionality following a critical incident
RPO (Recovery Point Objective) 24 hours Maximum data loss acceptable in a catastrophic failure. Data from the last backup is the worst case.

3. Critical Services and Dependencies

ServiceProviderCriticalityMitigation if Unavailable
Application hosting Vercel Critical Vercel maintains 99.99% uptime SLA with global redundancy. Previous deployment versions can be instantly redeployed.
Database (PostgreSQL) AWS RDS (eu-west-2) Critical Automated daily backups with 7-day retention. Point-in-time recovery available. Multi-AZ can be enabled for Enterprise customers.
File storage AWS S3 (eu-west-2) Critical S3 provides 99.999999999% (11 nines) durability. Cross-region replication can be enabled for Enterprise customers.
Open banking (bank sync) TrueLayer High Platform functions without live bank sync. Cached transaction data remains available. Sync resumes when TrueLayer service is restored.
AI document analysis OpenAI / Anthropic / Google Vision High Manual document upload and entry remains available. AI features degrade gracefully and the Platform does not fail. An alternative AI provider can be substituted.
Messaging (Telegram) Telegram Medium Messaging is a non-core feature. Core monitoring and classification functions are unaffected by Telegram outages.
External data (Land Registry, ONS, BoE) UK Government APIs (public) Medium All external market data is cached in the Mintstone database. Cached data continues to be served during API outages. Data freshness is flagged to users.

4. Backup and Recovery Procedures

4.1 Database Backups

4.2 File Storage

4.3 Application and Configuration

5. Incident Response and Escalation

5.1 Incident Severity Classification

PriorityDescriptionTarget ResponseTarget Resolution
P1 Critical Complete platform outage or data security breach affecting customers 1 hour 4 hours
P2 High Core feature unavailable (e.g., bank sync, classification, reporting broken for all users) 1 hour 8 hours
P3 Medium Feature degraded or unavailable for a subset of users; workaround available 4 hours (business hours) 2 business days
P4 Low Minor issue, cosmetic defect, or feature request 1 business day Next release cycle

5.2 Response Steps

  1. Detect: Incident identified via monitoring alert, customer report, or internal observation.
  2. Acknowledge: Mintstone acknowledges the incident and begins investigation within the target response time.
  3. Communicate: Affected customers notified of the incident, its scope, and estimated resolution time. Updates provided at least every 2 hours during a P1 incident.
  4. Contain and Remediate: Root cause identified and resolved. Where a third-party provider is the cause, Mintstone coordinates with that provider.
  5. Post-Incident Review: Root cause analysis documented for all P1 and P2 incidents within 5 business days.

5.3 Customer Communication

During a P1 incident, Mintstone will:

Status updates are communicated directly by email to the Customer's Designated Technical Contact as specified in the Order Form.

6. Scenario-Specific Continuity Plans

6.1 Loss of Key Personnel

Mintstone documents all critical operational procedures such that another qualified engineer can assume responsibility within 24 hours. Deployment credentials and access are stored securely and accessible to at least two authorised individuals at all times.

6.2 Vercel Platform Outage

In the event of an extended Vercel outage (>8 hours): the application can be redeployed to an alternative hosting provider (e.g., AWS Elastic Beanstalk or Railway) within the 4-hour RTO target, using the same environment configuration and database connection. This procedure is documented internally.

6.3 Database Corruption or Loss

In the event of database corruption or accidental deletion: Mintstone will restore from the most recent automated snapshot. For the most critical data loss scenarios, point-in-time recovery limits data loss to a maximum of 24 hours (RPO). Customers will be notified immediately and provided with a full account of data affected.

6.4 AWS Region Outage (eu-west-2)

In the event of an extended AWS London region outage: database restore to an alternative region is possible within the RTO window using the most recent snapshot. Enterprise customers may request cross-region backup replication as an add-on.

6.5 Cyberattack / Ransomware

In the event of a security compromise: Mintstone will immediately isolate affected systems, notify customers in accordance with the DPA breach notification requirements (within 72 hours), restore from clean backups, and rotate all credentials. No ransomware payment will be made.

7. Testing and Review

8. Contact

Contact TypeEmailWhen to Use
Security incidents / breachescontact@mintstone.co.ukSuspected breach, vulnerability disclosure
Platform incidents / supportcontact@mintstone.co.ukP1–P4 incidents, service questions
Legal / compliancecontact@mintstone.co.ukContract queries, DPA, regulatory