Skip to main content
Planview Customer Success Center

ProjectPlace 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 Information Security

Planview has established a security, trust and assurance ecosystem to address applicable legislation, data ownership, data retention, privacy, integration, and the traditional triad of security: confidentiality, integrity and availability.

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

The ProjectPlace service is on a physically segregated network that requires two-factor authentication for administrative access from its office network. All privileged accounts requiring access to the production environment require multi-factor authentication, which is granted using the least-privilege methodology, based on business need and security requirements. Access to information assets is only granted on a “need to know” basis. It is each asset owner’s responsibility to estimate an employee’s need to get access to the information stored in their asset(s).  

1.3 Data Segregation

Planview keeps a clear separation between its internal IT operations and the production infrastructure where the ProjectPlace application is hosted. Corporate headquarters includes all normal operational divisions of the company, including Sales, Marketing, Services, Internal IT, and so on.  The ProjectPlace application is hosted in the Amazon AWS infrastructure in the U.S. and in Sweden.

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 ProjectPlace service is owned solely by the user.

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 ProjectPlace 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 ProjectPlace service.

Note: ProjectPlace does not require any sensitive personally identifiable information. Refer to for information about what constitutes sensitive personally identifiable information.

1.4.3 Financial Data and Private Health Information

ProjectPlace 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

Customers have various options within the ProjectPlace applicatin to export data before their term ends.

1.5 Service Level

The ProjectPlace solution has an average uptime of 99.5%.

2 Third-Party Audit and Attestation

The ProjectPlace solution is ISO certified has completed a SOC 2 Type I self audit and attestation (Spring 2019).

3 Service Partners

The ProjectPlace solution is hosted in AWS facilities. Software and operating system components are controlled by Planview.

AWS is a highly secure, highly available hosting provider that utilizes state-of-the art electronic surveillance and multi-factor access control systems. Access is authorized strictly on a least-privileged basis, and security features are implemented throughout the facilities. Environmental systems are designed to minimize the impact of disruptions to operations.

AWS adheres to the following compliance programs:

•SOC 1/SSAE 16/ISAE 3402 (formerly SAS 70 Type II), SOC 2, SOC 3
•PCI DSS Level 1
•ISO 27001
•FIPS 140-2

Visit for more information.

4 System and Network Security

The ProjectPlace solution 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 Planview. Our 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

Each user in ProjectPlace is identified with a unique user name(e-mail) and authenticated in the system with a personal password. Specific password requirements, such as password length and complexity, can be implemented by the Project/Account administrator. Planview also supports, and recommends, the use of SAML for authentication (see section 5.1). With two-step verification users’ accounts are protected by both their password and their mobile, authenticator application, or Yubikey. We encourage all ProjectPlace users to enable this extra layer of user login security.

5.1. Single Sign-On

The ProjectPlace solution supports Single Sign-On (SSO), using SAML and an active directory federation service for enterprise users. Single sign-on allows network users to access ProjectPlace without having to log in separately.

5.2 Authorization Within the Application

One Account Administrator in each ProjectPlace Account is designated as the Account Owner. By default, this is the user who first created that ProjectPlace account, but the Account Owner can request that the support team 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. The Account Administrator(s) have elevated access when it comes to Users and Workspaces owned by the Account. An Administrator can, for instance, add/remove users from the Account, transfer ownership of Workspaces and give/remove access for users to tools within ProjectPlace.

5.3 Multi Tenant Data Security

In ProjectPlace, data access and security is enforced through user groups in Workspaces. All users who are members of a single Workspace belong to one or many groups that can have read/write/no access to the different tools, and the contents of the tools. Because the ProjectPlace application defaults to No Access in all requests for Workspace data, the use of Membership and user groups in Workspaces ensures that only users who have access to a Workspace can access the data.

5.4 Application Structure and Security

5.4.1  Presentation Tier

The Presentation tier dynamically generates the client side User Interface (UI). No static HTML content or pages are stored on the ProjectPlace application server. Each page is dynamically generated and takes into account a given user’s permissions to each object being displayed. This permission model is carried down even to individual data attributes of the objects, allowing the application to apply security in a very fine grained manner. Account Administrators can select who have the right to create Workspaces and get elevated access rights when it comes to managing Workspaces and users. Access within a Workspace is managed through groups where access to specific Tools, within one Workspace, and also finer level access to specific folders in Documents and to specific Boards as an example. The ProjectPlace solution uses both external and internal API to render the webpages. Cache and Cookies uses cookies to be able to determine user preferred language on the login page, the users time zone and for client authentication. The ProjectPlace application does not collect any personally identifiable or sensitive information without taking permission from the user. Refer to the privacy policy here:

 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

The Data Access tier is responsible for all reading and writing of data and interaction with the back-end database.This layer is custom built in-house and automatically implements the tracking of history for objects in the system. This allows the user to view changes to objects and determine who made the change and when it was made. Access to the data layer can only happen through the application. No direct access is allowed to the data by any other means.

5.5 Integration Level Security

The ProjectPlace application supports two ways of Authentication when it comes to integrations: User-based or Robot-based authentication. When using the User based authentication, in an integrations scenario, the same access rights will be applied as when the user is accessing the webservice. The same access check as for the webservice applies.

Robot-based authentication is a way to elevate the access rights in a integration scenario. An Account in ProjectPlace can request to have a Robot connected to their Account that will let give the integrations the same access rights as an Account Administrator. The ProjectPlace application supports this use case so that customers can build custom integrations that have access to all objects in ProjectPlace.

Refer to for information about the ProjectPlace API.

5.6 Data Encryption

The ProjectPlace solution uses TLS protocol with 256 bit AES encryption to protect data in transit and at rest. No user data (including login information) is ever sent through unencrypted public channels. All documents stored in ProjectPlace are automatically encrypted with a unique key per document, using the AES-256 encryption algorithm, which is saved anonymously in order to prevent identification. The encryption keys are stored separately and precautions taken to prevent unauthorized access both to the encrypted document and its corresponding encryption key.

5.7 Monitoring Logs/Audit Trails

Planview proactively monitors and analyzes firewall and system logs to identify unusual traffic patterns, potential intrusion attempts, and other security threats. ProjectPlace also uses reliable network monitoring services for its co-location facilities.

6 Backups and Disaster Recovery

The main ProjectPlace application infrastructure is redundant for failover purposes with two or more geographically dispersed datacenters in each region. Currently Ohio, US and Stockholm, Sweden are the regions in use.

6.1 Backup Processes

The ProjectPlace system components are backed up to AWS Simple Storage Service (“S3”). Full backups are taken nightly, and transactional backups are taken every ten minutes, at a minimum, and retained for 180 days. 

6.1.1  Backup to Removable Media

Removable media is not allowed in the production environment.

6.2 Incident Response Procedure

If a customer detects a breach, they must notify Planview immediately by sending an email to  Planview has an established incident management policy and process to ensure impacted customers are promptly notified, records are retained, and lessons-learned discussions are held. Planview will use commercially reasonable efforts to restore service or remedy a security breach/event as soon as possible, targeting a 24-hour delivery of formal Incident reports. To date, Planview has not encountered a security breach that had the potential to expose sensitive data.

Planview is currently partnered with the Rapid 7 Incident Response Team to provide accelerated incident investigation, containment, and management. The Rapid 7 Incident Response services include all aspects of threat detection, documenting findings, and collaborating to devise appropriate remediation activities. 

ProjectPlace incident status is published at

7 Change Management Procedures and Processes

7. 1 Change Control and Approval Process

The following change management-related processes are present at Planview :

  • Daily Operation
  • Sprint Release
  • Maintenance Release

Planview uses an agile development process that does not employ strictly delimited phases. The following list depicts a chain of key decisions during a typical development project, and the parties involved in the decision. 

  • The Development "Master Plan" contains the strategic product development decisions, in the medium to long term. This plan is prepared and continuously revised and decided upon by Product Management.
  • Roadmap of projects for the coming 3-12 months (Product Management )
  • Product management prepares the product backlog for the sprint, and then delivers the order to the development teams at the sprint planning. 
  • Sprint planning: several stories; each story may contain several tasks (scrum master, developers, stakeholders, operations)
  • Development & parallel story testing (developers, testers)
  • Story sign-off by product owner
  • Release preparation (developers, operations)
  • Deployment (operations, developers, testers)
  • Release verification and follow-up (operations, developers)

7. 2 System and Network Change Management

All major changes have to be approved by the Change Advisory Board. Changes are first tested in our non-production environments to ensure the quality of the change.

7. 3 Application Level Change Management

Planview has a secure coding practices policy in place, which provides developers with an overview of the general security architecture in the system. The policy is designed to work as a reference point at any time during a release:

  • While compiling a list of requirements in the concept/design phase, requirement analysts identify possible security problems, and refer to this page for protective measures
  • During the development phase, developers consult the policy as a checklist to ensure include all possible security measures into their code
  • The referenced policy is also used as a reference point during code reviews and/or security assessments

The policy covers the following top concerns:

  • Access Control
  • XSS Protection
  • XSRF Protection
  • Accessing the databases
  • Third-party integration - code & function review, updates, risk analysis
  • Security Guidelines

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.