Security and trust
Controls you can inspect. Deployment evidence you can request.
Review how staff access, patient sharing and activity records work in Thirty2OS. Ask for the hosting, recovery and contractual information relevant to your clinic.
ACCESS REVIEWSecurity is shared operating workProduct control · deployment evidence · clinic responsibility
01Organisation and clinic scope
02Role permissions
03Purpose-specific sharing
04Clinic activity audit
Data scope
Apply organisation, clinic and role controls to supported workflows
A signed-in staff member works inside an organisation and, where relevant, a selected clinic. What they can see and change depends on their clinic assignment and role permissions.
Staff profiles can be linked to clinics and access roles. The customer remains responsible for approving role design, removing access promptly and reviewing privileged users.
- Organisation and clinic boundaries for supported records
- Clinic assignment and selected-clinic access
- Role permissions for product areas and actions
- Separate access for platform administration
Control map: behaviour, evidence and clinic responsibility
Control map: behaviour, evidence and clinic responsibility
| Checkpoint | Implemented product behaviour | Deployment detail to request | Clinic responsibility |
|---|---|---|---|
| Organisation and clinic scope | Keep supported records inside the selected organisation and clinic | Current architecture and access-test evidence | Approve clinic structure and review access |
| Roles | Apply permissions to product areas and actions | Current role and permission inventory | Give only needed access and remove it promptly |
| Sessions and patient shares | Use signed-in access or purpose-specific patient links | Current link-expiry and session settings | Verify recipients and do not share credentials |
| Recorded activity | Retain supported administration, sharing and delivery-attempt records | Coverage and retention for the deployment | Review records and investigate exceptions |
| Communications | Consent, suppression, template and attempt context | Provider configuration and data flow | Obtain consent and own message outcomes |
| Production safeguards | Reject missing or unsafe required settings | Environment-specific validation evidence | Protect administration and provider credentials |
| Hosting, storage and recovery | Request the details for your clinic’s deployment | Current hosting, encryption, backup, residency, subprocessors and incident commitments | Assess evidence and maintain clinic continuity plans |
Organisation and clinic scope
Implemented product behaviourKeep supported records inside the selected organisation and clinic
Deployment detail to requestCurrent architecture and access-test evidence
Clinic responsibilityApprove clinic structure and review access
Roles
Implemented product behaviourApply permissions to product areas and actions
Deployment detail to requestCurrent role and permission inventory
Clinic responsibilityGive only needed access and remove it promptly
Sessions and patient shares
Implemented product behaviourUse signed-in access or purpose-specific patient links
Deployment detail to requestCurrent link-expiry and session settings
Clinic responsibilityVerify recipients and do not share credentials
Recorded activity
Implemented product behaviourRetain supported administration, sharing and delivery-attempt records
Deployment detail to requestCoverage and retention for the deployment
Clinic responsibilityReview records and investigate exceptions
Communications
Implemented product behaviourConsent, suppression, template and attempt context
Deployment detail to requestProvider configuration and data flow
Clinic responsibilityObtain consent and own message outcomes
Production safeguards
Implemented product behaviourReject missing or unsafe required settings
Deployment detail to requestEnvironment-specific validation evidence
Clinic responsibilityProtect administration and provider credentials
Hosting, storage and recovery
Implemented product behaviourRequest the details for your clinic’s deployment
Deployment detail to requestCurrent hosting, encryption, backup, residency, subprocessors and incident commitments
Clinic responsibilityAssess evidence and maintain clinic continuity plans
Authentication and sharing
Use purpose-specific access rather than exposing the full clinic application
The clinic application uses authenticated sessions for protected work. Patient-facing treatment-plan, document, consent and gallery workflows use purpose-specific share routes rather than a clinic login.
Configured consent flows include OTP verification and signing. Patient-link expiry and security settings must be correctly configured; clinics should send links only to the intended recipient.
AI review controls
Separate an operational answer from a record-changing action
AI Command can summarise supported reports and provide a route back to the report. Model-generated prose can vary and can be wrong, so staff should inspect the reporting period, figures and source records before relying on an answer.
Supported create or edit requests become structured drafts. The relevant create or update permission is checked again when a user confirms; until then, the clinic record remains unchanged even though the conversation and draft may be retained.
AI control map
AI control map
| Control | Evidence | Owner |
|---|---|---|
| Report answer | Question, period, metric cards and source-report path | User verifies the report before deciding |
| Action preparation | Matched references, editable fields and missing-detail warnings | User corrects or cancels the draft |
| Confirmation | Relevant permission rechecked before a supported record change | Authorised user deliberately confirms |
| Known limits | No appointment-availability check inside the AI draft | Clinic checks the schedule separately |
Clinic Audit
Review who changed what—and return to the source record
Authorised reviewers can filter supported activity by clinic, staff member, patient, category and date. Open an entry to inspect protected change details, review grouped operations and follow an available link back to the source record.
Permission-controlled CSV export supports an authorised review outside the page. Audit history can remain available when a source record has been removed, so the event can still be investigated even when its original destination no longer opens.
A contained activity review
- 01Filter
Choose clinic, staff member, patient, category and date.
- 02Inspect
Open protected change details and related activity.
- 03Group
Review supported batch operations as one connected event.
- 04Return
Follow an available link to the source record.
- 05Export
Use permission-controlled CSV export when an authorised review needs it.
Clinic Audit boundaries
Clinic Audit boundaries
| Control | Evidence | Owner |
|---|---|---|
| Access | Clinic and activity permissions | Clinic approves who can review or export |
| Changes | Protected before-and-after detail where supported | Reviewer interprets the event in context |
| Source record | Link when the record still exists and is accessible | Reviewer follows the source within existing permissions |
| Retention | Activity history may remain after a source record is removed | Deployment retention and legal terms must be confirmed |
Deployment safeguards
Review the safeguards for the deployment your clinic will use
Required public addresses and security keys must be set before relevant services can run. Browser access is restricted to approved origins, and sensitive communication content should not be written to routine application logs.
Hosting, storage, backup, encryption, incident response and subprocessor details can change by deployment. Request the current architecture and contractual security information during procurement.
NEXT STEP
Bring your security questionnaire
We will answer against the current product and deployment, identify customer-owned controls and separate implemented evidence from planned work.