Domains: Asset Classification and Control, Communications and Operations Management, Physical and Environmental Security, Information Security Incident Management.
1. Information Services (IS) Responsibility—All IS employees who come into contact with sensitive (Gorgias) internal information are expected to familiarize themselves with this data classification policy and to consistently use these same ideas in their daily (Gorgias) business activities. Sensitive information is either Confidential or Restricted information, and both are defined later in this document. Although this policy provides overall guidance, to achieve consistent information protection, IS employees are expected to apply and extend these concepts to fit the needs of day-to-day operations. This document provides a conceptual model for IS for classifying information based on its sensitivity, and an overview of the required approaches to protect information based on these same sensitivity classifications.
2. Addresses Major Risks - The IS data classification system, as defined in this document, is based on the concept of need to know. This term means that information is not disclosed to any person who does not have a legitimate and demonstrable business need to receive the information. This concept, when combined with the policies defined in this document, will protect (Gorgias) information from unauthorized disclosure, use, modification, and deletion.
3. Applicable Information - This data classification policy is applicable to all electronic information for which IS is the custodian.
1. Access Control
1.1 Need to Know—Each of the policy requirements set forth in this document are based on the concept of need to know. If an IS employee is unclear how the requirements set forth in this policy should be applied to any particular circumstance, he or she must conservatively apply the need to know concept. That is to say that information must be disclosed only to those people who have a legitimate business need for the information.
1.2 System Access Controls—The proper controls shall be in place to authenticate the identity of users and to validate each user’s authorization before allowing the user to access information or services on the system. Data used for authentication shall be protected from unauthorized access. Controls shall be in place to ensure that only personnel with the proper authorization and a need to know are granted access to (Gorgias) systems and their resources. Remote access shall be controlled through identification and authentication mechanisms.
1.3 Access Granting Decisions—Access to (Gorgias) sensitive information must be provided only after the written authorization of the Data Owner has been obtained. Access requests will be presented to the data owner using the Access Request template. Custodians of the involved information must refer all requests for access to the relevant Owners or their delegates. Special needs for other access privileges will be dealt with on a request-by-request basis. The list of individuals with access to Confidential or Restricted data must be reviewed for accuracy by the relevant Data Owner in accordance with a system review schedule approved by the VP, Director of Information Services and the AVP, Director of Risk Management.
2. Information Classification
2.1 Owners and Production Information—All electronic information managed by IS must have a designated Owner. Production information is information routinely used to accomplish business objectives. Owners should be at the VP level or above. Owners are responsible for assigning appropriate sensitivity classifications as defined below. Owners do not legally own the information entrusted to their care. They are instead designated members of the (Gorgias) management team who act as stewards, and who supervise the ways in which certain types of information are used and protected.
2.2 RESTRICTED—This classification applies to the most sensitive business information that is intended for use strictly within (Gorgias). Its unauthorized disclosure could seriously and adversely impact (Gorgias), its customers, its business partners, and its suppliers.
2.3 CONFIDENTIAL—This classification applies to less-sensitive business information that is intended for use within (Gorgias). Its unauthorized disclosure could adversely impact (Gorgias) or its customers, suppliers, business partners, or employees.
2.4 PUBLIC—This classification applies to information that has been approved by (Gorgias) management for release to the public. By definition, there is no such thing as unauthorized disclosure of this information and it may be disseminated without potential harm.
2.5 Owners and Access Decisions—Data Owners must make decisions about who will be permitted to gain access to information, and the uses to which this information will be put. IS must take steps to ensure that appropriate controls are utilized in the storage, handling, distribution, and regular usage of electronic information.
3. Object Reuse and Disposal
Storage media containing sensitive (i.e. restricted or confidential) information shall be completely empty before reassigning that medium to a different user or disposing of it when no longer used. Simply deleting the data from the media is not sufficient. A method must be used that completely erases all data. When disposing of media containing data that cannot be completely erased it must be destroyed in a manner approved by the Director of IS Security.
4. Physical Security
4.1 Data Center Access—Access to the data center must be physically restricted in a reasonable and appropriate manner.
4.2 Facility Access — All network equipment (routers, switches, etc.) and servers located in the corporate office and in all facilities must be secured when no (Gorgias) personnel, or authorized contractors, are present. Physically secured is defined as locked in a location that denies access to unauthorized personnel.
5. Special Considerations for Restricted Information
If Restricted information is going to be stored on a personal computer, portable computer, personal digital assistant, or any other single-user system, the system must conform to data access control safeguards approved by IS and Corporate senior management. When these users are not currently accessing or otherwise actively using the restricted information on such a machine, they must not leave the machine without logging off, invoking a password protected screen saver, or otherwise restricting access to the restricted information.
5.1 Data Encryption Software—(Gorgias) employees and vendors must not install encryption software to encrypt files or folders without the express written consent of IS Security.
6. Information Transfer
6.1 Transmission Over Networks—If (Gorgias) restricted data is to be transmitted over any external communication network, it must be sent only in encrypted form (Ex: using SSL and HTTPS). Such networks include electronic mail systems, the Internet, etc. All such transmissions must use a virtual public network or similar software as approved by the Information Security Team.
6.2 Transfer To Another Computer—Before any Restricted information may be transferred from one computer to another, the person making the transfer must ensure that access controls on the destination computer are commensurate with access controls on the originating computer. If comparable security cannot be provided with the destination system’s access controls, then the information must not be transferred.
7. Software Security
7.1 Secure Storage of object and source code—Object and source code for system software shall be securely stored when not in use by the developer. Developers must not have access to modify program files that actually run in production. Changes made by developers must be implemented into production by Technical Operations. Unless access is routed through an application interface, no developer shall have more than read access to production data. Further, any changes to production applications must follow the change management process.
7.2 Testing—Developers must at least perform unit testing. Final testing must be performed by the Quality Assurance team or the target user population.
7.3 Backups—Sensitive data shall be backed up regularly, and the backup media shall be stored in a secure environment.
8. Key Management
8.1 Protection of Keys—Public and private keys shall be protected against unauthorized modification and substitution.
8.2 Procedures—Procedures shall be in place to ensure proper generation, handling, and disposal of keys as well as the destruction of outdated keying material.
8.3 Safeguarding of Keys—Procedures shall be in place to safeguard all cryptographic material, including certificates. IS Security must be given copies of keys for safekeeping.
9. Data transit
9.1. Data into servers
All the incoming connections towards our servers are required to be encrypted with industry standard SSL encryption. Latest SSL Labs report can be found here. We also obfuscate (strip) sensitive information such as Credit Cards, IBAN, SSN and others before it reaches our main database.
9.2 Data between our servers
Connections between our servers (i.e. web servers <-> databases) are encrypted via TLS with a AES-256bit encryption method. Secrets such as database password, API secrets are encrypted using the same AES-256bit method.</->
9.3 Data out of our servers
Once the request is processed, the response is sent back using the same HTTPs SSL encrypted connection.
10. Data Security and Privacy
10.1 Data Encryption
All data in Gorgias servers is automatically encrypted at rest. Google Cloud Platform stores and manages data cryptography keys in its redundant and globally distributed Key Management Service. So, if an intruder were ever able to access any of the physical storage devices, the Gorgias data contained therein would still be impossible to decrypt without the keys, rendering the information a useless jumble of random characters.
Encryption at rest also enables continuity measures like backup and infrastructure management without compromising data security and privacy.
Gorgias exclusively sends data over HTTPS transport layer security (TLS) encrypted connections for additional security as data transits to and from the application. This data includes authentication credentials and other sensitive information.
10.2 Data Retention & Removal
Read more about our data lifecycle policy here.
10.3 PII removal
We recommend that users do not send any personally identifiable information (PII) to Gorgias. To mitigate accidents and other security risks, Gorgias offers server-side filtering as a default. We striping and obfuscating the incoming data such as Credit Card numbers, IBAN, SSN, etc...
10.4 Security Training
All new employees receive onboarding and systems training, including environment and permissions setup, formal software development training (if pertinent), security policies review, company policies review, and corporate values and ethics training.
All engineers review security policies as part of onboarding and are encouraged to review and contribute to policies via internal documentation. Any change to policy affecting the product is communicated as a pull request, such that all engineers can review and contribute before internal publication. Major updates are communicated via email to all employees.
10.5 Disclosure Policy
Gorgias follows the incident handling and response process recommended by SANS, which includes identifying, containing, eradicating, recovering from, communicating, and documenting security events. Gorgias notifies customers of any data breaches as soon as possible via email and phone call, followed by multiple periodic updates throughout each day addressing progress and impact.
10.6 Systems status live report
Gorgias maintains a live report of operational uptime and issues on our status page. Anyone can subscribe to updates via email from the status page. Any known incidents are reported there, as well as on our Twitter account.