Platform, security and compliance FAQ

Evaluating Awell usually means answering a security questionnaire, a privacy review, or a regulatory question before any care flow gets built. This page collects those answers in one place, grouped by the kind of review that asks them.

For anything not covered here, email support@awellhealth.com.

Architecture and hosting

Is there an architecture diagram of the Awell platform?

The security whitepaper gives a high-level view of the platform and its components. A detailed component diagram is available on request from support@awellhealth.com.

Where is the Awell stack hosted?

On Google Cloud. It can be deployed in several geographical regions to meet compliance requirements.

How scalable is the platform?

The integrations and infrastructure are designed to handle large patient volumes. Current uptime and incident history are on the status page.

How does Awell keep data inside a specific region?

Deployments are regional. Data does not leave the region it is deployed in.

Which environments are available?

Two customer-facing environments: Sandbox and Production. Awell runs additional internal environments to support its own development lifecycle. Base URLs for each region are listed in Environments.

Integration and testing needs beyond these two can be discussed with support@awellhealth.com.

Compliance and security

Where is Awell's security documentation?

The security whitepaper covers the approach at a high level. The trust center holds the detailed evidence, available on request.

Is Awell SOC 2 certified?

Not yet. Awell is certified to ISO 27001, the international standard for information security management. Awell's customers include pharmaceutical and medical device companies with strict security and compliance requirements.

Is data encrypted?

Yes, at rest and in transit.

The database runs on a Kubernetes cluster in Google Kubernetes Engine, backed by a Kubernetes persistent volume covered by Google Cloud's default encryption of data at rest. In-cluster database connections use HTTPS and so are encrypted in transit through TLS. Unencrypted HTTP access to the database is disabled.

How often are penetration tests and audits performed?

Penetration tests are scheduled annually and carried out by an external party. The information security management system is audited every year as part of the ISO 27001 certification.

What does disaster recovery and backup look like?

The product runs on Google Kubernetes Engine using regional clusters, which carry built-in redundancy across three zones per region. Backups run daily in every environment.

Provisioning a new environment is fully automated. If a Google data center were completely unavailable, Awell can create a deployment in a different data center and restore the latest backup within one day at most, as defined in the disaster recovery policy. In practice it can take about an hour.

Replicating a deployment across separate data centers adds a further layer of redundancy and is on the technical roadmap, not yet available.

Is multi-factor authentication required on production systems?

Yes, on all enterprise applications and production systems.

Are third parties with access to customer data assessed?

Yes. All third parties are reviewed annually under Awell's Supplier Security Policy, part of the information security management system audited each year for ISO 27001. Reviews cover risk assessment, background verification, contract clauses, and training and awareness.

How is product data backed up?

All data is backed up daily and retained for 30 days in Google Cloud, encrypted in transit and at rest.

What prevents malware reaching customers?

Awell follows industry-standard practices in its web applications: HTTPS traffic only, current certificates, sanitized user input, and no third-party scripts beyond trusted partners.

Under the ISO 27001 certification, all staff are required to keep their devices protected with antivirus and firewall software.

Data privacy

Is the platform HIPAA and GDPR compliant?

Yes. The Awell platform complies with both the Health Insurance Portability and Accountability Act and the General Data Protection Regulation.

How is personal and health data stored?

Personally identifiable information and protected health information are stored in a graph database, which supports orchestration, and in Google BigQuery, which supports analytics. Both run on Google Cloud.

How much of that data reaches Awell is the customer's decision. The platform also works with completely anonymous patients.

Will Awell sign a Business Associate Agreement?

Yes.

What prevents sensitive data leaking?

Access to the databases holding sensitive data is deliberately narrow: no sensitive data in logs, enforced strong password rules, no shared credentials, and no public database endpoint. Internal access is granted only when needed, such as troubleshooting.

Data is encrypted at rest and in transit.

The ISO 27001 certification requires hardware and software controls plus staff training aimed at preventing data leaks.

In multi-tenant deployments, all data is logically isolated per tenant so it cannot leak between customers.

Usage and billing

What counts as a monthly active patient?

Billing is per monthly active patient, and a patient counts as active whether they did anything or not. The full definition, including what does and does not trigger it, is in Monthly active patients.

Data

Are data points and answers uniquely identifiable?

Yes. Questions can also carry a human-readable identifier to make analytics queries easier to write.

Can custom attributes or tags be added to a care flow?

Not yet. This is on the roadmap, including making such tags available in Google BigQuery.

AI and large language models

Does the platform include AI features?

Yes. Shelly, Awell's CareOps analytics assistant, is built on current large language models. See Ask Shelly about your care flows.

What data does Awell send to large language model providers?

Shelly can read the data in a customer's own tenant. Three measures keep personal and health data out of what reaches the model provider:

1. Shelly has no access to patient profile data.
2. Personally identifiable information that could appear in care flow data is removed first, by an entity extraction model running on Awell's own infrastructure.
3. A zero-retention policy applies to everything Shelly sends to the model provider.

Has Awell signed a Business Associate Agreement with the model provider?

Yes.

Medical device compliance

Regulatory classification depends on what a care flow is intended to do, which makes it the customer's assessment to make. The answers below indicate where the line usually falls. They are not legal advice.

Is the Awell platform a medical device?

No. The Awell platform is general software for building and operating care flows.

An individual care flow built on it may be a different matter. Depending on its intended purpose, a care flow can qualify as a medical device under the EU Medical Device Regulation, known as MDR, or under the rules of the US Food and Drug Administration. In that case it may require CE certification or FDA approval. Awell recommends establishing the regulatory position before implementing a care flow.

Does a care flow need MDR certification?

A care flow that only collects information from patients and passes it to a healthcare professional most likely is not a medical device. Onboarding care flows and pre-consultation questionnaires are typical examples.

A care flow designed to diagnose, monitor or treat patients most likely is. Health institutions may only need to comply with article 5(5) of MDR, covering in-house medical devices, so it is worth reading that article and the guidance for in-house devices to check eligibility for that route. MDCG 2019-11 covers classification of software and is published on the European Commission's MDCG guidance page.

One case catches people out. Under the borderline manual published in December 2022, any simple calculation using patient variables counts as a medical calculation, and therefore a medical device. Calculating stroke risk for patients with atrial fibrillation using the CHA₂DS₂-VASc score is one example.

Does a care flow need FDA approval?

Depending on its intended purpose, a care flow may be clinical decision support software with device functions. The FDA's Clinical Decision Support Software guidance gives examples to compare a care flow against, and the Policy for Device Software Functions and Mobile Medical Applications covers exemptions. Awell recommends establishing the regulatory position before implementing a care flow.

Is Awell ISO 13485 certified?

No. ISO 13485 covers medical device manufacturing, and Awell does not manufacture medical devices. Awell follows industry best practices for quality.

Next steps

Next: Team, roles and permissions — security review usually moves on to who inside the organization can see and change what.