PRIVILEGED AND CONFIDENTIAL — ATTORNEY-CLIENT COMMUNICATION
MEMORANDUM
TO: Rachel Bernstein, Partner, Privacy & Data Security, Calderwood & Harkness LLP Diana Kowalski, Chief Privacy Officer, Vantage Mobility Systems Corp.
FROM: Alan Burke, Senior Associate, Privacy & Data Security, Calderwood & Harkness LLP
DATE: November 10, 2022
RE: Sub-Processor Risk Analysis — Cloudvault Infrastructure, Inc. (Proposed Sub-Processor for Meridian Telematics Solutions, Inc.)
MATTER NO.: 1007-00007
CLIENT: Vantage Mobility Systems Corp.
Right-click to update Table of Contents
I. Executive Summary
The purpose of this memorandum is to evaluate Cloudvault Infrastructure, Inc. ("Cloudvault") as a proposed sub-processor under the Data Processing Agreement ("DPA") currently being negotiated between our client, Vantage Mobility Systems Corp. ("VMS"), and Meridian Telematics Solutions, Inc. ("Meridian"). This analysis has been prepared at the request of Diana Kowalski, Chief Privacy Officer of VMS, and under the supervision of Rachel Bernstein, Partner in Calderwood & Harkness LLP's Privacy & Data Security practice group.
Cloudvault is a Nevada corporation headquartered at 200 Mill Street, Suite 100, Reno, NV 89501, that provides cloud hosting and data storage services to enterprise clients, with a particular emphasis on the automotive and mobility technology sectors. Meridian has proposed using Cloudvault's proprietary "AutoCloud" platform to host and process the vehicle telemetry and in-cabin sensor data that VMS would provide to Meridian under the connected-vehicle data-sharing partnership contemplated by the parties' non-binding Letter of Intent dated August 5, 2022.
This memorandum undertakes the following analyses:
(a) profiles Cloudvault as an entity and evaluates its relationship with Meridian;
(b) analyzes the scope and nature of VMS data that Cloudvault would process, including the sensitivity classification of certain data categories under VMS's internal data governance policy;
(c) evaluates Cloudvault's data center infrastructure, including current and proposed future processing locations;
(d) assesses the competing sub-processor approval models proposed by VMS (prior written consent) and Meridian (general authorization with a 30-day objection window) in the ongoing DPA negotiations;
(e) recommends a hybrid tiered approval mechanism designed to balance VMS's data protection interests with Meridian's operational flexibility requirements;
(f) addresses flow-down contractual obligations that should be imposed on Meridian with respect to its sub-processor agreements, including the Meridian-Cloudvault Master Services Agreement; and
(g) discusses audit rights vis-à-vis sub-processors and recommends a layered audit framework.
Overall Recommendation: Based on the analysis set forth herein, Cloudvault appears to be an acceptable sub-processor subject to the implementation of specific contractual safeguards and flow-down obligations as described in this memorandum. VMS should insist on the hybrid tiered approval model described in Section VI as its negotiating position in upcoming discussions with Whitfield, Barrow & Crane LLP ("WBC"), Meridian's outside counsel. However, VMS's final assessment of Cloudvault's adequacy remains contingent upon: (i) review of the existing Meridian-Cloudvault Master Services Agreement; (ii) receipt and evaluation of Cloudvault's SOC 2 Type II report or equivalent third-party security certification; and (iii) the findings of Pinehurst Cybersecurity Advisors LLC's ("Pinehurst") forthcoming security assessment of Meridian's data processing environment, which we recommend be expanded to specifically cover Cloudvault's AutoCloud platform and Columbus, Ohio data center.
II. Background
A. The VMS-Meridian Data-Sharing Partnership
VMS and Meridian executed a non-binding Letter of Intent ("LOI") on August 5, 2022, setting forth the framework for a connected-vehicle data-sharing partnership. Under the contemplated partnership, Meridian would receive and process vehicle telemetry and in-cabin sensor data generated by VMS's connected-vehicle fleet to develop derivative analytics products for the automotive, insurance, urban planning, and fleet management markets.
The data subject population encompasses approximately 800,000 opted-in vehicles equipped with VMS's proprietary "VantageLink" telematics hardware and software platform. These 800,000 vehicles represent a subset of VMS's total connected-vehicle install base of approximately 2.4 million vehicles, and specifically comprise those vehicle owners and lessees who have affirmatively enrolled in VMS's "Connected Insights" data-sharing program. The Connected Insights program is governed by VMS's consumer-facing privacy notice and data-sharing consent flow, which were last updated on June 15, 2022, and which Calderwood & Harkness reviewed in a separate advisory engagement earlier this year.
Fourteen (14) categories of vehicle telemetry and in-cabin sensor data are within the scope of the proposed data-sharing arrangement:
1. GPS/geolocation data
2. Vehicle speed
3. Acceleration/deceleration metrics
4. Braking events
5. Tire pressure readings
6. Engine diagnostic codes (OBD-II)
7. Fuel consumption data
8. In-cabin temperature
9. In-cabin humidity
10. Seat occupancy data
11. Seatbelt status
12. Ambient noise levels
13. Windshield wiper activation status
14. Headlight/taillight status
Of these fourteen categories, two — GPS/geolocation data and seat occupancy data — are classified as "Sensitive Vehicle Data" under VMS's internal data governance policy (Version 3.2, effective January 1, 2022) when combined with vehicle identification numbers ("VINs"). The sensitivity classification arises because VIN-linked GPS/geolocation data can reveal the precise movements and habitual locations of identifiable vehicle owners or lessees, and VIN-linked seat occupancy data can be used to infer information about the occupancy patterns and passenger composition of an identifiable individual's vehicle. This classification triggers enhanced data protection requirements under VMS's internal governance framework and has significant implications for the sub-processor analysis set forth in this memorandum.
The estimated daily data volume flowing from VMS to Meridian under the partnership is approximately 4.2 terabytes per day of raw telemetry data. This is a substantial and continuous data flow that will require robust hosting infrastructure and significant storage capacity, which is the primary reason Meridian has proposed utilizing Cloudvault's AutoCloud platform as its hosting and processing sub-processor.
The commercial terms contemplated by the LOI include an annual license fee payable by Meridian to VMS of $6.5 million per year, payable in quarterly installments of $1.625 million, plus a royalty of 3.5% on the net revenue generated by Meridian from derivative analytics products sold to third parties that incorporate VMS-sourced data. The partnership is structured for an initial term of three (3) years, with two (2) optional one-year renewal periods exercisable by mutual agreement. The total contract value for the base three-year term is $19.5 million, exclusive of royalty payments, which VMS estimates could generate an additional $2.1 million to $4.8 million over the base term depending on Meridian's commercial success with downstream analytics products. The financial magnitude of this partnership underscores the importance of ensuring that the data protection framework — including sub-processor governance — is robust and appropriately calibrated to protect VMS's interests and its consumers' data.
B. Calderwood & Harkness's Engagement
Calderwood & Harkness LLP ("C&H") was engaged by VMS on September 14, 2022, to draft and negotiate the Data Processing Agreement governing Meridian's processing of VMS vehicle telemetry and in-cabin sensor data under the data-sharing partnership. The engagement is supervised by Rachel Bernstein, Partner, and staffed by the undersigned as the primary drafting associate.
C&H circulated an initial draft of the DPA (DPA v1.0, consisting of 47 pages including all annexes) to VMS for internal review on September 28, 2022. Following VMS's approval of the initial draft, DPA v1.0 was transmitted to Whitfield, Barrow & Crane LLP ("WBC"), Meridian's outside counsel, on October 7, 2022. WBC returned a redlined version of the DPA (DPA v2.0) on October 21, 2022, containing 63 substantive comments and proposed revisions.
On November 4, 2022, C&H circulated to VMS an internal issues memorandum identifying eleven (11) material open issues arising from the DPA negotiation, ranked by significance and with preliminary recommendations for VMS's negotiating position on each. The sub-processor approval mechanism — which is the central focus of this memorandum — was identified as one of the eleven material open issues and was ranked as the fourth most significant open item (after data breach notification timelines, limitation of liability/indemnification, and data retention/deletion periods).
The next scheduled negotiation session between C&H and WBC is a teleconference currently set for November 15, 2022, at which time sub-processor approval rights are expected to be among the topics addressed. This memorandum is intended to inform VMS's and C&H's negotiating position in advance of that call.
C. Pinehurst Security Assessment
In addition to retaining C&H for the legal drafting and negotiation work, VMS has separately retained Pinehurst Cybersecurity Advisors LLC ("Pinehurst"), a Virginia-based cybersecurity consulting firm headquartered at 1900 Crystal Drive, Suite 710, Arlington, VA 22202, to conduct a technical security assessment of Meridian's data processing environment. Pinehurst's engagement is managed directly by VMS's Information Security team and is outside the scope of C&H's legal engagement, although the results of Pinehurst's assessment are expected to have a material bearing on the ongoing DPA negotiations.
As of the date of this memorandum, Pinehurst has not yet delivered its preliminary findings report. Based on discussions with Diana Kowalski, delivery of the preliminary report is anticipated for later in November 2022, though the precise delivery date has not been confirmed. Pinehurst's assessment scope is understood to include Meridian's use of sub-processors, including Cloudvault, as part of Meridian's overall data processing ecosystem, though we have not reviewed Pinehurst's engagement letter or scope of work document and therefore cannot confirm the precise boundaries of their assessment.
We recommend that VMS request that Pinehurst's assessment specifically evaluate Cloudvault's AutoCloud platform and the security controls in place at Cloudvault's Columbus, Ohio data center (discussed in Section III.B below). Given that Cloudvault would be the entity physically hosting and processing VMS's vehicle telemetry data, the adequacy of Cloudvault's technical and organizational security measures is a critical component of VMS's overall risk posture under the partnership. The Pinehurst findings, once available, should inform any final risk determination regarding Cloudvault's adequacy as a sub-processor and may influence VMS's decision regarding whether to approve Cloudvault for inclusion in Annex C of the DPA as a pre-approved sub-processor.
III. Cloudvault Infrastructure, Inc. — Entity Profile
A. Corporate Overview
Based on publicly available information and information disclosed by Meridian during the DPA negotiation process, we have compiled the following corporate profile of the proposed sub-processor:
Cloudvault appears to be positioned as a specialized cloud infrastructure provider with a focus on the automotive and mobility technology sector, as evidenced by the branding and functionality of its AutoCloud platform. While Cloudvault does not appear to have the market presence or scale of the major hyperscale cloud providers (e.g., Ridgeway Industries, Crestline Systems, Aldermere Technologies), its automotive industry focus may represent an advantage insofar as it suggests domain-specific expertise in handling the types of vehicle telemetry data at issue in this engagement. However, this specialization does not in itself substitute for a thorough due diligence review of Cloudvault's security posture, certifications, and contractual commitments.
We note that our current profile of Cloudvault is based on limited information. We have not conducted an independent background investigation of the entity, its financial stability, its ownership structure, or its management team. Depending on VMS's risk tolerance, VMS may wish to commission a more comprehensive due diligence investigation of Cloudvault as part of its sub-processor approval process.
B. Data Center Locations
Meridian has disclosed three Cloudvault facilities that are relevant to the sub-processor analysis:
U.S. Data Center — Columbus, Ohio. Cloudvault operates a data center located at 7400 Crossroads Boulevard, Columbus, OH 43219 (the "Columbus Data Center"). This is the primary facility that Meridian has proposed for hosting and processing VMS vehicle telemetry and in-cabin sensor data under the data-sharing partnership. Because the Columbus Data Center is located within the continental United States, its use for processing VMS data does not implicate cross-border data transfer restrictions under applicable U.S. or foreign data protection laws. Columbus, Ohio is a well-established data center market with robust power infrastructure, fiber connectivity, and a favorable risk profile with respect to natural disasters, which suggests that the choice of this location is reasonable from a business continuity perspective.
Headquarters Facility — Reno, Nevada. Cloudvault's corporate headquarters is located at 200 Mill Street, Suite 100, Reno, NV 89501. Based on the information currently available to us, it is unclear whether operational data processing activities occur at this facility or whether it serves purely as an administrative headquarters for Cloudvault's corporate, sales, and management functions. This distinction is important because if VMS data could be accessed, processed, or stored at the Reno facility — even temporarily or for administrative or support purposes — it would expand the geographic scope of VMS data processing and potentially the universe of Cloudvault personnel with access to VMS data. We recommend that VMS, through Meridian, seek clarification from Cloudvault regarding the nature of operations conducted at the Reno headquarters facility, including whether any Cloudvault personnel at that location would have logical or physical access to VMS data hosted on the AutoCloud platform.
Proposed Future EU Data Center — Dublin, Ireland. Meridian has disclosed that Cloudvault is developing or planning to deploy a data center facility at Unit 12, Parkwest Business Campus, Dublin 12, Ireland (the "Dublin Data Center"). Meridian has indicated that a future migration of some or all of Meridian's data processing operations to the Dublin Data Center is under consideration. The cross-border data transfer implications of migrating VMS data — particularly data relating to U.S. data subjects, including approximately 112,000 California residents — to an Irish facility raise significant regulatory and contractual questions. These questions are being analyzed separately and will be addressed in a forthcoming memorandum. For purposes of this sub-processor risk analysis, we focus exclusively on Cloudvault's current U.S.-based infrastructure, principally the Columbus Data Center. However, as discussed in Section IX.A below, the DPA should include a prior-consent requirement for any facility migration to ensure that VMS retains control over where its data is processed.
C. Meridian's Existing Relationship with Cloudvault
Meridian has disclosed that it has an existing commercial relationship with Cloudvault governed by a Master Services Agreement ("MSA") that was executed on March 1, 2021. The Meridian-Cloudvault MSA predates the VMS-Meridian data-sharing partnership by approximately seventeen (17) months, indicating that Meridian selected Cloudvault as its cloud infrastructure provider independently and prior to any discussions with VMS regarding the current partnership.
We have not reviewed the Meridian-Cloudvault MSA. This is a significant gap in our current analysis, as the terms of that agreement will directly govern Cloudvault's obligations with respect to data it processes on Meridian's behalf, including VMS data. We strongly recommend that VMS request a copy of the Meridian-Cloudvault MSA from Meridian, or at minimum a detailed summary of its key terms, in order to evaluate the following critical provisions:
(i) Data security obligations imposed on Cloudvault, including required technical and organizational security measures, encryption standards, access controls, and personnel security requirements;
(ii) Data breach notification requirements, including the timeframe within which Cloudvault must notify Meridian of a data security incident and the content requirements for such notification;
(iii) Data deletion and return obligations upon termination or expiration of the MSA, including the timeframe for deletion, the standard of destruction (e.g., NIST SP 800-88 or equivalent), and certification of destruction;
(iv) Cloudvault's right to further sub-contract its obligations under the MSA (i.e., sub-sub-processing), including whether Cloudvault may engage its own sub-processors to process data hosted on the AutoCloud platform, and if so, under what conditions; and
(v) Liability and indemnification provisions, including whether Cloudvault's liability to Meridian for data protection failures is uncapped or subject to a liability cap, and the scope of indemnification obligations with respect to data breaches, regulatory fines, and third-party claims.
Without review of the Meridian-Cloudvault MSA, we are unable to confirm that Cloudvault's existing contractual obligations to Meridian are sufficient to protect VMS's interests as the originating data controller. If the existing MSA does not contain adequate data protection provisions — or if its terms fall short of the flow-down requirements that we recommend be imposed through the VMS-Meridian DPA (as discussed in Section VII below) — VMS should require Meridian to amend the Cloudvault MSA or execute a supplemental data processing addendum before VMS data is made available to Cloudvault for processing.
D. AutoCloud Platform
Meridian has proposed using Cloudvault's proprietary "AutoCloud" platform specifically for hosting and processing VMS vehicle telemetry and in-cabin sensor data. AutoCloud is described as a cloud-based infrastructure platform designed to serve the automotive and mobility technology industry, suggesting that it may incorporate features tailored to the ingestion, storage, and processing of vehicle-generated data streams.
Beyond this general description, however, we have limited information regarding the technical architecture and security posture of the AutoCloud platform. Key questions that remain unanswered include:
• Whether AutoCloud operates on a multi-tenant or single-tenant architecture — a multi-tenant environment introduces additional data segregation and access concerns, as VMS data would reside on shared infrastructure alongside data belonging to Cloudvault's other customers;
• The encryption standards employed by AutoCloud for data at rest and data in transit, including the encryption algorithms, key lengths, and key management practices;
• The access control framework, including role-based access controls, multi-factor authentication requirements, and privileged access management procedures for Cloudvault personnel and Meridian personnel accessing VMS data;
• The data segregation mechanisms in place to isolate VMS data from other customers' data, particularly in a multi-tenant environment; and
• The data residency controls that can be applied to ensure VMS data remains within designated geographic boundaries (i.e., the Columbus Data Center).
VMS should require Meridian to provide Cloudvault's current SOC 2 Type II report (or equivalent third-party audit certification, such as ISO 27001 certification) for the AutoCloud platform. A SOC 2 Type II report would provide an independent assessment of the design and operating effectiveness of Cloudvault's controls relevant to security, availability, processing integrity, confidentiality, and privacy, and would materially advance VMS's ability to evaluate Cloudvault's adequacy as a sub-processor. The report should cover the Columbus, Ohio data center specifically, as that is the proposed processing location for VMS data.
IV. Scope of Data Accessible to Cloudvault
A. Data Categories
As the hosting and data storage platform for Meridian's processing of VMS vehicle telemetry data, Cloudvault would potentially have access to all fourteen (14) categories of VMS vehicle telemetry and in-cabin sensor data enumerated in Section II.A above. This is because the raw data streams from VMS's connected vehicles would be ingested into and stored on Cloudvault's AutoCloud platform infrastructure, meaning that Cloudvault's systems — and potentially its personnel, depending on the access control configuration — could access the full scope of VMS data.
Critically, the data categories accessible to Cloudvault include the two categories classified as "Sensitive Vehicle Data" under VMS's internal data governance policy: GPS/geolocation data and seat occupancy data. When these data categories are combined with vehicle identification numbers ("VINs") — which are necessary for Meridian's analytics processing and would therefore be present in the data sets hosted on AutoCloud — they can be linked to identifiable individuals (i.e., vehicle owners and lessees). This linkage effectively transforms what might otherwise be considered non-personal vehicle operational data into personal information or personally identifiable information, depending on the applicable legal framework.
The scope of Cloudvault's access to Sensitive Vehicle Data raises the same privacy and regulatory concerns that apply to Meridian's own processing of VMS data. From a risk perspective, the introduction of a sub-processor does not reduce the universe of applicable regulatory obligations — it expands the attack surface and the number of entities with access to potentially sensitive personal information, thereby compounding the risk profile that VMS must manage.
B. Data Volume
The estimated daily data volume flowing from VMS to Meridian — and, by extension, onto Cloudvault's AutoCloud platform — is approximately 4.2 terabytes per day of raw telemetry data generated by approximately 800,000 opted-in VantageLink-equipped vehicles. Over the course of a calendar year, this translates to approximately 1.5 petabytes of raw telemetry data, a substantial volume that underscores the importance of Cloudvault maintaining robust infrastructure capacity, data integrity controls, and scalable storage and processing capabilities.
The volume of data at issue also has implications for incident response and data return/deletion obligations. In the event of a data breach or upon termination of the DPA, the practical challenges of identifying, segregating, and securely deleting or returning 1.5 petabytes or more of VMS data from Cloudvault's infrastructure will be significant and should be addressed in the contractual framework.
C. California Data Subjects
Approximately 112,000 of the 800,000 opted-in vehicles participating in VMS's Connected Insights program are registered in the State of California, representing approximately 14% of the total data subject population. This is a significant population segment with direct regulatory implications.
The presence of California-registered vehicles in the data set triggers the applicability of the California Consumer Privacy Act of 2018 ("CCPA"), as amended by the California Privacy Rights Act of 2020 ("CPRA"), codified at Cal. Civ. Code § 1798.100 et seq. Under the CCPA/CPRA framework, Cloudvault — as an entity that processes personal information on behalf of Meridian, which in turn processes personal information on behalf of VMS — must be contractually designated and bound as either a "service provider" or a "contractor" (as those terms are defined under Cal. Civ. Code §§ 1798.140(ag) and 1798.140(j), respectively). This designation requires that the sub-processor agreement between Meridian and Cloudvault include specific CCPA-compliant provisions, including:
• A prohibition on Cloudvault selling or sharing VMS personal information;
• A prohibition on Cloudvault retaining, using, or disclosing VMS personal information for any purpose other than the specific business purpose of providing services to Meridian under the MSA;
• A prohibition on Cloudvault retaining, using, or disclosing VMS personal information outside of the direct business relationship between Meridian and Cloudvault; and
• A requirement that Cloudvault comply with the CCPA and provide the same level of privacy protection as required by the CCPA.
Failure to include these provisions in the Meridian-Cloudvault sub-processor agreement could expose VMS to regulatory enforcement risk under the CCPA, as the California Attorney General and the California Privacy Protection Agency have indicated that businesses bear responsibility for ensuring their service providers and contractors comply with applicable requirements.
D. Regulatory Implications for Sub-Processor
Beyond the CCPA/CPRA, several additional regulatory frameworks are potentially applicable to Cloudvault's processing of VMS data and should be addressed in the flow-down contractual obligations discussed in Section VII:
Michigan Identity Theft Protection Act (MCL 445.61 *et seq.*): VMS is a Michigan-headquartered company, and a significant portion of the vehicle population in the data set is likely registered in Michigan. To the extent that VIN-linked GPS/geolocation data or seat occupancy data constitutes "personal information" under the Michigan Identity Theft Protection Act — which defines personal information to include, among other things, a person's name in combination with certain identifying data elements — sub-processor agreements must ensure that appropriate administrative, technical, and physical safeguards are in place to protect such information from unauthorized access, acquisition, or use. The Michigan act also imposes data breach notification obligations that would need to be reflected in the notification chain.
CCPA/CPRA (Cal. Civ. Code § 1798.100 *et seq.*): As discussed in Section IV.C above, Cloudvault must be contractually restricted from retaining, using, or disclosing VMS personal information for purposes other than the specific services performed on behalf of Meridian (and, by extension, VMS as the originating data controller). The CPRA's expanded obligations, which take effect on January 1, 2023, should also be considered in structuring the sub-processor provisions, including the requirement for businesses to conduct risk assessments for processing activities that present a significant risk to consumers' privacy.
Driver's Privacy Protection Act ("DPPA") (18 U.S.C. § 2721 *et seq.*): To the extent that VIN-linked data processed by Cloudvault implicates motor vehicle records or information derived from motor vehicle records, the DPPA's restrictions on the use and disclosure of such information apply. The DPPA limits the permissible purposes for which motor vehicle record information may be obtained, disclosed, or used, and violations carry significant civil penalties. Sub-processor agreements must ensure that Cloudvault's access to and use of VIN-linked data is limited to permissible purposes under the DPPA and that Cloudvault does not further disclose such information except as authorized.
The DPA between VMS and Meridian should expressly require Meridian to flow down equivalent data protection obligations — including compliance with the regulatory frameworks identified above — to Cloudvault through the sub-processor agreement. The specifics of these flow-down requirements are addressed in Section VII below.
V. Competing Sub-Processor Approval Models
Sub-processor approval rights represent one of the eleven material open issues in the DPA negotiation between VMS and Meridian. The parties have adopted fundamentally different positions on this issue, reflecting a tension between VMS's interest in maintaining granular control over entities that process its data and Meridian's interest in preserving operational flexibility in managing its technology infrastructure. This section summarizes and evaluates each party's position before Section VI presents our recommended hybrid approach.
A. VMS's Position: Prior Written Consent
DPA v1.0, as drafted by Calderwood & Harkness, proposed that Meridian be required to obtain VMS's prior written consent before engaging or changing any sub-processor that would process VMS data. Under this model, Meridian would be prohibited from disclosing, transferring, or making available any VMS data to a sub-processor until VMS had provided its express written approval of the specific sub-processor, the scope of processing to be performed by that sub-processor, and the data center location(s) at which processing would occur.
The rationale for VMS's prior written consent position is straightforward: given the sensitivity of the data at issue — particularly GPS/geolocation and seat occupancy data that, when linked to VINs, constitutes information about identifiable individuals — VMS should retain maximum control over which entities have access to VMS data. This is the more protective approach from a data controller's perspective, and it is consistent with best practices for data processing agreements involving sensitive personal data. Industry guidance from organizations such as the International Association of Privacy Professionals (IAPP) and the UK Information Commissioner's Office (ICO) has recognized that prior specific consent is generally the more protective model and is appropriate where the data processed is particularly sensitive or the data controller has heightened risk concerns.
From a practical standpoint, the prior written consent model offers VMS a significant advantage: VMS can conduct due diligence on each proposed sub-processor before any VMS data is shared with that entity. This due diligence could include requesting and reviewing security certifications (e.g., SOC 2 Type II reports, ISO 27001 certificates), reviewing the proposed sub-processor's privacy policies and data handling practices, reviewing the terms of the sub-processor agreement between Meridian and the proposed sub-processor, and coordinating with Pinehurst or other security advisors to evaluate the proposed sub-processor's technical security controls. The prior consent model ensures that VMS is never presented with a fait accompli in which its data has already been shared with a sub-processor that VMS has not vetted.
B. Meridian's Position: General Authorization with 30-Day Objection Window
In DPA v2.0, WBC proposed replacing the prior written consent requirement with a general authorization model. Under WBC's proposed language, Meridian would maintain a list of approved sub-processors (to be appended to the DPA as an annex) and would have the right to add new sub-processors to the list upon providing VMS with thirty (30) calendar days' prior written notice. VMS would have the right to object to the proposed sub-processor within the 30-day notice period, but only on "reasonable grounds." If VMS did not object within the 30-day window, the proposed sub-processor would be deemed approved.
Meridian's rationale, as articulated in WBC's comments accompanying DPA v2.0, centers on operational flexibility. WBC argued that the prior written consent model creates delays that are incompatible with Meridian's technology development cycle and its need to rapidly scale and adjust its cloud infrastructure in response to evolving processing demands. WBC contended that requiring VMS's affirmative consent for each sub-processor change could result in weeks or months of delay, during which Meridian's ability to deliver its analytics products — and, by extension, the value of the data-sharing partnership to both parties — would be impaired.
WBC further argued that the general authorization model with an objection right provides VMS with adequate protection while preserving Meridian's ability to manage its vendor relationships efficiently. WBC characterized VMS's right to object within the 30-day window as a meaningful safeguard that ensures VMS is informed of and can challenge any proposed sub-processor change. WBC also noted that a general authorization approach is consistent with the framework contemplated under Article 28(2) of the European Union's General Data Protection Regulation ("GDPR"), which permits a controller to provide either "specific" or "general written authorisation" for sub-processors, with the general authorization model requiring the processor to inform the controller of intended changes and giving the controller the opportunity to object. WBC characterized the general authorization model as "industry standard" in modern data processing agreements.
C. Key Risks of Each Approach
Each of the competing models presents distinct risks that VMS should consider:
Risks of the Prior Written Consent Model:
• Meridian may object that operational delays resulting from the consent process could impair its ability to deliver contracted services, potentially leading to disputes regarding service level compliance and responsibility for performance failures.
• VMS must be prepared to respond to consent requests promptly. If VMS is slow to evaluate and approve proposed sub-processors, Meridian may argue that VMS's delays are the proximate cause of any resulting service interruptions or performance degradation, potentially undermining VMS's position in any subsequent dispute.
• The consent model places a recurring administrative burden on VMS's Privacy and Legal teams to evaluate sub-processor requests, which could be resource-intensive if Meridian frequently adjusts its vendor ecosystem.
Risks of the General Authorization Model:
• Thirty (30) calendar days may not provide VMS with sufficient time to conduct meaningful due diligence on a proposed new sub-processor, particularly if the sub-processor is a previously unknown entity requiring a comprehensive security assessment, review of certifications, and potentially engagement of third-party advisors such as Pinehurst.
• If VMS fails to object within the 30-day window — whether due to internal delays, personnel changes, or simple oversight — VMS may be deemed to have consented to the sub-processor by inaction. This passive approval mechanism effectively shifts the burden to VMS to affirmatively act within a fixed window, creating a risk of inadvertent approval.
• The standard for "reasonable grounds" for objection, as proposed by WBC, is undefined and could be a source of future dispute. Meridian might challenge VMS's objections as unreasonable if they are based on risk factors that Meridian considers speculative or overly conservative, potentially leading to protracted negotiations or disputes over individual sub-processor decisions.
• The general authorization model does not differentiate between sub-processors that would handle Sensitive Vehicle Data and those that would handle only lower-risk data categories, applying a uniform and less protective approval standard across the board.
Both models have valid justifications and legitimate concerns. The hybrid approach described in Section VI is designed to address the principal risks of each model while preserving the core interests of both parties.
VI. Recommended Hybrid Approach
A. Structure of the Hybrid Model
We recommend that VMS propose a tiered sub-processor approval mechanism that calibrates the level of VMS control to the sensitivity of the data that the proposed sub-processor would process. This hybrid model is structured as follows:
Tier 1 — Initial Approved Sub-Processors. Cloudvault Infrastructure, Inc. (and any other sub-processors identified and approved by VMS as of the date of DPA execution) would be listed in Annex C to the DPA as pre-approved sub-processors. Annex C should specify, for each pre-approved sub-processor: (i) the legal name and address of the sub-processor; (ii) a description of the processing activities to be performed by the sub-processor; (iii) the categories of VMS data to be processed; and (iv) the data center location(s) at which processing will occur. Cloudvault's listing in Annex C would specify the Columbus, Ohio data center (7400 Crossroads Boulevard, Columbus, OH 43219) as the approved processing location and would describe the scope of processing as hosting and storage of VMS vehicle telemetry and in-cabin sensor data on the AutoCloud platform. By listing these sub-processors in Annex C, VMS would be providing its specific written consent as of the DPA effective date, eliminating any delay or ambiguity with respect to the initial sub-processor configuration.
Tier 2 — New Sub-Processors Processing Sensitive Vehicle Data. Any new sub-processor that Meridian proposes to engage after the DPA effective date, and that would process GPS/geolocation data, seat occupancy data, or any other data category classified as "Sensitive Vehicle Data" under VMS's data governance policy (as may be amended from time to time), would require VMS's prior written consent. The general authorization model would not apply to Tier 2 sub-processors. This prior consent requirement ensures that VMS retains full veto authority over any entity that would access the most sensitive categories of VMS data — the categories most capable of identifying and tracking individual vehicle owners and lessees. VMS would have the right to withhold consent for any reason, and consent, if granted, could be made subject to conditions (e.g., additional security requirements, geographic restrictions, time limitations).
Tier 3 — New Sub-Processors Processing Non-Sensitive Data Only. Any new sub-processor that Meridian proposes to engage after the DPA effective date, and that would process only non-sensitive data categories — for example, tire pressure, engine diagnostic codes, fuel consumption, in-cabin temperature, in-cabin humidity, seatbelt status, ambient noise levels, windshield wiper activation, or headlight/taillight status — could be engaged under a general authorization model with a 30-day objection window, subject to the following conditions:
(a) Meridian must provide VMS with written notice at least thirty (30) calendar days before engaging the proposed sub-processor;
(b) The notice must include sufficient information to enable VMS to conduct a meaningful evaluation, including: the sub-processor's legal name, jurisdiction of incorporation, principal office address, data center location(s), a description of the processing activities to be performed, the specific VMS data categories to be processed, and any available third-party security certifications (e.g., SOC 2 Type II report, ISO 27001 certificate);
(c) VMS has the right to object to the proposed sub-processor within the 30-day notice period, as further described in Section VI.B below; and
(d) If VMS does not object within the 30-day window, the sub-processor is deemed approved and Meridian may proceed with engagement, subject to the flow-down obligations described in Section VII.
This tiered model reflects the principle that the level of data controller oversight should be proportionate to the risk associated with the processing activity — a principle recognized in the GDPR's risk-based approach and in VMS's own internal data governance policy.
B. Objection Rights
Under the Tier 3 general authorization model, the scope and standard of VMS's right to object to a proposed sub-processor is a critical drafting point. We recommend that VMS's right to object should not be limited to "reasonable grounds" as proposed by WBC. Instead, VMS should have the right to object for any reason, or, at a minimum, the grounds for objection should be broadly and non-exhaustively defined to include any of the following:
• Concerns regarding the proposed sub-processor's data security posture, including the adequacy of technical and organizational security measures;
• Concerns regarding the proposed sub-processor's compliance with applicable data protection laws and regulations, including the CCPA/CPRA, the Michigan Identity Theft Protection Act, and the DPPA;
• Concerns regarding the geographic location of the proposed sub-processor's data center(s) or processing facilities;
• Concerns regarding the proposed sub-processor's financial stability, business continuity preparedness, or operational reliability;
• Concerns regarding reputational risk to VMS associated with the proposed sub-processor; and
• Any other concern that VMS, in its reasonable discretion, considers material to the protection of VMS data or VMS's interests under the DPA.
If VMS objects to a proposed Tier 3 sub-processor and the parties are unable to resolve the objection within fifteen (15) business days following VMS's notice of objection, VMS should have the right to either: (i) terminate the DPA without penalty, without liability for early termination fees, and with a right to a pro-rata refund of any prepaid fees; or (ii) suspend the affected data categories from processing (i.e., instruct Meridian to cease processing the specific data categories that would have been processed by the objected-to sub-processor) until the objection is resolved or an alternative sub-processor acceptable to VMS is identified.
We anticipate that WBC may resist VMS's proposal for an unrestricted right of objection, arguing that it effectively converts the Tier 3 general authorization model into a de facto prior consent requirement. In negotiation, VMS may need to accept a "reasonable grounds" standard, provided it is coupled with a broadly and non-exhaustively defined list of grounds, as outlined above, and VMS retains the termination or suspension right as a meaningful remedy in the event of an unresolved objection.
C. Advantages of the Hybrid Approach
The tiered hybrid model offers several significant advantages over either the pure prior consent model or the pure general authorization model:
• Preserves VMS's control over the most sensitive data. By requiring prior written consent for any sub-processor that would process Sensitive Vehicle Data (Tier 2), the hybrid model ensures that VMS retains veto authority over the entities most likely to create privacy and regulatory risk. This is the critical safeguard from VMS's perspective.
• Provides Meridian with operational flexibility for lower-risk data. By applying the general authorization model to sub-processors that would process only non-sensitive data categories (Tier 3), the hybrid model accommodates WBC's concern about operational delays in Meridian's technology development cycle. For routine infrastructure changes involving lower-risk data, Meridian can move at the pace its business requires, subject to the 30-day notice and objection mechanism.
• Addresses WBC's concern about delays. The Tier 1 pre-approval of Cloudvault (and any other initial sub-processors) in Annex C eliminates any startup delay, and the Tier 3 general authorization for non-sensitive data substantially reduces the number of sub-processor changes requiring VMS's affirmative consent.
• Provides a pragmatic middle ground. In our experience, hybrid approval models are increasingly common in sophisticated data processing agreements and are likely to be viewed as a reasonable and defensible compromise by both parties. This model positions VMS as a pragmatic negotiating partner willing to accommodate legitimate operational concerns while maintaining appropriate data protection standards.
We believe this hybrid model has a reasonable likelihood of being accepted by WBC and Meridian in negotiation, though some fine-tuning of the specific terms (e.g., the objection standard, the notice period, the scope of the "Sensitive Vehicle Data" definition) is to be expected.
VII. Flow-Down Contractual Obligations
A. Requirement for Written Sub-Processor Agreements
Regardless of which sub-processor approval model is ultimately adopted, the DPA must include a robust requirement that Meridian enter into a written agreement with each sub-processor — including Cloudvault — that imposes data protection obligations no less protective than those imposed on Meridian under the VMS-Meridian DPA. This "no less protective" standard is the industry-standard formulation for flow-down provisions in data processing agreements and reflects the principle that data protection obligations should cascade down the processing chain without dilution.
The key provisions that should be flowed down to each sub-processor agreement include, at a minimum:
(1) Purpose and Scope Limitations. The sub-processor's processing of VMS data must be limited to the specific purpose and scope described in the DPA and the sub-processor's listing in Annex C. The sub-processor should be prohibited from processing VMS data for any purpose other than performing the services contracted by Meridian, and should be expressly prohibited from using VMS data for its own commercial purposes, including product development, analytics, marketing, or data monetization.
(2) Confidentiality Obligations. The sub-processor agreement must include confidentiality obligations binding on all sub-processor personnel who may have access to VMS data, including employees, contractors, and agents. Sub-processor personnel with access to VMS data should be subject to written confidentiality commitments or professional obligations of secrecy.
(3) Technical and Organizational Security Measures. The sub-processor must implement technical and organizational security measures at least equivalent to those specified in Annex B to the VMS-Meridian DPA. VMS should require that Annex B include specific minimum security requirements, including (as applicable) encryption standards for data at rest and in transit, access control requirements, multi-factor authentication, intrusion detection and prevention systems, vulnerability management and patching protocols, backup and disaster recovery capabilities, and physical security measures at data center facilities.
(4) Data Breach Notification Obligations. The sub-processor agreement must require Cloudvault to notify Meridian of any data security incident involving VMS data within a timeframe no less stringent than the notification timeline imposed on Meridian under the DPA. We note that the data breach notification timeline remains an open issue in the DPA negotiation: VMS has proposed a 24-hour notification window from discovery of the incident, while Meridian has proposed 72 hours. The sub-processor notification timeline should be aligned to ensure that VMS receives timely notification through the chain, as further discussed in Section IX.C below.
(5) Data Return and Deletion Obligations. Upon termination or expiration of the Meridian-Cloudvault MSA, or upon termination or expiration of the VMS-Meridian DPA, Cloudvault must return or securely delete all VMS data in its possession or control within a specified timeframe. The deletion standard should conform to recognized industry standards (e.g., NIST Special Publication 800-88, "Guidelines for Media Sanitization") and Cloudvault should be required to provide written certification of deletion upon completion.
(6) Prohibition on Further Sub-Contracting (Sub-Sub-Processing). The sub-processor agreement should prohibit Cloudvault from further sub-contracting any of its processing obligations with respect to VMS data — i.e., from engaging its own sub-processors (sub-sub-processors) — without the prior written consent of both Meridian and VMS. This "double consent" mechanism ensures that VMS retains visibility into and control over every link in the data processing chain.
(7) Cooperation with VMS Audit Rights. The sub-processor agreement should require Cloudvault to cooperate with and facilitate audit activities conducted by VMS or VMS's designated auditors, as discussed in Section VIII below.
B. Meridian's Liability for Sub-Processor Acts
The DPA should provide unambiguously that Meridian remains fully liable to VMS for the acts and omissions of its sub-processors — including Cloudvault — as if they were the acts and omissions of Meridian itself. This principle is well-established in data processing law and practice. Under GDPR Article 28(4), for example, where a processor engages a sub-processor, the processor "shall remain fully liable to the controller for the performance of that other processor's obligations." Although the GDPR does not directly apply to this U.S.-based transaction, the principle articulated in Article 28(4) represents an international best practice that should be reflected in the VMS-Meridian DPA.
The practical effect of this provision is that if Cloudvault experiences a data security incident, fails to comply with its processing obligations, or otherwise causes harm to VMS or VMS's data subjects, VMS would look to Meridian — not Cloudvault — for recourse. Meridian's decision to delegate processing to Cloudvault should not diminish VMS's ability to recover losses or obtain remedies under the DPA. Meridian should not be permitted to assert as a defense that a data protection failure was caused by its sub-processor rather than by Meridian itself.
We note that WBC may argue that Meridian's liability for sub-processor acts should be subject to the general limitation of liability provisions in the DPA. VMS should resist any attempt to carve sub-processor liability out of the DPA's general liability framework. If anything, sub-processor-related breaches should be treated as among the categories of loss for which heightened or uncapped liability applies.
C. Review of Existing Cloudvault MSA
As noted in Section III.C above, we strongly recommend that VMS request a copy of Meridian's existing Master Services Agreement with Cloudvault (executed March 1, 2021) to assess whether the existing terms meet the flow-down requirements described in Section VII.A. This request can be made directly by VMS to Meridian or through C&H to WBC as part of the DPA negotiation process.
If the existing MSA is insufficient — which, given that it was executed approximately seventeen months before the VMS-Meridian partnership was contemplated and was likely not drafted with VMS's specific data protection requirements in mind, is a realistic possibility — VMS should require Meridian to take one or more of the following steps before VMS data is made available to Cloudvault:
(a) Amend the existing Meridian-Cloudvault MSA to incorporate the necessary data protection provisions; or
(b) Execute a supplemental data processing addendum between Meridian and Cloudvault that addresses the specific data protection obligations required by the VMS-Meridian DPA; or
(c) Terminate the existing MSA and execute a new agreement that incorporates the required protections from the outset.
The DPA should include an express representation and warranty by Meridian that its agreements with all sub-processors contain data protection terms that are no less protective than the corresponding provisions of the VMS-Meridian DPA. Additionally, VMS should have the right to request copies of Meridian's sub-processor agreements (or the data-protection-specific provisions thereof) in order to verify compliance with this representation. Meridian may reasonably request the right to redact commercially sensitive terms — such as pricing, service levels, and other business terms unrelated to data protection — from any copies provided to VMS, which is an accommodation that VMS can accept without compromising its data protection interests.
VIII. Audit Rights Regarding Sub-Processors
A. Competing Positions on Audit Rights (General)
The parties' positions on audit rights — one of the eleven material open issues identified in the November 4, 2022 issues memorandum — reflect a significant divergence that has direct implications for the sub-processor audit framework.
VMS has proposed a robust audit right under which VMS (or its designated auditors) would have the right to conduct on-site audits of Meridian's data processing environment, with not less than ten (10) business days' prior written notice. VMS's proposed audit right is unlimited in frequency and scope, reflecting VMS's position that as the data controller, it must have unfettered access to verify Meridian's compliance with the DPA.
Meridian, through WBC, has proposed a significantly more restrictive audit framework. Under Meridian's proposed terms, audits would be limited to once per calendar year, with not less than thirty (30) calendar days' prior written notice. Furthermore, WBC has proposed a $25,000 cost-sharing cap per audit, under which VMS would be required to reimburse Meridian for audit-related costs (e.g., personnel time, facility access, document production) in excess of $25,000 per audit. Meridian's rationale is that unlimited audit rights impose an undue operational burden and that annual audits, supplemented by third-party certifications, provide adequate assurance of compliance.
While the general audit rights dispute is beyond the scope of this memorandum, the resolution of this issue will directly affect VMS's ability to audit sub-processors such as Cloudvault. We address the sub-processor-specific audit considerations below.
B. Sub-Processor Audit Rights — Recommended Approach
The DPA should expressly provide that VMS's audit rights extend to sub-processors, including Cloudvault. Without an express sub-processor audit provision, VMS would have no contractual basis to verify that Cloudvault is processing VMS data in compliance with the flow-down obligations imposed through the Meridian-Cloudvault MSA. This gap would be particularly problematic because Cloudvault is the entity that physically hosts and stores VMS data — it is, in effect, the frontline custodian of VMS's most sensitive data.
Given the practical complexities of VMS auditing Cloudvault directly — Cloudvault is Meridian's vendor, not VMS's, and VMS has no direct contractual relationship with Cloudvault — we recommend a layered audit approach that provides VMS with multiple mechanisms for verifying sub-processor compliance:
Primary Mechanism: Meridian-Conducted Annual Audit. Meridian should be contractually required to conduct an audit of Cloudvault at least once per calendar year, covering Cloudvault's compliance with the data protection obligations in the Meridian-Cloudvault sub-processor agreement. Meridian must provide VMS with the audit results — or, at a minimum, a detailed summary of findings, including any identified non-conformities and the remediation measures undertaken — within thirty (30) days of the audit's completion. This mechanism leverages Meridian's existing contractual relationship with Cloudvault and avoids the practical and legal difficulties of VMS attempting to audit a third party with whom it has no direct agreement. It also places the primary audit burden and cost on Meridian, which is appropriate given that Meridian is responsible for its sub-processor's compliance.
Secondary Mechanism: VMS-Initiated Direct Audit. Notwithstanding the primary mechanism, VMS should retain the right to conduct its own audit of Cloudvault (or to engage a third-party auditor, such as Pinehurst Cybersecurity Advisors, to conduct the audit on VMS's behalf) under specified circumstances. We recommend that VMS's direct audit right be triggered by any of the following events:
(i) A suspected or confirmed data breach or data security incident involving VMS data processed or stored by Cloudvault;
(ii) A material security incident at Cloudvault that, even if not directly involving VMS data, raises reasonable concerns about the adequacy of Cloudvault's security controls;
(iii) Material non-compliance by Cloudvault with its sub-processor obligations, as identified through Meridian's annual audit, VMS's review of third-party certifications, or other credible information; or
(iv) A material change in Cloudvault's ownership, control, management, or infrastructure that could affect its processing of VMS data.
The direct audit should be conducted upon reasonable advance notice (which we recommend be not less than ten (10) business days, consistent with VMS's general audit notice proposal) and at VMS's cost, except as noted below regarding incident-triggered audits.
Third-Party Certifications as Audit Supplement. As a practical alternative to annual on-site audits — and recognizing that direct audits of cloud infrastructure providers are operationally burdensome and may not be welcomed by Cloudvault — VMS may accept a current SOC 2 Type II report or equivalent certification (e.g., ISO 27001 certification, ISO 27701 certification) for Cloudvault's AutoCloud platform as a supplement to (though not a complete substitute for) the annual audit requirement. To be acceptable, the SOC 2 Type II report must:
(a) Cover the data center(s) at which VMS data is processed and stored (currently the Columbus, Ohio facility);
(b) Address relevant trust services criteria, including security, availability, confidentiality, and (if applicable) privacy; and
(c) Be current (i.e., issued within the preceding twelve months and covering an examination period that includes the most recent reporting period).
VMS should retain the right to reject a SOC 2 Type II report as insufficient if the scope of the report does not adequately cover the processing activities performed on VMS data, or if the report identifies material control deficiencies or qualified opinions.
Cost Allocation for Incident-Triggered Audits. The $25,000 cost-sharing cap proposed by Meridian in the general audit rights provisions should not apply to sub-processor audits triggered by a data security incident, suspected data breach, or material non-compliance. In such circumstances, the audit costs — whether incurred by VMS directly or through a third-party auditor — should be borne by Meridian. This allocation is appropriate because incident-triggered audits are necessitated by a failure in the data protection chain for which Meridian is responsible, and Meridian should not be able to shift the costs of investigating such failures to VMS.
C. Coordination with Pinehurst
As noted in Sections II.C and III.D above, VMS's engagement of Pinehurst Cybersecurity Advisors to assess Meridian's data processing environment presents an opportunity to obtain an independent technical evaluation of Cloudvault's AutoCloud platform and Columbus, Ohio data center before VMS finalizes its approval of Cloudvault as a sub-processor.
We recommend that VMS, outside the scope of Calderwood & Harkness's engagement (as the Pinehurst engagement is managed by VMS's Information Security team), request that Pinehurst's assessment scope be expanded to include a specific evaluation of:
• Cloudvault's technical security controls for the AutoCloud platform, including encryption, access control, network security, and vulnerability management;