Data Processing Agreement

This Data Processing Agreement (the “DPA”) adopts and incorporates by reference the terms andconditions, and is expressly made part,
the MSLA between Clientand Sales Performance International (hereinafter “SPI”).

This Data Processing Agreement (the “DPA”) adopts and incorporates by reference the terms and conditions, and is expressly made part,the MSLA between Client and Sales Performance International (hereinafter “SPI”).

 

  1. Definitions
    Any capitalised term not defined in this DPA shall have the meaning given to it in the Agreement

    • “Affiliates” means any entity that directly or indirectly controls, is controlled by, or is under common control of a party. “Control,” for purposes of this definition, means direct or indirect ownership or control of more than 50% of the voting interests of a party;
    • “Agreement” means the above referenced agreement between SPIand the Clientfor the provision of the Services;
    • “Controller” means the Client;“Data Subject”shall have the same meaning as in Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 (as amended from time to time,or replaced by subsequent legislation);
    • “DPA” means this data processing agreement together with Exhibits A and B;
    • “Personal Data” shall have the same meaning as in Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 (as amended from time to time,or replaced by subsequent legislation);
    • “Processor” means SPI;
    • “Security Policy”means SPI’s security document as updated from time to time, and accessible viathe account admin console from the SPI platform or otherwise made reasonably available by SPI. The version of this document as of the time of this Agreement is Exhibit B;
    • “Standard Contractual Clauses” means the EU model clauses for personal data transfer from controllers to processors c2010-593 -Decision 2010/87EU;
    • “Sub-Processor” means any person or entity engaged by SPIor its Affiliate to processPersonal Data in the provision of the Services to the Client.
  2. Purpose
    2.1 The Processor has agreed to provide the Services to the Controller in accordance with the terms of the Agreement. In providing the Services, the Processor shall process Client Content on behalf of the Controller. Client Content may include Personal Data. The Processor will process and protect such Personal Data in accordance with the terms of this DPA.
  3. Scope
    3.1 In providing the Services to the Controller pursuant to the terms of the Agreement, the Processor shall process Personal Data only to the extent necessary to provide the Services in accordance with both the terms of the Agreement and the Controller’s instructions documented in the Agreement and this DPA.
  4. Processor Obligations
    4.1 The Processor may collect, process or use Personal Data only within the scope of this DPA.4.2 The Processor confirms that is shall process Personal Data on behalf of the Controller and shall take steps to ensure that any natural person acting under the authority of the Processor who has access to Personal Data shall only process the Personal Data on the documented instructions of the Controller.4.3 The Processor shall promptly inform the Controller, if in the Processor’s opinion, any of the instructions regarding the processing of Personal Data provided by the Controller, breach any applicable data protection laws.4.4 The Processor shall ensure that all employees, agents, officers and contractors involved in the handling of Personal Data: (i) are aware of the confidential nature of the Personal Data and are contractually bound to keep the Personal Data confidential; (ii) have received appropriate training on their responsibilities as a data processor; and (iii) are bound by the terms of this DPA.4.5 The Processor shall implement appropriate technical and organisational procedures to protect Personal Data, taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons.

    4.6 The Processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: (i) the pseudonymisation and encryption of Personal Data; (ii) the ability to ensure the on-going confidentiality, integrity, availability and resilience of processing systems and services; (iii) the ability to restore the availability and access to Personal Data in a timely manner in the event of a physical or technical incident; (iv) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing. In accessing the appropriate level of security, account shall be taken in particular of the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to Personal Data transmitted, stored or
    otherwise processed.

    4.7 The technical and organisational measures detailed in Exhibit B shall be at all times adhered to as a minimum-security standard. The Controller accepts and agrees that the technical and organisational measures are subject to development and review and that the Processor may use alternative suitable measures to those detailed in the attachments to this DPA.

    4.8 The Controller acknowledges and agrees that, in the course of providing the Services to the Controller, it may be necessary for the Processor to access the Personal Data to respond to any technical problems or Controller queries and to ensure the proper working of the Services. All such access by the Processor will be limited to those purposes.

    4.9 Where Personal Data relating to an EU Data Subject is transferred outside of the EEA it shall be processed in accordance with the provisions of the Standard Contractual Clauses, unless the processing takes place: (i) in a third country or territory recognised by the EU Commission to have an adequate level of protection; or (ii) by an organisation located in a country which has other legally recognised appropriate safeguards in place, such as the EU-US Privacy Shield or
    Binding Corporate Rules.

    4.10 Taking into account the nature of the processing and the information available to the Processor, the Processor shall assist the Controller by having in place appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the Controller’s obligation to respond to requests for exercising the Data Subject’s rights and the Controller’s compliance with the Controller’s data protection obligations in respect of the processing of Personal Data.

  5. Controller Obligations
    5.1 The Controller represents and warrants that it shall comply with the terms of the Agreement,
    this DPA and all applicable data protection laws.5.2 The Controller represents and warrants that it has obtained any and all necessary permissions and authorisations necessary to permit the Processor, its Affiliates and Sub-Processors, to execute their rights or perform their obligations under this DPA.5.3 The Controller is responsible for compliance with all applicable data protection legislation, including requirements with regards to the transfer of Personal Data under this DPA and the
    Agreement.5.4 All Affiliates of the Controller who use the Services shall comply with the obligations of the Controller set out in this DPA.5.5 The Controller shall implement appropriate technical and organisational procedures to protect Personal Data, taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood andseverity for the rights and freedoms of natural persons. The Controller shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: (i) the pseudonymisation and encryption of Personal Data; (ii) the ability to ensure the on-going confidentiality, integrity, availability and resilience of processing systems and services; (iii) the ability to restore the availability and access to Personal Data in a timely manner in the event of a physical or technical incident; (iv) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing. In accessing the appropriate level of security account shall be taken in particular of the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to Personal Data transmitted, stored or otherwise processed.

    5.6 The Controller shall take steps to ensure that any natural person acting under the authority of the Controller who has access to Personal Data only processes the Personal Data on the documented instructions of the Controller.

    5.7 The Controller may require correction, deletion, blocking and/or making available the Personal Data during or after termination of the Agreement. The Processor will process the request to the extent it is lawful, and will reasonably fulfil such request in accordance with its standard operational procedures to the extent possible.

    5.8 The Controller acknowledges and agrees that some instructions from the Controller, including destruction or return of data, assisting with audits, inspections or DPIAs by the Processor, may result in additional fees. In such case, the Processor will notify the Controller of its fees for
    providing such assistance in advance, unless otherwise agreed.

  6. Sub-Processors
    6.1 The Controller acknowledges and agrees that: (i) Affiliates of the Processor may be used as Sub-processors; and (ii) the Processor and its Affiliates respectively may engage Subprocessors in connection with the provision of the Services.6.2 All Sub-processors who process Personal Data in the provision of the Services to the Controller shall comply with the obligations of the Processor set out in this DPA.6.3 Where Sub-processors are located outside of the EEA, the Processor confirms that such Subprocessors: (i) are located in a third country or territory recognised by the EU Commission to have an adequate level of protection; or (ii) have entered into Standard Contractual Clauses with the Processor; or (iii) have other legally recognised appropriate safeguards in place, such as the EU-US Privacy Shield or Binding Corporate Rules.6.4 The Processor shall make available to the Controller the current list of Sub-processors which shall include the identities of Sub-processors and their country of location. During the term of this DPA, the Processor shall provide the Controller with prior notification, via email, of any changes to the list of Sub-processor(s) who may process Personal Data before authorising any new or replacement Sub-processor(s) to process Personal Data in connection with the provision of the Services.
  7. Liability
    7.1 The limitations on liability set out in the Agreement apply to all claims made pursuant to any breach of the terms of this DPA.7.2 The parties agree that the Processor shall be liable for any breaches of this DPA caused by the acts and omissions or negligence of its Sub-processors to the same extent the Processor would be liable if performing the services of each Sub-processor directly under the terms of the DPA, subject to any limitations on liability set out in the terms of the Agreement.7.3 The parties agree that the Controller shall be liable for any breaches of this DPA caused by the acts and omissions or negligence of its Affiliates as if such acts, omissions or negligence had been committed by the Controller itself.7.4 The Controller shall not be entitled to recover more than once in respect of the same claim.
  8. Audit
    8.1 The Processor shall make available to the Controller all information reasonably necessary to demonstrate compliance with its processing obligations and allow for and contribute to audits and inspections.8.2 Any audit conducted under this DPA shall consist of examination of the most recent reports, certificates and/or extracts prepared by an independent auditor bound by confidentiality provisions similar to those set out in the Agreement. In the event that provision of the same is not deemed sufficient in the reasonable opinion of the Controller, the Controller may conduct a more extensive audit which will be: (i) at the Controller’s expense; (ii) limited in scope to matters specific to the Controller and agreed in advance; (iii) carried out during US or Belgian business hours and upon reasonable notice which shall be not less than 4 weeks unless an identifiable material issue has arisen; and (iv) conducted in a way which does not interfere with the Processor’s day-to-day business.8.3 This clause shall not modify or limit the rights of audit of the Controller, instead it is intended to
    clarify the procedures in respect of any audit undertaken pursuant thereto.
  9. Data Breach
    9.1 The Processor shall notify the Controller without undue delay after becoming aware of (and in any event within 72 hours of discovering) any accidental or unlawful destruction, loss, alteration or unauthorised disclosure or access to any Personal Data (“Data Breach”).9.2 The Processor will take all commercially reasonable measures to secure the Personal Data, to limit the effects of any Data Breach, and to assist the Controller in meeting the Controller’s obligations under applicable law.
  10. Compliance, Cooperation and Response
    10.1 In the event that the Processor receives a request from a Data Subject in relation to Personal Data, the Processor will refer the Data Subject to the Controller unless otherwise prohibited by law. The Controller shall reimburse the Processor for all costs incurred resulting from providing reasonable assistance in dealing with a Data Subject request. In the event that the Processor is legally required to respond to the Data Subject, the Controller will fully cooperate with the Processor as applicable.10.2 The Processor will notify the Controller promptly of any request or complaint regarding the processing of Personal Data, which adversely impacts the Controller, unless such notification is not permitted under applicable law or a relevant court order.10.3 The Processor may make copies of and/or retain Personal Data in compliance with any legal or regulatory requirement including, but not limited to, retention requirements.10.4 The Processor shall reasonably assist the Controller in meeting its obligation to carry out data protection impact assessments (DPIAs), taking into account the nature of processing and the information available to the Processor.10.5 The parties acknowledge that it is the duty of the Controller to notify the Processor within a reasonable time, of any changes to applicable data protection laws, codes or regulations which may affect the contractual duties of the Processor. The Processor shall respond within a reasonable timeframe in respect of any changes that need to be made to the terms of this DPA or to the technical and organisational measures to maintain compliance. If the parties agree that amendments are required, but the Processor is unable to accommodate the necessary changes, the Controller may terminate the part or parts of the Services which give rise to the noncompliance. To the extent that other parts of the Services provided are not affected by such changes, the provision of those Services shall remain unaffected.

    10.6 The Controller and the Processor and, where applicable, their representatives, shall cooperate, on request, with a supervisory data protection authority in the performance of their respective obligations under this DPA.

  11. Term and Termination
    11.1 The Processor will only process Personal Data for the term of the DPA. The term of this DPA shall coincide with the commencement of the Agreement and this DPA shall terminate automatically together with termination or expiry of the Agreement.11.2 The Processor shall at the choice of the Controller, upon receipt of a written request received within 30 days the end of the provision of the Services relating to processing, delete or return Personal Data to the Controller. The Processor shall in any event delete all copies of Personal Data in its systems within 60 days of the effective date of termination of the Agreement unless: (i) applicable law or regulations require storage of the Personal Data after termination; or (ii) partial personal data of the Client is stored in backups, then such personal data shall be deleted in the backups up 1 year after the effective date of termination of the Agreement.
  12. General
    12.1 This DPA sets out the entire understanding of the parties with regards to the subject matter herein.12.2 Should a provision of this DPA be invalid or become invalid then the legal effect of the other provisions shall be unaffected. A valid provision is deemed to have been agreed which comes closest to what the parties intended commercially and shall replace the invalid provision. The same shall apply to any omissions.

The parties agree that this DPA is incorporated into and governed by the terms of the Agreement.

Exhibit A

Overview of data processing activities to be performed by the Processor

  1. Controller The Controller transfers Personal Data identified in sections 3, 4 and 5 below, as it relates to the processing operations identified in section 6 below.
    The Controller is the Client.
  2. Processor
    The Processor received data identified in sections 3, 4 and 5 below, as it relates to the processing operations identified in section 6 below.
    The Processor is SPI.
  3. Data Dubjects
    The Personal Data transferred includes but is not limited to the following categories of Data Subjects:

    • Employees, freelancers and contractors of the Controller, and other users added by the Controller from time to time.
    • Authorised Users, Affiliates and other participants from time to time to whom the Controller has granted the right to access the Services in accordance with the terms of the Agreement.
      Service providers of the Controller.
    • Other individuals to the extent identifiable in the content of emails or their attachments or in archiving content.
  4. Categories of Data
    The Personal Data transferred includes but is not limited to the following categories of data:

    • Personal details, names, user names, passwords, email addresses of Authorised Users.
    • Personal Data derived from the Authorised Users use of the Services such as records and
      business intelligence information.
    • Personal Data within email and messaging content which identifies or may reasonably be used
      to identify, data subjects.
    • Meta data including sent, to, from, date, time, subject, which may include Personal Data.
    • Financial data.
    • Data concerning education and profession.
    • File attachments that may contain Personal Data.
    • Survey, feedback and assessment messages.
    • Information offered by users as part of support enquiries.
    • Other data added by the Controller from time to time.
  5. Special categories of Data
    No sensitive data or special categories of data are permitted to be transferred and shall not be contained
    in the content of or attachments to, emails.
  6. Processing operations
    The Personal Data transferred will be subject to the following basic processing activities:

    • Personal Data will be processed to the extent necessary to provide the Services in accordance with both the Agreement and the Controller’s instructions. The Processor processes Personal Data only on behalf of the Controller.
    • Processing operations include but are not limited to: competency assessments, learning plans and related training programs.
    • Technical support, issue diagnosis and error correction to ensure the efficient and proper running of the systems and to identify, analyse and resolve technical issues both generally in the provision of the Services and specifically in answer to a Controller query. This operation may relate to all aspects of Personal Data processed but will be limited to metadata where possible.
    • Virus, anti-spam and Malware checking in accordance with the Services provided. This operation relates to all aspects of Personal Data processed.
    • URL scanning for the purposes of the provision of targeted threat protection and similar service which may be provided under the Agreement. This operation relates to attachments and links in emails and will relates to any Personal Data within those attachments or links which could include all categories of Personal Data.

Exhibit B

Sales Performance International Information Security Management Program (ISMP)

Document Version: 1.2.1
This document describes the consolidated Information Security Management Program (ISMP).
Audience:

Purpose: This document is written to ensure that SPI employees and contractors act in accordance with the described security practices in order to protect SPI Client Data, SPI intellectual property, and to otherwise protect the information security of any data and systems operated by SPI. This ISMP is also written to ensure that SPI employees act in accordance with GDPR and specific Data Processing Agreements (DPAs) SPI has signed with SPI clients, but should also be used even when a given client is not subject to the GDPR.

Definitions:

Document structure:

  1. A. SPI-1 Platform Security Overview
  2. B. Policies for SPI Developers
  3. C. Policies for SPI Administrators

SPI-1 Platform Security Overview

Sections:

  1. Physical security: All data processing systems used in SPI-1 are housed with Amazon Web Services (AWS) in EU countries. These sites have very high security standards as described by AWS:“All data processing equipment which processes or uses Personal Data resides in the Amazon AWS Infrastructure. AWS provides physical data center access only to approved AWS employees. All employees who need data center access must first apply for access and provide a valid business justification. These requests are granted based on the principle of least privilege, where requests must specify to which layer of the data center the individual needs access, and are time-bound. Requests are reviewed and approved by authorized personnel, and access is revoked after the requested time expires. Once granted admittance, individuals are restricted to areas specified in their permissions.”
  2. Server security:
    1. a. All servers used in SPI run Ubuntu Linux LTS v 16.xx with:
      1. i. Tripwire installed for intrusion detection.
      2. ii. Password Authentication disabled.
      3. iii. Challenge/Response Authentication disabled.
      4. iv. AuthorizedKeys required for SSH, with each developer or devops person requiring unique public keys.
      5. v. Automatically applied security updates. Notifications are enabled for any security updates requiring reboot, and this is handled when notified.
    2. b. Only latest stable releases of approved software. The HTTP server itself is Nginx, with Passenger as the application server. All application stack components are set to run under non-root accounts.
  3. Cloud and Network security:
    1. a. IAM is required for any access to the AWS console.
    2. b. AWS CloudTrail is enabled and set to monitor for any violations.
    3. c. S3 security logs are enable and monitored.
    4. d. Root access requires two-factor authentication.
    5. e. Restrictive VPN settings in a restrictive VPC according to AWS best practices.
    6. f. Network traffic restricted to HTTPS over port 443 and SSH over port 22 (with
      a redirect from port 80 to port 443).
  4. Application security
    1. a. All Rails best practices for security are leveraged, including protection againstthe OWASP top 10 application security risks.
    2. b. All API calls require authentication and are funneled through a Pundit ACLlayer.
    3. c. All client data is segregated from any other client data by two systems – the first is account scoping within the application server, and the other is through use of cross-account link validations on all key models.
  5. Database security
    1. a. All databases use encryption at rest.
    2. b. Databases are configured to only allow access from within the VPC of the application servers.
    3. c. Databases all use the latest LTS Postgres DBMS.

Policies for SPI Developers

Document sections:

  1. Password guidelines
  2. Developer Security Policy
  3. Developer Offboarding Policy
  4. Production Security Policy
  5. Data Breach Response Policy

Password Guidelines:

  1. Unique identity: Each system or device that requires a password must use a password that is not shared with anyone else.
  2. All passwords must be strong. This means at least 8 characters, containing a mix of upper and lower case characters and at least 1 special character and at least 1 number.
  3. Passwords should not be written down or stored in an unencrypted manner anywhere.
  4. Passwords cannot:
    4.1. Contain less than eight characters.
    4.2. Be found in a dictionary, including foreign language, or exist in a language slang,dialect, or jargon.
    4.3. Contain personal information such as birthdates, addresses, phone numbers, ornames of family members, pets, friends, and fantasy characters.
    4.4. Contain work-related information such as building names, system commands, sites,companies, hardware, or software.
    4.5. Contain number patterns such as aaabbb, qwerty, zyxwvuts, or 123321.
    4.6. Contain common words spelled backward, or preceded or followed by a number (for example, terces, secret1 or 1secret).

Developer Security Policy:

  1. General guidelines
    1. 1.1. Developer hardware.
      1. 1.1.1. Operating systems. SPI Developers must use a secure operating system. This includes the current Ubuntu LTS and current version of OSX.
        1.1.2. Storage device encryption. All developer hardware (e.g. laptops, desktops, external drives) must use encryption for data storage. For OS X this means all drives must be Mac OS Extended, encrypted.
        1.1.3. Passwords. All devices must have passwords set and follow the password guidelines.
        1.1.4. All developer hardware must be kept physically safe from theft. In the event of theft of developer hardware the developer must inform management as soon as the theft is discovered.
        1.1.5. Any developer hardware that is to be disposed of, including giving it to another developer, must be securely wiped of any data before being disposed of. Shred is acceptable for Linux as long as the entire drive is wiped clean.
    2. 1.2. Email. Email is to be considered insecure at all times. Ssh keys, passwords, customer data and source code should not be transmitted via email.
  2. server access
    1. 2.1. Only developers with Dev ops responsibility or production support should have production server access.
      2.2. Production servers should control access through the documented SSH access guidelines.
      2.3. If a developer requires production ssh keys, another trusted developer will login to the server, generate a key uniquely for that developer, and add the new developer’s public key to AuthorizedKeys.
      2.4. Securely exchanging keys. If ssh keys or similar are created and need to be sent to a developer, Slack can be used. Directly paste the key into Slack instead of uploading a file, and delete the key once the receiver has acquired it. Do not use email to send keys.
  3. Source code
    1. 3.1. All source code must be maintained either on Developer Hardware or on a Secured server such as an EC2 instance or Github.com.
      3.2. All code in Github must be checked in by a developer individually (you cannot check in another developer’s code given to you outside of Github).
      3.3. All Github repos must be marked as private.
  4. Customer data
    1. 4.1. Any production data downloaded to a developer machine must adhere to the following rules:
      1. 4.1.1. DB snapshots must be transferred securely (SCP) from the production
        environment to the developer hardware.
        4.1.2. Customer data must not be copied from the developer hardware to any other
        devices that are not developer hardware.
        4.1.3. When testing is complete the customer data must be securely deleted using
        shred (Linux) or by using FileVault (OSX)
        4.1.4. Customer data must not be printed out or copied to paper.
        4.1.5. If customer data is medical or financial data it should not be copied to the
        developer machine at all, but should be tested against in the production mirror
        environment instead.
    2. 4.2. In general, it is preferable to test customer data in the production mirror
      environment rather than downloading data locally.

Developer Offboarding Policy:

In the event that a developer leaves the company or is no longer working on a project the following need to occur:

  1. The developer access to relevant Github repositories will be revoked (but any code will still be marked as developed by that developer).
  2. Access to any AWS Console related to the project will be revoked (via IAM).
  3. Access to any EC2 instances will be revoked by removal of their public keys from ssh.
  4. Access to Circle CI should be revoked. Access to purely monitoring systems such as HoneyBadger may be retained.
  5. Access to Trello for all projects may be retained if a developer has not left the company.

If the developer leaves the company, additionally:

  1. Access to the company Google drive must be revoked (and transferred to a manager)
  2. Access to email must be revoked.
  3. Access to Trello must be revoked.
  4. Access to HoneyBadger must be revoked.

Production Security Policy:

Below are technical policies that must be followed with regard to production systems:

  1. Linux servers (EC2)
    1. 1.1. AWS Security policies
      1. 1.1.1. Inbound traffic should generally be restricted to:
        1. 1.1.1.1. HTTP over 80
          1.1.1.2. HTTPS over 443
          1.1.1.3. SSH over 22
    2. 1.2. SSHD:
      1. 1.2.1. Servers should NOT allow:
        1. 1.2.1.1. PasswordAuthentication
          1.2.1.2. ChallengeResponseAuthentication
          1.2.1.3. PermitRootLogin yes (forced-commands-only is ok)
      2. 1.2.2. All SSH keys used on production servers should be 2048-bit SSH-2 RSA keys. Any public keys uploaded for access to servers (Authorized Keys) should be similarly constructed.
    3. 1.3. Security updates should be set to automatically apply.
    4. 1.4. Installation of software.
      1. 1.4.1. New software installed on servers will only be done by approval of the lead architect for the application or platform primarily used by the associated server.
        1.4.2. Only approved software is allowed to operate on the publicly available inbound ports listed above. The currently approved list includes:

        1. 1.4.2.1. Nginx 1.11.3 or higher. Acceptable plugins for Nginx include:
          1. 1.4.2.1.1. Passenger 5.0.x latest stable release
        2. 1.4.2.2. Apache2 2.4.x latest stable release
          1.4.2.3. JasperSoft Report Server (including Apache Tomcat) latest stable release
          1.4.2.4. OpenSSH 6.6.1 or greater with all patches
  2. Rails development specific policies:
    1. 2.1. All secure application configuration information should be stored only on the server
      itself in environment variables, and should NOT be in the secrets.yml file or stored in
      the repository.
      2.2. The secrets.yml file should reference linux env variables for production.
      2.3. User credentials must be encrypted with strong one-way encryption (Devise + bcrypt
      preferred).
      2.4. Strong user passwords should be enforced in applications.
      2.5. HTTPS must be required. Applications should be tested against SSLlabs tests.
      2.6. Pundit (or comparable ACL gem) must be used to enforce access policies.
  3. Database servers (RDS)
    1. 3.1. Servers should be set to only allow PostgreSQL (TCP) over 5432, and restrictinbound traffic to only include their common security group.
      3.2. Servers should use encryption.
      3.3. Server root password should only be stored securely in our main office location (and
      not used by the application).
      3.4. Server root password should be strong.
      3.5. Applications should have their own separate database user and password and not
      use the root database user.
      3.6. Auto Minor Version Upgrade should be enabled.

Data Breach Response Policy

In the event that any employee or contractor suspects a theft, breach, or exposure of any protected data, customer data, source code, or any infiltration of any server systems they must immediately contact information security at security@spisales.com . This e-mail address is
monitored by the Information Security team. This team will investigate all reported thefts, data breaches and exposures to confirm if a theft, breach or exposure has occurred. If a theft, breach or exposure has occurred, the Information Security Administrator will follow the appropriate procedures already in place.

Security Policies for SPI Administrators

Document audience, purpose and scope: This document is meant for SPI administrators and their managers and relates to security protocols for use with all SPI Client Data Processing Tools, including SPI-1 production environments. SPI-1 production environments means any environments that contain client data, such as US Production, EU Production, and Production Mirror.

This document is written to ensure that SPI-1 administrators act in accordance with GDPR and specific Data Processing Agreements SPI has signed with SPI clients, but should also be used even when a given client is not subject to the GDPR.

Definitions:

SPI Administrator: Any employee or contractor of SPI who handles client data.
Client Administrator: Any employee or representative of an SPI client who provides client data to SPI.
Client Data: Client Data means any data supplied to SPI by an SPI client. Examples of this might include the list of users to be added to an assessment or learning plans.
SPI Client Data Processing Tools: Any tools used by SPI Administrators to process or storeany Client Data. This includes but is not limited to SPI-1 and SPI Sales Process Playbooks.

  1. Who should have access to SPI-1 or other SPI Client Data Processing Tools?
  2. Securing your computer
  3. Access, Identity and Password guidelines
  4. Working with accounts and users
  5. Working with client data
  6. Offboarding clients
  7. Offboarding admins
  8. Reporting security issues
  1. Who should have admin access to SPI-1 or other SPI Client Data Processing Tools?
    1. a. Only employees and contract employees of SPI who are involved in actual administration of SPI-1 or other SPI client programs should have administrator credentials on SPI Client Data Processing Tools
      1. i. SPI CSG CSAs and CSMs qualify for admin access.
        ii. SPI Engineering team members generally qualify for admin access only if they are involved directly in Architecture, DevOps, or Project Management and QA related directly to the corresponding SPI Client Data Processing Tools.
        iii. SPI managers, executives, and sales people do not typically need admin credentials.
    2. b. All people who are granted access to SPI-1 need to sign the SPI Client Data Policy agreement.
  2. Securing your computer.
    1. a. The computer(s) you use for administration should itself be secured. It should:
        1. i. Have automatic updates enabled for operating system security patches.
          ii. Have a secure password or biometric security for access.
          iii. Have a “timeout” for access of no more than 5 minutes (meaning if you walk away from the computer it will be locked for access.
          iv. Be physically safe from theft or tampering.
          v. Only be used on secure Wifi networks attached to a secure network.

          1. 1. For example, on OSX, a secure Wifi network is shown as

        1. 2. A secure network would include the standard network at an SPI
          office location.