Security at MEDsort

1. Our Security Commitment

MEDsort processes some of the most sensitive documents a business can handle: pathology results, imaging reports, and clinical correspondence. We treat that responsibility as the foundation of the product, not a feature of it.

Our security programme rests on three principles: store as little as possible (MEDsort does not persistently store patient data), keep everything onshore (all processing occurs in Australia), and verify independently (we submit our platform to external certification and penetration testing rather than asking you to take our word for it).

2. Independent Certification and Testing

2.1 CyberCert Gold Certification

MEDsort holds active CyberCert Gold certification under the Australian SMB1001:2026 standard (Level 3), covering 27 independently certified cybersecurity requirements across technology management, access control, backup and recovery, policies, and incident planning.

CyberCert Gold certified — SMB1001:2026 Level 3Certification is issued and hosted by CyberCert and can be checked at any time. Verify our certification

2.2 CREST-Certified Penetration Testing

The MEDsort web application has been penetration tested by an independent, CREST-certified security firm. The engagement covered the externally facing application and its APIs, including authentication, session handling, access control, input validation, and anti-automation controls.

MEDsort passed the assessment. Every finding raised was remediated, and our remediation was reviewed and accepted by the testing firm. Fixes were verified in production, and regression tests replaying the testers' proof-of-concept scenarios now run as part of our automated test suite so the same issues cannot silently reappear.

Penetration testing is a recurring part of our security programme, not a one-off exercise. Summary findings can be made available to customers under confidentiality on request.

3. No Patient Data Stored

The most effective way to protect patient data is not to hold it. MEDsort is architected as a transient processing pipeline: documents are read from your connected Microsoft 365 mailbox, processed for extraction and classification, presented to your team for review, and routed to their destination. Patient information remains in your practice management system.

Our database stores only operational metadata:

• processing records — a message reference, timestamp, routing action, and document category
• practice settings — your configuration and preferences
• audit events — who did what and when, with zero patient-identifiable content

Extracted results, email content, and document contents are never written to our database, logs, or backups. For full detail, see our Data Storage Policy.

4. Australian Data Residency

All MEDsort infrastructure runs in Google Cloud's Sydney region (australia-southeast1). Application compute, database, and AI document processing all occur onshore. Documents are not sent overseas for processing by MEDsort.

5. Identity and Access

• Single sign-on only. Users authenticate with their practice Microsoft account via Microsoft Entra ID. MEDsort holds no passwords for your staff.
• Practice-controlled membership. Access is granted only by your practice's administrators through in-app invitations. Each invitation is single-use, expires after 7 days, and binds sign-in to the invited person's own Microsoft account — even a valid Microsoft account cannot sign in without a membership.
• Role-based access. Administrative actions, such as changing practice settings, require an admin role that is verified on the server for every request.
• Database-level isolation. Each practice's data lives in its own dedicated PostgreSQL database with its own credentials; no practice's credentials can reach another practice's database, and every request is bound to your practice's own connection.

6. Encryption

• In transit: all traffic is served over HTTPS with TLS and managed certificates; database connections are encrypted.
• At rest: all data stored in Cloud SQL and supporting Google Cloud services is encrypted at rest using AES-256.

7. Network and Edge Protection

Every request to MEDsort passes through Google Cloud Armor before it reaches the application:

• Web application firewall rules based on the OWASP Core Rule Set block cross-site scripting (XSS), SQL injection, and remote/local file inclusion attacks at the edge
• DDoS protection backed by Google's global edge network
• Edge rate limiting with tiered per-IP throttles for login attempts, API traffic, and page requests

8. Application Security

• Strict Content Security Policy using per-request nonces, mitigating script injection even if malicious content reaches a page
• CSRF protection via origin validation on all state-changing requests
• Layered rate limiting in the application itself — on top of the edge limits — with stricter budgets for authentication, AI processing, and outbound sending, keyed per user and per IP to resist automation and abuse
• Server-side input validation with typed schemas on API requests, including re-derivation of security-relevant values rather than trusting client input
• Authentication enforced on every API route, with admin-only operations additionally checked server-side

9. Infrastructure Security

• Hardened containers: the application runs as a non-root user on Google Cloud Run
• Vulnerability gates in CI/CD: deployments are blocked if container scanning detects critical or high-severity vulnerabilities
• Infrastructure as code: all cloud resources are defined in version-controlled Terraform, so changes are reviewed and auditable
• Least-privilege access: service accounts are scoped to the minimum permissions required
• Managed backups: the operational database is backed up daily with a 7-day retention window

10. AI Processing Safeguards

MEDsort uses AI to classify documents and extract structured information for your team to review. That processing is subject to the same guarantees as the rest of the platform:

• AI processing runs on Google Cloud infrastructure in Australia
• extraction results are transient — they are displayed for review and never persisted by MEDsort
• every AI output is presented to a human for review before any action is taken; MEDsort does not act on AI output autonomously
• AI-intensive endpoints carry stricter rate limits to prevent abuse

11. Audit Logging

Every significant action in MEDsort — sign-ins, document processing, routing decisions, settings changes — is recorded in an append-only audit trail. Audit events capture who acted, what they did, and when, and are deliberately designed to contain zero patient-identifiable information, so the audit trail itself can never become a source of clinical data exposure.

12. Incident Response

We maintain a documented incident response plan covering detection, containment, eradication, recovery, and post-incident review. In the event of a data breach that is likely to result in serious harm, we will notify affected customers as soon as practicable and comply with the Notifiable Data Breaches scheme under the Privacy Act 1988 (Cth). Our breach notification commitments are described in our Data Storage Policy.

13. Reporting a Vulnerability

We welcome reports from security researchers and customers. If you believe you have found a vulnerability in MEDsort, please email support@medsort.com.au with enough detail for us to reproduce the issue. Please do not access, modify, or retain data that is not yours while investigating.

We will acknowledge your report promptly, keep you informed as we investigate, and not pursue action against good-faith research conducted within these guidelines.

14. Contact Us

For security questionnaires, due-diligence requests, or any questions about our security posture:

Related policies: Privacy Policy, Terms of Service, and Data Storage Policy.