Security practices
The practical detail behind mConsent’s security posture: HIPAA Business Associate status, encryption, access controls, hosting, data retention, and incident response.
mConsent operates as a HIPAA Business Associate and executes a Business Associate Agreement with every customer. Patient data is encrypted in transit and at rest, access is role-restricted and logged, and infrastructure runs on US-based, SOC 2–aligned cloud providers. The sections below explain each in detail.
1.The short version
mConsent handles Protected Health Information (PHI) on behalf of dental practices and their patients. That makes us a Business Associate under HIPAA, with the same obligations as any other Business Associate. Our security program is built around four commitments:
- Data is encrypted while moving between patient, practice, and mConsent, and while stored in our systems.
- Access is earned, logged, and reviewed. Employees see patient data only when they have a specific, documented reason, and every access is auditable.
- Infrastructure is hosted with cloud providers that maintain their own SOC 2 and HIPAA-aligned compliance programs.
- Incidents are disclosed under the HIPAA Breach Notification Rule and our contractual commitments to customers.
The sections below describe each in more detail. For a completed security questionnaire, SIG-Lite response, or specific clause review for your procurement process, contact security@srswebsolutions.com.
2.HIPAA & Business Associate status
mConsent operates as a Business Associate under the Health Insurance Portability and Accountability Act (HIPAA). A Business Associate Agreement (BAA) is executed with each customer prior to the customer handling PHI in the mConsent platform. The BAA binds mConsent to the administrative, physical, and technical safeguards required by the HIPAA Security Rule and incorporates the Breach Notification Rule’s disclosure timelines.
mConsent does not describe itself as “HIPAA-certified” because HIPAA does not issue certifications. HIPAA is a statute with which Business Associates comply through documented safeguards. Anyone claiming a “HIPAA certification” is either misusing the term or referring to an unrelated third-party badge.
If your procurement process requires a reviewed copy of the BAA in advance, we can provide the template under NDA. Changes to the BAA to align with your legal team’s requirements are handled during contract review and documented in your Master Services Agreement.
3.Encryption & data protection
Patient data is encrypted at two layers:
- In transit. Transport Layer Security (TLS 1.2 or higher) between patient devices, practice browsers, and mConsent servers. SMS and email delivery uses the carrier and email-provider security stacks, which do not support end-to-end encryption as standard; practices should avoid including detailed PHI in outbound SMS or unencrypted email.
- At rest. AES-256 encryption for data stored in managed cloud databases and object storage. Encryption keys are managed through the cloud provider’s key management service (KMS) with documented rotation and access policies.
Voice recordings from Zaha AI calls, transcripts, and call metadata are stored under the same encryption stack. Patient intake data, insurance card images, and signed forms are encrypted in the same way.
Backups are encrypted with the same at-rest stack. Backup access is restricted to a smaller group of engineering staff than production access, and backup restoration events are logged.
4.Access controls & authentication
mConsent follows the principle of least privilege: employees get access to patient data only when they have a specific, documented business reason, and only to the minimum data set required for that reason.
For customers
Practice administrators configure role-based access within the mConsent application. Front-desk, office manager, doctor, and billing roles have different default permissions, which practice administrators can customize. Multi-factor authentication (MFA) is available for all user accounts and strongly recommended; enterprise customers can require MFA as a policy. Session timeouts apply to all signed-in sessions.
For mConsent employees
Production access is restricted to a limited group of engineering, support, and onboarding staff. All production access requires multi-factor authentication and SSO through the company identity provider. Access is logged, reviewed quarterly, and revoked within one business day of role change or termination.
Customer-support access to a specific practice’s data requires either an active support ticket or explicit customer authorization, and the access is logged with the reason.
5.Hosting & infrastructure
mConsent’s production infrastructure runs on US-based cloud providers that maintain their own HIPAA-aligned and SOC 2-audited compliance programs. Customer data is stored in US data centers and does not transit outside the United States under normal operation.
| Layer | Provider category | Role |
|---|---|---|
| Application & database hosting | HIPAA-eligible US cloud providers | Compute, managed databases, object storage |
| Email delivery | Transactional email service | Appointment confirmations, reminders, notifications |
| SMS delivery | US telecom carrier aggregators | Patient SMS notifications, review invitations |
| Voice infrastructure | Voice-AI and telephony providers | Zaha AI inbound call handling and recording |
For a current list of sub-processors, see section 7. Customers on enterprise contracts receive advance notification of material sub-processor changes per their Master Services Agreement.
6.Data retention & deletion
mConsent retains patient data for as long as the customer practice maintains an active account, plus a defined tail period to support transition and record-retention obligations. Specific retention windows are documented in your Master Services Agreement.
- Active customer accounts. Patient data is retained and accessible to the practice.
- After termination. Data is retained for a defined period (typically 30–60 days) to support export and transition, then deleted in accordance with the MSA.
- Export. Customers can request a data export in a machine-readable format at any time. Export requests are processed within the timeframe specified in the MSA.
- Audit and backup logs. Retained for a longer period than primary data to support security investigations and legal hold obligations.
Patient-initiated data requests (for example, a patient requesting that their intake record be corrected or removed) are routed to the practice to handle, since the practice is the covered entity under HIPAA. mConsent supports the practice in fulfilling those requests through the application’s deletion and amendment features.
7.Sub-processors
mConsent uses a small number of sub-processors to operate specific parts of the platform. Each sub-processor is selected based on their security program, HIPAA eligibility, and operational fit. A current sub-processor list is available to customers on request.
Sub-processors that handle PHI execute Business Associate Agreements with mConsent. Sub-processors that handle only de-identified or non-PHI operational data (for example, analytics on anonymized usage patterns) do not require BAAs.
For enterprise customers under MSA, material sub-processor additions are notified in advance per the MSA’s notification timeline. Customers on standard commercial contracts can subscribe to sub-processor updates at the email address at the top of this page.
8.Incident response
mConsent maintains a documented incident-response program covering detection, containment, customer notification, and remediation. In the event of an incident involving PHI, we follow the disclosure timelines required by the HIPAA Breach Notification Rule and any additional timelines committed in your MSA.
What customers can expect during an incident
- Notification through the customer’s designated security contact with initial information about scope and affected data types.
- Regular updates as the investigation progresses.
- Post-incident report with root cause, remediation actions, and any recommended customer-side steps.
Customers are responsible for designating and maintaining a current security contact in the mConsent admin panel. If we cannot reach the contact on file, the notification timeline may be affected.
9.Audits & ongoing review
mConsent’s security program is reviewed on a regular cadence by internal security staff, and specific controls are reviewed during contract renewals with enterprise customers. We are continuously improving our audit and compliance posture; specific third-party attestations (for example, SOC 2) are in progress or under consideration. For the current status of any specific attestation, contact security@srswebsolutions.com.
Customers conducting their own vendor audits can request:
- A completed security questionnaire (SIG-Lite or customer-provided format).
- A documented walkthrough of the controls summarized on this page.
- A review call with engineering leadership for technical questions.
10.Reporting a vulnerability
If you believe you’ve found a security issue in mConsent — a vulnerability, a misconfiguration, or anything else worth disclosing — send a description to security@srswebsolutions.com. Please include:
- A clear description of the issue and where you encountered it.
- Steps to reproduce.
- Any proof-of-concept material (without including actual PHI).
- Your contact information for follow-up.
We respond to reports as quickly as possible and commit not to pursue legal action against researchers who report vulnerabilities in good faith, do not access data beyond what is necessary to demonstrate the issue, and do not publicly disclose until we’ve had a reasonable opportunity to remediate.
