INITIAL DRAFT — PRIVILEGED & CONFIDENTIAL — PREPARED BY CALDERWOOD & HARKNESS LLP
DATA SECURITY ADDENDUM
Addendum to the Master Data License Agreement by and between Meridian Credit intelligence, Inc. and Quorum Insurance Holdings Corp.
Prepared by: David Cartwright, Partner Lisa Johannsen, Associate Data Privacy & Cybersecurity Practice Calderwood & Harkness LLP 425 Park Avenue New York, NY 10022
January 2023 C&H Matter No.: 1025-00008
This Data Security Addendum (this "DSA" or this "Addendum") is entered into as a schedule and addendum to the Master Data License Agreement (the "MDLA" or the "Agreement") dated [●], 2023, by and between Meridian Credit intelligence, Inc., a Georgia corporation ("Licensor" or "Meridian"), and Quorum Insurance Holdings Corp., a Delaware corporation ("Licensee" or "Quorum," and together with Meridian, the "Parties," and each, a "Party").
Capitalized terms used but not defined in this DSA shall have the meanings ascribed to such terms in the MDLA. In the event of any conflict between this DSA and the body of the MDLA with respect to data security matters, the terms of this DSA shall control.
Right-click to update Table of Contents
ARTICLE 1 — DEFINITIONS
1.1 "Authorized Personnel." "Authorized Personnel" means employees, contractors, and agents of either Party who (a) have been granted access to Licensed Data or Confidential Information in connection with the performance of their duties under the MDLA or this DSA, (b) have undergone the background checks required by Section 5.6 of this DSA, and (c) have completed the security awareness training required by Section 5.7 of this DSA. For the avoidance of doubt, Authorized Personnel includes personnel of a Party's Sub-processors only to the extent such Sub-processors have been approved in accordance with Article 10 of this DSA and the personnel of such Sub-processors satisfy the requirements of clauses (b) and (c) above.
1.2 "Data Breach" or "Security Incident." "Data Breach" or "Security Incident" means (a) any unauthorized access to, acquisition of, use of, disclosure of, alteration of, destruction of, or loss of Licensed Data, whether in electronic or physical form, including consumer credit-file data (MCI Consumer Credit File™), commercial credit data (MCI CommercialView™), alternative data (MCI AltSignal™), or any data derived therefrom; (b) any compromise, intrusion, or breach of systems, networks, applications, or infrastructure that store, process, or transmit Licensed Data; (c) any unauthorized access to or exfiltration of credentials, encryption keys, or other security mechanisms used to protect Licensed Data; or (d) any other event that, under Applicable Data Protection Laws, constitutes a breach, security incident, or unauthorized access requiring notification to individuals, regulatory authorities, or other parties. A Data Breach or Security Incident shall include both confirmed incidents and reasonably suspected incidents pending investigation and confirmation.
1.3 "Licensed Data." "Licensed Data" has the meaning set forth in the MDLA and, for purposes of this DSA, includes all data products delivered by Meridian to Quorum under the MDLA, including without limitation: (a) approximately 310 million consumer credit records delivered via the MCI Consumer Credit File™ product suite; (b) approximately 42 million commercial business records delivered via the MCI CommercialView™ product suite; and (c) approximately 85 million consumer alternative-data records delivered via the MCI AltSignal™ product suite. Licensed Data also includes all metadata, indices, keys, and identifiers delivered in connection with the foregoing data products.
1.4 "Information Security Program." "Information Security Program" means the comprehensive written program of administrative, technical, and physical safeguards established, implemented, and maintained by a Party in accordance with Article 3 of this DSA to protect the confidentiality, integrity, and availability of Licensed Data. An Information Security Program includes, without limitation, written policies and procedures, technical controls, personnel security measures, physical security measures, incident response plans, and business continuity and disaster recovery plans.
1.5 "Personal Information." "Personal Information" means any information that constitutes "personal information," "personally identifiable information," "personal data," "nonpublic personal information," "private information," or any similar term as defined under Applicable Data Protection Laws, including but not limited to the Fair Credit Reporting Act ("FCRA"), 15 U.S.C. § 1681 et seq.; the Gramm-Leach-Bliley Act ("GLBA"), 15 U.S.C. § 6801 et seq.; the California Consumer Privacy Act, as amended by the California Privacy Rights Act ("CCPA/CPRA"), Cal. Civ. Code § 1798.100 et seq.; and applicable state insurance data-security regulations.
1.6 "Sub-processor." "Sub-processor" means any third-party service provider, subcontractor, vendor, or other entity engaged by either Party that will have access to, receive, process, store, or transmit Licensed Data on that Party's behalf in connection with the performance of such Party's obligations under the MDLA or this DSA. For the avoidance of doubt, the term Sub-processor includes cloud infrastructure providers, managed security service providers, data hosting providers, and any other third party to whom Licensed Data is made available.
1.7 "Security Standards." "Security Standards" means, collectively, (a) the American Institute of Certified Public Accountants ("AICPA") SOC 2 Type II standards (Trust Services Criteria — Security, Availability, Confidentiality, Processing Integrity, and Privacy); (b) ISO/IEC 27001:2022 (Information Security Management Systems — Requirements); and (c) such additional standards as are specifically referenced in this DSA, including without limitation the Center for Internet Security ("CIS") Benchmarks, NIST Special Publication 800-57 (Recommendation for Key Management), and NIST Special Publication 800-88 (Guidelines for Media Sanitization).
1.8 "Applicable Data Protection Laws." "Applicable Data Protection Laws" means all applicable federal, state, and local laws, statutes, regulations, rules, ordinances, regulatory guidance, directives, and orders governing the security, privacy, protection, collection, use, storage, processing, disclosure, transfer, or destruction of data, including without limitation: (a) the FCRA and its implementing regulations, including Regulation V (12 C.F.R. Part 1022); (b) the GLBA and its implementing regulations, including the FTC Safeguards Rule (16 C.F.R. Part 314) and Regulation P (12 C.F.R. Part 1016); (c) the CCPA/CPRA and its implementing regulations; (d) the New York Department of Financial Services Cybersecurity Regulation, 23 NYCRR Part 500 (the "NY DFS Cybersecurity Regulation"); (e) the Connecticut Insurance Data Security Law (Conn. Gen. Stat. § 38a-38); (f) all other applicable state breach notification statutes; (g) all applicable state insurance data-security regulations; and (h) all other federal, state, and local laws of similar scope and purpose.
ARTICLE 2 — SCOPE AND APPLICABILITY
2.1 Scope. This DSA applies to all Licensed Data received, transmitted, stored, processed, accessed, or otherwise handled by either Party or its Sub-processors in connection with the MDLA. Without limiting the generality of the foregoing, this DSA governs the security obligations applicable to Licensed Data delivered via Meridian's SFTP batch transfer systems, Meridian's REST API (including real-time MCI Consumer Credit File delivery endpoints), and any other data delivery mechanism utilized by the Parties under the MDLA, whether existing as of the date hereof or implemented during the term of the MDLA.
2.2 Applicability to Derived Data. [Note: The treatment of Derived Data under this DSA is subject to the resolution of the Derived Data provisions in Article VII of the MDLA. The Parties have not yet reached agreement on the scope of Quorum's rights to create, use, retain, and transfer Derived Data. For purposes of this initial draft, the data security obligations set forth herein apply to Licensed Data and, to the extent such data constitutes Personal Information, to Derived Data as well. This provision is bracketed and will require conforming changes once the Article VII impasse is resolved.]
2.3 Regulatory Overlay. Both Parties acknowledge and agree that the Licensed Data is subject to extensive and evolving regulation under, among other laws, the FCRA, the GLBA, the CCPA/CPRA, the NY DFS Cybersecurity Regulation (23 NYCRR 500), and state insurance data-security requirements applicable to Quorum's insurance operations across all fifty (50) states and the District of Columbia. This DSA is intended to supplement, and not to replace, each Party's independent obligations under Applicable Data Protection Laws. Nothing in this DSA shall be construed to limit, reduce, or modify either Party's obligations under Applicable Data Protection Laws, and each Party shall remain independently responsible for its own regulatory compliance.
2.4 Conflict with MDLA. In the event of any inconsistency or conflict between the terms and conditions of this DSA and the terms and conditions of the body of the MDLA with respect to data security matters, the terms and conditions of this DSA shall control and govern. For the avoidance of doubt, the foregoing shall not affect the interpretation or enforceability of provisions of the MDLA that address matters other than data security.
ARTICLE 3 — INFORMATION SECURITY PROGRAM REQUIREMENTS
3.1 General Obligation. Each Party shall establish, implement, and maintain a comprehensive, written Information Security Program that includes administrative, technical, and physical safeguards designed to: (a) protect the confidentiality, integrity, and availability of Licensed Data; (b) protect against any anticipated threats or hazards to the security or integrity of Licensed Data; (c) protect against unauthorized access to, acquisition of, or use of Licensed Data; and (d) ensure the proper disposal of Licensed Data in accordance with this DSA and Applicable Data Protection Laws. Each Party's Information Security Program shall be appropriate to the size and complexity of that Party's operations, the nature and scope of its activities, and the sensitivity of the Licensed Data it receives, stores, processes, or transmits.
3.2 Risk Assessment. Each Party shall conduct periodic risk assessments, no less frequently than annually, to identify and evaluate reasonably foreseeable internal and external threats, vulnerabilities, and risks to the security, confidentiality, integrity, and availability of Licensed Data. Each risk assessment shall evaluate the sufficiency of the Party's existing safeguards and shall be used to inform updates to the Party's Information Security Program. Risk assessments shall be documented in writing and shall be retained for a minimum of five (5) years. Each Party shall update its Information Security Program promptly following completion of each risk assessment to address any identified gaps, deficiencies, or changes in the threat landscape.
3.3 Minimum Security Standards. The Information Security Program of each Party shall, at a minimum, comply with the following Security Standards:
(a) SOC 2 Type II — Trust Services Criteria for Security, Availability, Confidentiality, Processing Integrity, and Privacy, as published by the AICPA;
(b) ISO 27001:2022 — Information Security Management Systems — Requirements, as published by the International Organization for Standardization and the International Electrotechnical Commission; and
(c) Applicable Data Protection Laws, including without limitation the requirements of the NY DFS Cybersecurity Regulation (23 NYCRR 500), the GLBA Safeguards Rule, and applicable state insurance data-security regulations.
In the event that any Security Standard referenced herein is superseded, replaced, or updated during the term of the MDLA, each Party shall comply with the successor or updated standard within a commercially reasonable period following the effective date of such successor or updated standard, and in no event later than twelve (12) months following publication of the successor or updated standard.
3.4 Policy Documentation. Each Party shall maintain comprehensive written information security policies and procedures that address, at a minimum, the following subject areas:
(a) acceptable use of information systems and data;
(b) access control, including identity and access management, authentication, and authorization;
(c) change management and configuration management;
(d) incident response and breach notification;
(e) business continuity and disaster recovery;
(f) data classification and handling;
(g) encryption and key management;
(h) network security and perimeter defense;
(i) vulnerability management and patch management;
(j) physical and environmental security;
(k) employee and contractor security awareness training;
(l) vendor and Sub-processor risk management;
(m) secure software development lifecycle (for systems that process Licensed Data); and
(n) data retention, return, and secure destruction.
All policies and procedures shall be reviewed, and updated as necessary, at least annually by qualified information security personnel. Each Party shall make its information security policies and procedures available to the other Party upon reasonable request, subject to redaction of proprietary internal security architecture details that, if disclosed, could compromise the disclosing Party's security posture.
3.5 Updates and Improvements. Each Party shall continuously monitor the threat landscape and shall update its Information Security Program on an ongoing basis to respond to: (a) new and emerging threats, vulnerabilities, and attack vectors; (b) findings from risk assessments, penetration testing, and vulnerability scanning; (c) lessons learned from Data Breaches or Security Incidents (whether affecting that Party, the other Party, or the industry generally); and (d) changes in Applicable Data Protection Laws, regulatory guidance, or industry best practices. Each Party shall notify the other Party within thirty (30) days of any material change to its Information Security Program that could reasonably be expected to affect the security of Licensed Data.
ARTICLE 4 — SECURITY CERTIFICATIONS AND AUDIT REPORTS
4.1 Meridian Certifications. Meridian shall obtain and maintain, at a minimum, the following certifications and reports throughout the term of the MDLA:
(a) SOC 2 Type II Report. A SOC 2 Type II report prepared by an independent certified public accounting firm in accordance with AICPA attestation standards. Meridian's most recent SOC 2 Type II report was issued by Galloway Nash LLP and covers the examination period ending March 31, 2023. Meridian shall obtain a new SOC 2 Type II report at least annually.
(b) ISO 27001 Certification. An ISO 27001:2022 certification from a nationally recognized, accredited certification body. Meridian shall maintain the currency of its ISO 27001 certification and shall promptly notify Quorum of any suspension, withdrawal, or material qualification of such certification.
4.2 Quorum Certifications. Quorum shall obtain and maintain, at a minimum, the following certification and report throughout the term of the MDLA:
(a) SOC 2 Type II Report. A SOC 2 Type II report prepared by an independent certified public accounting firm in accordance with AICPA attestation standards. Quorum's most recent SOC 2 Type II report was issued by Felton Thorpe & Co. LLP and covers the examination period ending December 31, 2023. Quorum shall obtain a new SOC 2 Type II report at least annually.
4.3 Annual Delivery of Reports. Each Party shall deliver to the other Party a copy of its most recent SOC 2 Type II report and ISO 27001 certificate (if applicable) within thirty (30) days following issuance, and in any event no less than once annually. Delivery shall be made to the security contacts identified in Exhibit B. Each Party acknowledges that SOC 2 Type II reports and ISO 27001 certificates constitute Confidential Information of the issuing Party and shall be treated in accordance with the confidentiality provisions of the MDLA and the Mutual NDA (Reference No. NDA-QIH-MCI-2022-001).
4.4 Remediation of Findings. If a Party's SOC 2 Type II report or ISO 27001 audit identifies material control deficiencies, exceptions, qualifications, or findings of non-conformance, the affected Party shall:
(a) notify the other Party of such findings within ten (10) business days of the affected Party's receipt of the report or audit findings;
(b) provide a written remediation plan to the other Party within thirty (30) days of the affected Party's receipt of the report or audit findings, which plan shall identify the specific deficiencies, the proposed remedial measures, the responsible personnel, and the target completion dates; and
(c) complete remediation of all material deficiencies within ninety (90) days of the affected Party's receipt of the report or audit findings, or within such shorter period as may be required by the severity of the deficiency or by Applicable Data Protection Laws.
The affected Party shall provide periodic written updates on the status of remediation efforts and shall promptly notify the other Party upon completion of remediation. Failure to remediate material control deficiencies within the time periods specified herein may constitute a material breach of this DSA.
ARTICLE 5 — ACCESS CONTROLS
5.1 Principle of Least Privilege. Each Party shall restrict access to Licensed Data to Authorized Personnel on a need-to-know, least-privilege basis. Access to Licensed Data shall be limited to the minimum level of access necessary for each individual to perform his or her assigned duties in connection with the MDLA. No individual shall be granted access to Licensed Data in excess of what is required by such individual's role and responsibilities.
5.2 Role-Based Access Controls (RBAC). Each Party shall implement and enforce role-based access controls ("RBAC") for all systems, applications, databases, and environments that store, process, or transmit Licensed Data. Roles shall be defined based on job function and business need, and access permissions shall be assigned to roles rather than to individual users. Each Party shall document its RBAC framework and shall review and update role definitions at least annually or upon material changes to organizational structure or business processes.
5.3 Authentication Standards. Each Party shall require multi-factor authentication ("MFA") for:
(a) all remote access to systems, networks, or applications containing Licensed Data, including VPN connections, remote desktop access, and cloud-based environments;
(b) all access to administrative, privileged, or root-level accounts on systems that store, process, or transmit Licensed Data;
(c) all API access to data feeds, including the REST API used for real-time MCI Consumer Credit File™ delivery, and all SFTP batch connections; and
(d) all access to encryption key management systems and security monitoring tools.
MFA shall utilize, at a minimum, two of the following authentication factors: (i) something the user knows (e.g., password or passphrase); (ii) something the user has (e.g., hardware token, smart card, or mobile application); or (iii) something the user is (e.g., biometric identifier). Password requirements shall mandate a minimum length of fourteen (14) characters, complexity requirements, and prohibition on password reuse for at least twelve (12) prior passwords.
5.4 Unique Identifiers. Each individual granted access to systems, applications, or environments containing Licensed Data shall be assigned a unique user identifier. The use of shared, generic, group, or service accounts by individual users is prohibited. Service accounts used by automated processes shall be uniquely identified, documented, and subject to heightened monitoring and access review.
5.5 Access Reviews. Each Party shall conduct formal access reviews at least quarterly to ensure that access rights to systems containing Licensed Data remain appropriate and commensurate with each individual's current role and responsibilities. Access reviews shall include verification that: (a) terminated personnel have had their access promptly revoked; (b) personnel who have changed roles have had their access adjusted accordingly; (c) dormant or inactive accounts have been disabled or removed; and (d) privileged access remains limited to those individuals with a demonstrated business need. Each Party shall promptly revoke access for terminated personnel — in no event later than twenty-four (24) hours following termination of employment or engagement — and shall adjust access rights within five (5) business days following a change of role.
5.6 Background Checks. Each Party shall conduct appropriate background checks on all Authorized Personnel who will have access to Licensed Data, consistent with applicable law. Background checks shall be conducted prior to the individual being granted access to Licensed Data and shall include, at a minimum and to the extent permitted by applicable law: (a) verification of identity; (b) criminal history check; and (c) verification of employment history. Each Party shall maintain documentation of completed background checks and shall make such documentation available for audit upon request by the other Party.
5.7 Security Awareness Training. Each Party shall require all Authorized Personnel to complete comprehensive data security and privacy awareness training upon initial onboarding and at least annually thereafter. Training content shall include, at a minimum:
(a) the proper handling, storage, and transmission of consumer credit information and other Licensed Data;
(b) obligations under the FCRA, GLBA, and other Applicable Data Protection Laws;
(c) recognition and response to phishing, social engineering, and other common attack vectors;
(d) the Party's information security policies and procedures, including acceptable use and data classification;
(e) the Party's incident response procedures and each individual's responsibilities in the event of a Data Breach or Security Incident; and
(f) the consequences of non-compliance with information security policies.
Each Party shall maintain records of training completion for all Authorized Personnel and shall make such records available for audit upon request by the other Party. Authorized Personnel who fail to complete required training within the prescribed timeframe shall have their access to Licensed Data suspended until training is completed.
ARTICLE 6 — ENCRYPTION REQUIREMENTS
6.1 Data in Transit. All Licensed Data transmitted between the Parties — whether via SFTP batch transfer, REST API, or any other electronic delivery method — shall be encrypted using Transport Layer Security ("TLS") version 1.2 or higher, or an equivalent or successor cryptographic protocol providing an equivalent or greater level of security, with a minimum key length of 256 bits. The Parties shall negotiate and use only cipher suites that are recommended by current NIST guidelines and shall disable all deprecated or weak cipher suites, including but not limited to SSL 2.0, SSL 3.0, and TLS 1.0.
6.2 Data at Rest. All Licensed Data stored by either Party, including data stored on servers, databases, data warehouses, data lakes, storage area networks, backup media, archival media, portable devices, and any other storage medium (whether on-premises or in cloud environments), shall be encrypted using the Advanced Encryption Standard ("AES") with a key length of 256 bits ("AES-256") or an equivalent encryption standard providing an equivalent or greater level of security. Full-disk encryption alone shall not be sufficient; database-level and field-level encryption shall be implemented for Licensed Data elements that constitute Personal Information.
6.3 Key Management. Each Party shall implement and maintain a comprehensive encryption key management program consistent with NIST Special Publication 800-57 (Recommendation for Key Management) or an equivalent key management framework. The key management program shall address, at a minimum:
(a) Key Generation — Cryptographic keys shall be generated using cryptographically secure random number generators in accordance with NIST SP 800-90A or equivalent;
(b) Key Distribution — Keys shall be distributed using secure channels and shall not be transmitted in plaintext;
(c) Key Storage — Keys shall be stored in hardware security modules ("HSMs") or equivalent secure key storage mechanisms, separate from the data they protect;
(d) Key Rotation — Cryptographic keys shall be rotated at least annually, and more frequently if warranted by security considerations or regulatory requirements;
(e) Key Revocation and Destruction — Compromised or retired keys shall be promptly revoked and securely destroyed using methods that prevent recovery; and
(f) Key Escrow — Key escrow, if utilized, shall be subject to appropriate access controls and documented procedures.
6.4 Prohibition on Unencrypted Transmission. Neither Party shall transmit Licensed Data in unencrypted form under any circumstances, including via email, instant messaging, file-sharing services, removable media (e.g., USB drives, external hard drives), or cloud storage platforms, unless expressly approved in advance in writing by the other Party's Chief Information Security Officer (or equivalent senior security executive). Any such approval shall specify the scope, duration, and compensating controls applicable to the approved transmission and shall be documented in writing.
ARTICLE 7 — NETWORK SECURITY AND SYSTEM HARDENING
7.1 Network Segmentation. Each Party shall implement network segmentation to isolate systems, applications, and environments that store, process, or transmit Licensed Data from other network segments, including general corporate networks, development and testing environments, and guest or public-facing networks. Segmentation shall be enforced using firewalls, virtual local area networks ("VLANs"), access control lists, or equivalent technical controls. Inter-segment communication shall be restricted to the minimum necessary for authorized business purposes and shall be subject to monitoring and logging.
7.2 Firewalls and Intrusion Detection/Prevention. Each Party shall deploy and maintain next-generation firewalls, intrusion detection systems ("IDS"), and intrusion prevention systems ("IPS") on all network perimeters and at key internal boundaries within the network architecture. Firewall rule sets shall be reviewed and updated at least quarterly, and all unnecessary ports, protocols, and services shall be disabled. IDS/IPS systems shall be configured to generate real-time alerts for suspicious or anomalous activity and shall be monitored on a 24/7 basis by qualified security operations personnel.
7.3 Vulnerability Management. Each Party shall maintain a comprehensive vulnerability management program that includes:
(a) Regular Vulnerability Scanning — Automated vulnerability scanning of all systems, applications, and network infrastructure that store, process, or transmit Licensed Data shall be conducted at least monthly, and additionally following any material change to the environment. Scanning shall include both authenticated and unauthenticated scans.
(b) Timely Patch Management — Security patches and updates shall be applied in a timely manner based on risk severity:
(i) Critical patches (CVSS score 9.0 or above): within seventy-two (72) hours of public release or vendor notification;
(ii) High-severity patches (CVSS score 7.0–8.9): within fourteen (14) days of public release or vendor notification;
(iii) Non-critical patches (CVSS score below 7.0): within thirty (30) days of public release or vendor notification.
(c) Exception Management — Where a patch cannot be applied within the specified timeframe due to operational constraints, the affected Party shall document the exception, implement compensating controls, and remediate the vulnerability as soon as practicable.
7.4 System Hardening. All systems, servers, endpoints, and applications that store, process, or transmit Licensed Data shall be hardened in accordance with CIS Benchmarks or equivalent industry-recognized hardening standards. System hardening shall include, at a minimum: (a) removal or disabling of unnecessary services, protocols, daemons, and default accounts; (b) configuration of operating systems, applications, and databases to secure baseline configurations; (c) disabling of auto-run and auto-play features on endpoints; and (d) implementation of application whitelisting on critical systems where technically feasible.
7.5 Logging and Monitoring. Each Party shall implement comprehensive logging and real-time monitoring of all access to, and activity involving, Licensed Data. Logs shall capture, at a minimum: (a) user authentication events (successful and failed); (b) access to systems and data stores containing Licensed Data; (c) administrative and privileged actions; (d) changes to security configurations, access controls, and firewall rules; (e) data export, download, and transfer events; and (f) security alerts generated by IDS/IPS, antivirus, and other security tools. Log data shall be protected against unauthorized modification or deletion, shall be stored in a centralized log management or security information and event management ("SIEM") system, and shall be retained for a minimum of twelve (12) months online and accessible for search and analysis. Logs required for regulatory compliance purposes shall be retained for such longer periods as may be required by Applicable Data Protection Laws.
ARTICLE 8 — PENETRATION TESTING
8.1 Annual Testing. Each Party shall engage a qualified, independent third-party security firm to conduct penetration testing of the systems, applications, and infrastructure that store, process, or transmit Licensed Data at least once per calendar year. The third-party security firm shall possess recognized certifications (e.g., CREST, OSCP, GPEN) and shall have no material business relationship with the tested Party that could compromise the independence or objectivity of the testing engagement.
8.2 Scope of Testing. Penetration testing shall be comprehensive in scope and shall include, at a minimum:
(a) External Penetration Testing — Testing of externally facing systems, network perimeters, and internet-accessible services;
(b) Internal Penetration Testing — Testing of internal network segments, systems, and applications accessible from within the corporate network;
(c) Web Application Testing — Testing of web applications, including API endpoints used for Licensed Data delivery (specifically including the REST API endpoints used for real-time MCI Consumer Credit File™ delivery and the SFTP batch transfer interfaces);
(d) Social Engineering Assessments — Testing of personnel resilience to social engineering, phishing, and pretexting attacks; and
(e) Physical Security Testing — Testing of physical security controls at data centers and facilities where Licensed Data is stored or processed, including badge access, tailgating prevention, and visitor management controls.
8.3 Remediation. Any vulnerabilities identified through penetration testing shall be remediated according to risk severity in accordance with the following timelines:
Where remediation cannot be completed within the applicable timeframe, the affected Party shall implement compensating controls, document the exception and the basis therefor, and remediate the vulnerability as soon as practicable. The affected Party shall notify the other Party of any Critical or High severity vulnerabilities that cannot be remediated within the applicable timeframe.
8.4 Reporting. Each Party shall provide the other Party with an executive summary of penetration test results, including a description of identified vulnerabilities and current remediation status, within thirty (30) days following the completion of each penetration test. Full penetration test reports, including detailed technical findings and proof-of-concept materials, shall be made available to the other Party upon reasonable written request, subject to reasonable redaction of proprietary security architecture information that, if disclosed, could compromise the tested Party's security posture. All penetration test reports and executive summaries shall be treated as Confidential Information of the tested Party.
8.5 Meridian's Right to Test Quorum. In addition to the annual penetration testing requirement set forth in Section 8.1, Meridian may, upon sixty (60) days' prior written notice and no more frequently than once per calendar year, engage a mutually approved independent third-party security firm to conduct penetration testing of Quorum's systems, applications, and infrastructure that receive, store, or process Licensed Data. Such testing shall be conducted at Meridian's sole cost and expense. Quorum shall not unreasonably withhold, condition, or delay its approval of the proposed third-party security firm. Testing shall be conducted during mutually agreed timeframes and in a manner designed to minimize disruption to Quorum's operations. Quorum shall provide reasonable cooperation and access as necessary to facilitate such testing.
8.6 Quorum's Right to Test Meridian. In addition to the annual penetration testing requirement set forth in Section 8.1, Quorum may, upon sixty (60) days' prior written notice and no more frequently than once per calendar year, engage a mutually approved independent third-party security firm to conduct penetration testing of Meridian's systems, applications, and infrastructure that deliver, store, or process Licensed Data. Such testing shall be conducted at Quorum's sole cost and expense. Meridian shall not unreasonably withhold, condition, or delay its approval of the proposed third-party security firm. Testing shall be conducted during mutually agreed timeframes and in a manner designed to minimize disruption to Meridian's operations. Meridian shall provide reasonable cooperation and access as necessary to facilitate such testing.
ARTICLE 9 — DATA BREACH NOTIFICATION AND INCIDENT RESPONSE
9.1 Notification Obligation — 48 Hours. In the event either Party discovers or reasonably suspects a Data Breach or Security Incident affecting Licensed Data, that Party (the "Notifying Party") shall notify the other Party (the "Receiving Party") in writing within forty-eight (48) hours of the Notifying Party's discovery of the Data Breach or Security Incident. For purposes of this Section, "Discovery" shall mean the time at which the Notifying Party first becomes aware of facts sufficient to constitute a reasonable basis for believing that a Data Breach or Security Incident has occurred, whether through its own investigation, notification from a third party, or otherwise. Notification shall be provided to the security contacts identified in Exhibit B, utilizing the emergency contact procedures specified therein.
9.2 Contents of Initial Notification. The initial notification provided under Section 9.1 shall include, to the extent known or reasonably determinable at the time of notification:
(a) a description of the nature and circumstances of the Data Breach or Security Incident, including the categories of Licensed Data affected (e.g., MCI Consumer Credit File™ data, MCI CommercialView™ data, MCI AltSignal™ data) and the approximate number of records or individuals affected;
(b) the date and time of discovery of the Data Breach or Security Incident, and the estimated date and time of occurrence, if different;
(c) a description of the measures taken or proposed to be taken to contain and mitigate the Data Breach or Security Incident, including any immediate remedial actions;
(d) the identity and contact information of the designated incident response contact person for the Notifying Party;
(e) whether law enforcement or any regulatory authority has been contacted, and if so, the identity of such authority and the date of contact; and
(f) any other information reasonably necessary for the Receiving Party to understand the scope and potential impact of the Data Breach or Security Incident.
If the Notifying Party is unable to provide all of the foregoing information within the forty-eight (48) hour notification window, the Notifying Party shall provide the information that is then available and shall supplement the notification as additional information becomes available, in accordance with Section 9.3.
9.3 Supplemental Notifications. The Notifying Party shall provide supplemental written notifications to the Receiving Party as additional information becomes available regarding the Data Breach or Security Incident. Supplemental notifications shall be provided promptly and shall include, as applicable: (a) updated information regarding the scope and impact of the Data Breach, including revised estimates of the number of records or individuals affected; (b) results of the root cause analysis; (c) the identity of any third parties involved in or affected by the Data Breach; (d) detailed remediation steps taken and planned; and (e) any other material developments. The Notifying Party shall provide supplemental notifications no less frequently than every seventy-two (72) hours during the active investigation phase of the Data Breach or Security Incident, and weekly thereafter until the investigation and remediation are complete.
9.4 Incident Response Procedures. Each Party shall develop, implement, and maintain a comprehensive written incident response plan that addresses, at a minimum, the following phases and elements:
(a) Detection and Initial Assessment — Procedures for detecting potential Data Breaches or Security Incidents, including monitoring and alerting mechanisms, initial triage and classification, and escalation procedures;
(b) Containment and Eradication — Procedures for containing the Data Breach or Security Incident to prevent further unauthorized access, exfiltration, or damage, including isolation of affected systems, revocation of compromised credentials, and eradication of the threat vector;
(c) Forensic Investigation — Procedures for conducting a thorough forensic investigation of the Data Breach or Security Incident, including engagement of a qualified third-party digital forensics firm if warranted by the nature or scope of the incident. Each Party shall maintain a retainer agreement with at least one nationally recognized digital forensics firm;
(d) Notification — Procedures for providing timely notification to affected individuals, regulatory agencies, law enforcement, and other parties as required by Applicable Data Protection Laws, including compliance with specific notification timeframes established by applicable statutes and regulations;
(e) Remediation and Post-Incident Review — Procedures for remediating the vulnerabilities or deficiencies that contributed to the Data Breach or Security Incident, implementing corrective measures, and conducting a post-incident review ("lessons learned") to identify improvements to the Party's Information Security Program and incident response procedures.
Each Party's incident response plan shall be tested at least annually through tabletop exercises or simulated incident scenarios. Each Party shall update its incident response plan promptly following any actual Data Breach, post-incident review, or material change in its systems, operations, or regulatory environment.
9.5 Coordination. In the event of a Data Breach or Security Incident affecting Licensed Data, the Parties shall cooperate fully and in good faith to investigate, contain, remediate, and respond to the Data Breach. Cooperation shall include, without limitation:
(a) coordinating investigation and forensic analysis efforts to determine the root cause, scope, and impact of the Data Breach;
(b) sharing relevant information, data, and documentation related to the Data Breach, subject to the preservation of attorney-client privilege and work product protections;
(c) coordinating regulatory notifications and communications with affected individuals to ensure consistency, accuracy, and compliance with Applicable Data Protection Laws;
(d) agreeing on the content and timing of any public statements, press releases, or other public communications regarding the Data Breach; provided that neither Party shall issue any public statement that references the other Party, the other Party's data, or the other Party's systems without the prior written consent of the other Party, which consent shall not be unreasonably withheld, conditioned, or delayed; and
(e) cooperating with any investigation or inquiry by any regulatory authority, including the provision of information and access to personnel as may be required.
9.6 Regulatory Notification Obligations. Without limiting the general notification obligation set forth in Section 9.1, each Party shall comply with all applicable breach notification requirements under Applicable Data Protection Laws, including without limitation:
(a) the FCRA and its implementing regulations;
(b) the GLBA Safeguards Rule and related requirements;
(c) the CCPA/CPRA (which requires notification to the California Attorney General where more than 500 California residents are affected);
(d) the NY DFS Cybersecurity Regulation (23 NYCRR 500), which requires notification to the Superintendent of Financial Services within seventy-two (72) hours of a determination that a cybersecurity event has occurred;
(e) all applicable state breach notification statutes (currently enacted in all fifty states, the District of Columbia, and U.S. territories); and
(f) all other applicable federal, state, and local notification requirements.
Each Party shall keep the other Party informed of all regulatory notifications made in connection with a Data Breach affecting Licensed Data.
9.7 Costs. The Party whose acts, omissions, systems, or personnel were the proximate cause of a Data Breach or Security Incident (the "Responsible Party") shall bear all reasonable and documented costs and expenses arising from or related to the Data Breach, including without limitation: (a) costs of forensic investigation; (b) costs of notification to affected individuals, regulatory agencies, and law enforcement; (c) costs of credit monitoring, identity theft protection, and other remedial services provided to affected individuals; (d) legal fees and expenses; (e) regulatory fines, penalties, and assessments; and (f) public relations and crisis communications costs. The allocation of costs under this Section 9.7 is without prejudice to, and does not limit, either Party's indemnification rights under the MDLA or any other rights or remedies available at law or in equity.
ARTICLE 10 — SUB-PROCESSOR MANAGEMENT
10.1 Pre-Approval Requirement. Neither Party shall engage, appoint, or authorize a Sub-processor that will have access to, receive, process, store, or transmit Licensed Data without the prior written consent of the other Party. Such consent shall not be unreasonably withheld, conditioned, or delayed. A request for consent shall include the identity of the proposed Sub-processor, a description of the services to be provided, the categories and volume of Licensed Data to which the Sub-processor will have access, and the results of the engaging Party's due diligence assessment conducted pursuant to Section 10.2.
10.2 Due Diligence. Before engaging a Sub-processor, the engaging Party shall conduct and document a comprehensive due diligence assessment of the Sub-processor's information security practices, capabilities, and compliance posture. Such due diligence shall include, at a minimum: (a) review of the Sub-processor's most recent SOC 2 Type II report, ISO 27001 certification, or equivalent independent security assessment; (b) review of the Sub-processor's information security policies and procedures; (c) assessment of the Sub-processor's compliance with Applicable Data Protection Laws; (d) evaluation of the Sub-processor's incident response capabilities; and (e) assessment of the Sub-processor's financial stability and business continuity capabilities. The engaging Party shall make the results of its due diligence assessment available to the other Party upon request.
10.3 Flow-Down Obligations. Each Party shall ensure that all agreements with Sub-processors include data security, confidentiality, and data protection obligations that are at least as protective of Licensed Data as those set forth in this DSA. Sub-processor agreements shall include, at a minimum: (a) obligations regarding the use, disclosure, and protection of Licensed Data; (b) obligations regarding encryption, access controls, and other technical safeguards; (c) breach notification obligations consistent with Article 9; (d) audit rights consistent with Article 13; (e) data return and destruction obligations consistent with Article 12; and (f) appropriate indemnification and liability provisions.
10.4 Liability. Each Party shall remain fully liable and responsible for any Data Breach, Security Incident, security failure, or violation of this DSA caused by or arising from the acts or omissions of its Sub-processors. The engagement of a Sub-processor shall not relieve the engaging Party of any of its obligations under this DSA or the MDLA.
10.5 List of Sub-Processors. Each Party shall maintain a current, accurate, and complete list of all Sub-processors that have access to Licensed Data, including the name, location, and a brief description of the services provided by each Sub-processor. Each Party shall provide its Sub-processor list to the other Party upon written request and shall update such list promptly following any changes.
10.6 Notification of Changes. Each Party shall provide the other Party with at least thirty (30) days' prior written notice before: (a) engaging a new Sub-processor that will have access to Licensed Data; or (b) making a material change to an existing Sub-processor arrangement (including a change in the scope of services, the categories of Licensed Data accessed, or the location of processing). The other Party shall have fifteen (15) days from receipt of such notice to object in writing to the proposed new Sub-processor or material change, on reasonable data security grounds. If the other Party objects, the Parties shall negotiate in good faith to resolve the objection. If the Parties are unable to resolve the objection within thirty (30) days, the engaging Party shall not proceed with the proposed Sub-processor engagement or change, and the matter shall be escalated to the Parties' respective Chief Information Security Officers (or equivalents) for resolution.
ARTICLE 11 — PHYSICAL SECURITY
11.1 Data Center Security. All data centers, server rooms, co-location facilities, and other physical facilities where Licensed Data is stored, processed, or from which Licensed Data is accessed (collectively, "Secured Facilities") shall be secured with, at a minimum, the following physical security controls:
(a) Restricted Access — Entry to Secured Facilities shall be restricted to Authorized Personnel through the use of multi-factor physical access controls, including badge or key card access combined with biometric authentication (e.g., fingerprint, retinal scan, or facial recognition) at all entry points;
(b) Video Surveillance — Secured Facilities shall be equipped with 24/7 closed-circuit video surveillance and monitoring, with coverage of all entry and exit points, server rooms, and critical infrastructure areas. Video recordings shall be retained for a minimum of ninety (90) days;
(c) Environmental Controls — Secured Facilities shall be equipped with appropriate environmental controls, including fire detection and suppression systems (e.g., pre-action dry pipe or clean agent suppression), HVAC climate control systems maintaining temperature and humidity within manufacturer-recommended ranges, and flood detection and protection mechanisms;
(d) Visitor Management — All visitors to Secured Facilities shall be required to sign in, present valid identification, and be escorted by Authorized Personnel at all times while within the facility. Visitor logs shall be maintained and retained for a minimum of twelve (12) months; and
(e) Perimeter Security — Secured Facilities shall be protected by appropriate perimeter security measures, including secure fencing, controlled vehicle access, and guard services, as appropriate for the facility type and location.
11.2 Secure Disposal. Licensed Data stored on physical media (including hard drives, solid-state drives, magnetic tapes, optical media, paper records, and any other tangible medium) shall be securely destroyed in accordance with NIST Special Publication 800-88 (Guidelines for Media Sanitization) compliant methods upon the expiration of applicable retention periods, upon request by the data-providing Party, or upon termination or expiration of the MDLA. Secure disposal methods shall include, as appropriate, degaussing, cryptographic erasure, physical destruction (e.g., shredding, disintegration, or incineration), or such other methods as are approved by NIST SP 800-88 for the applicable media type and data sensitivity level. Each Party shall maintain records of media disposal, including the date, method, and media identifiers, and shall make such records available for audit upon request.
ARTICLE 12 — DATA RETENTION AND RETURN/DESTRUCTION
12.1 Retention During Term. Each Party may retain Licensed Data only for so long as reasonably necessary to fulfill the purposes set forth in the MDLA and this DSA, and subject to applicable legal and regulatory retention requirements. Each Party shall implement and maintain data retention schedules that specify retention periods for Licensed Data and shall ensure that Licensed Data is not retained beyond the applicable retention period except as required by Applicable Data Protection Laws or as expressly permitted by the MDLA.
12.2 Post-Termination Return or Destruction. Upon termination or expiration of the MDLA for any reason, Quorum shall, within ninety (90) days following the effective date of such termination or expiration:
(a) return to Meridian all Licensed Data (i.e., Meridian raw data, including MCI Consumer Credit File™, MCI CommercialView™, and MCI AltSignal™ data, and all copies, extracts, and reproductions thereof) in Quorum's possession, custody, or control, using secure transmission methods consistent with Article 6 of this DSA; or
(b) securely destroy all such Licensed Data in accordance with Section 11.2 and NIST SP 800-88 compliant methods;
and shall certify such return or destruction in writing in accordance with Section 12.4.
[Note: The treatment of Derived Data following termination of the MDLA remains a disputed term under Article VII of the MDLA. The Parties have not yet reached agreement on whether Quorum may retain Derived Data following termination and, if so, under what conditions and restrictions. This provision is bracketed and will require revision upon resolution of the Article VII negotiations.]
12.3 Regulatory Retention Exception. Notwithstanding Section 12.2, either Party may retain copies of Licensed Data to the extent, and for so long as, required by Applicable Data Protection Laws, regulatory requirements, litigation hold obligations, or legal process; provided, however, that: (a) such retention shall be limited to the minimum scope and duration required by the applicable legal or regulatory requirement; (b) such retained Licensed Data shall remain subject to all security and confidentiality obligations of this DSA and the MDLA for so long as it is retained; and (c) the retaining Party shall promptly notify the other Party of the legal or regulatory basis for such retention and the anticipated duration.
12.4 Certification. Upon completion of the return or destruction of Licensed Data required by Section 12.2, the responsible Party shall provide to the other Party a written certification, signed by an authorized officer of the certifying Party (at the level of Vice President or above), confirming that all Licensed Data has been returned or destroyed in compliance with this DSA, specifying the method and date of return or destruction, and confirming that no copies, extracts, or reproductions of the Licensed Data remain in the certifying Party's possession, custody, or control (except as permitted by Section 12.3). Such certification shall be provided within ten (10) business days following the completion of return or destruction.
ARTICLE 13 — AUDIT RIGHTS
13.1 Right to Audit. Each Party (the "Auditing Party") shall have the right, upon not less than thirty (30) days' prior written notice, to audit the other Party's (the "Audited Party's") compliance with this DSA. Audits may include review and examination of:
(a) information security policies, procedures, and controls;
(b) SOC 2 Type II reports, ISO 27001 certifications, and other security assessments;
(c) penetration test results and vulnerability remediation records;
(d) Sub-processor due diligence records and agreements;
(e) incident response logs, Data Breach notification records, and post-incident review documentation;
(f) access control logs, user access review records, and personnel training records;
(g) encryption key management records;
(h) data retention and destruction records; and
(i) any other records, systems, or processes relevant to the Audited Party's compliance with this DSA.
13.2 Frequency. Audits under this Article may be conducted no more than once per calendar year under ordinary circumstances. Notwithstanding the foregoing, if a Data Breach or Security Incident has occurred that affects Licensed Data, the Auditing Party may conduct additional audits as reasonably necessary to assess the scope and impact of the Data Breach, the adequacy of the Audited Party's response and remediation, and the Audited Party's ongoing compliance with this DSA. Such additional audits shall be limited in scope to matters reasonably related to the Data Breach or Security Incident.
13.3 Conduct of Audit. Audits shall be conducted during normal business hours at the Audited Party's facilities or, where appropriate, remotely via secure means. Audits shall be conducted by the Auditing Party's qualified internal audit or information security personnel, or by a mutually agreed independent third-party auditor (e.g., a nationally recognized accounting or consulting firm with information security audit expertise). The Auditing Party shall bear all costs and expenses of the audit, including the fees and expenses of any third-party auditor. The Auditing Party and its auditors shall comply with the Audited Party's reasonable security and safety requirements while on-site at the Audited Party's facilities.
13.4 Cooperation. The Audited Party shall cooperate fully and in good faith with any audit conducted under this Article, and shall provide the Auditing Party and its authorized auditors with reasonable access to Secured Facilities, systems, records, documentation, and personnel as necessary to conduct the audit. The Audited Party shall respond in writing to any audit findings, observations, or requests for information within thirty (30) days of receipt. The Parties shall work together to schedule and conduct audits in a manner that minimizes disruption to the Audited Party's business operations.
13.5 Remediation of Audit Findings. If an audit conducted under this Article identifies non-compliance with this DSA, the non-compliant Party shall:
(a) develop a written remediation plan, including specific remedial measures, responsible personnel, and target completion dates, within thirty (30) days of receipt of the audit findings;
(b) correct all identified deficiencies within sixty (60) days of receipt of the audit findings, or within such shorter period as the severity of the deficiency requires; and
(c) provide written confirmation to the Auditing Party upon completion of all remediation activities, including evidence of the effectiveness of the remedial measures implemented.
The Auditing Party may conduct a follow-up audit to verify completion and effectiveness of remediation activities.
13.6 Confidentiality of Audit Results. All audit findings, reports, workpapers, and related materials shall be treated as Confidential Information of the Audited Party under the Mutual Non-Disclosure Agreement (Reference No. NDA-QIH-MCI-2022-001) and the confidentiality provisions of the MDLA. The Auditing Party shall not disclose audit results to any third party without the prior written consent of the Audited Party, except: (a) to the Auditing Party's legal counsel, auditors, and regulators as required by law; or (b) as required by court order or legal process.
ARTICLE 14 — BUSINESS CONTINUITY AND DISASTER RECOVERY
14.1 BC/DR Plans. Each Party shall develop, implement, and maintain comprehensive written business continuity and disaster recovery plans ("BC/DR Plans") that address the recovery and restoration of all systems, applications, and infrastructure that store, process, or transmit Licensed Data. BC/DR Plans shall be designed to ensure the continued availability and integrity of Licensed Data in the event of a disruption, disaster, or other adverse event. BC/DR Plans shall establish the following minimum recovery objectives:
(a) Recovery Time Objective (RTO): No more than twenty-four (24) hours — i.e., systems processing Licensed Data shall be restored to operational status within twenty-four (24) hours of a disruption event; and
(b) Recovery Point Objective (RPO): No more than four (4) hours — i.e., the maximum acceptable data loss shall not exceed four (4) hours' worth of Licensed Data.
BC/DR Plans shall address, at a minimum: identification of critical systems and processes; roles and responsibilities of BC/DR personnel; communication and notification procedures; procedures for failover to redundant systems; data backup and restoration procedures; and procedures for returning to normal operations following a disruption.
14.2 Annual Testing. Each Party shall test its BC/DR Plans at least annually through tabletop exercises, simulation exercises, or full failover tests. Testing shall validate the effectiveness of recovery procedures and the Party's ability to meet the RTO and RPO objectives specified in Section 14.1. Each Party shall document the results of each BC/DR test, including any deficiencies identified and corrective actions taken, and shall provide evidence of testing results to the other Party upon reasonable written request.
14.3 Geographic Redundancy. Each Party shall maintain geographically redundant data storage and processing capabilities for Licensed Data. Redundant facilities shall be located in geographically diverse locations (i.e., in separate geographic regions or at sufficient distance to mitigate the risk of a single event affecting both primary and redundant facilities). Data replication between primary and redundant facilities shall be conducted on a real-time or near-real-time basis to ensure compliance with the RPO objective specified in Section 14.1.
ARTICLE 15 — INSURANCE REQUIREMENTS