Skip to main content
Security overview

This page covers most security topics

Carl Littke avatar
Written by Carl Littke
Updated over a week ago

We understand that many organizations require a security or policy review regarding Lookback's services, as such we've prepared this document for you to send to your security team.

1. Product Overview

Lookback is a platform that helps you understand your customers. Lookback focuses on qualitative user experience (UX) research. It’s used by thousands of companies including Facebook, Netflix, Spotify, Dropbox, eBay and SAP. 

Lookback lets you talk to your users anywhere in the world. You see their face and what they see on their screen, hear their voice, and see visualizations of where they interact on the screen (“touch icons”) while they use an app, website or prototype. Your users (we call them “participants”) can be using mobile or desktop devices.

All real-time sessions are automatically recorded and stored in the cloud. However, if you don’t have time to interview in real time, you can send out tasks to participants. Recordings from participants completing those tasks will then be uploaded to Lookback’s servers, where your UX team can watch, comment and export them.

Participants only use Lookback with consent. Sessions cannot be started automatically, and participants always have to explicitly enable screen sharing, camera sharing, and microphone sharing before a session can start.

2. Personally identifiable information (PII)

By default Lookback only collects three pieces of PII from participants: their full name, their email address and IP-address. We do that to help your researchers separate recordings from one another, to allow them to easily contact the participants in case a submission was not fully completed or contained errors. The IP-address is stored so we can debug errors and improve the service.

However, since Lookback’s primary content type is videos from a device’s screen and camera, anything could be captured in a recording. Including credit cards, passwords, etc. It all depends on what your participants do and what your researchers instruct them to do.

It is possible using Lookback without saving any participant PII, except for the IP-address.

Using Lookback without saving any PII

If you do not wish to capture any PII within Lookback, here are some tips:

  • Test with prototypes rather than real websites, to limit what can be inserted into certain fields. Avoid password fields and credit card fields.

  • Instruct participants to not enter full names and emails when prompted by Lookback. The fields aren’t required, and participant emails are never validated or reused.

  • Avoid asking questions or writing instructions to participants that may make them reveal any PII.

3. Security and privacy policy

We have a security policy based on the SOC 2 standard and we have a SOC 2 Type II report. The policy covers security in human resources, physical security, access control, acceptable use, software development, incident management, device security, and compliance with laws and regulations. It’s approved by management and communicated to the staff. We have an ISM who’s responsible for the policy. The policy is reviewed at least yearly by the security team.

As part of our security and privacy policy we maintain the following controls:

  • Written policies for safe handling and protection of data.

  • Yearly internal audits of the security and privacy policy.

  • A training program for the staff to ensure they are familiar with the security and privacy policy.

  • Background screening of employees.

  • Industry standard protection of servers and networks.

  • Applying the principle of least privilege for sensitive data and systems.

  • Protected access logs for sensitive data and systems.

  • A process to ensure third parties are capable of protecting sensitive data.

  • Processes to identify and address security and privacy incidents in a timely fashion.

  • A change management process with reviews for networks and systems.

  • A risk assessment program where we regularly review the threats to the company and how they can be addressed.

4. Personnel security

All employees undergo training on security and privacy. This training includes device security, password and 2FA management, physical security, malware protection, network security, incident reports and acceptable use.

All access to systems are granted based on the principle of least privilege. We have processes to revoke access when it’s no longer needed, be it because of new assignments or because the person is no longer working with Lookback.

Before hiring new employees we perform a background check for criminal record (to the extent permitted by applicable law) and an identity verification check.

5. Networks

Service network

Lookback runs the production systems in a segregated network in a AWS VPC. The network is divided in public and private subnets. Services that have to be exposed to the public internet are running in a DMZ and everything else is on our internal networks. Ports that are not required to operate the Lookback service are closed and administrative access to the servers is only possible via our private network.

All traffic between Lookback’s systems and client accessible services, like web apps and applications for recording, is encrypted using TLS 1.2 or higher.

Private network

The private network is protecting our internal resources like databases and servers, etc. It’s accessible via an encrypted VPN tunnel that requires two-factor authentication. The VPN also serves as an additional layer of security where we monitor traffic to and from our workstations. Only registered devices with the required security measures installed are allowed to access the private network.

6. Servers

Lookback’s servers run on AWS EC2. They are built and hardened using a standard build program. As part of the hardening we remove and disable all non-essential services, disable default accounts and passwords, disable password based authentication, disable ssh access, setup log forwarding to a centralized logging system, scan for known vulnerabilities, and prevent the applications from spawning additional processes.

We run vulnerability and malware scans daily and can roll out patches for critical vulnerabilities outside of our regular patching schedule. Patches can be tested in an isolated testing environment before being rolled out to production. Our employees are also signed up to mailing lists informing us of new security issues. 

7. Data and Storage

Where we store the data

We store all sensitive data on AWS in the EU, using S3 and EC2. Our database management is handled by a third party (MongoDB), but the actual data is stored on AWS in the EU.

We are currently using AWS’s datacenter in Ireland, but we may use other datacenters in the EU in the future.

Names and emails of users that have a Lookback account (i.e. not participants) will be sent to the US where the support tool we use (Intercom) processes the data. Transcripts of voice recordings from sessions will be sent to OpenAI in the US if you have enabled the Eureka feature in your organisation settings.

IP-addresses may also be sent to our logging facilities in the EU.

What we capture

When someone records with Lookback, we capture and store:

  • a video of the device’s screen, 

  • audio from the device’s microphone,

  • all gestures/touches (or mouse movements and clicks) performed on the device, 

  • optionally the front facing camera (capturing the user’s face),

  • participant’s first name, last name and email address (although you are free to submit bogus data in case you don't want to provide your or your participants' real information),

  • metadata about the device used to record with (model, OS version, etc.),

  • IP-address.

Encryption during sessions

For video/audio streaming we encrypt data using the industry standard AES-128 algorithm.

Encryption at rest

Your data is encrypted at rest using the industry-standard AES-256 algorithm.

Data segregation

You view your data using our webapp. It uses app level logic to determine who can see what data. Data is tied to an organization and if you are not a member of an organization you cannot see any of the organization’s data. 


The database is backed up by MongoDB. Files are backed up by AWS. We do not keep any backups of our own.

8. Logging 

We log events on our servers, including authentication, privileged system calls and data access. Logs are sent to a centralized environment with limited access and are regularly reviewed. Sensitive logs are encrypted, protected from modification and stored for at least two years. Log events that are outside of the ordinary result in notifications for a human to inspect.

9. Administrative access

Lookback servers run on Linux without any ways to login to the server (SSH is disabled).

Personnel with access to accounts at third party providers such as AWS have individual user accounts with 2FA. We have processes in place to audit and revoke access to the systems within 24 hours of someone leaving their position at Lookback.

10. Clients

Workstations at Lookback are registered and monitored centrally. They are configured according to a standard that includes full disk encryption, anti malware programs that are centrally managed, secure administrative passwords and screen locking that activates within a few minutes of inactivity.

Updates are installed automatically shortly after being released.

Security staff follow mailing lists to be up to date on vulnerabilities and when necessary we take action to protect our systems in case patches for new vulnerabilities haven’t been released yet. 

11. Development

Development is performed through a process that involves planning, co-ordination, implementation, review, testing and follow up after deployment.

The planning and co-ordination steps involves stakeholders from different departments, including security. Complex systems or complex changes are implemented by more than one developer, and/or reviewed by senior developers. Security related changes are always reviewed.

We do a range of testing depending on the size and complexity of the changes. It involves automated tests, and may also involve testing in an isolated testing environment, as well as internal and external user research/beta testing.

All code is kept in a secure version management system.

12. Technical security testing

To ensure our systems are secure we contract third party security firms to perform penetration tests on a yearly basis. It’s a white box test covering applications, systems and networks, including both manual and automatic testing. Any findings are tracked and resolved by the security team.

Our last major review was in November 2023, when an independent security group performed a thorough, two weeks test of our applications.

13. Your use of Lookback

Your Lookback user account

If you login with username and password (i.e. not using SAML) your password is hashed with sha256 on the client, and sent over HTTPS to our servers where it's hashed with bcrypt before it's stored or compared with the value in the database.

Passwords must be at least 12 characters and must not have appeared in any previous password leaks (You cannot set your own password policy when logging in with your email and password, but if you use SAML, you are free to set your own requirements). We do not force rotation of passwords.

We rate limit login attempts to prevent brute force attacks.

User roles

There are three roles that you can assign to your users:

  • Owner,

  • Member (called Collaborator on enterprise plans), and

  • Observer (only available on enterprise plans).

The Owner cannot be removed, and is the only role that can delete your organization. It otherwise has the same permissions as the Member. The Member can manage users, create and manage content. The Observer may only view content.

14. Enterprise Plan Security Features

The following security features are only available in the Enterprise plan:

Single Sign On (SSO)

We support SAML 2.0 and provide a simple interface for organization owners to configure it in our web dashboard. There are four primary settings you need to interact with:

  • SAML Validation URL: Input this into your server's SAML configuration.

  • SAML SSO URL: The SAML 2.0 endpoint that our servers should redirect to to authenticate the request.

  • Identity Provider Issuer: An identifier/name for your Identity Provider (IdP), usually a url like

  • Public Certificate: Your IdP's public certificate.

Further, we support the following options:

  • Sign AuthnRequest

  • Encrypt Assertion

You can get a copy of our Metadata.xml, our certificate and see the current field definitions.

Security audits

We allow Enterprise Plan customers to audit our data processing procedures and documentation once a year, with reasonable notice, in order to assess our compliance with the security agreements between your company and ours. We also give access to recent penetration testing reports upon request.

Make all projects private

If you require all projects within Lookback to be private by default, Enterprise Plan customers can enable that setting. This is useful for large organizations working on sensitive projects that should not be shared organization wide, or if you want to limit the exposure of the PII you capture with Lookback.

Customizable data retention rules

Per default, recordings are stored on Lookback’s servers until one of your researchers delete them, or until you stop being a customer. With the Enterprise Plan, you can set a custom time period that decides how long we’ll store your recordings, notes and comments. Reach out to our support for further information.

Compliance with your additional security requests

Missing something? Let us know and we may be able to accommodate your request.

15. Additional Questions

To learn more, see our Service Agreement, Privacy Policy or Terms of Use.

For additional questions, reach us at 

Did this answer your question?