A cloud accounting vendor says its service is “encrypted.” What should a medical practice owner ask next?

The useful question is not simply which encryption standard the vendor names. It is which financial records are protected, where that protection applies, who manages it and what falls outside the documented coverage.

For a staffed private practice, that review may include bank statements, payer receipts, patient-balance reports, provider and administrative payroll, tax documents and location-level financial reports. Those records can pass through several services before they reach the owner’s monthly financial package.

Use this framework with qualified IT support to evaluate vendors before purchase, during a system change or when adding a new financial-data connection. It is a procurement guide—not an encryption implementation manual. Encryption alone does not establish security or regulatory compliance.

Start With the Financial Workflow, Not the Vendor’s Slogan

Before requesting technical documents, list the records the service will receive and the routes they will take. Include the copies people create outside the main application.

For example, a payer deposit may appear in the bank feed as a summarized receipt. A supporting remittance file may contain patient information. Both help explain revenue, but they do not have the same data content or handling needs.

Practice-finance workflow Records to identify Boundary to review
Bank reconciliation Bank activity, statements and reconciliation reports Bank connection, accounting platform and downloaded copies
Payroll accounting Wage summaries, payroll liabilities and employee details Payroll service, accounting transfer and supporting-file storage
Revenue reconciliation Payer receipts, patient collections and adjustment summaries Billing-system export, transfer method and finance workspace
Location reporting Per-location P&L, shared-cost allocations and supporting schedules Reporting service, shared folders and owner downloads
Multi-entity accounting Entity-level accounts, intercompany balances and consolidated reports Each entity’s account, reporting connection and user permissions
Tax preparation Financial statements, supporting schedules and tax documents Document portal, preparer access and archived copies

Assign someone to maintain this inventory. A practice manager can coordinate it, the finance team can explain which records are needed, and IT can assess technical coverage. Do not assume that approval of one application also approves every connected service.

Understand What Encryption Documentation Actually Says

Encryption in transit

Encryption in transit protects information while it travels over a connection. Transport Layer Security, or TLS, is a protocol commonly used for this purpose. Vendor documents may name TLS 1.2 or TLS 1.3; have IT review the supported versions and configuration rather than treating a version number as a complete assessment.

The Internet Society’s explanation of TLS provides background on its role in protecting internet communications.

Ask whether the documentation covers more than the browser connection. Relevant paths may include bank connections, application programming interfaces, file uploads, report delivery and transfers to supporting service providers.

An encrypted browser session does not establish that a report remains protected after someone downloads and emails it.

Encryption at rest

Encryption at rest protects stored information. AES-256 is a commonly documented encryption specification, but its appearance in a security overview does not tell you which storage locations are covered.

Ask about databases, uploaded attachments, temporary processing files, logs, backups and archives. Also ask whether a statement applies to the application you are buying or only to the underlying cloud infrastructure.

For example, documentation about encrypted database storage may not answer how exported payroll files are handled. A cloud infrastructure provider’s security page is useful background, but it is not a substitute for the application vendor’s explanation of its own configuration.

Data being used by the application

A cloud service may need to decrypt records to display them, calculate totals or generate reports. Encryption at rest therefore does not necessarily prevent the application—or appropriately authorized people—from reading those records.

If a vendor uses terms such as “end-to-end encryption,” ask it to define the term for the specific service. Who can decrypt the data? Which features require readable information? What happens during support access or report generation?

The goal is to understand the actual operating model, not to choose the most impressive label.

Keep Encryption Separate From Access Control

Encryption and access control answer different questions:

  • Encryption: How is information protected against being read without the necessary cryptographic keys?
  • Access control: Which users and services are allowed to view, change, download or share information?

A properly encrypted payroll report can still be exposed if an employee’s account has unnecessary access to it. Likewise, encryption does not prevent an authorized user from sending a downloaded report to the wrong recipient.

For a medical practice, review permissions by job and responsibility. A location manager may need their location’s operating results without access to every provider’s compensation. An outside bookkeeper may need reconciliation records without unrestricted user-administration rights.

Ask about individual accounts, multifactor authentication, role permissions, support access and removal of access when staff or advisers leave. Have IT assess these controls alongside encryption, rather than treating encryption as a replacement for them.

Clarify Key Management and Responsibility

Encryption keys make encrypted information usable again. Their management affects both confidentiality and the practice’s ability to retrieve records.

Start with these questions:

  • Who controls the keys: the application vendor, its infrastructure provider, the practice or another party?
  • Who can authorize use of those keys or change their configuration?
  • How are keys protected, replaced and recovered?
  • What happens if a key is unavailable, compromised or deleted?
  • Which responsibilities belong to the practice, and who will perform them?

Vendor-managed keys and customer-managed keys create different responsibilities. More customer control is not automatically a better operational choice for a practice without the staff to manage it. Losing access to required keys can also make records unavailable.

Ask IT to review any references to a key management service or hardware security module. Those terms describe parts of a design; they do not, by themselves, establish coverage or suitability. Avoid prescribing a universal key-rotation schedule without understanding the service and its documented requirements.

Use a Vendor-Question Matrix to Request Evidence

Send the same questions to each shortlisted vendor. Request current, service-specific documentation and written clarification where the documents are incomplete. Some detailed material may be available only through a controlled review process.

Area Question to ask Evidence to request Responsibility and exceptions to clarify
Browser and mobile access How are financial records protected between users and the service? Transport-encryption documentation and supported connection methods Are any clients or access methods excluded? Who manages device settings?
Bank and payroll connections What protects each transfer to and from connected services? Data-flow description and connection-specific documentation Which protections belong to each provider? Are legacy connections different?
Uploads and integrations How are uploaded files and integration transfers protected? Documentation covering file-transfer and API paths Must the practice or an implementation partner enable particular settings?
Primary storage Which databases, files and attachments are encrypted at rest? Application-specific storage coverage and encryption specifications Does coverage vary by product, feature or configuration?
Temporary files and logs Can financial or personal information appear outside primary storage? Description of temporary storage, logging and exclusions Are sensitive fields omitted, masked or stored under separate controls?
Backups and archives Are backup copies and recovery transfers encrypted? Backup-encryption scope and recovery documentation Who controls backup keys? Are older archives treated differently?
Keys Who manages keys and authorizes their use? Key-management overview and responsibility statement What changes if the practice chooses customer-managed keys?
Support and service providers When can other people or services access readable records? Support-access explanation and relevant service-provider scope Which parties are covered by the documentation, and which require separate review?
Reports and exports What happens when records leave the application? Export, report-delivery and download documentation Where does vendor protection end and practice responsibility begin?
Service exit How can the practice retrieve records and close the account? Export and deletion terms, including backup treatment What remains after closure, for what stated purpose, and under whose control?

Do not accept “we use a major cloud provider” as the complete response. Ask how the vendor uses that infrastructure for the service and features your practice will purchase.

Review Backups, Downloads and the Month-End Handoff

Financial workflows often create extra copies during month-end close. A manager downloads a payroll summary, a bookkeeper exports a reconciliation, and an owner saves the reporting package locally. Those copies may sit outside the vendor’s documented encryption boundary.

Walk through a representative close with the finance team and IT:

  1. Identify each report or supporting file that leaves a cloud service.
  2. Record where it is saved and who receives it.
  3. Confirm the approved transfer and storage methods.
  4. Check whether personal devices or unmanaged folders are involved.
  5. Assign responsibility for managing working copies under the practice’s records policy.

Backups need a separate review. Encryption does not establish that a backup can be restored, and a successful restore does not establish that every backup copy is encrypted. Ask about both protection and recoverability, including the availability of necessary keys.

Keep recordkeeping requirements separate from a vendor’s default deletion settings. The IRS guidance on business records explains the importance of complete records and bank reconciliation. Have the CPA help determine which financial records the practice needs to preserve; have IT assess how those records remain accessible and protected.

Address Patient Information Without Assuming Compliance

Not every financial report needs patient-level information. A location P&L or shared-cost allocation may be prepared from summarized figures, while resolving a particular revenue discrepancy may require more detailed supporting records.

Define what the finance task actually needs before transferring data. Avoid putting patient-identifiable information into ordinary Slack conversations or general-purpose AI tools. Use approved workflows and consult the practice’s privacy and IT advisers when identifiable information is involved.

HHS guidance on the minimum necessary standard explains the standard and its exceptions. It should not be reduced to a universal instruction covering every disclosure.

A separate cloud service that maintains electronic protected health information on behalf of a covered entity or business associate can be a business associate even if it cannot decrypt the data. HHS cloud-computing guidance explains these responsibilities, including appropriate business associate agreements and applicable safeguards.

An encryption statement does not replace that review. HHS does not endorse or certify cloud products, and encryption alone does not establish HIPAA compliance.

Turn the Review Into a Documented Decision

Create a short decision record rather than relying on a sales call or a security badge. Include:

  • The service, features and financial workflows reviewed.
  • The categories of information approved for use.
  • The documentation reviewed and its date.
  • Coverage gaps, exclusions and unanswered questions.
  • Settings or procedures the practice must manage.
  • The people responsible for technical, financial and any necessary legal review.
  • Events that should trigger reassessment, such as a new integration or reporting service.

Distinguish not documented from not supported. An unanswered question is not proof of a security failure, but it is not evidence of protection either. If a material data path remains unclear, resolve it before sending sensitive records or limit the proposed workflow until the review is complete.

The practical outcome is a clear division of responsibility: what the vendor protects, what connected services protect, and what the practice must manage. That is more useful than comparing encryption labels in isolation.

FAQs

Is AES-256 enough to approve a cloud financial vendor?

No. It identifies an encryption specification, not complete protection. Ask which records and storage locations it covers, how keys are managed, what exceptions exist and whether the practice must enable any settings. Review access controls and transfers separately.

Does an HTTPS connection mean downloaded financial reports are encrypted?

No. HTTPS protects the connection between the browser and the service. It does not establish how a downloaded file is protected on a laptop, in a shared folder or during a later transfer. Those copies need their own handling review.

Should a medical practice manage its own encryption keys?

Not automatically. Customer-managed keys can add control but also introduce configuration, recovery and availability responsibilities. Ask qualified IT support to compare the options against the practice’s needs and its ability to maintain them.

Does encryption eliminate the need for a business associate agreement?

No. HHS explains that a cloud service maintaining electronic protected health information on behalf of a covered entity or business associate can be a business associate even without access to the decryption key. Have qualified advisers assess the relationship, required agreements and applicable safeguards.

Who should lead the vendor review?

The owner or practice manager should coordinate the decision. Finance staff should define the records and workflows, qualified IT support should evaluate technical documentation, and privacy or legal advisers should address applicable obligations. Assign ongoing responsibilities before the service goes live.