Vendor Security Standards Addendum
LAST UPDATED: Sep 3, 2026
This Vendor Security Standards Addendum (“Addendum”) outlines the minimum security requirements with respect to administrative, technical, and physical safeguards applicable for any third parties providing services to Asana, Inc. or its affiliates (“Asana”). Capitalized terms shall have the meaning assigned to them in the underlying master agreement between Asana and Vendor (the “Agreement”) unless otherwise defined herein.
1. Definitions
1.1 “Asana Data” means any information or data provided by, or on behalf of, Asana to Vendor.
1.2 “Incident Response Plan” means a management and response plan that outlines a reasonable and consistent response to Security Incidents.
1.3 “Personnel” means employees, contractors, and subcontractors of Vendor with access to Asana data.
1.4 “Security Incident” means the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Asana Data.
2. Use of Asana Data
Vendor will only access and use Asana Data to provide the Services to Asana and fulfill its purposes under the Agreement. Asana Data will remain the sole property of Asana. Upon termination of the Agreement or upon Asana’s written request, Vendor will, at the choice of Asana, return all Asana Data or securely destroy all Asana Data and confirm such in accordance with the Agreement.
3. Information Security Program
3.1 Vendor agrees to implement and maintain an information security program designed to ensure the security, availability, and confidentiality of Asana data stored, accessed, processed, or transmitted, or otherwise provided to Vendor to provide the Services under the Agreement.
3.2 Vendor’s information security program will adhere to applicable standards and laws, and at a minimum, cover the following areas: security risk management, policies and procedures, Security Incident management, access controls, vulnerability management, physical security, operational security, corporate security, infrastructure security, product security, business continuity and disaster recovery, personnel security, security compliance, and vendor security.
3.3 Vendor will designate an appointed security officer and appropriate security employees who are responsible for implementing, maintaining, monitoring, and enforcing security safeguards aligned with the information security program.
4. Policies and Procedures
4.1 Vendor will maintain documented information security policies and standards that conform to applicable data protection laws and regulations. At a minimum, Vendor’s policies and standards must cover the following areas: (i) appropriate protection and use of Asana Data; (ii) acceptable use of computing and network resources and assets; (iii) maintenance by Personnel of security, confidentiality, integrity, and availability of Asana Data; and (iv) appropriate disciplinary actions for non-compliance with the policies and standards.
4.2 Policies and procedures will be reviewed and approved by appropriate employees on at least an annual basis or upon a material change in business practices.
5. Personnel Security
5.1 Vendor will perform background checks on Personnel in accordance with applicable laws, regulations, ethical requirements, and/or accepted local practices for non-US jurisdictions. The level of verification will be appropriate according to the role of the employee, the sensitivity of the information accessed in the course of that person’s role, risks that may arise from misuse of the information, and accepted practices in non-US jurisdictions. Background checks must be initiated prior to Personnel’s start date and the results of the background check performed must be evaluated prior to the Personnel receiving any Asana Data. The following checks shall be performed for each individual at least upon initial hire, unless prohibited by law or inconsistent with accepted local practices for non-US jurisdictions: (i) identity verification and (ii) criminal history.
5.2 Vendor will provide Personnel with security and privacy training upon hire and on at least an annual basis thereafter. At a minimum, security and privacy training will cover: (i) acceptable use of assets; (ii) access to Asana data; (iii) Vendor’s information security policy; and (iv) applicable privacy laws and regulations. Vendor will require Personnel to acknowledge they have read and understood applicable information security policies upon hire and on at least an annual basis thereafter. Vendor will track and monitor Personnel’s completion of the training.
5.3 If Vendor is providing Personnel to perform work for Asana and Asana is providing systems access, Vendor shall inform Asana in advance of any Personnel’s termination date.
6. Security Assessments
6.1 Vendor will perform security audits on at least an annual basis with independent third parties that are applicable to services provided by Vendor (e.g. ISO 27001, SOC 2, SOC 1, ISO 9001, PCI DSS). If Vendor provides software, cloud services, and/or stores or processes Asana Data on its hosted systems, Vendor will also perform a third-party penetration test on at least an annual basis.
6.2 At least once annually or in the case of a Security Incident, Vendor will make available to Asana security artifacts that demonstrate its compliance with all applicable provisions within this Addendum. Artifacts will include applicable evidence, including but not limited to: audits and attestations, completed industry standard questionnaires, an executive summary of penetration test results, a summary of business continuity and disaster recovery approach, and proof of annual testing. To the extent Asana cannot reasonably confirm Vendor's compliance with this Addendum, Asana may conduct a risk assessment with reasonable notice to Vendor and with minimal disruption to Vendor’s business operations. This assessment will occur no more than once annually, or upon the confirmation of a Security Incident.
7. Security Incidents
7.1 Vendor will monitor its information systems to identify any unauthorized access, unexpected behavior, certain attack signatures, and other indicators of an actual or suspected Security Incident.
7.2 Vendor will establish and maintain an Incident Response Plan that complies with industry standards and applicable laws addressing investigation and response to Security Incidents. The Incident Response Plan must be reviewed and tested on at least an annual basis.
7.3 Vendor will notify Asana without undue delay (but in no event later than 48 hours) after becoming aware of a Security Incident and will provide all such timely information and cooperation as Asana may require.
8. Security Controls
8.1 Access Control
8.1.1 Access to Asana data will be restricted to authorized Personnel who are required to access Asana data in order for Vendor to provide services to Asana and only when needed for a legitimate business purpose. Access is granted based on the principle of least privilege and access granted will be commensurate with job responsibilities. Vendor will inform Personnel of the obligations set forth in this Addendum and will remain responsible for the acts, omissions, and breach of its Personnel.
8.1.2 Vendor will implement and maintain the following access control activities:
8.1.2.1 Access control will be technically enforced through unique usernames and passwords. Passwords will follow a set of controls that is technically enforced.
8.1.2.2 Multi-factor authentication through either a hard or soft token will be enabled on all of Vendor’s accounts with access to Asana data.
8.1.2.3 Administrative or elevated privilege access will be encrypted, monitored, and elevated privileged account use will be tracked back to an individual.
8.1.2.4 Asana Data will not be downloaded onto endpoints or exported into unapproved file transfer services.
8.1.2.5 Access to Asana data must be logged and monitored. Logs must, at a minimum, meet the following requirements:
Logs must capture user identity, timestamp, action performed, and the resource or data accessed.
Logs must be retained for a minimum of 12 months, with at least 90 days readily accessible for review.
Logs must be protected against unauthorized modification, deletion, or tampering.
Log access must be restricted to authorized personnel only.
Logs must be reviewed on a periodic basis and in response to any suspected Security Incident.
A process must be in place to generate alerts for anomalous or suspicious access patterns.
Logs must be made available to Asana upon request in the event of a Security Incident or audit.
8.1.2.6. Personnel access to systems will be removed within 24 hours upon termination or reassignment of job duties.
8.2 Application Security
8.2.1. If Vendor develops software as part of the services:
8.2.1.1. Vendor will maintain a Software Development Lifecycle (SDLC) process that incorporates security vulnerability and malicious code assessments throughout each stage of the development process. Vendor’s SDLC must include a vulnerability and malicious code assessment prior to initial application deployment.
8.2.1.2. All application code will be reviewed prior to being deployed to production.
8.2.1.3. Asana Data will not be copied or replicated outside of production environments.
8.2.1.4. Vendor will implement and maintain vulnerability management processes to identify, report, and remediate all vulnerabilities as soon as practical by: (i) performing vulnerability scans on at least a quarterly basis; (ii) promptly address critical vulnerabilities and in any event no later than 30 business days; and (iii) implementing a risk treatment plan to address vulnerabilities commensurate with their risk.
8.2.1.5. Vendor will maintain policies and procedures addressing security and intellectual property requirements that apply to open source code incorporated or used to derive any deliverable provided to Asana.
8.3 If Vendor is transmitting Asana Data over an electronic network, Vendor will encrypt data in transit and at rest using an encryption mechanism appropriate for the mechanism of transfer (at a minimum, TLS 1.2, ssh, AES-256).
9. Business Continuity and Disaster Recovery
9.1 Vendor will implement and maintain a documented set of disaster recovery policies and procedures to enable the recovery and or continuation of vital technology infrastructure and systems following a disaster. Vendor will perform tests of its disaster recovery plan on at least an annual basis. Upon request, Vendor will provide Asana with a summary of its business continuity and disaster recovery plan, which shall substantially conform to the minimum standards below.
9.2 Vendor will perform backups of Asana Data at a frequency sufficient to meet the RPO commitments below. All backups will be encrypted and subject to the same security controls as production data.
9.3 Vendor will use reasonable efforts to achieve the following backup and recovery commitments to ensure the availability of Asana Data and the services provided under the Agreement:
RPO (Recovery Point Objective) — maximum acceptable data loss measured in time; backups must occur at least this frequently.
Critical Systems: 4 hours. Non-Critical Systems: 48 hours.
RTO (Recovery Time Objective) — maximum time to restore systems and resume normal operations.
Critical Systems: 4 hours. Non-Critical Systems: 48 hours.
MTTR (Mean Time to Recover) — average time to fully recover from a failure or incident, from detection to full restoration.
Critical Systems: 4 hours. Non-Critical Systems: 48 hours.
For purposes of this Section, "Critical Systems" means any system or component that directly supports Asana’s day-to-day business operations, system security, or Asana’s core products or services to its customers. "Non-Critical Systems" means systems supporting internal corporate functions whose short-term disruption has low-to-moderate business impact, which can be resolved through manual workarounds, and whose unavailability does not prevent Asana’s customers’ access to or use of Asana’s core products or services. Asana will identify whether Vendor qualifies as a Critical System or Non-Critical System in its sole discretion.
9.4 Vendor will notify Asana at security@asana.com and legal@asana.com upon declaring a disaster or initiating disaster recovery procedures that affect the availability of Asana Data or the services. Vendor will assign a designated point-of-contact for all communications to Asana until normal business operations are restored, and Vendor will provide regular updates (at a mutually agreed cadence) regarding root-cause assessments, data integrity verifications, and restoration progress and completion.
9.5 Vendor’s business continuity and disaster recovery plan must be tested on at least an annual basis, and Vendor will provide Asana with written confirmation of RPO, RTO, and MTTR performance annually and any time upon request. In the event Vendor fails to meet any commitment in this Section 9, Vendor shall notify Asana within 24 hours and provide a written remediation plan within five (5) business days. Persistent failure to meet the targets outlined in this policy may be deemed a material breach of the Agreement.
10. Hardware
10.1 If Vendor uses its own hardware to provide the services, Vendor will comply with the following requirements:
10.1.1 Vendor maintains an up-to-date asset inventory of user endpoints that is periodically updated, audited, and reviewed.
10.1.2 Vendor maintains a documented process for provisioning endpoints based on documented hardening standards.
10.1.3 Vendor’s endpoints employ commercially reasonable security controls, including, at a minimum:
10.1.3.1 Local hard drive encryption
10.1.3.2 A local password
10.1.3.3 EDR software with continuous monitoring and automatic updating, including anti-virus and malware scanning, detection, containment, and reporting capabilities
10.1.3.4 End users will not be able to override or modify these endpoint controls.
10.1.4 Vendor employs mechanisms to maintain control over distribution of sensitive media, including preventing end users from performing file transfers through unapproved file transfer services or transferring data to external media (e.g. USB drives).
10.1.5 Vendor ensures Personnel do not access Asana data on unapproved or unmanaged devices.
10.1.6 Vendor employs mechanisms to securely dispose of, destroy, or repurpose hardware when it is no longer needed. Vendor ensures endpoints are rendered inaccessible to users when they are no longer authorized or if it is no longer needed (e.g. upon termination).
10.1.7 Vendor maintains the ability to remotely wipe machines if they are lost, stolen, or otherwise compromised.
10.2 If Vendor uses Asana-issued devices to provide the services, Vendor will:
10.2.1 only use devices that are managed by Asana to perform work related to the services.
10.2.2 only use Asana hardware to perform services related to the underlying agreement between Asana and Vendor.
11. Risk Management
11.1 Vendor will maintain a risk management program designed to identify, monitor, and manage risks that may impact the confidentiality, integrity, or availability of Asana Data. Vendor will conduct risk assessments periodically.
11.2 Vendor will conduct a vendor risk assessment on any third party service providers that may have access to Asana data prior to the beginning of services and periodically thereafter. Vendor risk assessment will evaluate the Vendor’s ability to maintain security measures consistent with or exceeding this Addendum. Vendor will enter into a contractual agreement with third party service providers that requires such providers to meet or exceed certain minimum security standards which are no less protective than those set forth under this Addendum.
12. Technical Controls: SSO & SCIM
The following will apply if Vendor provides licenses to its software as part of the services: Vendor represents that the service fully supports SAML 2.0 or OIDC for single sign-on (“SSO”) and SCIM for automating provisioning/deprovisioning tasks. If the service is not available as such, the Vendor agrees that the service will support SAML or OIDC (SSO) and SCIM (provisioning/deprovisioning) integrations within six (6) months of executing the underlying agreement between Vendor and Asana. If the service supports SAML 2.0 or OIDC for SSO and has an exposed API to allow SAML/OIDC connections, then this period will be extended to nine (9) months.