Skip to content

Information Security

This is how we think about and incorporate security into what we do at Assistiv Labs. Have questions or feedback? Reach out to us at contact@assistivlabs.com.

SOC 2 Type 2
Assistiv Labs has a SOC 2 Type 2 attestation for Security criteria. Contact us for a copy of the report.

Contents:

Why security really is vital to Assistiv Labs

We believe in shift left accessibility, or including accessibility as early in your process as possible. We’re building tools to help you do that with real assistive technologies.

Often that means testing websites before they’re released to the public, or haven’t left localhost. Maybe they’re experiments that will never ship.

We want you to feel confident testing with Assistiv Labs at any point, and we hope to build your trust with clear values and continued transparency.

How we take care of your data

Encryption in transit

All communication between you and Assistiv Labs traverses the Internet via encrypted HTTPS/WSS traffic using TLS. This includes everything you might do on assistivlabs.com and with AssistivTunnel.

Encryption during communication ensures information cannot be read or manipulated by unauthorized third parties. We do not expose unencrypted API endpoints.

SSO/SAML login

Customers on Company Plans can enable secure authentication with platforms like Okta, Auth0, and more.

SAML and OIDC are supported with JIT user creation. SSO can be enforced as a requirement for your organization and associated with one or more email domains.

Data storage and encryption at rest

All data is encrypted at rest and it’s not possible to disable encryption. This includes:

Physical security

We do not have data centers as we are a cloud SaaS provider. Physical security to our servers and to your data is managed by GCP, Vercel, and Stripe.

Backups and data retention

Every time you end a test session, the test device's virtual disk is securely deleted or, in the case of real devices, reset to factory settings, erasing all trace of the websites you visited, files you downloaded, and actions you took; except in cases where software licenses require a long-lived disk (learn more about JAWS licenses).

Your account details and payment details are regularly backed up.

When you delete your account, all your data is deleted.

Access to data

We follow the principle of least privilege when granting staff and services access to systems and data. We will only access your data to assist with support, and we will always ask for your consent.

To administer our cloud infrastructure (GCP, Vercel, Stripe), staff must authenticate with our Single Sign-On (SSO) provider, which is additionally protected by multi-factor authentication (MFA, also known as 2FA).

Production services that need access authenticate using their service account keys, which are encrypted and stored with the appropriate secret providers.

Network and application level security monitoring and protection

Only APIs that require public Internet access are exposed, and are protected from DDoS attacks by Vercel Enterprise WAF and GCP Cloud Armor. Everything else is inside a Virtual Private Cloud (VPC) secured by firewall. Firewall rules are default deny, only opening communication between APIs where necessary.

Test devices do not have public IPs, they are behind NAT. Firewall rules block ingress to all ports and prevent test devices from discovering or communicating with one another.

We monitor and protect our infrastructure and application from various threats using:

  • Network and resource misconfiguration scanning and alerting via GCP Security Command Center (SCC) Health Analytics
  • Intrusion detection and alerting via GCP SCC Anomaly Detection and custom log alarms
  • Dependency and container vulnerability scanning and alerting via Snyk
  • Maintaining a network log and cloud provider audit trails
  • Infrastructure as Code (IaC); all changes go through security review
  • API throttling controls and alerts

How we keep our code secure

Vulnerability management

All vulnerabilities are managed and tracked through a defined set of stages. Once a vulnerability is detected, it is assigned a score, using the CVSS scoring system.

We have an internal SLA that stipulates deadlines for fixing vulnerabilities.

If necessary, a post-mortem is arranged as a learning exercise for our whole company to improve security.

Continuous integration (CI) checks

When code is committed, our CI process automatically initiates a series of checks, including:

  • Automatic static code analysis for common security flaws
  • Unit and integration tests validating component-specific access controls and protections

Secure software development life cycle (SDLC)

Security is part of our SDLC and influences the product roadmap and specific features. We implement the philosophy of “security by design” where security features are embedded in the product design to ensure, to the best of our abilities, that existing and new functionalities are free of vulnerabilities.

How we secure our business

Personnel

All our staff sign confidentiality agreements before gaining access to code and data. Everyone is trained and made aware of security concerns and best practices.

Endpoint management

We require our staff’s endpoints (laptops, phones) to have full disk encryption, approved software, and automatic updates enabled.

Passwords

We have a password policy in place to ensure complex, unique passwords. Whenever possible, we use our SSO provider to authenticate with cloud providers. Staff are encouraged to use password managers, such as 1Password, to track credentials.

Multi-factor authentication

The use of MFA is required to access email, chat, and all other cloud providers whenever possible.

Shared Responsibility Model

Security is also a shared responsibility between the platform provider (us) and the consumer (you). There are certain aspects only you can help keep secure.

For example, you are allowed to (likely accidentally) download malicious software onto the test devices your sessions run on, and we cannot do anything to prevent that. We are instead trusting you to be diligent in keeping your sessions free from malware.

Another example is that we cannot help if a malicious piece of software installs a forward proxy on your machine and performs a man-in-the-middle attack on your use of AssistivTunnel. We are instead trusting that you are only running AssistivTunnel from a secure machine.

These are 2 examples that are intended to illustrate the broader shared responsibility between us and you.

Reporting

We believe working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology. If you've found a security issue, we encourage you to notify us. We welcome working with you to resolve any issue, promptly.

Disclosure policy

In the event of a security incident, we will always notify affected customers within 24 hours of resolution.