SaaS Security Controls

Version 3.4

1. Introduction

1.1. Own Company software-as-a-service applications (SaaS Services) were designed from
the beginning with security in mind. The SaaS Services are architected with a variety of
security controls across multiple tiers to address a range of security risks. These security
controls are subject to change; however, any changes will maintain or improve the overall
security posture.

1.2. The descriptions of controls below apply to the SaaS Service implementations on both
the Amazon Web Services (AWS) and Microsoft Azure (Azure) platforms (together
referred to as our Cloud Service Providers, or CSPs), except as specified in the Encryption
section below. These descriptions of controls do not apply to RevCult software services
except as provided under “Secure Software Development” below.

2. Audits and Certifications

2.1. The SaaS Services are certified under ISO/IEC 27001:2013 (Information Security
Management System) and ISO/IEC 27701:2019 (Privacy Information Management
System).

2.2. Own Company undergoes an annual SOC2 Type II audit under SSAE-18 to independently
verify the effectiveness of its information security practices, policies, procedures, and
operations for the following Trust Services Criteria: Security, Availability, Confidentiality,
and Processing Integrity.

2.3. Own Company utilizes global CSP regions for its computing and storage for the SaaS.

3. Web Application Security Controls

3.1. Customer access to the SaaS Services is only via HTTPS (TLS1.2+), establishing the
encryption of the data in transit between the end-user and the application and
between Own Company and the third-party data source (e.g., Salesforce).

3.2. The customer’s SaaS Service administrators can provision and deprovision SaaS
Service users and associated access as necessary.

3.3. The customer’s SaaS Service administrators can access audit trails including
username, action, timestamp, and source IP address fields. Audit logs can be viewed
and exported by the customer’s SaaS Service administrator logged into the SaaS Services
as well as through the SaaS Services API.

3.4. Access to the SaaS Services can be restricted by source IP address.

3.5. The SaaS Services allow customers to enable multi-factor authentication for
accessing SaaS Service accounts utilizing time-based one-time passwords.

3.6. The SaaS Services allow customers to enable single sign-on via SAML 2.0 identity
providers.

3.7. The SaaS Services allow customers to enable customizable password policies to help
align SaaS Service passwords to corporate policies.

4. Encryption

4.1. Own Company offers the following SaaS Service options for encryption of data at
rest:

4.1.1. Standard offering

• Data is encrypted using AES-256 server-side encryption via a key management system validated under FIPS 140-2.
• Envelope encryption is utilized such that the master key never leaves the Hardware Security Module (HSM).
• Encryption keys are rotated no less than every two years.

4.1.2. Advanced Key Management (AKM) option

• Data is encrypted in a dedicated object storage container with a customer-provided master encryption key (CMK).
• AKM allows for future archiving of the key and rotating it with another master encryption key.
• The customer can revoke master encryption keys, resulting in the immediate inaccessibility of the data.
• The customer defines the encryption key policy that permits the customer’s SaaS Service account on AWS to access the key from the customer's own AWS KMS.

4.1.3. Bring Your Own Key Management System (KMS) option (available on AWS only)

• Encryption keys are created in the customer’s own, separately purchased account utilizing AWS KMS.
• The customer may instantly revoke access to the encrypted data by revoking Own Company’s access to the encryption key, without interacting with Own Company.
• Own Company employees have no access to the encryption keys at any time and do not access the KMS directly.
• All key usage activities are logged in the customer’s KMS, including key retrieval by the dedicated object storage.

4.2. Traffic between Own Company and Salesforce APIs is over HTTPS utilizing TLS 1.2+ and OAuth 2.0.

5. Network

5.1. The SaaS Services utilize CSP network controls to restrict network ingress and egress.

5.2. Stateful security groups are employed to limit network ingress and egress to authorized endpoints.

5.3. The SaaS Services use a multi-tier network architecture, including multiple, logically separated Amazon Virtual Private Clouds (VPCs) or Azure Virtual Networks (VNets), leveraging private, DMZs, and untrusted zones within the CSP infrastructure.

5.4. In AWS, VPC S3 Endpoint restrictions are used in each region to permit access only from the authorized VPCs.

6. Monitoring and Auditing

6.1. The SaaS Service systems and networks are monitored for security incidents, system health, network abnormalities, and availability.

6.2. The SaaS Services use an intrusion detection system (IDS) to monitor network activity and alert Own Company of suspicious behavior.

6.3. The SaaS Services use web application firewalls (WAFs) for all public web services.

6.4. Own Company utilizes security information and event management (SIEM) systems providing continuous security analysis of the SaaS Services’ networks and security environment, user anomaly alerting, command and control (C&C) attack reconnaissance, automated threat detection, and reporting of indicators of compromise (IOC). All of these capabilities are administered by Own Company’s local syslog server and a region-specific SIEM. These logs are automatically analyzed and reviewed for suspicious activity and threats.

6.5. Own Company’s incident response team monitors the security@owndata.com alias and responds according to the company’s Incident Response Plan (IRP) when appropriate.

7. Isolation Between Accounts

7.1. The SaaS Services use Linux sandboxing to isolate customer accounts’ data during processing. This helps to ensure that any anomaly (for example, due to a security issue or a software bug) remains confined to a single Own Company account.

7.2. Tenant data access is controlled through unique IAM users with data tagging that disallows unauthorized users from accessing the tenant data.

8. Disaster Recovery

8.1. Own Company uses CSP object storage to store encrypted customer data across multiple availability-zones.

8.2. For customer data stored on object storage, Own Company uses object versioning with automatic aging to support compliance with Own Company’s disaster recovery and backup policies. For these objects, Own Company’s systems are designed to support a recovery point objective (RPO) of 0 hours (that is, the ability to restore to any version of any object as it existed in the prior 14-day period).

8.3. Any required recovery of a compute instance is accomplished by rebuilding the instance based on Own Company’s configuration management automation.

9. Vulnerability Management

9.1. Own Company incorporates static code analysis, and external dynamic assessments as part of its continuous monitoring program to help ensure application security controls are properly applied and operating effectively.

9.2. Own Company's Disaster Recovery Plan is designed to support a 4-hour recovery time objective (RTO).

9.3. Vulnerability assessment results are incorporated into the Own Company software development lifecycle (SDLC) to remediate identified vulnerabilities. Specific vulnerabilities are prioritized and entered into the Own Company internal ticket system for tracking through resolution.

10. Incident Response

10.1. In the event of a potential security breach, the Own Company Incident Response Team will perform an assessment of the situation and develop appropriate mitigation strategies. If a potential breach is confirmed, Own Company will immediately act to mitigate the breach and preserve forensic evidence, and will notify impacted customers’ primary points of contact without undue delay to brief them on the situation and provide resolution status updates.

11. Secure Software Development

11.1. Own Company employs secure development practices for Own Company and RevCult software applications throughout the software development life cycle. These practices include static code analysis, Salesforce security review for RevCult applications and for Own Company applications installed in customers’ Salesforce instances, peer review of code changes, restricting source code repository access based on the principle of least privilege, and logging source code repository access and changes.

12. Dedicated Security Team

12.1. Own Company has a dedicated security team with over 100 years of combined multi-faceted information security experience. Additionally, the team members maintain a number of industry-recognized certifications, including but not limited to CISM, CISSP, and ISO 27001 Lead Auditors.

13. Privacy and Data Protection

13.1. Own Company provides native support for data subject access requests, such as the right to erasure (right to be forgotten) and anonymization, to support compliance with data privacy regulations, including the General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA). Own Company also provides a Data Processing Addendum to address privacy and data protection laws, including legal requirements for international data transfers.

14. Background Checks

14.1. Own Company conducts background checks on employees during the prior seven years, subject to applicable law.