From 8e413bbf17f82093b3839c31d82b789de6763511 Mon Sep 17 00:00:00 2001 From: KayLEvans Date: Mon, 12 Jan 2026 17:45:30 -0500 Subject: [PATCH 1/2] Security annual review and update updates to follow a template and terminology and review date --- README.md | 4 ++-- access-control/index.md | 24 +++++++++++++------ bcp-dr/index.md | 18 ++++++++++----- change-management/index.md | 18 ++++++++++----- data-retention-deletion/index.md | 26 +++++++++++++-------- incident-disclosure/index.md | 12 +++++++++- incident-response-policy/index.md | 22 ++++++++++++------ incident-response-process/index.md | 32 +++++++++++++++++-------- information-classification/index.md | 17 ++++++++++---- overview.md | 9 +++++++- password/index.md | 36 +++++++++++++++++++---------- patch-management/index.md | 28 ++++++++++++++-------- personnel/index.md | 24 +++++++++++++++---- risk-assessment/index.md | 13 ++++++++++- testing/index.md | 22 +++++++++++------- vendor/index.md | 18 +++++++++++---- 16 files changed, 229 insertions(+), 94 deletions(-) diff --git a/README.md b/README.md index 0b852be..f3c93fc 100644 --- a/README.md +++ b/README.md @@ -8,7 +8,7 @@ _Since these are our internal policies, some links to internal documents or reso This repository is the source of truth for the policies available at https://tailscale.com/security-policies/. -These policies were last reviewed on 2025-04-07. +These policies were last reviewed on 2026-01-12. ### FAQ @@ -32,7 +32,7 @@ This repository includes: ### When does Tailscale review or update these policies? -The Chief Operating Officer is responsible for reviewing and updating security policies on a quarterly basis. +The Chief Operating Officer is responsible for reviewing and updating security policies on an annual basis. See [overview](/overview.md) of policies. ### Why don't you use the stronger security control X for the Y policy? diff --git a/access-control/index.md b/access-control/index.md index 9088fde..ed2f92f 100644 --- a/access-control/index.md +++ b/access-control/index.md @@ -6,6 +6,8 @@ faq: false weight: 7 --- +### Purpose + Tailscale limits access control based on job requirements, following the principle of least privilege. ### Scope @@ -14,26 +16,34 @@ This policy applies to Tailscale’s internal systems, including its production This policy applies throughout the entire lifecycle of employee, contractor, or vendor access, from onboarding of new individuals who need access, to the removal of existing individuals who no longer need access. -### Access to internal systems +### Policy + +#### Access to internal systems Where possible, access policies are enforced by technical measures. -Tailscale should implement monitoring on its systems where possible, to record logon attempts and failures, successful logons and date and time of logon and logoff. Activities performed as administrator are logged where it is feasible to do so. +Tailscale must implement monitoring on its systems where possible, to record logon attempts and failures, successful logons and date and time of logon and logoff. Activities performed as administrator are logged where it is feasible to do so. + +Personnel that require access to systems must submit a ticket for review and approval by a manager or a member of the Security Team to provision access. -Personnel who have administrative system access should use other less powerful accounts for performing non-administrative tasks. +Personnel who have administrative system access must use other less powerful accounts for performing non-administrative tasks. Where possible, more than one person must have full rights to any critical piece of infrastructure serving or storing production services or customer data. -### Granular access controls +#### Granular access controls -Tailscale systems must have sufficient granularity to allow appropriate authorized access. There is a delicate balance between protecting the data and permitting access to those who need to use the data for authorized purposes. Tailscale recognizes that balance. +Tailscale systems must have sufficient granularity to allow appropriate authorized access and all access requests require approval from the Security team. There is a delicate balance between protecting the data and permitting access to those who need to use the data for authorized purposes. Tailscale recognizes that balance. -### End user devices +#### End user devices Employees, contractors, and vendors are responsible for safe handling and storage of Tailscale-provided end user devices. If a device is lost or stolen, the loss must be immediately reported as an incident. -### Changing roles or responsibilities +#### Changing roles or responsibilities Terminated employees must have their accounts disabled within 1 business day of transfer or termination. Transferred employee access is reviewed and adjusted as found necessary. Since there could be delays in reporting changes in user responsibilities, periodic user access reviews are conducted by the Security Review Team. + +### Roles and responsibilities + +Tailscale’s Security team is responsible for administering access to systems and reviewing and updating the Access Control process on an annual basis. \ No newline at end of file diff --git a/bcp-dr/index.md b/bcp-dr/index.md index 614aee3..3041990 100644 --- a/bcp-dr/index.md +++ b/bcp-dr/index.md @@ -6,7 +6,7 @@ faq: false weight: 6 --- -### Context +### Purpose Tailscale’s customers are dependent on our services operating as normal. Proper planning, monitoring, and recovery steps are critical to address incidents that may impact the integrity or availability of services and data is critical to the operation of Tailscale. Business Continuity and Disaster Recovery is a set of processes and techniques used to help an organization recover from a disaster and resume routine business operations. @@ -14,12 +14,12 @@ Tailscale’s customers are dependent on our services operating as normal. Prope The following minimum standards apply to Tailscale’s assets as managed by employees, contractors and vendors. These include but are not limited to: cloud service providers, cloud regions, major components within cloud regions, key vendors (those included in our [vendor assessment](/security-policies/vendor/), and key open-source components. -### Schedule +### Policy Tailscale reviews its backups, and any BCP/DR plans annually with a walkthrough exercise. Tailscale tests its ability to restore production data at least annually. -### Backups +#### Backups Tailscale regularly reviews backups and service redundancy to ensure they can be used in the event of an outage. The Security Review Team: @@ -28,10 +28,16 @@ Tailscale regularly reviews backups and service redundancy to ensure they can be * Reviews proposed and existing architecture plans for resiliency * Implements monitoring tools to detect potential continuity issues for key services -### Outage detection +#### Outage detection An incident could be detected internally by monitoring tools, by an employee in their course of work, or reported by a third party including customers. -### Outage response and remediation +#### Outage response and remediation -If a suspected outage or other business continuity incident is detected, it should be responded to following the [Incident response process](/security-policies/incident-response-process). +If a suspected outage or other business continuity incident is detected, it must be responded to following the [Incident response process](/security-policies/incident-response-process). + +### Roles and responsibilities + +Tailscale’s Security team is responsible for conducting tests and reviewing and updating the BCP/DR process on an annual basis. + +All departments have processes in place to continue business during an interruption. diff --git a/change-management/index.md b/change-management/index.md index e81c431..16a93cc 100644 --- a/change-management/index.md +++ b/change-management/index.md @@ -6,9 +6,17 @@ faq: false weight: 9 --- +### Purpose + To avoid potential security incidents, Tailscale requires change management controls to ensure only authorized changes are made to its environment and processes. -### Environment +### Scope + +This policy applies to code, infrastructure, and customer account changes. + +### Policy + +#### Environment #### Code changes @@ -30,7 +38,7 @@ Documentation can be updated without requiring a separate reviewer. #### Infrastructure changes -Employees should notify others prior to making changes to Tailscale’s infrastructure, e.g., over Slack. Where infrastructure is codified and uses a deployment tool, infrastructure changes should be approved by another employee prior to being deployed. +Employees must notify others prior to making changes to Tailscale’s infrastructure, e.g., over Slack. Where infrastructure is codified and uses a deployment tool, infrastructure changes must be approved by another employee prior to being deployed. #### Customer accounts @@ -38,8 +46,6 @@ Tailscale may make changes to customers’ networks and accounts in Tailscale at Tailscale may also make changes to customer environments without the customer initiating the request, such as when required by law or due to an urgent security issue. -### Security policies - -Security policies must have a change log to allow auditing of past changes, including when and by whom these changes were made. Tailscale stores these security policies in GitHub and uses git to track changes. +### Roles and responsibilities -Tailscale will review and evaluate its security policies, adapt them as needed due to changing risks, and validate if the implemented information security continuity controls are sufficient on a quarterly basis. \ No newline at end of file +Tailscale’s Security Review team is responsible for reviewing and updating the Change Management policy requirements on an annual basis. \ No newline at end of file diff --git a/data-retention-deletion/index.md b/data-retention-deletion/index.md index 65176fa..ac3c6ef 100644 --- a/data-retention-deletion/index.md +++ b/data-retention-deletion/index.md @@ -6,19 +6,23 @@ faq: false weight: 12 --- +### Purpose + Tailscale must retain certain kinds of data for a minimum amount of time, to comply with legal requirements. At the same time, Tailscale wants to avoid retaining any identifiable data for longer than is necessary, in case of a breach. ### Scope This policy applies to all data assets handled by Tailscale, including data from customers, potential customers, third parties, and employees. -### Schedule +### Policy + +#### Schedule -Tailscale should review the data it retains as part of reviewing its data register quarterly. +Tailscale must review the data it retains as part of reviewing its data register quarterly. -### Retention period +#### Retention period -Data should be retained for a set period of time, depending on the type of data: +Data must be retained for a set period of time, depending on the type of data: @@ -209,12 +213,16 @@ Data should be retained for a set period of time, depending on the type of data: *In response to a customer request and in compliance with legal requirements, Tailscale may also delete customer data prior to the end of the retention period. -Where not specified, customer data should be retained no longer than is needed to provide the service, and anonymized or deleted afterwards. +Where not specified, customer data must be retained no longer than is needed to provide the service, and anonymized or deleted afterwards. + +#### Privacy Policy + +Tailscale must delete customer data in accordance with the commitments, if any, made in [Tailscale’s Privacy Policy](/privacy-policy/). If the privacy policy is updated, the above retention periods must also be updated to reflect any changes. -### Privacy Policy +#### Deletion method -Tailscale must delete customer data in accordance with the commitments, if any, made in [Tailscale’s Privacy Policy](/privacy-policy/). If the privacy policy is updated, the above retention periods should also be updated to reflect any changes. +Data may be destroyed by overwriting on disk, deleting a cloud resource, encrypting and destroying the key, resetting a device, and/or physical destruction. -### Deletion method +### Roles and responsibilities -Data may be destroyed by overwriting on disk, deleting a cloud resource, encrypting and destroying the key, resetting a device, and/or physical destruction. \ No newline at end of file +Tailscale’s Security Review team is responsible for reviewing and updating the Data Retention policy requirements on an annual basis. diff --git a/incident-disclosure/index.md b/incident-disclosure/index.md index ad3627f..9d338ed 100644 --- a/incident-disclosure/index.md +++ b/incident-disclosure/index.md @@ -6,15 +6,21 @@ faq: false weight: 5 --- +### Purpose + This policy specifies when and how we notify users about security incidents. +### Scope + Both the client software and our managed backend infrastructure (i.e. coordination server) are in scope for this policy. +### Policy + For incidents that fall under any legal disclosure requirements (such as [California’s Data Security Breach Reporting](https://oag.ca.gov/privacy/databreach/reporting)), those requirements will take precedence over this policy. By “notify” here we mean explicitly contacting users in addition to regular release notes in the [changelog](https://tailscale.com/changelog/) and GitHub commit history. For example, you may read about minor vulnerability patches in release notes, but we may not notify users via a dedicated security bulletin. -### When we notify users +#### When we notify users Generally, we aim to reduce noise and only notify users for actionable incidents. Tailscale does not notify users for routine security patching of dependencies. We also don’t notify users for vulnerabilities in our software, if we confirm the vulnerability was not exploited and no users were affected. @@ -36,3 +42,7 @@ To disclose security vulnerabilities, Tailscale publishes security bulletins pub To notify users about security vulnerabilities, Tailscale will **email** affected tailnets’ administrators, with information specific to the tailnet, including specific users or nodes which are affected. These emails will be sent to the [security contact](https://tailscale.com/kb/1224/contact-preferences/#setting-the-security-issues-email) for the tailnet, which by default is the Owner of the tailnet. Occasionally, Tailscale may decide to notify users in additional ways about a security issue, such as by publishing a [blog post](https://tailscale.com/blog/), or with in-product notifications (such as by putting a warning banner in the admin console). + +### Roles and responsibilities + +Tailscale’s Security Review team is responsible for sending notifications for incidents. The Security team is responsible for reviewing and updating this policy on an annual basis. diff --git a/incident-response-policy/index.md b/incident-response-policy/index.md index fb8e590..84d5442 100644 --- a/incident-response-policy/index.md +++ b/incident-response-policy/index.md @@ -6,27 +6,32 @@ faq: false weight: 5 --- -### Context +### Purpose Tailscale’s customers are dependent on our services operating as normal. Proper detection and response to incidents that may impact the integrity, confidentiality or availability of services and data is critical to the operation of Tailscale. +### Scope + The following minimum standards apply to Tailscale’s assets as managed by employees, contractors and vendors. These recommendations represent the recommended minimum efforts necessary for incident detection and response. -### Incident detection +### Policy + +#### Incident detection -An incident could be detected internally by an employee in their course of work, by an employee or vendor doing a review of Tailscale’s security posture, or an external third party reporting a potential vulnerability to us. +An incident could be detected by automated alerting, internally by an employee in their course of work, by an employee or vendor doing a review of Tailscale’s security posture, or an external third party reporting a potential vulnerability to us. -If you see something, say something. All Tailscale employees should immediately report suspected security incidents or suspicious activity that occurs at Tailscale, including but not limited to security incidents, physical injury, theft, property damage, denial of service attacks, threats, harassment, abuse of individual user accounts, forgery and misrepresentation. Suspicious activity can be reported to the Slack channel #incident-response, or, for potentially sensitive incidents, to the Security Review Team or to the Chief Operating Officer (COO). Violations of the [Code of Conduct](http://go/code-of-conduct) should be reported to the Chief Operating Officer (COO). +If you see something, say something. All Tailscale employees must immediately report suspected security incidents or suspicious activity that occurs at Tailscale, including but not limited to security incidents, physical injury, theft, property damage, denial of service attacks, threats, harassment, abuse of individual user accounts, forgery and misrepresentation. Suspicious activity can be reported to the Slack channel #incident-response, or, for potentially sensitive incidents, to the Security Review Team or to the Chief Operating Officer (COO). Violations of the [Code of Conduct](http://go/code-of-conduct) must be reported to the Chief Operating Officer (COO). -All employees should watch for potentially suspicious activities, including: +All employees much watch for potentially suspicious activities, including: * Warnings from antivirus tools * Unexpected system reboots and/or sudden degradation of system performance * Password reset notifications * Modification or defacement of websites * New open network ports on a system +* Multi-factor authentication prompts -Tailscale regularly reviews logs to detect and track attempted intrusions and other suspicious activity. These include git, cloud, networking, SaaS tool, and other infrastructure logs. +Tailscale regularly reviews logs to detect and track attempted intrusions and other suspicious activity. These include git, cloud, networking, SaaS tools, and other infrastructure logs. The Security Review Team: @@ -40,8 +45,11 @@ Tailscale’s Security Review Team reviews and responds to potential third-party ### Incident response and remediation -If a suspected incident is detected, it should be responded to following the [Incident response process](/security-policies/incident-response-process/). +If a suspected incident is detected, it must be responded to following the [Incident response process](/security-policies/incident-response-process/). We respond to reported incidents, and resolve and determine impact as soon as possible. We aim to remediate incidents as soon as possible. Confirmed incidents may be disclosed publicly per our [disclosure policy](/security-policies/incident-disclosure/). + +### Roles and responsibilities +Tailscale’s Security Review team is responsible for handling potential security incidents. The Security team is responsible for reviewing and updating this policy on an annual basis. \ No newline at end of file diff --git a/incident-response-process/index.md b/incident-response-process/index.md index e276bbe..e55a1bf 100644 --- a/incident-response-process/index.md +++ b/incident-response-process/index.md @@ -6,12 +6,22 @@ faq: false weight: 5 --- -### Incident response +### Purpose + +Tailscale’s customers are dependent on our services operating as normal. Proper detection and response to incidents that may impact the integrity, confidentiality or availability of services and data is critical to the operation of Tailscale. + +### Scope + +The following minimum standards apply to Tailscale’s assets as managed by employees, contractors and vendors. These recommendations represent the recommended minimum efforts necessary for incident detection and response. + + +### Policy + +#### Incident response When a suspected incident is reported, it is first investigated by the eng-primary -oncall. If it is suspected to be an incident, they should declare an incident, -and identify the Incident Commander in the #incident-response Slack channel. -The Incident Commander is responsible for: +oncall. If it is suspected to be an incident, they must declare an incident, +and identify the Incident Commander in the #incident-response Slack channel. Information from an incident must be kept confidential. The Incident Commander is responsible for: * If an incident is likely to require ongoing response and remediation efforts, opening a GitHub issue in the tailscale/corp repo to track updates to @@ -26,17 +36,17 @@ The Incident Commander is responsible for: * Ensuring handoff between team members, for example, at the end of a work day. * Escalating to leadership if responses are insufficient. -In addition to remediating the incident, Tailscale employees should also seek +In addition to remediating the incident, Tailscale employees must also seek to put into place any corrective actions possible to lessen the impact of an incident. If an incident affects customers, including their data or their ability to use Tailscale, Tailscale may choose to proactively communicate the issue publicly. -### Incident recovery +#### Incident recovery If data or processes were disrupted by the incident, then the [BCP/DR policy](/security-policies/bcp-dr/) -should be followed to remediate the issue. +must be followed to remediate the issue. Once an incident is mitigated or otherwise closed, it is the Incident Commander’s responsibility to ensure that @@ -49,9 +59,9 @@ Commander’s responsibility to ensure that mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring. Where applicable, some version of the post-mortem may be shared with external affected parties. Newly identified - risks should be added to the risk register. + risks must be added to the risk register. -### Incident classification +#### Incident classification An incident is an adverse event which affects Tailscale’s infrastructure or business operations in such a way that it compromises our ability to deliver @@ -92,3 +102,7 @@ Incidents can be classified based on their severity:
+ +### Roles and responsibilities + +Tailscale’s Security team is responsible for reviewing and updating the incident response process on an annual basis. diff --git a/information-classification/index.md b/information-classification/index.md index a6fbd54..bf9701d 100644 --- a/information-classification/index.md +++ b/information-classification/index.md @@ -6,11 +6,17 @@ faq: false weight: 3 --- +### Purpose + To understand its potential exposure from a security risk, issue or incident, Tailscale regularly catalogues and classifies its data and other in-scope assets, in order to apply risk-based controls. -Assets are anything that has value to the organization, including but not limited to, customer data, production data, financial data, intellectual property, and any material non-public information. +### Scope + +Applicable assets include, but not limited to, customer data, production data, financial data, intellectual property, and any material non-public information. -### Asset cataloging +### Policy + +#### Asset cataloging Tailscale catalogues assets with several pieces of information, to help identify the potential risk of the asset. Information collected is as follows: @@ -72,8 +78,9 @@ Tailscale classifies assets into three risk categories: **Low Risk**, **Medium R -When multiple classifications may apply, the highest applicable classification is used. For example, if a machine is low-risk by itself, but can be used to access high-risk data, its overall classification is also high-risk. +When multiple classifications may apply, the highest applicable classification is used. For example, if a machine is low-risk by itself, but can be used to access high-risk data, its overall classification is also high-risk. Any unlabeled assets will be considered confidential with the risk category of High by default. + -### Schedule +### Roles and responsibilities -Tailscale should review the data it collects and processes, and update the data register, quarterly. \ No newline at end of file +Tailscale’s Security team is responsible for reviewing and updating data assets on an annual basis. diff --git a/overview.md b/overview.md index 4c1dfa5..47b7bba 100644 --- a/overview.md +++ b/overview.md @@ -4,4 +4,11 @@ All security policies are owned by the Chief Operating Officer (COO). The Securi The Chief Operating Officer and the Security Review Team are responsible for implementing the processes and controls laid out in the security policies, and pulling in other employees as needed. ### Schedule -The Chief Operating Officer is responsible for reviewing and updating security policies on an annual basis. \ No newline at end of file +Security policies must have a change log to allow auditing of past changes, including when and by whom these changes were made. Tailscale stores these security policies in GitHub and uses git to track changes. +Tailscale will review and evaluate its security policies, adapt them as needed due to changing risks, and validate if the implemented information security continuity controls are sufficient on an annual basis. + +### Compliance and enforcement +Employee’s adherence to these policies is acknowledged in the Employee Handbook as part of onboarding. + +### Violations +If the Company determines a policy violation has occurred, the person found to have violated this policy will be subject to disciplinary action, up to and including termination of the working relationship. \ No newline at end of file diff --git a/password/index.md b/password/index.md index fe77543..6168e20 100644 --- a/password/index.md +++ b/password/index.md @@ -6,13 +6,21 @@ faq: false weight: 8 --- +### Purpose + To avoid potential security incidents, Tailscale requires employees to follow password requirements. ### Scope -This policy applies to passwords for any application or server accessed by Tailscale employees, contractors, or vendors. _It does not apply to the passwords customers of Tailscale use to access the Tailscale service._ +This policy applies to passwords for any Software as a Service (SaaS), cloud environments, and owned or leased applications or servers accessed by Tailscale employees, contractors, or vendors. _It does not apply to the passwords customers of Tailscale use to access the Tailscale service._ + +### Policy + +#### Password strength -### Password strength +Passwords must be generated using a password management service. + +Password length must be at least a 15 character minimum. Passwords must be unique for each use. @@ -22,27 +30,27 @@ Default passwords on all systems are changed after installation. Initial passwor Passwords do not need to be regularly rotated. However, if a password is known or thought to be compromised, it must be rotated to a new password. -### Single sign-on +#### Single sign-on Where a third-party application supports single sign-on, it must be used. -### Multi-factor authentication +#### Multi-factor authentication Where a third-party application supports multi-factor authentication, it must be used. Use of multi-factor is enforced where possible. Acceptable forms of multi-factor authentication include authentication apps or a WebAuthn token. Embedded tokens (e.g., TouchID) are permitted. WebAuthn hardware or embedded hardware tokens are preferred to authentication apps. -### Password manager +#### Password manager -Where SSO is not used, and where possible, passwords should be stored in a password manager. +Where SSO is not used, and where possible, passwords must be stored in a password manager. -### Encryption at rest +#### Encryption at rest -Passwords should be stored encrypted at rest. +Passwords must be stored encrypted at rest. -### Logging +#### Logging -Passwords should not be logged. +Passwords must not be logged. ### Requirements for specific use cases @@ -52,7 +60,7 @@ Access to servers, for both production as well as development and testing infras #### Automated processes -Automated processes, including deployment or CI/CD tools, should use passwords or API keys to access and communicate with other systems. Passwords used in scripts must be encrypted at rest. +Automated processes, including deployment or CI/CD tools, must use passwords or API keys to access and communicate with other systems. Passwords used in scripts must be encrypted at rest. #### End user devices @@ -62,4 +70,8 @@ End user devices must use passwords to encrypt their disks and unlock the device Access to third party applications must use SSO where possible, MFA where possible, and enforce MFA where possible. -An individual’s password for their password management vault must be unique. These do not need to be randomly generated. \ No newline at end of file +An individual’s password for their password management vault must be unique. These do not need to be randomly generated. + +### Roles and responsibilities + +Tailscale’s Security team is responsible for reviewing and updating the Password requirements on an annual basis. \ No newline at end of file diff --git a/patch-management/index.md b/patch-management/index.md index 4bd8ef6..1b231cd 100644 --- a/patch-management/index.md +++ b/patch-management/index.md @@ -6,6 +6,8 @@ faq: false weight: 11 --- +### Purpose + To avoid potential security incidents, Tailscale regularly reviews potential vulnerabilities in its environment and applies relevant patches. ### Scope @@ -14,28 +16,34 @@ This patch management policy applies to Tailscale’s infrastructure, including This patch management policy also applies to the software Tailscale ships to customers. -### Vulnerability and patch detection +### Policy + +#### Vulnerability and patch detection In order to detect potential vulnerabilities, the Security Review Team: -* Subscribes to and reviews announcements for security patches in OSes from vendors and open source maintainers for servers, development infrastructure, and end user devices. +* Subscribes to and reviews announcements for security vulnerabilities and patches in OSes from vendors and open source maintainers for servers, development infrastructure, and end user devices. * Reviews dependencies for security patches prior to new builds for software that Tailscale ships. -Where automated patch rollout is available, e.g., auto-updates on iOS devices, it should be enabled. +Where automated patch rollout is available, e.g., auto-updates on iOS devices, it must be enabled. -### Review and approval +#### Review and approval Security patches can be applied without further approval. -### Schedule +#### Schedule + +Tailscale must review any new security patches when they are released by vendors, or when building a new release, which in practice is about monthly. + +Tailscale must patch security vulnerabilities as soon as possible. The expected timeline for remediation, from when a patch is available to when it is applied, is 90 days. -Tailscale should review any new security patches when they are released by vendors, or when building a new release, which in practice is about monthly. +#### Mitigations -Tailscale should patch security vulnerabilities as soon as possible. The expected timeline for remediation, from when a patch is available to when it is applied, is 90 days. +Where a patch is not yet available, or cannot be applied, Tailscale must put in place mitigations as appropriate to prevent a vulnerability from being exploited. Tailscale must also put in place mitigations if a vulnerability is known to be actively exploited in the wild. -### Mitigations +Mitigations can include: removing functionality, limiting who can access a service, or taking down a service. -Where a patch is not yet available, or cannot be applied, Tailscale should put in place mitigations as appropriate to prevent a vulnerability from being exploited. Tailscale should also put in place mitigations if a vulnerability is known to be actively exploited in the wild. +### Roles and responsibilities -Mitigations can include: removing functionality, limiting who can access a service, or taking down a service. \ No newline at end of file +Tailscale’s Security Review team is responsible for reviewing and updating the Vulnerability policy requirements on an annual basis. diff --git a/personnel/index.md b/personnel/index.md index efcf747..895aa02 100644 --- a/personnel/index.md +++ b/personnel/index.md @@ -6,13 +6,27 @@ faq: false weight: 1 --- -Tailscale reviews risks on a regular basis, to ensure proper mitigations are in place. +### Purpose -### Reference Checks +To establish clear guidelines and requirements for employee behavior and responsibilities in regard to security, confidentiality, and integrity. + +### Scope + +This policy covers all Tailscale employees including interns, contractors, part-time and full-time staff. + +### Policy + +#### Reference Checks As part of its hiring process, Tailscale does not perform criminal background checks, but does employ a reference check process for prospective employment candidates prior to or within 30 days of their hire date. -### Security Awareness training +#### Security Awareness training + All employees must complete Tailscale’s information security awareness training as part of their initial onboarding and thereafter, while still under contract, on an annual basis. -### Performance Reviews -All full time employees must complete an annual Performance Review, the results of which are signed and dated by both the employee and their manager, and uploaded to the employee’s personnel files in the HR system. \ No newline at end of file +#### Performance Reviews + +All full time employees must complete an annual Performance Review, the results of which are signed and dated by both the employee and their manager, and uploaded to the employee’s personnel files in the HR system. + +### Roles and responsibilities + +Tailscale’s People Operations team is responsible for conducting reference checks and managing the performance review process. The Security Team is responsible for security awareness training assignments. \ No newline at end of file diff --git a/risk-assessment/index.md b/risk-assessment/index.md index ec54181..a2a10f4 100644 --- a/risk-assessment/index.md +++ b/risk-assessment/index.md @@ -6,14 +6,19 @@ faq: false weight: 2 --- +### Purpose + Tailscale reviews risks on a regular basis, to ensure proper mitigations are in place. ### Scope + This policy covers any risk that could affect confidentiality, availability, and integrity of Tailscale’s key information assets and systems. Risk assessments can be conducted on any information system, to include applications, servers, and networks, and any process or procedure by which these systems are administered and/or maintained. -### Risk assessment +### Policy + +#### Risk assessment The Security Review Team is responsible for completing periodic information security risk assessments for the purpose of determining areas of vulnerability, and to identify and initiate appropriate remediations. A risk register should include: @@ -24,5 +29,11 @@ A risk register should include: The execution, development and implementation of remediation programs is the joint responsibility of the Security Review Team. Employees are expected to cooperate fully with any risk assessment being conducted on systems for which they are held accountable. Employees are further expected to work with the Security Review Team in the development and implementation of a remediation plan. +### Roles and responsibilities + +Tailscale’s Security team is responsible for reviewing risks on an annual basis. + + ### Schedule + Risks should be evaluated on an annual basis. diff --git a/testing/index.md b/testing/index.md index effb14a..0a83490 100644 --- a/testing/index.md +++ b/testing/index.md @@ -6,28 +6,34 @@ faq: false weight: 10 --- +### Purpose + To avoid potential security incidents, Tailscale requires testing of its software to ensure that it functions as expected. ### Scope This policy applies to code developed by Tailscale for its clients or run on its production servers. -### Code changes +#### Code changes -Changes to production code which alter Tailscale’s product functionality should be tested by Tailscale’s continuous integration (CI) system prior to being merged. Testing should not be conducted locally in a development environment or in production. +Changes to production code which alter Tailscale’s product functionality must be tested by Tailscale’s continuous integration (CI) system prior to being merged. Testing must not be conducted locally in a development environment or in production. Exceptionally, changes to production code may be merged without first testing them, such as to resolve an incident. See the [Change management policy](/security-policies/change-management). Changes to production code which do not alter product functionality, e.g., changes to documentation, may be but do not need to be tested. -### Client releases +#### Client releases + +When a new version of the Tailscale client is built, it must be tested prior to being released. This includes testing [major product features on supported platforms](http://go/testing-procedure). + +New functionality must be released as part of an unstable track prior to being incorporated in stable client releases. New functionality may be released directly to a stable client to address an incident, such as a security issue. -When a new version of the Tailscale client is built, it should be tested prior to being released. This includes testing [major product features on supported platforms](http://go/testing-procedure). +#### Infrastructure changes -New functionality should be released as part of an unstable track prior to being incorporated in stable client releases. New functionality may be released directly to a stable client to address an incident, such as a security issue. +Changes to Tailscale’s production infrastructure must be tested where possible. -### Infrastructure changes +Where possible, infrastructure must be implemented ‘as code’, so that it can be reviewed, approved, and tested as other code changes are. -Changes to Tailscale’s production infrastructure should be tested where possible. +### Roles and responsibilities -Where possible, infrastructure should be implemented ‘as code’, so that it can be reviewed, approved, and tested as other code changes are. +Tailscale’s Security Review team is responsible for reviewing and updating the Testing policy requirements on an annual basis. \ No newline at end of file diff --git a/vendor/index.md b/vendor/index.md index 1ad87a4..825c98b 100644 --- a/vendor/index.md +++ b/vendor/index.md @@ -6,30 +6,34 @@ faq: false weight: 4 --- +### Purpose + Tailscale reviews vendor security practices before contracting, and on a regular basis, to ensure vendors properly handle Tailscale’s customer data, confidential data, and other data. ### Scope This policy only applies to vendors or contractors handling Tailscale or its customers’ data. -### Schedule +### Policy + +#### Schedule -Vendors’ security practices should be initially evaluated as part of their contract review, and while still in use, on an annual basis. +Vendors’ security practices must be initially evaluated as part of their contract review, and while still in use, on an annual basis. Contractors must read and acknowledge Tailscale’s security policies as part of their onboarding. Contractors must complete Tailscale’s information security training as part of their onboarding and thereafter, while still under contract, on an annual basis. ### Vendor assessment -As part of vendor evaluation and contracting, vendors’ security practices should be reviewed to ensure they sufficiently protect Tailscale’s and its customers’ data. +As part of vendor evaluation and contracting, vendors’ security practices must be reviewed to ensure they sufficiently protect Tailscale’s and its customers’ data. The requirements for a vendor may change based on the risk classification of the assets they are handling (see the Information classification policy), such as sensitive data, or access to production resources; and may change during a contract if a vendor’s scope or responsibilities change. Tailscale will: -1. Ask vendors for their SOC 2 type II or type I report for an overview of their current security practices. If a SOC 2 report does not exist or where insufficient information is provided, Tailscale will ask the vendor to complete the [VSAQ](https://vsaq-demo.withgoogle.com/). +1. Ask vendors for their SOC 2 type II or type I report for an overview of their current security practices. If a SOC 2 report does not exist or where insufficient information is provided, Tailscale will ask the vendor to complete the Vendor Security Assessment Questionnaire (VSAQ). 2. Review the vendor’s responses and compare these to Tailscale’s security policies to identify any gaps where the vendor may have weaker policies. -3. For each notable gap or where insufficient information is provided, Tailscale can: ask the vendor to make a change or provide additional information, implement a mitigating control, or accept the risk. These should be documented in the risk register. +3. For each notable gap or where insufficient information is provided, Tailscale can: ask the vendor to make a change or provide additional information, implement a mitigating control, or accept the risk. These must be documented in the risk register. Tailscale will document vendor information, to help in case of a potential incident. This information includes: @@ -38,3 +42,7 @@ Tailscale will document vendor information, to help in case of a potential incid * **Type of data shared**, i.e. What types of data from Tailscale does the vendor collect or otherwise have access to? * **Terms of Service** for services provided by the vendor * **Security report or questionnaire** shared by the vendor + +### Roles and responsibilities + +Tailscale’s Security team is responsible for reviewing and updating third party vendors on an annual basis. From 6cdf8e5893e1d5c03d68d38b11cd4e38a9b8a4c9 Mon Sep 17 00:00:00 2001 From: KayLEvans <106268083+KayLEvans@users.noreply.github.com> Date: Tue, 13 Jan 2026 13:15:25 -0500 Subject: [PATCH 2/2] Update index.md remove "Environment" and replaced with "Policy" --- change-management/index.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/change-management/index.md b/change-management/index.md index 147b152..944b969 100644 --- a/change-management/index.md +++ b/change-management/index.md @@ -17,8 +17,6 @@ This policy applies to code, infrastructure, and customer account changes. ### Policy -#### Environment - #### Code changes Changes to code in Tailscale’s environment made by an employee or contractor must be tested and approved by another employee prior to being merged and rolled out.