Technical Security Plan — Tidecast SaaS Platform

System / product: Tidecast — a multi-tenant scheduling SaaS for clinics Owner: Priya Nair, Head of Engineering Version: 1.2 Last reviewed: 28 May 2026 Next review: 28 November 2026

---

1. Scope & overview

This plan covers the Tidecast production platform: the web application, its API, the primary database, the file store for clinic documents, and the supporting infrastructure on our cloud provider. It does not cover employee laptops or the corporate email system, which are governed by the company-wide IT policy. Engineering owns this plan; the Head of Engineering is accountable.

2. Assets & data classification

Asset	Data it holds	Classification	Owner
Primary database	Clinic accounts, patient appointment records	Confidential	Engineering
File store	Uploaded consent forms and clinic documents	Confidential	Engineering
Analytics warehouse	De-identified, aggregated usage metrics	Internal	Data team
Marketing site	Public pages	Public	Marketing

Patient names and contact details are treated as Confidential. We do not store payment card data; billing is delegated to a PCI-compliant payment provider.

3. Access control & least privilege

• Identity: Staff authenticate through our identity provider with mandatory MFA. Customers log in to the app with email and password plus optional MFA.
• Roles: Three internal roles — Support (read-only on a single tenant when a ticket is open), Engineer (no standing production data access), and Admin (break-glass only, two-person approval).
• Least privilege: Production database access is default-deny. Engineers request time-boxed, audited access through a just-in-time tool; access expires automatically after four hours.
• Service-to-service: Each service uses a scoped credential stored in the secrets manager. No shared "god" keys exist.
• Review cadence: Access is reviewed monthly. Leavers are de-provisioned within one hour of their last day via the identity provider.

4. Data protection & encryption

• At rest: Database and file store are encrypted with provider-managed keys (AES-256). Backups inherit the same encryption.
• In transit: TLS 1.2+ enforced on all public endpoints; internal service traffic runs over mutual TLS.
• Secrets: All credentials and keys live in a managed secrets store, rotated every 90 days; nothing sensitive is committed to source control, enforced by a pre-commit scan.
• Backups: Encrypted nightly backups are retained for 30 days in a separate region with restricted access.

5. Network & infrastructure security

• Segmentation: Production runs in an isolated network. Staging and development are separate accounts with no path to production data.
• Ingress / egress: Only the load balancer is internet-facing. Databases sit in private subnets with no public route. Egress is restricted to known endpoints.
• Hardening: Services run from patched, minimal base images rebuilt weekly; default accounts and unused ports are disabled.

6. Monitoring & logging

• What is logged: Authentication and MFA events, admin and break-glass actions, data-access queries, and application errors.
• Where logs go: A centralised log store that engineers can read but not modify; log integrity is protected.
• Retention: Security logs are kept for 12 months.
• Alerting: Failed-login spikes, break-glass use, and disabled-control events page the on-call engineer through the alerting channel within minutes.

7. Vulnerability management

• Dependency scanning: Automated scans run on every pull request and nightly against the deployed images.
• Patch cadence: Critical findings are patched within 48 hours, high within 7 days, routine within 30.
• Triage: The on-call engineer triages findings; severity follows CVSS, adjusted for our exposure.

8. Incident response plan

Step	Action	Owner
Detect	Alert fires or a report arrives; declare an incident in the response channel	On-call
Contain	Revoke affected credentials, isolate the affected service, snapshot evidence	Incident lead
Eradicate	Remove the root cause (patch, rotate keys, close the gap)	Engineering
Recover	Restore from clean state, confirm controls, monitor closely	Engineering
Review	Blameless post-incident review within 5 working days; track fixes to closure	Head of Engineering

Escalation contacts: On-call engineer (rotation), Incident lead (Priya Nair), and the executive sponsor for customer-impacting events. Notification: Customers affected by a confirmed data breach are notified without undue delay, with the facts known and the steps being taken; regulatory notification follows applicable law.

9. Compliance mapping

Control	Framework reference	Status
Monthly access reviews	SOC 2 — Logical access	Implemented
Encryption at rest and in transit	SOC 2 — Confidentiality	Implemented
Centralised, tamper-evident logging	SOC 2 — Monitoring	Implemented
Documented incident response	SOC 2 — Incident management	Implemented
Formal risk assessment cycle	ISO 27001 — Risk treatment	In progress