Data Storage and Handling Policy

1. Scope

How BuildaBox stores, protects, retains and destroys data, including patient personal and health information from practices using Bp. Applies to all staff, contractors, sub-processors and environments. Supports APP 6, 8 and 11, the Notifiable Data Breaches scheme, and our obligations to Best Practice Software and to each practice.

2. Control status

3. Data classification

Patient health information and personal information are Restricted: encrypted, accessed only on documented business need, all access logged. Credentials are held in a secrets manager, never in code, tickets or logs. Anything patient-derived defaults to Restricted.

4. Residency and hosting

All production data (databases, recordings, transcripts, backups, logs) is stored in Amazon Web Services (AWS), region ap-southeast-2 (Sydney). Production, staging and development are separated accounts with no shared credentials. No database or server is directly internet-reachable.

Australian entity and control. BuildaBox Pty Ltd is an Australian company. The cloud account holding production data is held by BuildaBox Pty Ltd and administered from Australia. No personnel outside Australia have direct access to production credentials or systems. Offshore personnel access production data only through AWS WorkSpaces virtual desktops hosted in ap-southeast-2 (Sydney), with local file transfer and clipboard access disabled, session activity logged, and access time-limited rather than standing. No production data is stored, downloaded or copied outside Australia.

Lawful access. AWS is US-owned, so production data may be subject to US legal process (e.g. a CLOUD Act request) despite being stored exclusively in Sydney. We mitigate this with encryption at rest using AWS KMS customer-managed keys (CMKs), and by notifying the affected practice of any such request we become aware of, to the extent legally permitted, redirecting it to the practice as data custodian.

5. Access control

Least privilege and MFA enforced on all systems. Standing production data access is limited to the founder, reviewed quarterly. Other access via time-limited break-glass with ticket reference and approval, logged and reviewed monthly. Access revoked same day on departure. No shared accounts. No production access from personal devices.

6. Voice, transcript and AI handling

Audio retained 30 days by default, configurable per practice down to no retention. Transcripts and chat logs retained 90 days by default, configurable per practice down to no retention or up to 12 months. Recording notice played on every call with an opt-out to a human. Prompts to the model are minimised to what each turn requires: the caller’s spoken utterances, conversation state, and appointment-matching fields (date, time, provider, appointment ID). For patient matching (required to prevent duplicate patient or appointment records in Bp), the caller’s stated name, date of birth and phone number are passed to the model and used to call a Bp lookup function; no other record fields (clinical history, results, documents) are ever included in a prompt. The model does not retain these fields beyond the call. All AI and transcription providers are under contractual zero data retention and no training on our data (§2). The agent can only perform defined booking actions; it cannot read or write clinical content.

7. Bp integration (intended design, pending partnership)

• Per-practice credentials issued with practice authorisation, stored in the secrets manager, rotated annually and on any suspected compromise. Rotation cadence to be automated and shortened once Bp’s API supports programmatic key rotation.
• Minimum scopes only. Read: appointment availability, appointment types, providers, locations, and provider schedules/blocked times. Read (patient-identifying): patient contact details, used only for identity confirmation. Write: create and modify appointments; create a new patient record only when no existing match is found. No access is requested to clinical records, results, documents or correspondence.
• No bulk extraction or local mirror of the patient database. We cache only appointment availability, for up to 60 seconds, to reduce API load.
• Every API call logged with timestamp, tenant, actor, endpoint and outcome. Rate limits and error handling per Bp’s published requirements.

8. Sub-processors

Register maintained covering name, service, data accessed, location and review date. Each sub-processor is assessed before engagement for residency, encryption, certifications, breach notification and deletion terms, and reviewed periodically thereafter. Practices notified 30 days before a new sub-processor handling patient data is added.

9. Retention and destruction

• Call audio 30 days by default, configurable per practice down to no retention
• Transcripts and chat logs 90 days by default, configurable per practice down to no retention or up to 12 months
• Booking records 12 months
• Logs 12 months
• Backups 35 days rolling
• Account and contract records term + 7 years

On termination, data is exported on request and deleted within 30 days; backup copies expire within a further 35 days. Certificate of destruction available.

10. Backup and recovery

Encrypted backups daily, retained 35 days, stored in a separate account within Australia. Restore tested once, with a 60-minute restore time observed; further test cycles to be scheduled to build a reliable baseline. RPO up to 5 minutes (RDS point-in-time recovery from continuous transaction logs). RTO estimated at approximately 2 hours, pending validation across repeated drills. Degraded mode: if the AI provider fails, or if our own systems fail while Twilio remains available, calls fail over to voicemail via Twilio’s fallback routing, with an SMS notification sent to practice staff for manual follow-up. A full outage of the telephony carrier itself is not currently mitigated by an automated failover.

11. Secure development

Peer review on all changes, no direct commits to production. Automated dependency, container and secret scanning in CI. Patching: critical 7 days, high 30 days, medium 90 days. Independent penetration test before production launch and annually thereafter, remediation tracked to closure. Production data is never copied to development or staging; test data is synthetic.

12. Personnel

Confidentiality agreements signed, privacy and security induction before access, annual refresher. Access provisioned on documented request and removed on departure day.

13. Incident response

Documented plan with severity levels, roles and escalation. On detection: contain, assess, eradicate, review. Notification: affected practice within 24 hours of becoming aware of an actual or reasonably suspected incident affecting their data; OAIC and individuals where the breach is likely to cause serious harm, within statutory timeframes. As the practice is data custodian, we support its notifications rather than contacting patients directly, unless required by law.

14. Review

Reviewed annually by the Privacy Officer, and after any material change to architecture, sub-processors, legislation, or any incident.