Pepper Cloud Security

At Vodori, we take security seriously. Our software, infrastructure, operations, and HR policies are all designed to keep your data safe while adhering to industry best practices and standards. We believe in developing quality software while also promoting transparency around how we keep your data secure so you can focus on utilizing Pepper Cloud products to transform your business.

Compliance & Regulations

Vodori has decades of experience working in and developing software for life sciences. We know that your business depends on secure company and customer data, protected in compliance with applicable laws. Vodori’s rigorous compliance program covers data security, SDLC and infrastructure, risk management, and how we select and assess our vendors.

soc-2-compliant-logo   gdpr image


Vodori regularly completes a third party SOC 2 Type II audit for the security, availability, and confidentiality principles, demonstrating Vodori’s commitment to our customers’ data security and privacy. To obtain a copy of this report, please contact your Customer Success Manager or Vodori Account Executive.


Vodori processes data in compliance with EU General Data Protection Regulations (GDPR), adhering to comprehensive internal privacy and security practices to ensure compliance, including:

  • employee security and data privacy training program,
  • contract transparency,
  • vendor data privacy, compliance, and risk assessment,
  • process for handling data information requests,
  • data collection, consent, and retention policies, and 
  • data breach response plan.

ISO 27001 Compliant Data Centers

Vodori partners with Amazon Web Services (AWS), a SOC 2 Type II and ISO 27001 certified data center providing a high degree of availability and security for Pepper Cloud. AWS’s SOC 2 and ISO 27001 compliance requirements ensure systematic evaluation of risks, threats, and vulnerabilities through a set of established controls.

GxP & FDA 21 CFR Part 11: Compliance and Software Validation

Pepper Cloud is validated for its intended use, in accordance with FDA regulations. The software meets specific requirements for the use of electronic records and the capture of electronic signatures (i.e., FDA 21 CFR Part 11), and is in compliance with other applicable industry standards and good practice guidelines (GxP). Our rigorous validation program was designed by experts with years of experience; our SOC 2 report includes testing of controls supporting our validation processes.

How We Keep Your Data Safe

Data Storage & Encryption

Data Storage and Encryption at Rest
The Pepper Cloud architecture is designed to keep your data safe and secure. Pepper Cloud uses:

  • a redundant, fault-tolerant, MongoDB database that is deployed across multiple availability zones, and
  • Amazon’s highly available and highly redundant S3 storage service.

Relational data in MongoDB is partitioned by both customer and application with dedicated credentials. Our MongoDB data volumes are encrypted at rest using AWS Elastic Block Store (EBS) (see below). Network communication between Pepper Cloud and MongoDB is encrypted.

Customer binary data is stored in customer-specific S3 buckets with dedicated access credentials. Data stored in S3 is encrypted at rest using a customer-specific encryption key and AES-256 encryption. Network communication between Pepper Cloud and S3 is encrypted.

Across the Pepper Cloud physical infrastructure, we encrypt data at rest using AWS Elastic Block Store (EBS) which uses AES-256 encryption. EBS encrypts:

  • data at rest inside the volume,
  • all data moving between the volume and the instance, and
  • all snapshots created from the volume.

Pepper Cloud uses AWS Key Management Services (KMS) which provides unique keys for each customer to encrypt:

  • the credentials for each MongoDB database used to store customer data,
  • the credentials for each S3 bucket used to store customer data,
  • OAuth2 credentials used for authentication between applications,
  • sensitive configuration values (such as external authentication provider credentials), and
  • customer data.

Pepper Cloud uses BCrypt, a strong one-way hashing algorithm with unique salts, to store user passwords. These passwords are not recoverable by inspection of the data and are only ever known to the end user.

Data Encryption in Transit
All communication between you and Pepper Cloud is encrypted via HTTPs using TLS v1.2. Additionally, all data exchanged between internal services is also encrypted.

User Authentication
Applications requiring authentication (including mobile applications) delegate responsibility to the Pepper SSO through the use of the OAuth2 authentication protocol with the authorization code grant type. The Pepper SSO may be configured to further delegate authentication to enterprise identity providers.

Once a user is authenticated, applications making service calls to other applications use a cryptographically signed short-lived access token issued by the Pepper SSO. The access token encapsulates the permissions of both the authenticated user and the originating application.

SAML & OAuth2 Based SSO
Pepper Cloud’s SSO is based on industry standards SAML and OAuth2/OpenIDC for managing user authentication. Our SSO is able to integrate with third-party SSO providers such as: Microsoft Azure Active Directory, Google Apps, Ping Federate, Auth0, and Okta.

Network Protection

Web Application Firewall (Threat Detection & Intrusion Detection)
Vodori uses a Web Application Firewall (WAF) to protect against cyberattacks. Our WAF is integrated with AlertLogic, a managed 3rd party Intrusion Detection System (IDS) and Intrusion Protection System (IPS) that is deployed between public traffic and our applications to continuously monitor network traffic and report and block suspicious activity. If suspicious activity is identified, it is logged and escalated to Vodori’s Security Team.

Security Groups
Vodori uses AWS Security Groups for stateful firewalling to ensure that only the appropriate traffic is allowed between systems within AWS.

Secure Headers
Pepper Cloud uses browser protections such as HTTP Strict Transport Protection.

Storage Device Decommissioning

When a storage device has reached the end of its useful life, AWS procedures include a decommissioning process designed to prevent customer data from being exposed to unauthorized individuals. AWS uses techniques detailed in DoD 5220.22-M (National Industrial Security Program Operating Manual ) or NIST 800-88 (Guidelines for Media Sanitization) to destroy data as part of the decommissioning process, with magnetic storage devices being degaussed and physically destroyed in accordance with industry-standard practices.

Data Retention

Pepper Cloud does not archive or purge any information stored in the system unless requested by the customer.

Standard Operating Procedures

Access to Data at AWS
Access to customer data by Vodori is restricted to only authorized Vodori personnel. All production data access at AWS is logged and reviewed on a regular basis.

Access to Data in Pepper Cloud
To best support our customers and end-users, the following teams have access to each customer-assigned Pepper Cloud environment:

  • Customer Success Manager(s)
  • Implementation Specialist(s)
  • Support Analyst(s)

Customers are able to view, report, and modify this access using Pepper Cloud’s User Management solution. Data is not stored or retained by Vodori employees.

Regular Updates / Patch Management
All patches are downloaded and tested on non-production servers monthly prior to installation in production. Deployment into production is scheduled based on the results of testing patches in non-production environments. Patches are evaluated based upon security risk, benefit to the system, and danger to overall network.  Patches and hotfixes deemed necessary are installed within thirty (30) days of release or notification. Critical patches are applied within 72 hours. Non-critical patches are applied during the monthly network maintenance window.

Physical Security
Physical access at AWS is strictly controlled both at the perimeter and at building access points by trained security staff utilizing video surveillance, intrusion detection systems, and other electronic systems. Read more on AWS physical security.

Vodori employees do not have physical access to data centers. Access to Vodori offices is granted only to authorized individuals and is physically protected by key fob, which is required at all entrances.

Encryption Policy

  • All laptops, workstations, and portable devices that store or access Vodori protected or customer data are encrypted.
  • Electronic transfer of Vodori protected and customer data is transferred via an encrypted channel (SSL, SFTP, VPN).
  • Any physical transfer (e.g. DVD) of customer data is also encrypted.

Access Control Policy
Vodori institutes the following access controls, which are designed to minimize potential exposure resulting from unauthorized use of resources and to preserve and protect the confidentiality, integrity and availability of the networks, systems and applications:

  • Employee access to systems is restricted based on need.
  • Access is through named accounts with separately provisioned accounts for administrative access.
  • Access to systems is logged.
  • No unapproved devices may access the Vodori network.
  • Segregation of duties ensures that proper authorization is performed prior to access.

Antivirus Policy
Vodori requires antivirus software on all operating systems to improve the overall security of Vodori-managed networks.

Computer Security Policy
Vodori has established standards for computer security to protect against unauthorized access to employee computers. This policy includes requirements for computer locking, compliance with encryption and password policies, staying current with operating system patches, and computer decommissioning.

How We Maintain Performance and Reliability

AWS Partnership

Pepper Cloud is hosted at Amazon Web Services (AWS), who maintains compliance with globally recognized auditing standards including SOC 1/2/3 and ISO 9001/27001/27017/27018.

Microservices & Kubernetes

Kubernetes is a cluster orchestration software that schedules containers onto compute resources and manages the container runtime and networking to achieve high availability. Kubernetes is used to manage the scheduling of containers across virtual machines to spread system load, provide fault tolerance, enable automatic restarts, and to manage rolling deployments of new releases. Virtual machines participating in the cluster are spread across multiple availability zones to provide continued availability in case of issues with a single zone.

Pepper Cloud is built using loosely coupled microservices with an architecture design pattern that provides:

  • rapid delivery of new capabilities to customers through a validated process,
  • reduced total cost of ownership to Vodori and its customers,
  • multiple layers of security to protect customer data,
  • efficient resource usage, and
  • future innovation with minimal dependencies.

Distributed Denial of Service (DDOS) Protection

Pepper Cloud is protected from DDOS attacks by leveraging AWS Web Application Firewalls (WAF), AWS Load Balancers, and AlertLogic’s fully managed security service who monitor and tune the Web Application firewall 24x7x365.


Application clusters are deployed across multiple availability zones to provide continued availability.


Backups of customer data occur at least daily, are stored in secure data centers, and are encrypted at rest using the customer-specific encryption key using AES-256 encryption. Backups are stored in separate S3 bucket, which automatically replicates data across multiple data centers. Backup restoration procedures are routinely tested.

Monitoring, Logging, and Reporting

Sentry is a software solution that provides real-time error tracking to give Vodori’s Infrastructure and Product Teams insight into production deployments and information to reproduce and fix errors.

Pepper Cloud applications are configured to send critical errors for review and triage by the Infrastructure and Product Teams. Issues that get addressed in future releases of the product are tracked as part of Vodori’s SDLC and release notes. 

Each application within Pepper Cloud implements health checks that return information about the application’s availability. The Kubernetes orchestration layer monitors each application’s health check and will restart an application if the health check fails in an attempt to restore service. Vodori’s Engineering Teams are notified of this event.

Vodori also utilizes a digital intelligence platform allowing product and infrastructure engineers to measure and monitor the performance of Pepper Cloud applications and infrastructure.

Disaster and Data Recovery

Vodori has a standard operating procedure for disaster and data recovery that is practiced biannually. Results of the disaster recovery procedures are documented and preserved according to the Vodori data retention policy, with a postmortem report made available to customers on an annual basis.

Vodori operates with a Recovery Point Objective (RPO) of 4 hours and a Recovery Time Objective (RTO) of 24 hours.

How We Keep Our Code Secure

Secure Software Development & SDLC

Vodori has designed and implemented a secure software development life cycle (SDLC) based on GxP guidelines which integrates security best practices from start to finish, ensuring that Pepper Cloud and your data is always secure. 

  • Comprehensive security and penetration scans are performed using a third-party toolset prior to completion of each product release — at compile time and runtime.  
  • All issues identified by the tools are reviewed and appropriately mitigated before the release is promoted to production.
  • We build our products using the “Security by Design” principles, a process and mindset that anticipates security features through the entire development process.
  • Passwords, access tokens, and sensitive configuration files are not stored in Vodori’s Version Source Control (VCS) system.
  • All production builds of Vodori software have integrated code and framework dependency security checks that fail builds for any Critical or High reported concerns. 
  • Vodori engineers develop using test data and do not use production customer data.
  • Applications do not log user sensitive information such as passwords, access tokens, or any other information which could lead to an account or system being compromised.

Code Peer Review

Vodori requires all code merged into production code branches be reviewed and approved via a Pull Request and that code reviews follow Vodori’s Code Reviews standards.

Quality Assurance (QA)

Quality Assurance is integrated into our process, from individual code changes all the way through preparing a release for our customers. Each feature or change developed in Pepper Cloud is tested using a combination of unit, integration, and regression test scripts as appropriate. All releases of Pepper Cloud undergo rigorous regression and security testing prior to release. 

Vodori tests in a separate test environment, within a separate AWS account, to ensure that production and customer data is separated from test data.

Vulnerability Management

Each day, new threats and vulnerabilities are discovered. To protect your data against external attackers, we’ve designed and implemented a strict vulnerability management process into our SDLC.

All builds of Pepper Cloud include a constantly updated integrated code and framework dependency security check. If there are any reported critical or high issues, Pepper Cloud will not build or deploy. Vulnerabilities identified as medium- or low-risk will be reviewed and addressed as needed. Further, all of our dockerized microservices are security scanned to ensure bundled middleware is not susceptible to known security issues. Pepper Cloud builds will fail for any CRITICAL or HIGH issues reported via container scanning.

Software Release Process

In preparation for a release, Vodori prepares the internal Release Notes and the Release Checklist to facilitate the release process. Release Notes describe the purpose for the release, outline the changes being made in the release, include the associated tickets, and provide any other important context. The Release Checklist describes detailed steps needed to perform the changes in the target environment.

All development tickets are systematically associated to a specific release, and upon completion of all tickets for a particular release, the release branch can be created. The release branch segregates all code for that particular release, which can then be deployed to the target environment.

The System Owner, Quality Assurance team, and Infrastructure Team meet to review the Release Checklist to ensure it is clear, complete, and accurate. 

After a release branch has been created, a security scan is executed to identify and report any security risks that exist within the application code. All releases performed by Vodori must pass a security scan, or have a formal exception granted, before the code can be deployed to a validation or production environment.

When the scan is complete and all vulnerabilities resolved, a code freeze is placed on the release branch. No changes may exist in a release that were not present during the security scanning process and execution of validation. Should additional changes be needed for any reason, a new scan must be executed or an exception must be granted.

Once the code freeze is effective, validation testing is executed according to the Software Validation Procedures.

Have additional questions about Pepper Cloud Security?

Contact Us