Skip to main content
Planview Customer Success Center

Planview Leankit Statement of Security and Architecture Standards

1 General Information

1.1 Planview Headquarters  

Planview HQ address:
12301 Research Blvd.
Building V, Ste. 101
Austin, Texas 78759

No customer data is stored at Planview Corporate HQ. However, to protect against any possible fraudulent access to any internal systems, all Planview vendors, guests, and visitors are escorted upon arrival.

The Planview Corporate HQ building is accessible only by keycard access.

1.2 Planview Information Security

Information is a critical asset for Planview. Information security is the protection of information from a wide range of threats to ensure business continuity, minimize business risk, and maximize return on investments and business opportunities. All Planview information security policies, standards, guidelines, and practices are coordinated through Planview Operations teams, which are responsible for ensuring a consistent enterprise-wide approach in developing, implementing, and managing information systems security.

Planview employees are required to attend information security awareness training and GDPR training upon employment and each year thereafter.

The information security team performs regular internal audits. Also, Planview corporate systems as well as LeanKit services are audited annually by third-party audit firms for SOC 2 Type I and ISO 27001 compliance.

1.2.1 Wireless Network

Planview’s corporate wireless is secured with WPA2 Enterprise. This protocol known as 802.1X is an IEEE standard framework for encrypting and authenticating a user who is trying to associate to a wired or wireless network. WPA2-Enterprise uses TKIP with AES encryption.

1.2.2 Authentication

All privileged accounts requiring access to the production environment via VPN (non-test environments), will require multi-factor authentication to be implemented. This will be facilitated by the Leankit Security or Operations administrator.

1.2.3 Roles and Permissions

Access to the LeanKit VPN and corresponding machines by Planview employees, users, developers, or other personnel can be administered on a case-by-case basis under the approval of LeanKit Operations and Planview Information Security administrators.

1.2.4 Access Restrictions

Planview has documented user access policies and procedures, and implemented supporting business processes and technical measures for ensuring appropriate identity, entitlement, and access management for all internal corporate and customer (tenant) users with access to data and Planview Leankit application interfaces and infrastructure network and systems components.

1.3 Data Segregation

Planview keeps a clear separation between its internal IT operations and the production infrastructure where the LeanKit application is hosted. Corporate headquarters includes all operational divisions of the company, including Sales, Marketing, Services, Internal IT, and so on. The LeanKit application is at Microsoft Azure. LeanKit customer data is logically separated from that of other customers in a multi-tenant database, ensuring proper client segregation as well as an easy way to retrieve said data when a client requests their stored data. 

1.4 Customer Data

Planview manages, processes, and stores customer data in accordance with relevant data protection regulations with specific requirements formally established in customer contracts. All user-generated content in the LeanKit environment is owned solely by the customer.

1.4.1 Access to Customer Data

Planview grants access on a least-privilege, need-to-know basis to ensure only those employees with a business need to access customer data have it. Access is reviewed regularly and removed promptly upon an employee’s departure. Access to production environments is granted using multi-factor authentication and is logged / monitored by a dedicated security team.

1.4.2 Personally Identifiable Information

Elements of personally identifiable information stored and processed by LeanKit include User ID, name, surname, contact information (e-mail, address, phone number, and fax number), and IP address.

Customer data is owned by the customer. In the context of data subject rights, the customer is the controller, and Planview is the processor.  The customer has responsibility for all data subject requests made by the customer’s employees regarding data stored in the LeanKit service.

Note: LeanKit does not require any sensitive personally identifiable information. Refer to https://ec.europa.eu/info/law/law-to...d-sensitive_en for information about what constitutes sensitive personally identifiable information.

1.4.3 Financial Data and Private Health Information

LeanKit does not require financial data, cardholder information, or personal health information, and thus is not PCI-DSS certified or HIPAA compliant.

1.4.4 Data Return and Deletion

To retain data at the end of their term with Planview, LeanKit customers can export their cards to a CSV format. Customers must submit a support ticket to have their data deleted from the LeanKit services.

1.5 Service Level

Note: This service level is subject to the limitations set forth in the Master Service Agreement.

LeanKit service is available 24 hours per day, 7 days per week, and 365 days per year, 99.5% of the time. Refer to the Master Service Agreement for information about scheduled downtime and remedies for uptime that falls below 99.5%.

2 Third-Party Audit and Attestation

The information security team performs regular internal audits. Also, Planview corporate systems as well as LeanKit services are audited annually by third-party audit firms for SOC 2 Type I and ISO 27001 compliance.

3 Service Partners

Planview Leankit is hosted in Microsoft Azure facilities. Microsoft Azure is responsible for the dedicated hardware, storage, network routers and switches, firewalls, etc. Software and operating system components hosted on these devices are controlled by LeanKit.

3.1 Service Provider Compliance

Microsoft Azure meets a broad set of international and industry-specific compliance standards, such as General Data Protection Regulation (GDPR), ISO 27001, HIPAA, FedRAMP, SOC 1 and SOC 2. Visit https://azure.microsoft.com/en-us/overview/trusted-cloud/ for more information.

4 System and Network Security

LeanKit is hosted in a secure server environment that uses a firewall and other advanced technology to prevent interference or access from outside intruders. All system components run on servers dedicated to LeanKit. Microsoft Azure facilities offer state of the art physical and technology security measures. Only authorized personnel are provided physical access to the facilities.

5 Application Level Security

5.1 Login and related Security

Passwords are SHA1 hashed and salted w/a unique value and only salted+hashed version is stored. Forms Authentication tickets (cookies) use AES-256 CBC when encrypting the cookie. All of our data is encrypted at rest using AES-256 CBC (using SQL Transparent Data Encryption protocol). LeanKit access logs can be found both in our edge proxy and authentication service.

5.1.1  Password Policies

LeanKit Account Administrators can configure a strong password policy and session timeout parameters for LeanKit users using the Advanced Security tab in the settings page.

5.1.2  Single Sign-On

The Security Assertion Markup Language (SAML) is a standard document for configuring single sign-on. LeanKit currently supports SAML 2.0. There are three parties involved in these integrations: the principal (LeanKit user), the service provider or SP (LeanKit), and the identity provider or IdP (SSO service operated by the customer).

LeanKit SSO works with forms-based authentication. The default for this is the email address of the user, however an alternate ID can be provided to map users in the customer’s IdP to LeanKit users.

  • Once SSO is enabled, all users within the account will be required to use SSO only to authenticate.
  • Only one SSO configuration (signing certificate and SSO endpoint) can be applied to a single account.
  • Enabling SSO will disable the ability for Planview agents who support the LeanKit service to log into the account and provide support, so if LeanKit support is required another mechanism will have to be negotiated to provide this service.
5.2 Authorization Within the Application

One Account Administrator in each LeanKit Account is designated as the Account Owner. By default, this is the user who first created that LeanKit account, but the Account Owner can request that LeanKit Support designate another Account Administrator as the new Owner. In addition to what Account Administrators can do, the Account Owner has the ability to increase the number of user licenses, upgrade editions, and close the account. An Account Administrator is a user that is able to create, edit, and delete boards; create, enable, disable, and edit users (including making other users Account Administrators); configure certain security settings; and export usage and access reports. The Account Administrator has access to all boards on the Account, regardless of the access they have on individual boards. One or more users in a LeanKit account are designated as Account Administrators.

5.3 Multi Tenant Data Security

LeanKit is a multi-tenant solution in which customer data is segregated using a token-based authentication service that restricts customer access to their own data.

5.4 Application Structure and Security

The LeanKit application is a client-server, multi-tiered architecture in which the presentation, application processing, and data management are logically separate layers of the application.

5.4.1  Presentation Tier

The LeanKit browser client is dynamically generated and rendered. Approximately 85-90% of the application uses React on the front end, while the remaining 10-15% uses ASP.NET MVC to render sever-side. The customer account settings and user settings are always taken into account when rendering data as well as the available menu options presented to the user. LeanKit leverages a “SPA” (single-page-app) type approach. The web client monitors for updates to the deployed code, and updates when new changes are released. The user is not required to manually refresh to get the update.

The LeanKit development team maintains a pattern library for common components in the application, which enables consistent UX and application behavior and reduces maintenance overhead. All LeanKit UI libraries have unit test coverage between 95-100% of all code paths. In addition, the LeanKit development team uses automated UI tests focusing on key workflows.

5.4.1.1 Cache and Cookies

Each time a User logs on. LeanKit issues a session "cookie" only to record encrypted authentication information for the duration of a specific session. The session "cookie" does not include either the username or password of the user - it contains only an authentication ticket ID and the sub-domain portion of the hostname. LeanKit does not use "cookies" to store other confidential user and session information, but instead implements more advanced security methods based on dynamic data and encoded session IDs.

 5.4.2   Application Tier

Also referred to as the business logic layer, the Application tier handles all detailed processing and implementation of business rules. This ensures that standard processes are implemented consistently regardless of where the action is initiated. This tier is also responsible for transaction consistency from a business logic perspective.

5.4.3  Data Access Tier

LeanKit’s HTTP API is comprised of several services that are logically divided by the focus of the behavior they implement. These services sit behind multiple proxies and can be seamlessly upgraded without taking the services down. When necessary, LeanKit can ban misbehaving/malicious traffic.

The data access logic utilized by these API services enforces identifying the user and organization associated with a request, as well as any other relevant permissions. Changes made through our data access modules result in an event being generated once the transaction is committed. The event contains metadata about what properties were changed, etc. These events are used to populate our analytics databases as well as events we send to third-party application usage analysis tools. All LeanKit API services have both unit and integration tests at or above 90-95% test coverage.

5.5 Integration Level Security

LeanKit API services support the following types of authentication: HTTP BASIC, Forms Authentication, JWT (external third-parties would have to request support for this on a case-by-case basis), and Bearer token.

5.6 Data in Transmission

The LeanKit application forces the user to communicate with TLS encryption for all network communication.

5.7 Data Encryption at Rest

All data is encrypted at rest using AES-256 CBC using the SQL Transparent Data Encryption protocol.

5.8 Monitoring Logs/Audit Trails

Application event logs are maintained as well as infrastructure system logs, in a central logging repository. This aggregated log collection is monitored for unauthorized activity, login attempts, excessive network traffic, and other abnormal activity. Activities in these logs include that of privileged users.

Intrusion detection is enabled on infrastructure critical hosts, and provides additional insight and alerting to the LeanKit infrastructure and application.

6 Backups and Disaster Recovery

The main LeanKit application infrastructure is redundant for failover purposes with sites in Microsoft Azure West and Microsoft Azure East.

6.1 Backup Processes

To ensure that your data is available even if a disaster occurs, the following steps are taken:

  1. Continually ship transaction log backups to our disaster recovery location to ensure 1 hour RPO is met.
  2. Immediately copy transaction log backups to a different physical location and retain them for 3 days.
  3. Perform full backups every 24 hours.
  4. Send full backup files directly to a different physical location and retain them for 7 days.
6.1.1  Backup to Removable Media

Removable media is not allowed in the LeanKit production environment at Microsoft Azure.

6. 2 Incident Response Procedure

In the event of a security breach or customer impacting event, Planview LeanKit has a process to recognize potential issues affecting customers from any channel, verify as thoroughly as feasible and quickly raise the issue to the appropriate teams that can manage the resolution process. Incident status is published at https://status.planview.com/, and is updated every 30 minutes starting with confirmation of the incident and when the issue is resolved. 

7 Change Management Procedures and Processes

7. 1 Change Control and Approval Process

LeanKit follows a continuous-deployment paradigm. Refer to section 7.3.1 Maintenance and Upgrades and to section 7.3.2 Coding Practices for information about how change management is applied.

7. 2 System Change Management

7.2.1  Applying Security Patches

Patching of all physical hardware is maintained by Microsoft Azure. Software, operating system, application, and all host-based services are patched by LeanKit network operations. Patching on LeanKit systems is automated to ensure that the most recent working patches are in place. 

7. 3 Application Level Change Management

LeanKit utilizes a lean process – where changes flow (and are deployed) continually in small increments. Requests for new features are handled by LeanKit Product Management. The prioritization of new features and the method for addressing defects is a collaborative effort between Product Management and LeanKit Product Development technical leadership.

7.3.1  Maintenance and Upgrades

LeanKit follows a continuous-deployment paradigm. As soon as application bug fixes or features are release-able, they are deployed (typically several times per day). As mentioned above, the browser portion of the app (the “SPA” code), monitors for new version of the application and will queue a refresh at a navigational “seam”, causing the app to refresh to the latest code without requiring the user to manually do so. As a result, even idle browser tabs will have the updates within 30 minutes of release.

7.3.2  Coding Practices

LeanKit developers regularly pair-program. Developers that make commits to our source code are not allowed to merge those commits into an upstream branch themselves. Instead, the merge is performed by another qualified reviewer.

LeanKit source code is stored in private repositories on GitHub, and thus code reviews take place when a developer opens a Pull Request (PR) on GitHub asking for code to be merged in. The team uses GitHub PR templates to provide reviewers a checklist of key things they should focus on. Prior to submitting a PR, developers must provide unit tests that cover any new/changed behavior, and this process includes automated static analysis, such as linting and formatting, to warn of any issues that should be addressed prior to submitting the PR. As a general rule, test coverage for LeanKit projects must be at or above 90% of all code paths (most are at 100%).

Once a PR has been merged, the new code will be deployed to a development environment by a continuous deployment bot that monitors a Kanban board in LeanKit looking for code that needs to be deployed.

An upstream feature branch of the code is deployed (i.e. – the code is not in our master branch yet). LeanKit QE will then test the changes both by running automated UI and API tests as well as manually testing steps. If any issues are found during testing, LeanKit development will prioritize a rework task to fix the issue so that it can be re-tested. Once it has passed QE review, a PR is opened from the upstream branch to the master branch. Automation Engineers will merge these PRs and create a new Git tag using semantic versioning to tag releases. The newly merged-into-master-and-tagged code will be deployed into our integration environment, where automated UI and API tests are run. Once these automated tests pass, the code is then deployed to our production instances.

New Developers

LeanKit Product Development is organized into smaller sub-teams called “fireteams.” The fireteams consist of 2-4 developers. New developers will pair very heavily within their fireteam, and also semi-regularly across fireteams. The primary means of mentoring is through pair-programming and weekly team training sessions. When a new developer comes on board, the pairing will initially focus on exposing new developers to various code bases and having them observe workflow. Very quickly, new developers begin to “drive” the pairing session, and this is followed by a mix of solo and pairing task work. A new Senior Developer will also be mentored on how LeanKit development reviews PRs so that they can become a reviewer as well.

Source Code Control

LeanKit uses Git and GitHub for managing source code. LeanKit developers fork the upstream branches when making changes, and the developers only merge those changes in when they have passed QE. The combination of the LeanKit codebase being managed as separate projects and the lean process the team follows results in reduced conflicts when merging or rebasing branches. All LeanKit projects, such as deployable services and supporting libraries, are versioned using Git tags using principles of semantic versioning.

7. 4 Employee Related Change Management

7.4.1  Hiring Practices

Planview adheres to a standard screening process for all individuals seeking employment with the company. Extensive reference checks are performed on individuals that may gain access to sensitive customer data to perform their job duties. In addition, Individuals offered employment from Planview must read and sign the Information Security Awareness policy and a Non-Disclosure Agreement before gaining access to any production systems.

7.4.2  Employees

All Planview information security policies and procedures that are read and signed as acknowledgement by newly hired employees are kept in their permanent personnel files.