Security
Vitalis Health Systems, Inc. ("Vitalis") builds the Vitalis Platform, which research teams, sponsors and customers use to run studies and collect participant data, including questionnaires, cognitive task results, and Apple HealthKit and wearable sensor data. We treat all of this as sensitive health data. This page describes how we protect it.
01 / Our commitment
We designed our security program around two frameworks: the SOC 2 Trust Services Criteria for Security and the HIPAA Security Rule. We manage the program in Vanta, which continuously monitors our cloud infrastructure, code repositories, staff devices and personnel controls, and holds our policies, risk register and evidence.
Our leadership approves our written security policies and reviews them at least once a year. We also run a formal risk assessment every year and after any significant change to our systems.
Vitalis has not yet completed a SOC 2 audit and does not claim SOC 2 or HIPAA certification. A SOC 2 Type 1 audit is in progress.
02 / Infrastructure and hosting
- The Vitalis Platform runs entirely on Amazon Web Services (AWS) in US regions, using managed services for compute, database and storage.
- Development, staging and production are separate AWS accounts. Real customer and participant data exists only in production. Development and testing use synthetic data only.
- All infrastructure is defined as code. Every infrastructure change goes through the same review process as application code.
- Network traffic is restricted by firewall rules and logged. AWS's standard protection against denial-of-service attacks is in place.
- Vitalis is a remote-first company with no offices or data centers. AWS operates the physical security of the facilities that host our systems, and we review AWS's independent SOC 2 report as part of our vendor review.
03 / Data protection and encryption
- Encryption at rest: customer and participant data, including backups, is encrypted with AES-256. Encryption keys are managed by AWS.
- Encryption in transit: all connections use TLS 1.2 or higher, with TLS 1.3 preferred. Public endpoints enforce HTTPS.
- Secrets such as credentials and API keys are kept in a managed secrets service. They are never stored in source code.
- Notifications contain no health information. Email, push and SMS messages only say that something is waiting, and ask the recipient to sign in.
- Application logs contain no health data.
- Data stays off laptops. Staff may not store protected health information on laptops, phones or removable media. They can only reach it through approved systems.
- Retention and deletion: we keep data only as long as contracts, research protocols and the law require. When a contract ends, we delete customer account data within 30 days unless a legal or contractual duty requires us to keep it longer. We delete study data according to the research protocol and the applicable agreement.
04 / Access control
- Least privilege. Staff get only the access their role needs, assigned through groups and roles. Access must be approved before it is granted.
- Single sign-on and multi-factor authentication are required for all staff on every system we use, including cloud administration.
- No standing access to production data. A small named group can access production, only for a specific task. That access is removed when the task is done.
- Our policy requires staff access to be reviewed every quarter and removed within 24 hours when someone leaves.
- The Vitalis Platform signs users in through a managed identity provider. It does not store user passwords.
05 / Application security and secure development
- Every change to the platform goes through a pull request. Another engineer must review and approve it, and authors cannot approve their own changes.
- Protected branches require automated checks to pass before code can merge. Those checks include dependency license checks and a software bill of materials.
- Dependencies are monitored automatically for known vulnerabilities.
- Changes are tested in separate development and staging environments before they reach production.
- Engineers complete secure development training every year. It covers common web application attacks.
- Customer data, participant data and secrets are never entered into AI tools. An accountable engineer reviews and owns all AI-assisted code under the same process as any other change.
06 / Vulnerability management
We scan our cloud environment and code repositories for vulnerabilities at least every quarter. We fix issues on fixed deadlines: within 30 days for critical and high severity, 60 days for medium and 90 days for low. We plan to engage an independent firm to perform penetration testing of the platform.
07 / Monitoring and logging
- We collect audit logs for administrative activity and for access to customer data across our cloud environment. These logs are stored centrally, protected against tampering and kept for 365 days.
- The platform keeps an audit record of sign-ins, of every create, read, update and delete action on governed records, and of any change to security settings.
- Automated alerts flag events that could affect the security or availability of production systems. Our engineers review them.
08 / Business continuity and backups
- Production databases are backed up automatically every day and support point-in-time recovery. Storage is versioned. Backups are encrypted and kept in US locations, separate from the primary systems.
- Our recovery objectives for the platform are a recovery time of 8 hours and a recovery point of 24 hours.
- Because infrastructure is defined as code, we can rebuild environments from source, including in another US region if needed.
- We plan to test our backup restore process and our continuity plan, through a restore drill and a tabletop exercise, at least once a year.
09 / Incident response
We maintain a documented incident response plan with defined roles, severity levels, escalation steps and post-incident reviews. We plan to test it at least once a year with a tabletop exercise. Staff must report any suspected incident within 4 hours.
If an incident affects your data, we will notify you without undue delay, as our contract and the law require. Where Vitalis acts as a business associate, we notify the affected covered entity of any breach of unsecured protected health information within the deadline in the Business Associate Agreement (BAA), and never later than 60 calendar days after discovery. We will also give you the information you need to meet your own reporting duties.
10 / People security
- Staff complete a criminal background check, where the law permits, before they get access to production systems or health data.
- Everyone signs a confidentiality agreement and accepts our acceptable use policy when they join and every year after.
- Our policy requires everyone to complete security awareness and HIPAA training within 30 days of starting and every year after.
- Vitalis work is done only on company laptops, never personal ones. Every laptop must have full-disk encryption, automatic screen lock, anti-malware protection and timely updates.
11 / Vendor management
We review every vendor's security before it gets access to our data or systems. We then assign each vendor a risk level and review high-risk vendors every year. Each vendor is bound by a written agreement, and any vendor that handles health data must sign a Business Associate Agreement first.
No vendor may handle protected health information unless a BAA is in place. Our hosting provider, AWS, is covered by the AWS Business Associate Addendum, and protected health information is stored and processed only in AWS's HIPAA-eligible services. We provide a list of our subprocessors on request.
12 / HIPAA and privacy
Vitalis is not a HIPAA covered entity. When we provide services to a covered entity that involve protected health information, we act as its business associate. We sign a BAA with that customer and meet the HIPAA obligations that apply to business associates.
Whether or not a BAA applies, we protect all study and participant health data to HIPAA Security Rule standards. Research data is also governed by the research agreement, the IRB-approved protocol and participant consent.
We use and disclose protected health information only as the BAA permits or the law requires, and only the minimum needed. We do not sell health data, use it for marketing, or try to re-identify de-identified data. When a BAA ends, we return or destroy the protected health information we hold.
13 / Responsible disclosure
If you believe you have found a security vulnerability in a Vitalis service, please email security@vitalishealth.ai. Please include enough detail for us to reproduce the issue.
We ask that you:
- give us reasonable time to fix the issue before disclosing it publicly;
- avoid accessing, changing or keeping data that does not belong to you;
- avoid degrading our services.
We will acknowledge your report, keep you informed as we investigate, and credit you if you wish.
14 / Request more information
Customers, research sponsors and prospects can request more security documentation, usually under a non-disclosure agreement. This can include policy summaries, our subprocessor list, completed security questionnaires and details of our HIPAA safeguards. To request it, email security@vitalishealth.ai.