Data Classification and Access Control Policy

Related links

Domains: Asset Classification and Control, Communications and Operations Management, Physical and Environmental Security, Information Security Incident Management.


1.  Information Services (IS) Responsibility—All 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, 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 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 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 employee 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 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 CTO.

2.  Information Classification

2.1 Owners and Production Information—All electronic information managed 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. This includes for example credentials or Gmail API access and refresh tokens.

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 CTO.

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 are secured when no (Gorgias) personnel, or authorized contractors, are present by physical locks and security alarms. 

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 the CTO.  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  the CTO.

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—When a pull request is initiated, our automated test suite is triggered to run against the new code.

7.3 Backups— Gorgias configures full, daily database backups for all data stored for us by our cloud services provider. If a database instance is deleted, all associated backups are also automatically deleted.

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. 

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.

9.2 Data between our servers

Connections between our servers are encrypted via TLS. The minimum acceptable TLS standard in use by the company is TLS v1.0

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 sensitive data in transit and at rest must be encrypted using strong, industry-recognized algorithms. Gorgias maintains approved encryption algorithm standards. Gorgias will not engage in “roll-your-own” encryption, algorithms, or practices and will not use “security through obscurity” within production infrastructure or applications.

Gorgias uses GCP resources to store and encrypt sensitive data. All GCP resources are encrypted at rest by default, using Google-managed keys. For specific services, encryption can also be configured to use customer-managed encryption keys using Cloud KMS or customer-supplied encryption keys.
GCP server-side encryption uses one of the strongest block ciphers available, 256-bit AdvancedEncryption Standard (AES-256) or 128-bit Advanced Encryption Standard (AES-128), to encrypt Gorgias data. 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.The minimum acceptable TLS standard in use by the company is TLS v1.0.

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

  • If you believe you’ve discovered a potential vulnerability, please let us know by emailing us at We will acknowledge your email within 24 hours.
  • Provide us with a reasonable amount of time to resolve the issue before disclosing it to the public or a third party. We aim to resolve critical issues within 24 hours of disclosure.
  • Make a good faith effort to avoid violating privacy, destroying data, or interrupting or degrading the Gorgias service. Please only interact with accounts you own or for which you have explicit permission from the account holder.

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.