Security Overview

This document describes the organizational and technical measures by which Planfix, Inc. (the "Provider") protects Client data in providing access to the Planfix platform. It is written for the information security teams of corporate Clients and contains only statements that are supported by the Provider's binding documents and by the actual configuration of the Service. Where a measure is not applied, or cannot be confirmed, this is said directly, in a block headed "Limits of this statement". Those blocks are part of the answer, not fine print.

This document is informational: the obligations of the Provider are established by the Terms of Service and the other binding documents published on this site, and this overview neither changes nor extends them. Where they differ, the binding documents control.

Responsibility for the security of the Service is split three ways, and this document keeps them apart:

• Provider — the software platform, the processing of data, operation of the Service, backups, incident response.
• Data center — the facility, its engineering systems, physical security, the network perimeter, baseline protection against network attacks.
• Client — the settings of its Account, the set of users, the permissions it assigns, the integrations it connects, and its obligations as a controller of personal data.

1. LEGAL FRAMEWORK AND ALLOCATION OF ROLES

1.1. Under the published Terms of Service the Service is remote access by the Client to the functionality of the Platform on a software-as-a-service model. Copies of the software are not delivered to the Client: the Platform is hosted on the Provider's server infrastructure and is operated by the Provider. The Terms of Service call the two parties the Provider and the Customer; the Privacy Policy, the Data Processing Addendum and the Subprocessor list call them the Operator and the Client. This document uses Provider and Client throughout, and the parties are the same ones.

1.2. For personal data that the Client places in its Account, the roles are allocated as follows:

• The Client is the controller within the meaning of Article 4(7) of Regulation (EU) 2016/679 (GDPR). It determines the categories of data, the purposes of processing and the retention periods.
• Planfix, Inc. is the processor within the meaning of Article 4(8) of the GDPR. The basis for the processing is the Data Processing Addendum published on this site, which forms part of the agreement under Section 6.4 of the Terms of Service.
• For data that Planfix, Inc. collects on its own account — the registration data of the Client's representative, data about the use of the website — Planfix, Inc. is a controller in its own right. That processing is described in the Privacy Policy.
• For personal information processed on behalf of the Client, Planfix, Inc. is a service provider under the California Consumer Privacy Act as amended by the California Privacy Rights Act, and does not sell or share personal information.

2. INFRASTRUCTURE AND PHYSICAL SECURITY

2.1. The Platform runs in cloud environments that the Provider operates itself, across several independently secured data centers. The Service is offered in geographic hosting clusters: the Client selects the cluster for its Account from the options offered by the Provider, and an Account can be migrated to another cluster on request.

2.2. Alongside its own cloud environments the Provider uses a limited set of Amazon Web Services components: Amazon S3 as the production store for files uploaded by users, Amazon S3 Glacier for long-term backup archives, Amazon Route 53 for authoritative DNS and health checks, and AWS Lambda for individual serverless automations. For Accounts in the European Union cluster, data in S3 and S3 Glacier is stored in the Europe (Ireland) region. Compute and the primary databases remain in the cloud environments operated by the Provider.

2.3. Physical security at the sites is the responsibility of the infrastructure providers. Their facilities operate on-site security staff, controlled access, video surveillance, redundant power supply with backup generators and automatic fire suppression; physical access to equipment is controlled by the data-center operators.

3. NETWORK ARCHITECTURE AND PERIMETER PROTECTION

3.1. The Platform's network infrastructure is segmented. Public traffic terminates at hardened edge load balancers; the application tier and the database tier are placed in separate trust zones with least-privilege network policies. Database servers accept connections only from application servers and are not reachable from the Internet.

3.2. At the application layer the Provider applies a web application firewall, rate limiting of API and sign-in requests, and protection against credential guessing with a temporary lockout after a series of failed sign-in attempts.

3.3. Network traffic and system events are monitored continuously, with automated alerts when indicators deviate from their normal ranges.

4. PROTECTION OF DATA IN TRANSIT AND AT REST

4.1. All traffic between the user's device and the Platform is encrypted with TLS 1.2 or higher, with support for TLS 1.3, using AES-GCM for symmetric encryption and ECDHE key exchange, which provides forward secrecy. HTTP Strict Transport Security is enforced, so there is no fallback to an insecure connection. The protocols and cipher suites in use are updated as security technology develops.

4.2. Access to the application programming interface is possible over HTTPS only: requests sent over an unprotected connection are rejected on the server side.

4.3. Files uploaded by users and stored in Amazon S3 are encrypted at rest with AES-256. The buckets are private, with no public access, and access is limited to the Provider's backend services through narrowly scoped IAM policies; objects are served only through the application. Backup archives are encrypted with AES-256 before they are placed in storage (Section 11).

5. MULTI-TENANCY AND SEPARATION OF CLIENT DATA

5.1. The Platform is multi-tenant: Clients share one software platform, and the data of each Account is separated from the data of every other Account.

• Each Account operates on a dedicated database schema, so that the records of different Accounts are not held in shared tables.
• Files and attachments are stored in object storage, segregated by prefixes specific to the Account and encrypted at rest.
• Authorization is checked on every request, including requests through the programming interface: the Account identifier is part of every query and API call, and the system returns only the data of the Account in which the user is authenticated.

6. ACCESS MANAGEMENT ON THE CLIENT SIDE

6.1. The Platform gives the Client's administrator a set of access controls. Applying them remains the Client's decision: the Provider supplies the capability but does not configure the access policy on the Client's behalf. The set of available controls depends on the Account's plan, and in the default configuration the restrictions described below are not switched on — they are set by the Primary Account Administrator.

Two-factor authentication

6.2. The second factor is a one-time password generated by an application on the user's smartphone and valid for 30 seconds. Two-factor authentication can be required across the whole Account or for selected employees, so that a stolen password alone does not give access to the Account.

Single sign-on through a corporate directory

6.3. Signing in with a corporate account is supported over SAML 2.0. Setup is performed by the Primary Account Administrator or an Administrator in Account Management — Integrations — Single Sign-On, and requires prior configuration on the identity provider's side. The supported providers, and the scope of support, differ:

6.4. An Account can additionally be set to permit signing in through the identity provider only. Where that setting is off and other sign-in methods remain allowed, a user disabled in the corporate directory can still sign in with a password.

Restricting access by address and by time

6.5. The Primary Account Administrator can allow access to the Account only from specified IP addresses, for example the office network or the egress addresses of a corporate VPN, and can set the hours during which access is permitted, which makes it possible to confine work with the Platform to business hours. The rules are set in Account management — Account security — Access by IP, and their number is not limited. Access is denied by default, but every newly created Account carries a standing rule that admits all of its users from any address; until that rule is deactivated, the Client's own rules do not take effect.

Roles and permissions

6.6. Access to data and functions inside an Account is governed by roles and permissions, assigned so that a user holds no more than the access their work requires.

Beyond the system role a user can hold roles within a project and within a task, and permissions are set separately for tasks, projects, contacts, documents, reports and administrative settings.

Passwords and termination of access

6.7. Where the Account's plan provides for it, the Primary Account Administrator sets the password policy in Account management — Account security — Password Policy: a minimum length, typically 8 to 12 characters depending on the configuration, the character types required (upper and lower case, digits, special characters) and, where configured, an expiry period after which the user has to set a new password. Passwords are never stored in plaintext; they are salted and hashed with a strong one-way algorithm. Repeated failed sign-in attempts result in a temporary lockout, as a rule for 15 minutes after three attempts. Access for a departing employee is terminated by deactivating that employee in the Account.

7. LOGGING AND CONTROL OF ACTIONS

Logs available to the Client

7.1. The Platform keeps Account-level audit logs of user activity, available to the Client, alongside the history held on each object: the log of a task holds every action and change made to it, and an employee sees only the actions they have access to; the log of a project aggregates the same across the tasks in it. The composition of the logs and the depth of history available in the interface depend on the Account's plan.

Access by the Provider to Account data

7.2. Support cannot sign in to a Client's Account under a user's credentials. That capability, sometimes called impersonation, does not exist in the Platform. Where support has to reach Account data to handle a request, it does so only through internal tools, and every such request is logged. Within the Client's own Account an Administrator can sign in through another user's account; that is a capability the Client grants and controls, and it is not one available to the Provider.

7.3. Access to production systems is granted on a least-privilege basis to a small number of authorized engineers, who are bound by confidentiality. Administrative access is by key-based SSH or a VPN with multi-factor authentication, administrative actions are logged, and access rights are reviewed periodically.

The Provider's technical logs

7.4. Security logging is centralized and covers access events, configuration changes and errors in the application and the infrastructure, with continuous monitoring and alerting. Access to the technical logs is limited to security and operations personnel. Security and audit logs are retained for at least one year and are progressively reduced to aggregated, non-identifiable form.

8. PROGRAMMING INTERFACE AND INTEGRATIONS

8.1. The Platform provides a REST API that exchanges JSON and is described by an OpenAPI 3.0 specification, an XML API, and webhooks. The entry point is an address of the form https://account_name.planfix.com/rest/ and exchange is possible over HTTPS only.

• Authorization tokens are created in the Account management section and can be limited in scope.
• Requests are executed on behalf of the employee who owns the token and inherit that employee's permissions. For integrations that need broad access, a robot account is used; it cannot sign in to the web interface.
• Rate limits apply to the number of requests and to the number of results returned by list methods. The values depend on the Account's plan and are stated in the API documentation.

9. PLANFIX AI FUNCTIONALITY

Control of the functionality

9.1. Planfix AI is additional functionality of the Platform. The Client switches it on and off through the Platform interface, and the Account administrator is responsible for controlling its state. Individual Platform features may invoke Planfix AI automatically unless the Client has disabled the functionality beforehand.

Transmission of data and the guarantees given

9.2. To deliver the functionality the Provider uses the AI technologies of third-party organizations, defined in the Terms of Use Planfix AI as Technology Providers. Client requests and generated content are transmitted to them to the extent needed to fulfil the request. The identities of the Technology Providers are not disclosed publicly; they appear as a category in the Subprocessor list instead, and a Client that does not accept this can refrain from using, or disable, the functionality for its Account.

9.3. The Provider has activated every training and model-improvement opt-out control available to it with its Technology Providers. To the Provider's knowledge, based on the current terms and configurations of those Technology Providers, Client data and requests transmitted through Planfix AI are not used by them to train, improve or develop AI models. The Provider reviews those terms and configurations periodically and updates the Terms of Use Planfix AI if they change.

Cross-border transfer

9.4. Requests may be processed outside the country in which the Account's cluster is located, including transfer from the European Union to the United States. For data about individuals in the European Union, the United Kingdom and Switzerland, such transfers rely on the Standard Contractual Clauses or another lawful transfer mechanism (Section 13).

Restrictions on the data transmitted

9.5. Sensitive personal data must not be sent through Planfix AI: this covers health and financial data, biometric data, and data revealing racial or ethnic origin, political opinions or religious beliefs. The Client is responsible for observing that restriction, and for holding the legal basis and any consents required for the data it does send.

10. EXPORT, RETURN AND DELETION OF DATA

10.1. The Client can export its data at any time using the built-in export tools of the Service and the programming interface, without contacting support.

10.2. Return of data at the end of the relationship needs no separate procedure: the Client exports the data itself before the Account is deleted. On the Client's written request made before deletion, the Provider instead enables the Client to export a complete copy of the Account data.

10.3. An Account in which there is no new activity is frozen. The Provider prompts the user a week in advance, freezes the Account after a month without activity, and deletes the Account and all of its data automatically if it is not unfrozen within a month of freezing. Only the Account Owner can unfreeze it.

10.4. After deletion, a copy of the Account is retained for 180 days and all Account data is then permanently deleted. Residual copies in encrypted offline backups are purged within 180 days of deletion. A verified deletion request is fulfilled within 30 days, and within 45 days where a California resident exercises rights under the California Consumer Privacy Act, subject to the statutory exceptions that the Data Deletion Procedure sets out.

11. BACKUP AND RECOVERY

11.1. Backups of Platform data are taken daily. The archives are encrypted with AES-256 and integrity-checked, and the retention depth allows data to be recovered to a point in time within the preceding 90 days. Access to backups is limited to authorized engineers, every restoration is logged, and restore testing is performed periodically.

11.2. Backup copies for every geographic cluster are stored in EU regions only, and cross-region replication uses EU-to-EU pairings. This applies to Accounts in all clusters, including those hosted outside the European Union.

Recovery scenarios

12. INCIDENT RESPONSE AND NOTIFICATION

12.1. The incident response process is documented and covers detection, classification by severity, containment, eradication of the cause, restoration of service, and a post-incident review with the findings recorded. An on-call team is available around the clock for critical events.

12.2. Where an incident is a personal data breach affecting Client Personal Data, the Provider notifies the Client without undue delay and in any event no later than 72 hours after becoming aware of it, at the email address designated for the Account. The notification describes the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences and the measures taken, so far as that information is available, and may be given in phases. A notification is not an acknowledgment of fault or liability.

12.3. Under the GDPR the obligation to notify the supervisory authority, and where required the data subjects, rests with the controller, that is with the Client. The Provider acts as processor: it notifies the Client and supplies the information the Client needs to discharge its own obligations.

12.4. The service status page at https://planfix.com/status/ publishes the current operational status of each hosting cluster. That page reports availability and is not a register of security incidents: notice of a personal data breach reaches the affected Clients directly under 12.2, and not through it.

13. DATA PROTECTION: ROLES, TRANSFERS AND RESIDENCY

The contract that governs the processing

13.1. Processing of personal data that the Provider performs on the Client's behalf is governed, within the scope set out in it, by the Data Processing Addendum published at https://planfix.com/doc/dpa/ and forming part of the agreement. The Addendum is accepted in its published wording and is signed as a separate copy on request.

International transfers

13.2. Planfix, Inc. is established in the United States. Where Client Personal Data is transferred to a country that is not the subject of an adequacy decision of the European Commission, the transfer is governed by the Standard Contractual Clauses, Module Two, controller to processor, incorporated into the Data Processing Addendum by reference. The docking clause in Clause 7 is included; in Clause 9(a) Option 2 applies, with a period of 30 days; under Clause 17 Option 1 the clauses are governed by the law of Ireland, and under Clause 18(b) disputes are heard by the courts of Ireland.

13.3. For data within the scope of the UK GDPR, the Standard Contractual Clauses apply as supplemented by the International Data Transfer Addendum issued by the UK Information Commissioner. For data within the scope of the Swiss Federal Act on Data Protection, they apply with the adaptations recognized by the Swiss Federal Data Protection and Information Commissioner.

13.4. Planfix, Inc. is not certified under the EU-U.S. Data Privacy Framework and does not rely on it as a transfer mechanism.

Where the data is held

13.5. Client Personal Data is hosted in the cluster selected by the Client (Section 2). For the European Union cluster, production hosting is in Germany and files and backup archives are in the Europe (Ireland) region. Backup copies for all clusters are stored in EU regions. Technical support and development are performed from the United States of America and, through a subprocessor, from the Republic of Moldova (Section 15). Administration and corporate operations are performed from the United States of America.

Rights of data subjects

13.6. Requests from data subjects are handled by the Client as controller. The Provider assists with the built-in export and deletion tools of the Service and, where such a request reaches the Provider directly in respect of data it processes as processor, routes the request to the Client.

Contact for data protection matters

13.7. Planfix, Inc. has not appointed a Data Protection Officer and is not required to appoint one. Requests concerning data protection are handled through https://planfix.com/support/ or by mail to Planfix, Inc., Attn: Privacy Office, 4445 Eastgate Mall, Suite 200, San Diego, CA 92121, USA.

Requests from public authorities

13.8. A request from a government body or a law-enforcement authority is reviewed for the authority of the body that sent it and for the scope of what is sought, and the request is recorded. Where the law permits and the Provider is not prohibited from doing so, the Client is notified before Account data is disclosed, so that the Client can take its own steps. Disclosure of personal data for which Planfix, Inc. is itself a controller is governed by the Privacy Policy rather than by this section.

14. CERTIFICATIONS AND EXTERNAL VALIDATION

14.1. Planfix, Inc. holds no SOC 2 report, no ISO/IEC 27001 certificate and no other security certification, and has not undergone an external security audit. This is stated plainly so that an assessment of the Provider is not built on the opposite assumption.

14.2. The Provider's controls are designed against the intent of recognized frameworks: the control domains of ISO/IEC 27001 and the Trust Services Criteria used in SOC 2 reporting. Formal certification is intended as the company scales, and no date for it is announced here.

14.3. Reports of a suspected vulnerability in the Platform are accepted through the support channel named in Section 19.2. They are routed to the Provider's security team, and the Provider asks that a report be sent to it before the finding is published.

15. SUBPROCESSORS

15.1. The Provider engages subprocessors to deliver the Service. The composition at the date of this document is as follows.

15.2. The hosting subprocessors supply servers and facilities, and the storage subprocessor supplies object storage; none of them has application-level access to the contents of Accounts. Files and backup archives held in object storage are encrypted at rest; what is and is not encrypted at rest is set out in Section 4. Bonsoft IT S.R.L. has remote access to production systems to the extent required for development and technical support, under the access controls described in Section 7.

15.3. The Provider announces any intended addition or replacement of a subprocessor on the published list and by email to the address designated for the Account, at least 30 days before the change takes effect. The Client may object on reasonable data protection grounds, under the procedure that Section 6.3 of the Data Processing Addendum lays down. The Provider imposes on each subprocessor, by contract, data protection obligations that are in substance no less protective than those of the Addendum, and remains fully liable to the Client for the subprocessor's performance.

15.4. The authoritative list is the one published at https://planfix.com/doc/subprocessors/ and it completes Annex III to the Standard Contractual Clauses. Where the table above and that page differ, the page states the current composition.

16. DOCUMENTS AND THE LIMITS OF WHAT THEY PROVE

16.1. The binding documents are published and available to anyone; they are listed in Section 1. The document the Provider executes with a Client is the Data Processing Addendum itself, in its published wording.

16.2. Beyond the published documents, a Client can ask for the information reasonably necessary to demonstrate compliance with the Data Processing Addendum. Section 11.1 of the Addendum sets out that undertaking, and requests are made through the support channel named in Section 19.2. What can be supplied in answer to a given request depends on what the Provider actually holds; Section 14 states what it does not hold.

16.3. Section 11 of the Data Processing Addendum sets out audit rights. The Provider makes available the information reasonably necessary to demonstrate compliance and contributes to an audit by the Client or an auditor it mandates, no more than once in any 12 months except after a personal data breach or where a supervisory authority requires it, on 30 days' notice, during business hours and subject to confidentiality. Audits exclude the data of other clients and the premises controlled by the data-center operators; for those premises the Provider supplies the attestations of the operators that are available to it.

17. MOBILE APPLICATIONS

17.1. The mobile applications are published in the App Store and in Google Play; the publisher is Planfix, Inc.

• The application works together with the server. The authorization token and a cache of the data being displayed are held locally; the Account's data set is not stored permanently on the device.
• All network connections are established over HTTPS with TLS encryption, and only with the Platform's servers.
• The application runs inside the operating system's sandbox, so access to its data by other applications through operating-system means is precluded.
• Push notifications are delivered through the native notification services of the respective platforms.
• The permissions an application requests are listed on its page in the corresponding store.

18. THE CLIENT'S AREA OF RESPONSIBILITY

18.1. The Provider is responsible for the infrastructure and the software platform; the Client is responsible for how access is configured inside its Account. In practice that means the following.

• Selecting the hosting cluster that matches the Client's own data residency requirements.
• Requiring two-factor authentication for employees and for external users.
• Configuring the rules for access by address and by time.
• Assigning roles and permissions to objects on the principle of the least access a person's work requires.
• Terminating access when an employee leaves, bearing in mind that automatic deactivation from a corporate directory works only with the identity providers that support SCIM.
• Keeping and revoking the tokens used for access to the programming interface.
• Assessing the third-party integrations connected to the Account, including whether they transfer data across borders.
• Deciding whether to use Planfix AI and performing the controller's obligations that follow from that decision (Section 9).
• Performing the obligations of a controller: establishing the legal basis for the processing, obtaining the consents the law requires, and handling requests from data subjects.
• Keeping the Account email address current, since notices of changes to the subprocessor list are sent to it (Section 15).

19. CURRENCY OF THIS DOCUMENT AND HOW TO ASK FOR MORE

19.1. The document is updated when the information in the Data Processing Addendum or in the subprocessor list changes, and on any material change to the infrastructure; the date from which the current version applies is shown at the head of this page. Where this document and the binding documents differ, the binding documents control.

19.2. Questions about security, and requests for the materials listed in Section 16, are submitted through https://planfix.com/support/ or by mail to Planfix, Inc., 4445 Eastgate Mall, Suite 200, San Diego, CA 92121, USA.