Fullview

Fullview is SOC 2 Type II compliant. On SOC2C this listing is Listed.

According to Fullview's public trust center, Fullview is GDPR compliant. On SOC2C this listing is Listed.

Fullview is SOC 2 Type II compliant. A Type II report covers how security controls operated over a period (typically 3 to 12 months), a stronger signal than a point-in-time Type I.

Yes. Fullview's SOC 2 status, frameworks, auditor, and renewal timing are on SOC2C for vendor risk and security reviews. Request the underlying report through SOC2C to complete your third-party risk file.

Yes — Fullview undergoes third-party penetration testing as part of its security program. The pentest vendor is listed on its SOC2C profile.

User properties: When installing Fullview, you will have to send an identification object via Fullview's API. To correctly identify a customer you will send a minimum of a user ID and Name. Optionally, any other user properties can be sent to Fullview, at your discretion (eg: user role, environment, market, etc). These are not mandatory but useful for your team when it comes to customer segmentation and filtering. Auto-captured events representing user activity: In terms of the actual session replays, Fullview captures: - the DOM of your webapp (HTML without assets) in the form of text - all the mutation events, such as clicks, mouse movements, scrolls, keystrokes - device and browser metadata: browser, resolution, tab ID, OS Even though when watching a replay it looks like a video, Fullview only captures a stream of events representing DOM mutations, in text, compressed and encrypted at rest. Based on those events, Fullview's proprietary engine can recreate the the registered events in a visual representation.

Fullview's offers 3 completely independent instances of its product and infrastructure: - EU1 (AWS - eu-central-1 - Frankfurt, Germany) Subprocessor: Amazon Web Services EMEA SARL, 38 Avenue John F. Kennedy, 1855 Luxembourg - EU2 (OVH - Frankfurt, Germany) Subprocessor: OVH Groupe SA, 2 rue Kellermann 59100 Roubaix, FRANCE - US1 (AWS - us-east-2 - Ohio, USA) Subprocessor: Amazon Web Services, Inc., 410 Terry Avenue North, Seattle, WA 98109-5210, United States Access to any of the underlying infrastructure is secured using AWS or OVH IAM and associated security mechanisms such as 2FA.

Capturing DOM events can contain sensitive information, therefore Fullview's agent supports agent-side redaction of specific sensitive data. Data marked as sensitive can't reach Fullview's servers and thus is not available for analysis. This allows you to mark what elements of your product you want to redact agent-side (data does not leave your customer's machine, hence it's not transported over the network). There are 3 ways of redacting sensitive data: - by adding Fullview's universal masking classes `.fvMask` and `.fvBlock` - by adding specific HTML selectors (i.e. `.class` or `#id`) to your Fullview settings - by setting general rules that prevent capturing data from all: input fields, images, selectors,… If there are any DOM elements containing any of the 3 rules above, Fullview's agent simply skips to the next HTML element without reading the content of it, hence the data is not sent to Fullview's backend.

Captured data is encrypted in-transit using TLS 1.2+ and at-rest using an industry-standard AES-256 encryption algorithm. Data Encryption In-Transit - When data is transmitted between our application, the user's device, and our servers, we use Transport Layer Security (TLS) 1.2 or higher. TLS is a widely adopted security protocol designed to provide privacy and data integrity between two communicating applications. - With TLS 1.2+, data is protected from interception or tampering during transmission. The protocol employs strong encryption methods, such as AES (Advanced Encryption Standard), to secure the data as it travels through the internet. This ensures that sensitive information like personal data, payment details, or authentication credentials are kept confidential and secure from any unauthorized access during transmission. Data Encryption At-Rest: - Once the data reaches our servers, it is stored securely using AES-256 encryption. AES-256 (Advanced Encryption Standard with a 256-bit key length) is one of the strongest encryption standards available and is used globally to protect sensitive data. - This encryption ensures that the data remains secure and unreadable by unauthorized individuals or entities even if they manage to gain access to the storage medium. - Access to the encrypted data is strictly controlled through strong authentication mechanisms and role-based access controls within our infrastructure. Furthermore, the encryption keys used to secure the data are managed by our secure key management systems, ensuring they are rotated, stored, and protected in compliance with industry best practices. Encryption Key Management: - Secure Key Storage: - Encryption keys are securely managed and stored using a Key Management Service (KMS), such as AWS KMS, which utilizes hardware security modules (HSMs) to safeguard keys. - Access Controls: - Access to encryption keys is restricted to authorized personnel only, enforced through strict role-based access…

Instead Fullview stores a representation of what happened inside the browser-tabs, that are part of the application that was configured to use Fullview and only if recording of sessions or cobrowsing calls is desired. What does that mean? First of all Fullview will never receive any information about things that happen outside of the application that has Fullview-scripts installed. Users can safely browse any other side with the same browser instance without fullview noticing. Only the tabs that belong to the actual application to be supported will send their events to the backend - if configured to do so. Since Fullview needs to redact data according to your company’s policies and to stay GDPR compliant, Fullview can’t use a video to transport the data. Instead we use a textual, machine-readable format to transmit what is called “mutations”. Mutations are changes in layout (a button gets highlighted while the user hovers over it) in data (a table gets updated data after a search was performed), etc. We use the fact that the browser handles anything it renders in a tree structure and simple update nodes and leaves according to what the browser sees. This data is then used for replays (replaying one event after the other, applying the mutations that were recorded to the state of the tree from the event before) or to visualize the customers’ browser-tab content to the agent while cobrowsing (cobrowsing uses the same component for replaying, except that it focuses more on realtime-ness rather than time-accuracy as in replays).