Vulnerability Management Policy

SOC 2 Criteria: CC1.2, CC3.1, CC3.3, CC3.4, CC4.1, CC4.2, CC5.1, CC5.2, CC7.1, CC7.2

ISO 27001 Annex A: A.12.1.1, A.12.7.1, A.18.2.3

Keywords: Penetration testing, Pen testing, Vulnerability scans, Vulnerability priority levels, Security SLAs

Purpose

Userflow policy requires that:

• All product systems must be scanned for vulnerabilities at least annually.
• All vulnerability findings must be reported, tagged, and tracked to resolution in accordance with the SLAs defined herein. Records of findings must be retained for at least 5 years.

Roles and Responsibilities

The acting information security officer and team will facilitate and maintain this policy and ensure all employees have reviewed and read the policy.

Policy

Information Systems Audit

The following guidelines will be observed for setting information systems audit controls:

• Audit requirements for access to systems and data should be agreed with appropriate management.
• Scope of technical audit tests should be agreed and controlled.
• Audit tests should be limited to read-only access to software and data.
• Access other than read-only should only be allowed for isolated copies of system files, which should be erased when the audit is completed, or given appropriate protection if there is an obligation to keep such files under audit documentation requirements.
• Requirements for special or additional processing should be identified and agreed.
• Audit tests that could affect system availability should be run outside business hours.
• All access should be monitored and logged to produce a reference trail.

Vulnerability Scanning and Infrastructure Security Testing

The scanning and identification of Userflow’s system vulnerabilities is performed by:

• Automated Drata security agent installed on all employees’ machines.

Additionally, periodic security scans of Userflow systems are done using a well known vulnerability scanner (open source or commercial).

Penetration Testing

On top of our development-related continuous testing, we also conduct periodic third-party manual penetration testing of both our application and infrastructure. You can request a copy of our latest report at security@userflow.com.

Findings from a vulnerability scan and/or penetration test are analyzed by the Security Officer, together with IT and Engineering as needed, and reported through the process defined in the next section.

Security Findings Reporting, Tracking and Remediation

Userflow follows a simple vulnerability tracking process using Notion. The records of findings are retained for 5 years.

Reporting a Finding

• Upon identification of a vulnerability (including vulnerability in software, system, or process), a Notion ticket is created.
• The description of the Finding should include further details, without any confidential information, and a link to the source.
• The Finding will be given a priority level in Notion.

Priority/Severity Ratings and Service Level Agreements

In an effort to quickly remediate security vulnerabilities, the following timelines have been put in place to address vulnerabilities:

In the case a severity rating and/or priority level is updated after a vulnerability finding was originally created, the SLA is updated as follow:

• Priority upgrade: reset SLA from time of escalation
• Priority downgrade: SLA time remains the same from time of creation/identification of finding

Resolving a Finding

• The Finding should be assigned to the owner responsible for the system or software package.
• All findings should be addressed according to the established SLA.
• No software should be deployed to production with unresolved CRITICAL or HIGH findings, unless an Exception is in place (see below).
• A finding may be resolved by
  1. providing a valid fix/mitigation
  2. determining as a false positive
  3. documenting an approved exception

Closing a Finding

• The assignee should provide a valid resolution (see above) and add a comment to the finding.
• The finding should be re-assigned to the Reporter or a member of the security team for validation.
• Upon validation, the finding can be marked as Done (closed) by the Reporter.
• Before the finding can be marked as closed by the reporter, the fix must be deployed to a development environment and have a targeted release date for deploying to production noted on the ticket.

Exceptions

• An Exception may be requested when a viable or direct fix to a vulnerability is not available. For example, a version of the package that contains the fix is not supported on the particular operating system in use.
• An alternative solution (a.k.a. compensating control) must be in place to address the original vulnerability such that the risk is mitigated. The compensating control may be technical or a process or a combination of both.
• An Exception must be opened in the form of a Notion ticket
• The Exception Issue must reference the original Finding by adding an Issue Link to the Finding issue.
• Each Exception must be reviewed and approved by the Security Officer and the impacted asset owner.

Revision History