Business Continuity & Disaster Recovery Plan

Touch2Sign Ltd

Version: 1.0

Effective date: 11 July 2026

Owner: Robert — Engineering Lead

Approved by: Robert — CEO / Managing Director

Next review: 11 July 2027

---

1. Purpose

Ensure Touch2Sign can maintain or rapidly restore eSignature and eWitness services following disruption to AWS infrastructure, application failure, or regional outage. Supports ISO 27001 A.5.29 and SOC 2 Availability criteria.

2. Scope

Covers:

• Touch2Sign SaaS platform (AWS eu-west-1, Ireland)
• Customer documents, audit trails, and signing workflows
• Supporting services: Cognito, RDS, S3, App Runner, CloudFront, SES
• Internal operations required to communicate with customers during outage

Excludes: customer-owned integrations outside Touch2Sign control (e.g. customer SMTP relays).

3. Recovery objectives

Metric	Target	Notes
RTO (Recovery Time Objective)	4 hours	Restore core signing and document access
RPO (Recovery Point Objective)	1 hour	Maximum acceptable data loss
Communication SLA	1 hour	Customer status update after confirmed major outage

Tier 2 functions (reporting, non-critical admin) may recover within 24 hours.

4. Critical systems

System	Function	Priority
App Runner / application tier	Signing, witnessing, API	P1
Amazon RDS (PostgreSQL)	Documents metadata, audit_log, accounts	P1
Amazon S3	Document PDFs, signed artifacts	P1
Amazon Cognito	Authentication	P1
CloudFront	CDN, TLS termination	P1
AWS SES	Transactional email (signing links, OTP)	P2
Stripe	Billing (degraded mode acceptable short-term)	P3

5. AWS region strategy

Item	Current state
Primary region	eu-west-1 (Ireland)
Data residency	Customer data stored in eu-west-1 unless sub-processor DPA specifies otherwise
Multi-region active-active	Not currently deployed — single-region with backup restore
Failover region	eu-west-2 (London) or eu-central-1 (Frankfurt) — target for future DR drill

Cross-region failover requires CEO and Engineering Lead approval and customer communication if data location changes.

6. Backup strategy

6.1 Amazon RDS

Control	Configuration
Automated backups	Enabled; retention 35 days minimum
Backup window	Off-peak UTC window
Point-in-time recovery	Enabled
Manual snapshots	Before major migrations or schema changes
Encryption	KMS-encrypted backups

6.2 Amazon S3

Control	Configuration
Versioning	Enabled on document buckets where supported
Cross-region replication	Evaluate for critical buckets — target Q4
Lifecycle	Per Data Retention & Disposal Policy

6.3 Configuration and code

• Infrastructure and application code in GitHub — tagged releases match production
• Secrets in Secrets Manager — backed up via AWS resilience (not exported)
• Runbooks in docs/compliance/ and engineering wiki

7. Recovery procedures

7.1 Application failure (single service)

1. Confirm scope via CloudWatch alarms and error rates
2. Roll back to last known good deployment — see Change Management Policy
3. Scale App Runner instances if capacity-related
4. Verify signing flow end-to-end (docs/QA_SIGN_FLOW.md smoke tests)
5. Post-incident note if customer-visible > 15 minutes

7.2 Database failure or corruption

1. Stop writes if corruption suspected
2. Assess latest restorable point (PITR or snapshot)
3. Restore to new RDS instance in eu-west-1
4. Update application connection string via Secrets Manager
5. Validate audit_log integrity — sample document lifecycle checks
6. Notify affected customers if data loss exceeds RPO

7.3 Regional AWS outage

1. Activate incident response — P1
2. Assess AWS Health Dashboard and Enterprise Support case
3. If extended outage (> 4 hours): evaluate restore to alternate EU region from snapshots
4. Customer communication via status page and email
5. Document decision and timeline for regulators if personal data impact

7.4 Total platform loss

1. Provision infrastructure from IaC / runbooks in alternate EU region
2. Restore RDS from latest snapshot; S3 from replication or backup
3. Redeploy application from tagged release
4. DNS cutover to recovery environment
5. Full QA sign flow before declaring recovery

8. Restore testing

Test	Frequency	Owner	Evidence
RDS point-in-time restore to isolated instance	Semi-annual	Engineering Lead	Test report + ticket
S3 object restore (versioning)	Annual	Engineering	Checklist
Full DR tabletop	Annual	Security + Engineering	Meeting notes
Signing smoke test post-restore	Every restore test	QA / Engineering	QA_SIGN_FLOW.md results

First restore test target: Month 6 of compliance programme.

9. Roles during disruption

Role	Responsibilities
Incident Commander	Declares DR; coordinates recovery; customer comms
Engineering Lead	Executes restore; validates data integrity
DPO	Assesses personal data impact; breach notification if applicable
CEO / Comms	External statements; enterprise customer calls

10. Communication plan

• Internal: Slack incident channel; on-call phone tree
• Customers: Status page update within 1 hour of confirmed major outage
• Enterprise customers: Direct CSM contact for P1 outages > 2 hours
• Regulators: If personal data breach — see Breach Notification Procedure

11. Related documents

• Incident Response Plan
• Change Management Policy
• Data Retention & Disposal Policy
• SUB_PROCESSORS.md

12. Review

Reviewed annually and after every DR test or major AWS architecture change.

---

Approval

Name	Role	Signature	Date
Robert	CEO / Engineering Lead	Electronic	11 July 2026