├── .github ├── scripts │ ├── mkpdf.sh │ └── filter.lua └── workflows │ └── pandoc.yaml ├── overview.md ├── _index.md ├── personnel └── index.md ├── risk-assessment └── index.md ├── testing └── index.md ├── bcp-dr └── index.md ├── access-control └── index.md ├── patch-management └── index.md ├── change-management └── index.md ├── vendor └── index.md ├── password └── index.md ├── data-retention-deletion └── index.md ├── incident-disclosure └── index.md ├── incident-response-policy └── index.md ├── information-classification └── index.md ├── README.md ├── incident-response-process └── index.md └── LICENSE /.github/scripts/mkpdf.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | set -e 3 | 4 | printf '\\newpage\n\n' > combined.md 5 | cat _index.md >> combined.md 6 | printf '\n\n' >> combined.md 7 | cat overview.md >> combined.md 8 | for md in */*.md; do 9 | printf '\n\n\\newpage\n\n' >> combined.md 10 | pandoc $md \ 11 | --lua-filter=.github/scripts/filter.lua \ 12 | -f markdown-markdown_in_html_blocks \ 13 | -t markdown >> combined.md 14 | done 15 | pandoc combined.md --toc --pdf-engine=xelatex -o policies.pdf 16 | -------------------------------------------------------------------------------- /.github/scripts/filter.lua: -------------------------------------------------------------------------------- 1 | -- A RawBlock filter to parse inlined html tags, mainly s. 2 | function RawBlock(raw) 3 | if raw.format:match 'html' then 4 | return pandoc.read(raw.text, 'html').blocks 5 | end 6 | end 7 | 8 | -- A Pandoc (i.e. whole document) filter to insert the title from metadata as a header. 9 | function Pandoc(doc) 10 | local title = pandoc.utils.stringify(doc.meta.title) 11 | table.insert(doc.blocks, 1, pandoc.Header(1, pandoc.Str(title))) 12 | return doc 13 | end 14 | -------------------------------------------------------------------------------- /overview.md: -------------------------------------------------------------------------------- 1 | ### Security policy ownership 2 | All security policies are owned by the Chief Operating Officer (COO). The Security Review Team (members in Security, Engineering, and Operations) are responsible for reviewing the policies. 3 | 4 | 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. 5 | 6 | ### Schedule 7 | The Chief Operating Officer is responsible for reviewing and updating security policies on an annual basis. 8 | -------------------------------------------------------------------------------- /.github/workflows/pandoc.yaml: -------------------------------------------------------------------------------- 1 | name: Generate PDFs 2 | 3 | on: push 4 | 5 | jobs: 6 | pandoc: 7 | runs-on: ubuntu-latest 8 | 9 | steps: 10 | - name: Check out code 11 | uses: actions/checkout@v3 12 | with: 13 | fetch-depth: 0 14 | 15 | - uses: docker://pandoc/latex:latest-ubuntu 16 | with: 17 | entrypoint: /bin/sh 18 | args: -c .github/scripts/mkpdf.sh 19 | 20 | - name: Upload output 21 | uses: actions/upload-artifact@master 22 | with: 23 | name: policies.pdf 24 | path: policies.pdf 25 | -------------------------------------------------------------------------------- /_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Our security policies 3 | header-includes: | 4 | \usepackage{fancyhdr} 5 | \pagestyle{fancy} 6 | \lhead{} 7 | \rhead{TAILSCALE SECURITY POLICIES} 8 | \rfoot{\thepage} 9 | \cfoot{} 10 | \lfoot{Tailscale Inc.} 11 | --- 12 | 13 | Tailscale has several security policies in place to properly identify, respond to, and mitigate potential security risks. All employees, vendors and contractors working with Tailscale must follow these policies in order to best protect Tailscale’s and its customers’ data. 14 | 15 | We've published these publicly for transparency, so that you can see where we are in terms of security maturity. We also hope you use these to adopt similar policies and processes at your organization. 16 | 17 | *Since these are our internal policies, some links to internal documents or resources are only visible to employees.* 18 | 19 | [Get policies on GitHub →](https://www.github.com/tailscale/policies) -------------------------------------------------------------------------------- /personnel/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Personnel policy 3 | slug: personnel 4 | policy: true 5 | faq: false 6 | weight: 1 7 | last_updated: 2025-04-07 8 | --- 9 | 10 | Tailscale reviews risks on a regular basis, to ensure proper mitigations are in place. 11 | 12 | ### Reference Checks 13 | 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. 14 | 15 | ### Security Awareness training 16 | 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. 17 | 18 | ### Performance Reviews 19 | 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. 20 | -------------------------------------------------------------------------------- /risk-assessment/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Risk assessment policy 3 | slug: risk-assessment 4 | policy: true 5 | faq: false 6 | weight: 2 7 | last_updated: 2025-04-07 8 | --- 9 | 10 | Tailscale reviews risks on a regular basis, to ensure proper mitigations are in place. 11 | 12 | ### Scope 13 | This policy covers any risk that could affect confidentiality, availability, and integrity of Tailscale’s key information assets and systems. 14 | 15 | 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. 16 | 17 | ### Risk assessment 18 | 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. 19 | 20 | A risk register should include: 21 | 22 | * Identification of the risk 23 | * What mitigations have been put in place 24 | * Acceptance of the residual risk 25 | 26 | 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. 27 | 28 | ### Schedule 29 | Risks should be evaluated on an annual basis. 30 | -------------------------------------------------------------------------------- /testing/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Testing policy 3 | slug: testing 4 | policy: true 5 | faq: false 6 | weight: 10 7 | last_updated: 2025-04-07 8 | --- 9 | 10 | To avoid potential security incidents, Tailscale requires testing of its software to ensure that it functions as expected. 11 | 12 | ### Scope 13 | 14 | This policy applies to code developed by Tailscale for its clients or run on its production servers. 15 | 16 | ### Code changes 17 | 18 | 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. 19 | 20 | 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). 21 | 22 | Changes to production code which do not alter product functionality, e.g., changes to documentation, may be but do not need to be tested. 23 | 24 | ### Client releases 25 | 26 | 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). 27 | 28 | 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. 29 | 30 | ### Infrastructure changes 31 | 32 | Changes to Tailscale’s production infrastructure should be tested where possible. 33 | 34 | Where possible, infrastructure should be implemented ‘as code’, so that it can be reviewed, approved, and tested as other code changes are. 35 | -------------------------------------------------------------------------------- /bcp-dr/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: BCP/DR policy 3 | slug: bcp-dr 4 | policy: true 5 | faq: false 6 | weight: 6 7 | last_updated: 2025-04-07 8 | --- 9 | 10 | ### Context 11 | 12 | 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. 13 | 14 | ### Scope 15 | 16 | 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. 17 | 18 | ### Schedule 19 | 20 | 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. 21 | 22 | 23 | ### Backups 24 | 25 | Tailscale regularly reviews backups and service redundancy to ensure they can be used in the event of an outage. The Security Review Team: 26 | 27 | * Ensures backups for key services are in place 28 | * Tests backups and restore procedures 29 | * Reviews proposed and existing architecture plans for resiliency 30 | * Implements monitoring tools to detect potential continuity issues for key services 31 | 32 | ### Outage detection 33 | 34 | 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. 35 | 36 | ### Outage response and remediation 37 | 38 | 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). 39 | -------------------------------------------------------------------------------- /access-control/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Access control policy 3 | slug: access-control 4 | policy: true 5 | faq: false 6 | weight: 7 7 | last_updated: 2025-04-07 8 | --- 9 | 10 | Tailscale limits access control based on job requirements, following the principle of least privilege. 11 | 12 | ### Scope 13 | 14 | This policy applies to Tailscale’s internal systems, including its production network, production servers, and SaaS applications. 15 | 16 | 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. 17 | 18 | ### Access to internal systems 19 | 20 | Where possible, access policies are enforced by technical measures. 21 | 22 | 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. 23 | 24 | Personnel who have administrative system access should use other less powerful accounts for performing non-administrative tasks. 25 | 26 | Where possible, more than one person must have full rights to any critical piece of infrastructure serving or storing production services or customer data. 27 | 28 | ### Granular access controls 29 | 30 | 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. 31 | 32 | ### End user devices 33 | 34 | 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. 35 | 36 | ### Changing roles or responsibilities 37 | 38 | Terminated employees must have their accounts disabled within 1 business day of transfer or termination. 39 | 40 | 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. 41 | -------------------------------------------------------------------------------- /patch-management/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Patch management policy 3 | slug: patch-management 4 | policy: true 5 | faq: false 6 | weight: 11 7 | last_updated: 2025-04-07 8 | --- 9 | 10 | To avoid potential security incidents, Tailscale regularly reviews potential vulnerabilities in its environment and applies relevant patches. 11 | 12 | ### Scope 13 | 14 | This patch management policy applies to Tailscale’s infrastructure, including Linux servers running production infrastructure in third party cloud providers; development or testing infrastructure, including Linux, Windows, and macOS machines; and end user devices such as laptops and phones, including Linux, Windows, macOS, iOS, and Android devices. Test or demo environments are exempt from this policy. 15 | 16 | This patch management policy also applies to the software Tailscale ships to customers. 17 | 18 | ### Vulnerability and patch detection 19 | 20 | In order to detect potential vulnerabilities, the Security Review Team: 21 | 22 | * Subscribes to and reviews announcements for security patches in OSes from vendors and open source maintainers for servers, development infrastructure, and end user devices. 23 | * Reviews dependencies for security patches prior to new builds for software that Tailscale ships. 24 | 25 | Where automated patch rollout is available, e.g., auto-updates on iOS devices, it should be enabled. 26 | 27 | 28 | ### Review and approval 29 | 30 | Security patches can be applied without further approval. 31 | 32 | ### Schedule 33 | 34 | 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. 35 | 36 | 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. 37 | 38 | ### Mitigations 39 | 40 | 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. 41 | 42 | Mitigations can include: removing functionality, limiting who can access a service, or taking down a service. 43 | -------------------------------------------------------------------------------- /change-management/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Change management policy 3 | slug: change-management 4 | policy: true 5 | faq: false 6 | weight: 9 7 | last_updated: 2025-04-07 8 | --- 9 | 10 | To avoid potential security incidents, Tailscale requires change management controls to ensure only authorized changes are made to its environment and processes. 11 | 12 | ### Environment 13 | 14 | #### Code changes 15 | 16 | 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. 17 | 18 | Tailscale uses branch protection rules on GitHub to require changes be made through a pull request with a second review prior to merging code. 19 | 20 | Exceptionally, employees can push changes without a second review where they are required to mitigate an incident. Changes pushed without prior approval are tagged and audited after the fact, within 2 business days. 21 | 22 | Changes to update dependencies, publish documentation, changes to the marketing website, or non-substantive code changes are exempt from this policy. 23 | 24 | ##### Dependencies 25 | 26 | Dependencies can be updated without requiring a separate reviewer. Tailscale reviews the release notes for a dependency prior to merging the changes. 27 | 28 | ##### Documentation 29 | 30 | Documentation can be updated without requiring a separate reviewer. 31 | 32 | #### Infrastructure changes 33 | 34 | 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. 35 | 36 | #### Customer accounts 37 | 38 | Tailscale may make changes to customers’ networks and accounts in Tailscale at their request. Changes are initiated by customer support tickets. 39 | 40 | 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. 41 | 42 | ### Security policies 43 | 44 | 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. 45 | 46 | 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. 47 | -------------------------------------------------------------------------------- /vendor/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Third party vendor review policy 3 | slug: vendor 4 | policy: true 5 | faq: false 6 | weight: 4 7 | last_updated: 2025-04-07 8 | --- 9 | 10 | 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. 11 | 12 | ### Scope 13 | 14 | This policy only applies to vendors or contractors handling Tailscale or its customers’ data. 15 | 16 | ### Schedule 17 | 18 | Vendors’ security practices should be initially evaluated as part of their contract review, and while still in use, on an annual basis. 19 | 20 | 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. 21 | 22 | 23 | ### Vendor assessment 24 | 25 | As part of vendor evaluation and contracting, vendors’ security practices should be reviewed to ensure they sufficiently protect Tailscale’s and its customers’ data. 26 | 27 | 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. 28 | 29 | Tailscale will: 30 | 31 | 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/). 32 | 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. 33 | 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. 34 | 35 | Tailscale will document vendor information, to help in case of a potential incident. This information includes: 36 | 37 | * **Vendor name**, i.e. Which vendor? 38 | * **Vendor contact information**, i.e. How do we contact the vendor? List different contacts for billing, support, and/or security where they apply. 39 | * **Type of data shared**, i.e. What types of data from Tailscale does the vendor collect or otherwise have access to? 40 | * **Terms of Service** for services provided by the vendor 41 | * **Security report or questionnaire** shared by the vendor 42 | -------------------------------------------------------------------------------- /password/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Password policy 3 | slug: password 4 | policy: true 5 | faq: false 6 | weight: 8 7 | last_updated: 2025-04-07 8 | --- 9 | 10 | To avoid potential security incidents, Tailscale requires employees to follow password requirements. 11 | 12 | ### Scope 13 | 14 | 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._ 15 | 16 | ### Password strength 17 | 18 | Passwords must be unique for each use. 19 | 20 | Passwords must be randomly generated. 21 | 22 | Default passwords on all systems are changed after installation. Initial passwords generated for new users must be changed after login. 23 | 24 | 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. 25 | 26 | ### Single sign-on 27 | 28 | Where a third-party application supports single sign-on, it must be used. 29 | 30 | ### Multi-factor authentication 31 | 32 | Where a third-party application supports multi-factor authentication, it must be used. Use of multi-factor is enforced where possible. 33 | 34 | 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. 35 | 36 | ### Password manager 37 | 38 | Where SSO is not used, and where possible, passwords should be stored in a password manager. 39 | 40 | ### Encryption at rest 41 | 42 | Passwords should be stored encrypted at rest. 43 | 44 | ### Logging 45 | 46 | Passwords should not be logged. 47 | 48 | ### Requirements for specific use cases 49 | 50 | #### Servers 51 | 52 | Access to servers, for both production as well as development and testing infrastructure, must be with a password and MFA or with per-user public keys (e.g., SSH keys). Only Tailscale-based network authentication is permitted for services not exposed to the Internet. 53 | 54 | #### Automated processes 55 | 56 | 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. 57 | 58 | #### End user devices 59 | 60 | End user devices must use passwords to encrypt their disks and unlock the device. These must be unique for each individual but may be reused across an individual’s devices. These do not need to be randomly generated. 61 | 62 | #### SaaS applications or other software 63 | 64 | Access to third party applications must use SSO where possible, MFA where possible, and enforce MFA where possible. 65 | 66 | An individual’s password for their password management vault must be unique. These do not need to be randomly generated. 67 | -------------------------------------------------------------------------------- /data-retention-deletion/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Data retention and deletion policy 3 | slug: data-retention-deletion 4 | policy: true 5 | faq: false 6 | weight: 12 7 | last_updated: 2025-04-23 8 | --- 9 | 10 | Tailscale must retain and process certain kinds of customer and user data to deliver the Tailscale Solution and to comply with our customer commitments and legal requirements. At the same time, Tailscale wants to avoid retaining data for longer than is necessary. 11 | 12 | ### Scope 13 | 14 | This policy applies to the data assets associated with customer accounts that are processed by Tailscale in connection with providing the Tailscale Solution. 15 | 16 | ### Schedule 17 | 18 | Tailscale should review the data it retains as part of reviewing its data register at least annually. 19 | 20 | ### Retention period 21 | 22 | Data subject to this policy will be retained for a set period of time, depending on the type of data: 23 | 24 |
25 | 26 | 28 | 30 | 31 | 32 | 34 | 36 | 37 | 38 | 40 | 42 | 43 | 44 | 46 | 48 | 49 | 50 | 52 | 54 | 55 | 56 | 58 | 60 | 61 |
Data Assets 27 | Retention period 29 |
Customer account and tailnet live production data* 33 | Duration of contract 35 |
Client logs (that is, Usage Data used for security and fraud prevention and analytics purposes) 39 | 12 months 41 |
Support communications and other customer service records 45 | 5 years 47 |
Payment and billing information 51 | 7 years 53 |
Aggregated or anonymized data or reports 57 | As long as needed for the business purposes 59 |
62 | 63 | \*Tailscale acts as the data processor for this information pursuant to our DPA. In all other cases, Tailscale acts as the data controller. 64 | 65 | Where not specified, customer data will be retained no longer than is needed to provide the service, and anonymized or deleted afterwards. 66 | 67 | ### Privacy Policy 68 | 69 | Tailscale will delete personal data pursuant to individual data subject requests in accordance with applicable data privacy laws as set forth in our [Privacy Policy](/privacy-policy/). 70 | 71 | ### Suspension 72 | 73 | Tailscale may suspend routine deletion of customer data if required for security forensic analysis purposes or a legal hold involving such data. Legal holds may be issued, for example, in connection with an active, imminent, threatened or reasonably anticipated investigation, litigation, arbitration, subpoena, financial transaction, or other legal matter. 74 | 75 | ### Deletion method 76 | 77 | Data may be destroyed by overwriting on disk, deleting a cloud resource, encrypting and destroying the key, resetting a device, and/or physical destruction. 78 | -------------------------------------------------------------------------------- /incident-disclosure/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Incident disclosure and notification policy 3 | slug: incident-disclosure 4 | policy: true 5 | faq: false 6 | weight: 5 7 | last_updated: 2025-04-07 8 | --- 9 | 10 | This policy specifies when and how we notify users about security incidents. 11 | 12 | Both the client software and our managed backend infrastructure (i.e. coordination server) are in scope for this policy. 13 | 14 | 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. 15 | 16 | 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. 17 | 18 | ### When we notify users 19 | 20 | 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. 21 | 22 | We will **disclose** a security vulnerability **when a fix is available** and any of the following is true: 23 | 24 | * User action is needed to fix the vulnerability, e.g. updating the client software, or applying another mitigation; 25 | * We can confirm that tailnet metadata or data was visible to an unauthorized party; or 26 | * We cannot confirm that no users were affected by the vulnerability. 27 | 28 | We will **notify users directly** about a security vulnerability when we can confirm that the tailnet was affected, and any of the following is true: 29 | 30 | * User action is needed to fix the vulnerability, and it is a critical or high impact vulnerability; or 31 | * We can confirm that tailnet metadata or data was visible to an unauthorized party. 32 | 33 | ### How we notify users 34 | 35 | To disclose security vulnerabilities, Tailscale publishes security bulletins publicly for a broad audience at [https://tailscale.com/security-bulletins/](https://tailscale.com/security-bulletins/). These can be consumed directly, via RSS readers or via social media bot accounts. 36 | 37 | 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. 38 | 39 | 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). 40 | -------------------------------------------------------------------------------- /incident-response-policy/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Incident response policy 3 | slug: incident-response 4 | policy: true 5 | faq: false 6 | weight: 5 7 | last_updated: 2025-04-07 8 | --- 9 | 10 | ### Context 11 | 12 | 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. 13 | 14 | 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. 15 | 16 | ### Incident detection 17 | 18 | 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. 19 | 20 | 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). 21 | 22 | All employees should watch for potentially suspicious activities, including: 23 | 24 | * Warnings from antivirus tools 25 | * Unexpected system reboots and/or sudden degradation of system performance 26 | * Password reset notifications 27 | * Modification or defacement of websites 28 | * New open network ports on a system 29 | 30 | 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. 31 | 32 | The Security Review Team: 33 | 34 | * Ensures that a very high level of logging is enabled 35 | * Checks logs regularly for suspicious activities and entries 36 | * Looks for missing time spans in logs 37 | * Checks for repeated login failures or account lockouts 38 | * Investigates unexpected system reboots 39 | 40 | Tailscale’s Security Review Team reviews and responds to potential third-party reports of security issues to [security@tailscale.com](mailto:security@tailscale.com) promptly. 41 | 42 | ### Incident response and remediation 43 | 44 | If a suspected incident is detected, it should be responded to following the [Incident response process](/security-policies/incident-response-process/). 45 | 46 | We respond to reported incidents, and resolve and determine impact as soon as possible. We aim to remediate incidents as soon as possible. 47 | 48 | Confirmed incidents may be disclosed publicly per our [disclosure policy](/security-policies/incident-disclosure/). 49 | -------------------------------------------------------------------------------- /information-classification/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Information classification policy 3 | slug: information-classification 4 | policy: true 5 | faq: false 6 | weight: 3 7 | last_updated: 2025-04-07 8 | --- 9 | 10 | 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. 11 | 12 | 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. 13 | 14 | ### Asset cataloging 15 | 16 | Tailscale catalogues assets with several pieces of information, to help identify the potential risk of the asset. Information collected is as follows: 17 | 18 | * **Description**, i.e. what is the asset? 19 | * **Risk**, i.e. what is the asset risk classification? 20 | * **Use**, i.e. how is this asset used? 21 | * **Location,** i.e. where is it stored, used, and backed up? 22 | * **Sharing**, i.e. is it shared with any third parties, such as vendors? Which specific third parties? 23 | 24 | If new data is catalogued, or data use changes, it should be specifically reviewed to verify that its collection and use is in line with [Tailscale’s Privacy Policy](/privacy-policy/). 25 | 26 | 27 | ### Asset risk classification 28 | 29 | Tailscale classifies assets into three risk categories: **Low Risk**, **Medium Risk**, and **High Risk**. Definitions are as follows: 30 | 31 | 32 | 33 | 35 | 37 | 38 | 39 | 41 | 49 | 50 | 51 | 53 | 61 | 62 | 63 | 65 | 73 | 74 |
Risk category 34 | Definition 36 |
High risk 40 | 42 |
    43 |
  • Data: protection is mandated by confidentiality agreements, labor codes, specific laws and regulations (e.g. PCI DSS, HIPAA, GDPR), or data is subject to breach reporting requirements, or disclosure would have a significant adverse impact on Tailscale (e.g., user accounts database). 44 | 45 |
  • Hardware and software systems: compromise would have a significant adverse impact on Tailscale (e.g. the login.tailscale.com control plane service). 46 |
    • 47 |
48 |
Medium risk 52 | 54 |
    55 |
  • Data: not generally available to the public, and disclosure would have some adverse impact on Tailscale (e.g. internal engineering documentation). 56 | 57 |
  • Hardware and software systems: compromise would have some adverse impact on Tailscale (e.g. cloud VM running production monitoring system). 58 |
    • 59 |
60 |
Low risk 64 | 66 |
    67 |
  • Data: publicly available, or disclosure would have no adverse operational or financial impact on Tailscale (e.g. tailscale.com website source code). May still have some limited reputational impact. 68 | 69 |
  • Hardware and software systems: compromise would have no adverse impact on Tailscale (e.g. testbed cloud VM with no user data or privileged access). 70 |
    • 71 |
72 |
75 | 76 | 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. 77 | 78 | ### Schedule 79 | 80 | Tailscale should review the data it collects and processes, and update the data register, quarterly. 81 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Tailscale Security Policies 2 | 3 | Tailscale has several security policies in place to properly identify, respond to, and mitigate potential security risks. All employees, vendors and contractors working with Tailscale must follow these policies in order to best protect Tailscale’s and its customers’ data. 4 | 5 | We’ve published these publicly for transparency, so that you can see where we are in terms of security maturity. We also hope you use these to adopt similar policies and processes at your organization. 6 | 7 | _Since these are our internal policies, some links to internal documents or resources are only visible to employees._ 8 | 9 | This repository is the source of truth for the policies available at https://tailscale.com/security-policies/. 10 | 11 | These policies were last reviewed on 2025-04-07. 12 | 13 | ### FAQ 14 | 15 | ### What policies are included? 16 | 17 | This repository includes: 18 | * [Personnel policy](/personnel/index.md) 19 | * [Risk assessment policy](/risk-assessment/index.md) 20 | * [Information classification policy](/information-classification/index.md) 21 | * [Third party vendor review policy](/vendor/index.md) 22 | * [Incident response policy](/incident-response-policy/index.md) 23 | * [Incident response process](/incident-response-process/index.md) 24 | * [BCP/DR policy](/bcp-dr/index.md) 25 | * [Access control policy](/access-control/index.md) 26 | * [Password policy](/password/index.md) 27 | * [Change management policy](/change-management/index.md) 28 | * [Testing policy](/testing/index.md) 29 | * [Patch management policy](/patch-management/index.md) 30 | * [Data retention and deletion policy](/data-retention-deletion/index.md) 31 | * [Incident disclosure and notification policy](/incident-disclosure/index.md) 32 | 33 | ### When does Tailscale review or update these policies? 34 | 35 | The Chief Operating Officer is responsible for reviewing and updating security policies on an annual basis. 36 | See [overview](/overview.md) of policies. 37 | 38 | ### Why don't you use the stronger security control X for the Y policy? 39 | 40 | These policies do reflect the current state of Tailscale's security practices. 41 | Are they perfect? Absolutely not. We hope to improve them over time. 42 | 43 | ### Why are these policies in Git? 44 | 45 | These policies are in Git for document control, to track what changes were made over time, by whom, and who reviewed and approved those changes. 46 | 47 | ### Why are some links broken, like to the Code of Conduct? 48 | 49 | Since these are Tailscale's internal policies, some links to internal documents or resources are only visible to employees. 50 | 51 | ### Why did Tailscale publish these policies? 52 | 53 | These policies are published and available under CC0-1.0 in order to: 54 | * Be transparent about where we are in terms of security at Tailscale. 55 | * Help you be inspired by these policies as you complete your own SOC 2 audit or improve your own organization's security. 56 | 57 | ### Can I use these security policies? 58 | 59 | Yes! Feel free to be inspired by Tailscale's internal security policies for use in your own organization. These policies are available under CC0-1.0. 60 | 61 | ## Contributing 62 | 63 | We do not accept public contributions or issues on this repository. This is because this repository acts as the source of truth for Tailscale's internal policies. If you are a Tailscale user, and have a question or concern about one of these policies, please contact info@tailscale.com. 64 | 65 | We may consider public comment on proposed changes. 66 | 67 | ## Acknowledgements 68 | 69 | @danderson, @rachlubman, @DentonGentry, and @mayakacz, with feedback from Tailscale employees and auditors. 70 | 71 | ## License 72 | 73 | Dedicated to the public domain under CC0-1.0 by Tailscale and contributors. 74 | -------------------------------------------------------------------------------- /incident-response-process/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Incident response process 3 | slug: incident-response-process 4 | policy: true 5 | faq: false 6 | weight: 5 7 | last_updated: 2025-04-07 8 | --- 9 | 10 | ### Incident response 11 | 12 | When a suspected incident is reported, it is first investigated by the eng-primary 13 | oncall. If it is suspected to be an incident, they should declare an incident, 14 | and identify the Incident Commander in the #incident-response Slack channel. 15 | The Incident Commander is responsible for: 16 | 17 | * If an incident is likely to require ongoing response and remediation efforts, 18 | opening a GitHub issue in the tailscale/corp repo to track updates to 19 | the incident and creating a Google doc for collaborative work. 20 | * Classifying the severity of the incident, including scope and the risk of any 21 | assets which may be affected. This can be further updated as information 22 | changes, and may inform how we choose to react. Depending on the urgency of 23 | the incident, this may be done after the fact. 24 | * Contacting vendors or coordinating to contact vendors, to validate if their 25 | product may be compromised. 26 | * Appointing roles, including a communications lead, if needed. 27 | * Ensuring handoff between team members, for example, at the end of a work day. 28 | * Escalating to leadership if responses are insufficient. 29 | 30 | In addition to remediating the incident, Tailscale employees should also seek 31 | to put into place any corrective actions possible to lessen the impact of an 32 | incident. 33 | 34 | If an incident affects customers, including their data or their ability to use 35 | Tailscale, Tailscale may choose to proactively communicate the issue publicly. 36 | 37 | ### Incident recovery 38 | 39 | If data or processes were disrupted by the incident, then the [BCP/DR policy](/security-policies/bcp-dr/) 40 | should be followed to remediate the issue. 41 | 42 | Once an incident is mitigated or otherwise closed, it is the Incident 43 | Commander’s responsibility to ensure that 44 | 45 | * The resolution is communicated to all affected parties, including external 46 | customers, if applicable. 47 | * For incidents causing a production outage or loss of customer or other 48 | critical data, a post-mortem is completed. This should include: details of 49 | the incident, timeline of the incident, its impact, the actions taken to 50 | mitigate or resolve it, the root cause(s), and the follow-up actions to 51 | prevent the incident from recurring. Where applicable, some version of the 52 | post-mortem may be shared with external affected parties. Newly identified 53 | risks should be added to the risk register. 54 | 55 | ### Incident classification 56 | 57 | An incident is an adverse event which affects Tailscale’s infrastructure or 58 | business operations in such a way that it compromises our ability to deliver 59 | the service customers expect. A vulnerability is not necessarily an incident; 60 | for example, a vulnerability not being actively exploited may require action, 61 | but not expedited action beyond existing vulnerability remediation processes. 62 | 63 | Incidents can be classified based on their severity: 64 | 65 | 66 | 67 | 68 | 73 | 74 | 75 | 76 | 81 | 82 | 83 | 84 | 88 | 89 | 90 | 91 | 94 | 95 |
Critical 69 | Extreme or complete production outage, significantly degraded experience 70 | for >50% of Tailscale users, or customer or other critical data loss or 71 | corruption. 72 |
High 77 | Partial outage of some production functionality or in some regions, 78 | degraded experience for multiple customers with no workaround available, or 79 | suspected severe security breach. 80 |
Medium 85 | Non-critical functionality loss or degradation for some customers, with 86 | possible short-term workaround, or detection of unauthorized activity. 87 |
Low 92 | No current or known customer impact. 93 |
96 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Creative Commons Legal Code 2 | 3 | CC0 1.0 Universal 4 | 5 | CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE 6 | LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN 7 | ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS 8 | INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES 9 | REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS 10 | PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM 11 | THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED 12 | HEREUNDER. 13 | 14 | Statement of Purpose 15 | 16 | The laws of most jurisdictions throughout the world automatically confer 17 | exclusive Copyright and Related Rights (defined below) upon the creator 18 | and subsequent owner(s) (each and all, an "owner") of an original work of 19 | authorship and/or a database (each, a "Work"). 20 | 21 | Certain owners wish to permanently relinquish those rights to a Work for 22 | the purpose of contributing to a commons of creative, cultural and 23 | scientific works ("Commons") that the public can reliably and without fear 24 | of later claims of infringement build upon, modify, incorporate in other 25 | works, reuse and redistribute as freely as possible in any form whatsoever 26 | and for any purposes, including without limitation commercial purposes. 27 | These owners may contribute to the Commons to promote the ideal of a free 28 | culture and the further production of creative, cultural and scientific 29 | works, or to gain reputation or greater distribution for their Work in 30 | part through the use and efforts of others. 31 | 32 | For these and/or other purposes and motivations, and without any 33 | expectation of additional consideration or compensation, the person 34 | associating CC0 with a Work (the "Affirmer"), to the extent that he or she 35 | is an owner of Copyright and Related Rights in the Work, voluntarily 36 | elects to apply CC0 to the Work and publicly distribute the Work under its 37 | terms, with knowledge of his or her Copyright and Related Rights in the 38 | Work and the meaning and intended legal effect of CC0 on those rights. 39 | 40 | 1. Copyright and Related Rights. A Work made available under CC0 may be 41 | protected by copyright and related or neighboring rights ("Copyright and 42 | Related Rights"). Copyright and Related Rights include, but are not 43 | limited to, the following: 44 | 45 | i. the right to reproduce, adapt, distribute, perform, display, 46 | communicate, and translate a Work; 47 | ii. moral rights retained by the original author(s) and/or performer(s); 48 | iii. publicity and privacy rights pertaining to a person's image or 49 | likeness depicted in a Work; 50 | iv. rights protecting against unfair competition in regards to a Work, 51 | subject to the limitations in paragraph 4(a), below; 52 | v. rights protecting the extraction, dissemination, use and reuse of data 53 | in a Work; 54 | vi. database rights (such as those arising under Directive 96/9/EC of the 55 | European Parliament and of the Council of 11 March 1996 on the legal 56 | protection of databases, and under any national implementation 57 | thereof, including any amended or successor version of such 58 | directive); and 59 | vii. other similar, equivalent or corresponding rights throughout the 60 | world based on applicable law or treaty, and any national 61 | implementations thereof. 62 | 63 | 2. Waiver. To the greatest extent permitted by, but not in contravention 64 | of, applicable law, Affirmer hereby overtly, fully, permanently, 65 | irrevocably and unconditionally waives, abandons, and surrenders all of 66 | Affirmer's Copyright and Related Rights and associated claims and causes 67 | of action, whether now known or unknown (including existing as well as 68 | future claims and causes of action), in the Work (i) in all territories 69 | worldwide, (ii) for the maximum duration provided by applicable law or 70 | treaty (including future time extensions), (iii) in any current or future 71 | medium and for any number of copies, and (iv) for any purpose whatsoever, 72 | including without limitation commercial, advertising or promotional 73 | purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each 74 | member of the public at large and to the detriment of Affirmer's heirs and 75 | successors, fully intending that such Waiver shall not be subject to 76 | revocation, rescission, cancellation, termination, or any other legal or 77 | equitable action to disrupt the quiet enjoyment of the Work by the public 78 | as contemplated by Affirmer's express Statement of Purpose. 79 | 80 | 3. Public License Fallback. Should any part of the Waiver for any reason 81 | be judged legally invalid or ineffective under applicable law, then the 82 | Waiver shall be preserved to the maximum extent permitted taking into 83 | account Affirmer's express Statement of Purpose. In addition, to the 84 | extent the Waiver is so judged Affirmer hereby grants to each affected 85 | person a royalty-free, non transferable, non sublicensable, non exclusive, 86 | irrevocable and unconditional license to exercise Affirmer's Copyright and 87 | Related Rights in the Work (i) in all territories worldwide, (ii) for the 88 | maximum duration provided by applicable law or treaty (including future 89 | time extensions), (iii) in any current or future medium and for any number 90 | of copies, and (iv) for any purpose whatsoever, including without 91 | limitation commercial, advertising or promotional purposes (the 92 | "License"). The License shall be deemed effective as of the date CC0 was 93 | applied by Affirmer to the Work. Should any part of the License for any 94 | reason be judged legally invalid or ineffective under applicable law, such 95 | partial invalidity or ineffectiveness shall not invalidate the remainder 96 | of the License, and in such case Affirmer hereby affirms that he or she 97 | will not (i) exercise any of his or her remaining Copyright and Related 98 | Rights in the Work or (ii) assert any associated claims and causes of 99 | action with respect to the Work, in either case contrary to Affirmer's 100 | express Statement of Purpose. 101 | 102 | 4. Limitations and Disclaimers. 103 | 104 | a. No trademark or patent rights held by Affirmer are waived, abandoned, 105 | surrendered, licensed or otherwise affected by this document. 106 | b. Affirmer offers the Work as-is and makes no representations or 107 | warranties of any kind concerning the Work, express, implied, 108 | statutory or otherwise, including without limitation warranties of 109 | title, merchantability, fitness for a particular purpose, non 110 | infringement, or the absence of latent or other defects, accuracy, or 111 | the present or absence of errors, whether or not discoverable, all to 112 | the greatest extent permissible under applicable law. 113 | c. Affirmer disclaims responsibility for clearing rights of other persons 114 | that may apply to the Work or any use thereof, including without 115 | limitation any person's Copyright and Related Rights in the Work. 116 | Further, Affirmer disclaims responsibility for obtaining any necessary 117 | consents, permissions or other rights required for any use of the 118 | Work. 119 | d. Affirmer understands and acknowledges that Creative Commons is not a 120 | party to this document and has no duty or obligation with respect to 121 | this CC0 or use of the Work. 122 | --------------------------------------------------------------------------------