Information Security and Compliance
Rubicon Holdings, LLC (“Rubicon”) is committed to information security and the protection of company and customer data. Rubicon believes security is the responsibility of everyone. Our Information Security Program focuses on the Security Trust Principle outlined by the American Institute of CPA’s (“AICPA”). Rubicon has successfully completed a SOC2 Type2 audit of the security program. The Type2 audit cast a spotlight on our SaaS solutions. Our program consists of several policies and controls focusing on access, asset management, internal audit and compliance, continuity, information communication, organizational management, risk management, software development and change management, and security operations. Rubicon ultimately considers information security to be the responsibility of everyone.
Rubicon understands the importance of demonstrating ethical values and integrity with a “Tone at the Top” mentality. Rubicon has established an employee handbook.
Rubicon’s Board of Directors is ultimately accountable for independent oversight of Rubicon operations and their responsibilities. The Board, through the Audit Committee, provides oversight of the internal controls described in this report.
Rubicon’s Executive Leadership Team (ELT) is focused on providing value to customers. Security is recognized as a critical component of the company. Controls for security are recognized as key enablers for the delivery of value to the customer.
The ELT is responsible for operational activities within Rubicon. To this end, management has developed a formal organization chart delineating roles and responsibilities, reporting lines, and delegation of authority relating to the design, implementation, and operations as part of the Information Security Program.
Rubicon utilizes a cloud-based platform to manage its Information Security Program.
The ELT recognizes that highly skilled people are critical to success. Controls have been developed to support hiring, retaining, and developing competent personnel. At least annually, performance and development of personnel are evaluated by management to confirm that they are capable to continue to fulfil their responsibilities. Additionally, security awareness training is completed at least annually.
A formal change management process is defined to control the design, development, testing and implementation of fixes and improvements to Rubicon applications and infrastructure.
Logging and monitoring tools are used to monitor system capacity and performance based on defined thresholds. Alerts are enabled for conditions or events that exceed these thresholds and are investigated and resolved timely.
Incident management policies and procedures as well as an incident response plan have been established and implemented.
Documented data backup and retention policies and processes exist and have been made available to guide the relevant staff in executing the controls over the process. Cloud-based solutions are utilized to take snapshots of critical application and system data and components. These snapshots are taken based on an automated schedule and stored in case of an outage.
Configuration and patch management processes are in place to confirm that systems are securely configured. Systems are scanned to detect non-compliant configurations. Anti-virus technology is deployed to workstations. Penetration tests are performed, and any issues identified are remediated in a timely manner.
Rubicon performs an annual risk assessment, which requires both the identification of risks and to implement appropriate measures to address those risks. The assessment process identifies risks related to security, fraud, regulatory, and technology changes. Identified risks along with mitigation strategies are documented and implemented by the organization.
Potential Third Parties are screened against specific risk factors based on the service(s) or product(s) being procured in accordance with Rubicon’s vendor management process. Existing vendors are evaluated based on performance and compliance with SLAs. Non-disclosures and confidentiality commitments are required to be signed by Third Parties whom Rubicon intends to engage with. Third Parties in which Rubicon conducts business with must be governed by a formal agreement.
Internal controls are reviewed at least annually. Controls are tested through an internal control assessment and identified deficiencies are addressed in a timely manner.
Complimentary Subservice Organization Controls (CSOC)
Rubicon’s security controls cover only a portion of the overall list of controls for each of Rubicon’s SaaS products. It is not feasible for the control objectives related to these products to be achieved solely by Rubicon. Therefore, each entity’s controls must be evaluated in conjunction with Rubicon’s security controls, considering the related Complementary Subservice Organization Controls (CSOC’s) expected to be implemented at the subservice organization as described below.
Cloud Computing Service Provider(s): Rubicon utilizes subservice organizations for Cloud Computing Services (“cloud providers”). These cloud providers are responsible for providing physical and environmental security controls, access to its systems, infrastructure, and other applicable components, and incident response related to security incidents. Cloud providers are responsible for segregating Rubicon’s environments from other customers. The cloud providers document all areas of responsibility. Rubicon reviews the cloud providers’ security documentation as part of the company’s Third-Party Vendor Management policy and controls.
CSOCs are controls that Rubicon assumes will be implemented by the subservice organization as it is necessary to achieve one or more of the Trust Services Criteria stated in this report. The subservice organization significant to Rubicon services, including the applicable trust services criteria that are intended to be met by controls at the subservice organization in combination with controls at Rubicon, are as follows:
*Note: the listing presented below should not be regarded as a comprehensive list of all controls that should be employed by this or any other subservice organization
|Control Activities Expected to be Implemented by Cloud Providers||Applicable Trust Criteria|
|Cloud providers are responsible for restricting logical and physical access to data center facilities, backup media, and other system components including firewalls, routers, and servers.||CC6.1, CC6.2, CC6.3, CC6.4, CC6.5, CC6.6, CC6.7, CC6.8, CC9.2|
|Cloud providers are responsible for implementing measures to prevent or mitigate threats consistent with the risk assessment. Additionally, cloud providers are responsible for evaluating the impact of a security incident, communicating the incident to impacted clients, remediating against incidents, and working towards prevention of future incidents.||CC3.1, CC3.3, CC4.1, CC4.2, CC6.3, CC6.8, CC7.2, CC7.3, CC7.4, CC7.5, CC9.1, CC9.2|
|Cloud providers are responsible for maintaining segregation of client environment(s) from other provider clients.||CC6.1, CC6.6|
|Cloud providers are responsible for maintaining the integrity of system logs and their associated configurations. Cloud providers must also monitor system components and operations to identify security incidents (both suspected and actual), in addition to indications of natural disasters.||CC5.3, CC7.1, CC7.2, PI1.4|
|Cloud providers are responsible for demonstrating integrity and ethical values and actions in relation to its operations and with clients.||CC1.1|
|Cloud providers are responsible for demonstrating independent governance and oversight from management. Cloud providers are responsible for holding individuals at all levels accountable for their operating and security controls. Cloud providers are also responsible for the management of any third-party vendors with access to customer environments.||C1.2, C1.3, C1.4|
|Cloud providers are responsible for communicating with clients (as needed) regarding matters affecting functionality and security and operating controls.||CC2.3|
|Cloud providers are responsible for identifying changes that could significantly impact the system of security controls, including the effects, both positive and negative, on its clients.||CC3.4, CC8.1|
|Cloud providers are responsible for monitoring environmental conditions (temperature, fire, and water), leak detection, UPS battery life and capacity, and other key equipment to help maintain the availability of services.||A1.2|
|Cloud providers are responsible for the backup and recovery of data in their environment and to notify Rubicon of any issues regarding the availability or integrity of their backup data.||A1.2|
Complimentary User Entity Controls (CUEC)
Rubicon’s security controls cover only a portion of the overall list of controls for each of Rubicon’s SaaS products. It is not feasible for the control objectives related to these products to be achieved solely by Rubicon. Therefore, each entity’s controls must be evaluated in conjunction with Rubicon’s security controls, considering the related Complementary User Entity Controls (CUEC’s) expected to be implemented at the client organization as described below.
|Complementary User Entity Controls||Related Trust Criteria|
|Clients are responsible for demonstrating a commitment to integrity ethical values and action, and confidentiality. Clients hold individuals at all levels within their organization accountable for control responsibilities in pursuit of business objectives and security.||CC1.1, CC1.3, CC1.5|
|Clients are responsible for reviewing and acting upon notification (as needed) of Rubicon’s communication regarding system changes, maintenance windows, or other matters impacting the security.||CC2.2, CC2.3|
|Clients are responsible for processing data and accuracy of such data in accordance with their corporate confidentiality policies. Additionally, clients are responsible for implementing general controls over access and activities to SaaS product(s).||CC3.2, CC5.2, CC5.3|
|Clients are responsible for assigning usernames and passwords to authorized users, activating MFA if deemed necessary; and maintaining the confidentiality of login credentials.||CC6.1|
|Clients are responsible for periodically reviewing end users’ access to the SaaS product(s) for validity and appropriateness and making corrective changes within a timely manner.||CC6.2, CC6.3|
|Clients restrict transmission, movement, and removal of client information as needed and are responsible for issuing best practices in the creation and transmission of client data.||CC6.7|
|Clients are responsible for granting physical access to facilities and protected information assets.||CC6.4, CC6.5|
|Clients are responsible for deploying security controls related to their operation to both protect against and detect security incidents, in addition to acting upon security incidents be it suspected or actual.||CC6.8|
|Clients are responsible for monitoring operations and operating data to identify anomalies and indications of security incidents, natural disasters, etc.||CC7.2|
|Clients must evaluate suspected or actual security incidents and act upon incidents to remediate and resolve against the incident and prevent future incidents of similar nature.||CC7.3, CC7.4, CC7.5|
Rubicon’s Service Availability (“SA”) commitment for a given calendar month is 99.5%. this commitment is calculated as stated below:
SA = (Total Time – Unplanned Outage – Planned Maintenance) / (Total – Planned Maintenance) X 100
These values listed in the formula above are defined as follows:
- Total time is the total minutes in the month
- Unplanned Outage is total minutes unavailable due to an unplanned outage in the month
- Planned Maintenance is total minutes of planned maintenance in the month. Currently, Planned Maintenance is four (4) hours for weekly maintenance, four (4) hours for monthly maintenance, four (4) hours for quarterly maintenance. Rubicon’s current weekly maintenance begins at 10 pm (Eastern) on Fridays; monthly maintenance begins at 02:00 am (Eastern) on Saturday; and quarterly maintenance begins at 06:00am (Eastern) on Saturday. All times are subject to change upon reasonable notice. If actual maintenance exceeds the time allotted for Planned Maintenance, it is considered an Unplanned Outage. If actual maintenance is less than time allotted for Planned Maintenance, that time is not applied as a credit to offset any Unplanned Outage time for the month. The measurement point for Service Availability is the availability of the Rubicon Service. Client may request an availability report once per month.
As it relates to Disaster Recovery (DR), Rubicon commits to a Recovery Time Objective (RTO) of twelve (12) hours—measured from the time that the Rubicon Service becomes unavailable until it is available again. Rubicon commits to a Recovery Point Objective (RPO) of one (1) hour—measured from the time that the first transaction is lost until the Rubicon Service became unavailable.