To gain access to Freshworks’ Information Security resources , please fill the below requested form. Our team will get back to you with the details.
If you have questions about features, trials, pricing, need a demo, or anything else, you may reach out to email@example.com (existing freshworks customers) or firstname.lastname@example.org (trial or prospective customers).
White-paper on Security @ Freshworks
Cloud Security Alliance- CAIQ
Independent Opinion on Freshworks’ control environment
Certification for Freshworks’ Information Security Management
The Information Security Steering Committee (ISSG) comprising of the executive leadership members sets the tone and drives the agenda for information security practices.
Information Security Initiatives: On a monthly basis, the ISSG takes stock of the various information security initiatives or projects and provide recommendations on the direction or resolves any roadblocks.
Information Security Expertise: Ensure that adequate expertise is available for all the information security initiatives. The ISSG provides the required technical inputs and ensures that Freshworks leverages from the guidance of necessary security mavens from internal and external sources.
Key Resource Allocation: Ensure that adequate people and financial resources are made available to various initiatives for effective execution.
Freshworks has developed a Risk Management Framework as part of the Information Security Management System (ISMS) in accordance with ISO/IEC 27001:2013 standard. The information security team assesses security risks annually and on an ongoing basis when major changes occur. The various feeder channels that are factored for risk management includes findings from audits, incidents, changing threat landscape, and changing contractual / regulatory.
Freshworks is aligned to and certified as per the ISO/IEC 27001:2013 standards. Also, Freshworks has been independently audited by one of the Big 4 global audit firms based on the SOC 2 Type II framework covering security, confidentiality and availability trust service principles. We are also certified under the Cyber Essentials framework and are registered with CSA STARwatch.
Freshworks partners with organizations, that like itself adhere to global standards and regulations. These organizations include sub-processors or third-parties that Freshworks utilizes to assist in providing its products.
Regular assessments are conducted on such service providers to ensure data is processed in a fair manner, and that data is processed only for purposes it was collected. Apart from evaluation for technical requirements, an examination for data protection measures, compliance with Freshworks’ security requirements and security audit report review is conducted before on-boarding the service provider. Various checks on the service provider’s vulnerability, patch management processes for intrusion protection capabilities in AWS environments are reviewed. Copies of access management process, third-party vulnerability testing reports, SOC2 reports, ISO 27001 reports, etc. are shared by the service partner, and reviewed by Freshworks. Provision for breach notification in the event of unwarranted data incidents, and necessary security measures for protection and recovery of data is made part of data processing agreements between such service providers and Freshworks.
Freshworks Network architecture is designed using a multi-tiered security framework with each tier complementing each other in providing a fault-tolerant architecture. All the services and data are hosted in a Virtual Private Cloud (VPC) and are mirrored across multiple availability zones.
The solution integrates with a set of external technology components as well and these are specifically called out as sub-processors. In addition, we provide API based integrations with 600+ apps in our marketplace or custom apps that are within our client's environment.
All our products are hosted in dedicated VPCs in non-promiscuous mode. The network has been further decoupled and has multiple security groups that reduces the surface of attack in case of any breach. Routing rules hardened are based on pre-established criteria for various permissible transactions across all resources. Freshworks uses a multi-tenant data model to host its customers and each customer is uniquely identified by a tenant ID. The application is engineered and verified to ensure that it always fetches data only for the logged-in tenant. Per this design, no customer has access to another customer’s data.
The security settings and configurations that are applied at server or application architecture apply to all the clients. Hardening is performed at network, application and database layers. All these are reviewed as part of the periodic security assessments and re-baselined annually based on an independent external assessment by a cyber security organization.
We have a 24x7 NOC (Network Operations Center) and SOC (Security Operations Center) that monitors various security events and patterns. We have tools that analyses traffic patterns and correlates network events.
All outbound network traffic is encrypted using FIPS-140-2 standard encryption over a secure socket connection for all accounts hosted on Freshworks. Instances are guarded by security groups which are further segregated by private subnets. All inbound HTTPS calls hit the reverse proxy that acts as the first level of application load balancer. The high availability zones are made resilient with AWS’s Elastic Load balancers.
Freshworks has a formal backup and recovery process. Application logs are backed up and are maintained for a duration of one year. Customers’ data is backed up in two ways:
A continuous backup is maintained in different datacenters to support a system failover if it were to occur in the primary datacenter. Should an unlikely catastrophe occur in one of the datacentres, businesses would lose only five minutes of data.
Data is backed up to persistent storage every day and retained for the last seven days.
Yes. System state snapshots of baselined configuration are created and saved using Amazon Machine Images (AMI). The AMIs are periodically updated and are used while creating new instances.
Yes. All backups are encrypted using AES 256-bit encryption with key strength of 1,024 bits and keys being managed through AWS Key Management Services (KMS).
We follow a uniform backup and retention schedule. By default, all data are retained for the data retention period in the Terms of Service at www.freshworks.com/terms and deleted thereafter. All data from encrypted backup servers are deleted within three months from termination of the account.
Freshworks has an in-built authentication module where it provides the ability for customers to define user names and assign access roles. Users can be authenticated using the authentication module within Freshworks products or can enable SSO. In case customers are using our own authentication module, the password rules for authentication can be customized covering password length, password complexity, and password history. In addition, customer can restrict support agents and customers who can login to their support portal to certain IP addresses.
Customers can configure our products to provide SAML Single Sign On for their end users. This way, the users do not have to provide separate login credentials for Freshdesk. The authentication of the user is done by any SAML provider such as Okta the customer configures on their end.
Our products also integrates with customer's ADFS server
By default, Freshworks offers a wildcard SSL for all users who have a support portal on a freshdesk.com domain. This can be used as long as you continue to use the default Freshdesk URL you signed up with (for example, yourcompany.freshdesk.com). However, the default SSL does not work when you've linked a custom domain name to your support portal (for example, support.yourcompany.com).
Freshworks has defined the Security incident management process to classify and handle incidents and security breaches. The Information Security team is responsible for recording, reporting, tracking, responding, resolving, monitoring, reporting, and communicating about the incidents to appropriate parties in a timely manner. The process is reviewed as part of periodic internal audit and is audited as part of ISO 27001 and SOC 2 Type II assessment.
We have processes established for early identification and reporting of incidents/breaches. The Information Security Office is responsible for internally coordinating with the relevant internal teams to ensure that the customers are reported about the incident / breach with any undue delay.
Different environments are in use for development and testing purposes, and access to systems are strictly managed, based on the principles of need to do/know basis as appropriate to the information classification, and with Segregation of duties built in, and reviewed on a periodic basis.
All accesses to the customer environment are approved by the reporting manager and product owner. Accordingly, access to the production environment is limited to a very limited set of authorized users that are outside of the development or testing teams. System access logs for access to customer data are maintained and are subject to review by a NOC and SOC team that operates on 24x7 basis. Procedures are established for periodic access recertification and timely access revocation in case of internal transfers and employment terminations.
Through the Risk Management framework, conflicting responsibilities are avoided or controlled while defining roles and responsibilities. An Identity and Access Management (IAM) solution has been defined to manage user access through role-based access profiles that support the implementation of accesses based on the principles of need to know basis and support segregation of duties. Privileges relating to Administration of user access privileges and role configurations are different from the authorized approver that approves access requests. The approvers are either the Product Heads or respective function Heads are their authorized delegates. Developers do not have access to the production environment (including no access to migrate changes). Access to migrate changes is limited to very limited number of designated and authorized individuals.
Yes. Privileged users are provided only with the elevated access that is required for their job function. Segregation of roles is in place for management operations to ensure there is a clear separation of roles based on applications.
Freshworks has a formal Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) defined and implemented to enable people and process support during any crisis or business interruptions. Appropriate roles and responsibilities has been defined and documented as part of the BC plan. Freshworks Information Security Office and respective Customer Manager will be responsible for communication and notification during a crisis.
The BCP and DR Plan is tested and reviewed on a yearly basis by Freshworks Information Security Officer and approved by the ISSG. On a yearly basis, training on BCP and DRP requirements are provided to all relevant employees involved in the process. The BCP and DR plan of Freshworks are reviewed and audited as part of ISO 27001 standards and SOC 2 Type II covering availability as one of the trust service principles.
Freshworks partners with organizations, that like itself adhere to global standards and regulations. These organizations include sub-processors or third-parties that Freshworks utilizes to assist in providing its products. Regular assessments are conducted to ensure continuity and availability of services.
We have formally agreed on and assessed the commitments with our service providers and perform periodic evaluation of our service providers as part of our Risk Management framework to ensure that our service providers support our BCP and DR commitments.
We have a highly resilient and fault tolerant architecture that is leveraged further from the disaster resilience provided by AWS.
AWS provides us with the flexibility to place instances and store data within multiple geographic regions as well as across multiple availability zones (AZ) within each region. Each AZ is designed as an independent failure zone. This means that AZ are physically separated within a typical metropolitan region and are located in lower risk flood plains (specific flood zone categorization varies by Region). In addition to discrete uninterruptible power supply (UPS) and onsite backup generation facilities, they are each fed via different grids from independent utilities to further reduce single points of failure. Availability zones are all redundantly connected to multiple Tier-I transit providers.
Data centers are built in clusters in various global regions. All data centers are online and serving customers; no data center is “cold.” In case of failure, automated processes move customer data traffic away from the affected area. Core applications are deployed in an N+1 configuration, so that in the event of a data center failure, there is sufficient capacity to enable traffic to be load-balanced to the remaining sites.
Following the principles of Security by Design, at Freshworks, products security is a blueprint and design consideration in every build cycle.
Our DevOps sprints are powered by a multi disciplinary Squad of members including the Product Owner, Squad Lead, Tribe Lead and Members, and Quality Assurance.
All changes are tested by the Quality Assurance team and criteria are established for performing code reviews, web vulnerability assessment, and advanced security tests.
Builds are put through a stringent functionality tests, performance tests, stability tests, and Ux tests before the build is certified "Good to go".
On an on-going basis also, the product goes through static and dynamic code reviews, OWASP risk reviews including code injections, clickjacking, XSS vulnerabilities etc., and technology landscape vulnerability reviews performed by the in-house white hat hackers and external cyber security organizations.
Source Code is managed centrally with version controls and access restricted based on various teams that are assigned to specific sprints. Records are maintained for code changes and commits.
We have dedicated instances for development, test and production instances. Access to the production environment is restricted to a limited set of authorized users based on their job responsibilities. Access to the production is restricted to very limited set of users based on the job roles. Access to the production environment for developers and Quality Assurance team members are restricted based on their job responsibilities.
Sorry, our deep-dive didn’t help. Please try a different search term.