1004-00001 · Client 1004 · Diligence

privacy-data-security-diligence-memo.docx DOCUMENT M&A / Corporate

19 / 38 ← → ✕

CALDERWOOD & HARKNESS LLP Attorneys at Law

1800 Page Mill Road, Suite 200 Menlo Park, California 94025 Telephone: (650) 493-7200 Facsimile: (650) 493-7201 www.calderwoodharkness.com

PRIVILEGED AND CONFIDENTIAL ATTORNEY-CLIENT COMMUNICATION / ATTORNEY WORK PRODUCT

PRIVACY & DATA SECURITY DILIGENCE MEMORANDUM

MERIDIAN DIAGNOSTICS, INC.

TO: Elaine Cho, Managing Partner, Cobalt Ventures LP David Hargrove, Partner, Cobalt Ventures LP Morgan Tsai, VP of Legal Affairs, Cobalt Ventures LP

FROM: Kevin Ostrowski, Partner, Privacy & Data Security, Calderwood & Harkness LLP

DATE: January 28, 2026

RE: Privacy and Data Security Diligence Assessment — Meridian Diagnostics, Inc.

Matter No.: 1004-00001

This memorandum is a privileged and confidential attorney-client communication and constitutes attorney work product prepared in anticipation of litigation and in connection with the provision of legal advice. This memorandum is intended solely for the use of the addressees and should not be disclosed, distributed, or reproduced without the prior written consent of Calderwood & Harkness LLP.

Right-click to update Table of Contents

I. EXECUTIVE SUMMARY

This memorandum sets forth the findings and recommendations of Calderwood & Harkness LLP ("Calderwood & Harkness" or the "Firm") with respect to its assessment of the data privacy and data security practices of Meridian Diagnostics, Inc. (the "Company" or "Meridian"). This assessment has been conducted in connection with the proposed lead investment by Cobalt Ventures Fund III, LP ("Cobalt" or the "Fund") of Seven Million Two Hundred Thousand Dollars ($7,200,000) as part of a Twelve Million Dollar ($12,000,000) Series Seed Preferred Stock financing round (the "Financing").

Meridian Diagnostics, Inc. is a Delaware C-corporation headquartered at 225 Binney Street, Suite 400, Cambridge, Massachusetts 02142. The Company was founded on June 15, 2023, by Dr. Priya Ramaswamy, who serves as Chief Executive Officer, and Dr. Julian Ochoa, who serves as Chief Technology Officer. The Company is developing the "MeridianPulse" platform — a microfluidic point-of-care diagnostic device capable of running a 14-marker blood panel in under eight minutes from a small-volume blood sample. The MeridianPulse platform represents a potentially significant advance in rapid point-of-care diagnostics, with anticipated applications in clinical settings including hospitals, urgent care facilities, and physician offices.

As of the date of this memorandum, the Company employs eighteen (18) full-time employees and maintains a monthly burn rate of approximately One Hundred Eighty-Five Thousand Dollars ($185,000). The Company has approximately One Million Four Hundred Thousand Dollars ($1,400,000) in remaining cash from a prior friends-and-family convertible note round, which, absent the closing of the Financing, provides the Company with an estimated runway of approximately seven to eight months.

This memorandum evaluates Meridian's current data privacy and security posture across several critical dimensions, including compliance with the Health Insurance Portability and Accountability Act of 1996, as amended ("HIPAA"), including the Privacy Rule, Security Rule, and Breach Notification Rule; the Health Information Technology for Economic and Clinical Health Act ("HITECH Act"); applicable state health privacy and data security laws, with particular focus on Massachusetts and California; cybersecurity infrastructure and technical controls; organizational readiness and personnel measures; incident response and breach preparedness; third-party vendor risk management; and considerations arising from the Company's anticipated regulatory pathway with the U.S. Food and Drug Administration ("FDA").

Overall Assessment. Meridian is an early-stage, pre-commercial company with foundational privacy and security practices in place that will require meaningful maturation as the Company progresses toward clinical deployment and commercialization. The Company's leadership demonstrates awareness of the applicable regulatory landscape, and preliminary steps have been taken to establish baseline policies and procedures. However, several significant gaps have been identified — most notably, the absence of a formal HIPAA Security Rule risk analysis, the lack of a Massachusetts Written Information Security Program ("WISP"), incomplete incident response planning, and the absence of formal employee training and vendor risk management programs. These gaps are addressable and are generally consistent with the Company's early stage of development. Specific recommendations and a proposed remediation timeline are provided in Section XIII of this memorandum.

Importantly, we note that no issues have been identified in this assessment that would constitute a closing impediment for the Financing. The identified gaps are remediable and can be addressed through a structured post-closing remediation plan, the execution of which can be monitored through the annual compliance audit right that Cobalt has negotiated in the proposed Cobalt Side Letter (between the Company and Cobalt Ventures Fund III, LP, to be executed at the closing of the Financing currently scheduled for February 9, 2026). This annual audit right, which is discussed in detail in Section XI of this memorandum, will provide Cobalt with an ongoing contractual mechanism to assess and monitor the Company's privacy and security posture following the investment. The audit right complements additional information and governance rights negotiated in the Cobalt Side Letter, including a monthly KPI dashboard, cap table access, and a board observer right, all of which will enhance Cobalt's ability to monitor Company operations in the post-closing period.

II. SCOPE AND METHODOLOGY

A. Scope of Review

This privacy and data security diligence review was conducted as part of a broader legal due diligence engagement commenced on January 6, 2026, with a target completion date of January 31, 2026. Calderwood & Harkness's privacy and data security practice group was engaged specifically to evaluate those aspects of the Company's operations, policies, procedures, and technical infrastructure that pertain to the collection, use, storage, processing, transmission, and protection of personal data and health information.

The scope of this review was focused on data privacy and security matters relevant to the Company's ongoing development and anticipated commercialization of the MeridianPulse diagnostic platform. Given the Company's pre-commercial status, the assessment necessarily encompasses both the Company's current practices and its preparedness for the regulatory and compliance obligations that will attach as the platform moves into clinical validation, regulatory approval, and commercial deployment.

The regulatory frameworks examined in connection with this assessment include the following:

(a) HIPAA — including the Privacy Rule (45 C.F.R. Parts 160 and 164, Subparts A and E), the Security Rule (45 C.F.R. Parts 160 and 164, Subparts A and C), and the Breach Notification Rule (45 C.F.R. Part 164, Subpart D);

(b) HITECH Act — Subtitle D of the Health Information Technology for Economic and Clinical Health Act (Public Law 111-5), including enhanced enforcement provisions and breach notification requirements;

(c) Massachusetts Data Security Regulations — 201 CMR 17.00, Standards for the Protection of Personal Information of Residents of the Commonwealth, including the requirement to develop, implement, and maintain a comprehensive Written Information Security Program;

(d) California Consumer Privacy Act / California Privacy Rights Act — Cal. Civ. Code §§ 1798.100–1798.199.100, as amended by the CPRA (Proposition 24), including its applicability thresholds and consumer rights framework;

(e) FDA Regulations — applicable requirements regarding medical device data integrity, cybersecurity, and software validation under pre-market and post-market regulatory frameworks, including relevant FDA guidance documents on cybersecurity in medical devices; and

(f) General cybersecurity best practices — including standards and frameworks published by the National Institute of Standards and Technology ("NIST"), the International Organization for Standardization ("ISO"), and other recognized authorities.

In conducting this review, Calderwood & Harkness coordinated with Whitfield & Ames LLP, the Company's outside legal counsel, through Catherine Devereaux and Thomas Whitaker of that firm, regarding document production and responses to diligence requests. We appreciate the responsiveness and cooperation of both the Company and Whitfield & Ames throughout the diligence process.

B. Materials Reviewed

In preparing this memorandum, Calderwood & Harkness reviewed the following categories of documents and information:

1. The Company's privacy policies, including both internal-facing policies and any external-facing or patient-facing privacy notices in draft or final form;

2. Data flow diagrams and architecture documentation for the MeridianPulse platform, including depictions of data collection points, transmission pathways, storage locations, and processing workflows;

3. The Company's information security policies and procedures manual (version 1.2, dated September 2025);

4. Relevant provisions of the Company's employee handbook pertaining to data privacy, confidentiality, acceptable use of technology, and information security;

5. Executed confidentiality and Proprietary Information and Inventions Assignment Agreements ("PIIAs") for current employees, to the extent available;

6. Third-party vendor and service provider agreements, including cloud hosting agreements, software licensing agreements, and professional services engagement letters;

7. Existing Business Associate Agreements ("BAAs") executed between the Company and its cloud infrastructure providers;

8. The Company's draft incident response plan (version 0.8, dated November 2025), prepared by Dr. Julian Ochoa;

9. IT infrastructure documentation, including cloud environment configurations, network architecture descriptions, and any cybersecurity audit reports or assessments (noting that no formal external audit has been conducted to date);

10. The Company's responses to the Calderwood & Harkness Privacy and Security Diligence Questionnaire (submitted January 10, 2026; responses received January 17, 2026, with supplemental responses received January 22, 2026);

11. Memoranda and notes from discussions conducted by Calderwood & Harkness attorneys with Dr. Julian Ochoa (CTO) on January 14, 2026, and Nadia Chen (VP of Operations) on January 15, 2026, regarding the Company's current data privacy and security practices; and

12. The Company's intellectual property portfolio documentation, including five (5) issued U.S. utility patents and three (3) pending PCT applications, which were reviewed for data-related claims and embedded security features relevant to the MeridianPulse platform.

A complete itemized list of all documents reviewed is set forth in Appendix A to this memorandum.

C. Limitations. Several limitations apply to this assessment, which should be taken into account in evaluating the findings and recommendations set forth herein.

First, Meridian is a pre-commercial, early-stage company. Many of the Company's data privacy and security practices are still under active development, and the Company has not yet reached the stage of maturity at which a fully developed compliance infrastructure would be expected. The findings in this memorandum should be understood in that context.

Second, no independent penetration testing, vulnerability scanning, or technical security audit was conducted by Calderwood & Harkness or by any third party engaged by the Firm in connection with this assessment. This review was limited to a documentary and interview-based assessment of the Company's policies, procedures, technical controls, and organizational measures. The technical findings set forth herein are based on the Company's representations and documentation, and have not been independently verified through technical testing.

Third, the Company's auditors, Graystone & Pallister CPAs, LLP, have not performed a Service Organization Control ("SOC") 2 examination or any similar information security audit of the Company's systems or controls. Accordingly, no independent third-party assurance report regarding the design or operating effectiveness of the Company's security controls was available for review.

Fourth, this assessment reflects the Company's data privacy and security posture as of January 2026. The Company's practices and risk profile will necessarily evolve as it progresses toward clinical validation, regulatory submissions, and commercial deployment. The recommendations set forth in this memorandum are intended to guide that evolution, but ongoing monitoring and reassessment will be required.

III. COMPANY OVERVIEW AND DATA ENVIRONMENT

A. Business Overview

Meridian Diagnostics, Inc. is developing the MeridianPulse platform, a microfluidic point-of-care diagnostic device designed to perform a 14-marker blood panel from a small-volume capillary or venous blood sample in under eight minutes. The platform integrates a disposable microfluidic cartridge with a compact, bench-top analyzer unit and associated cloud-connected software for result processing, storage, and reporting.

The Company's technology is currently in the development and pre-commercial stage. The Company has not yet submitted a pre-market notification (510(k)) or pre-market approval (PMA) application to the FDA, although it is actively preparing for regulatory engagement. The Company's initial target deployment model contemplates placement of MeridianPulse devices in clinical settings, including hospitals, urgent care centers, and physician offices, where the device would be operated by clinical personnel in connection with patient care. The Company has indicated that it may also explore a direct-to-consumer model in future development phases, although this pathway remains exploratory and is not reflected in current business plans.

On the intellectual property front, the Company holds five (5) issued U.S. utility patents and has three (3) pending Patent Cooperation Treaty ("PCT") applications. These patents and applications cover various aspects of the microfluidic technology, as well as associated software analytics and data processing methods employed by the platform. Certain of these patents include claims related to on-device data processing and security features that are relevant to the Company's overall data protection architecture.

B. Types of Data Collected and Processed

Based on our review of the Company's data flow diagrams, architecture documentation, and discussions with the CTO and VP of Operations, the Company collects, generates, or processes the following categories of data in connection with the MeridianPulse platform and its business operations:

Patient-Identifiable Diagnostic Data. The MeridianPulse platform is designed to generate blood panel results across 14 biomarkers from patient blood samples. These results constitute clinical diagnostic data that, when associated with an identifiable patient, will constitute protected health information ("PHI") under HIPAA. The specific biomarkers tested and the clinical significance of the panel are described in the Company's technical documentation.

Patient Demographic and Identifying Information. Depending on the deployment model and the degree of integration with healthcare provider electronic health record ("EHR") systems, the platform may receive, process, or store patient demographic and identifying information, including patient name, date of birth, sex, medical record number, and other identifying data elements. The extent of such data collection will vary based on the specific integration architecture implemented at each deployment site.

Device Telemetry and Calibration Data. The MeridianPulse device generates operational telemetry data, including performance metrics, error logs, calibration records, and quality control data. This data is transmitted to the Company's cloud environment for monitoring, quality assurance, and device management purposes. To the extent that such telemetry data does not include patient-identifiable information, it may fall outside the scope of HIPAA and similar health privacy regulations, although this determination will depend on the specific data elements captured and their potential for linkage to patient records.

Clinical Validation and Research Data. The Company is currently in the research and development phase and is generating data in connection with internal testing and early-stage clinical validation studies. Based on our review, certain R&D datasets may include data derived from human blood samples, and the identifiability of such data is discussed further in Section III.C below.

Employee Data. The Company maintains standard human resources and payroll records for its eighteen (18) full-time employees, including personally identifiable information such as names, Social Security numbers, addresses, bank account information for direct deposit, and tax withholding information.

Business and Operational Data. The Company generates and maintains standard business records, including financial data, corporate records, intellectual property documentation, business plans, investor communications, and other operational data.

C. Data Classification

A critical aspect of any privacy and data security assessment is the accurate classification of data types to determine the applicable regulatory requirements. Based on our review, the following classifications are relevant:

Protected Health Information (PHI) under HIPAA. Once the MeridianPulse platform reaches clinical deployment and is used in connection with patient care by healthcare providers, diagnostic results and associated patient-identifying data will constitute PHI as defined in 45 C.F.R. § 160.103. At present, the Company is in the R&D phase, and the primary question is whether current research datasets contain PHI. Based on our discussions with Dr. Ochoa and our review of the Company's data flow documentation, certain pilot testing activities have involved the analysis of blood samples from identifiable individuals under informal arrangements. The Company has represented that it maintains these datasets on its secured cloud environment and limits access to authorized engineering and scientific personnel. However, the Company has not formally assessed whether these datasets meet the definition of PHI or whether the data has been properly de-identified under applicable HIPAA standards. This represents a gap that should be addressed promptly.

Personally Identifiable Information (PII). Employee records and any identifiable pilot patient data constitute PII subject to applicable state data protection laws, including Massachusetts 201 CMR 17.00 and, potentially, the CCPA/CPRA. The Company's employee PII is maintained through standard payroll and HR systems.

Proprietary and Trade Secret Data. The Company's device specifications, algorithms, software code, manufacturing processes, and patent-related data constitute proprietary information and trade secrets. The protection of this data is addressed through the Company's PIIAs, confidentiality agreements, and access controls, and is relevant to the Company's overall information security posture.

With respect to the question of whether current R&D datasets contain de-identified versus identifiable health data, the Company has not yet formally adopted either the Safe Harbor or Expert Determination method of de-identification under 45 C.F.R. § 164.514. We discuss this further in Section IV.B below and recommend that the Company formalize its de-identification procedures before expanding any pilot testing or research activities involving human samples.

IV. HIPAA COMPLIANCE ASSESSMENT

A. Covered Entity / Business Associate Status

A threshold question in any HIPAA compliance assessment is whether the entity under review is a "Covered Entity" or a "Business Associate" under the statute. The applicability of HIPAA's Privacy Rule, Security Rule, and Breach Notification Rule depends on this classification.

Current Status Analysis. Meridian's classification under HIPAA will depend on its deployment model for the MeridianPulse platform. We have analyzed the most likely deployment scenarios as follows:

(i) Deployment by Healthcare Providers (Most Likely Scenario). If the MeridianPulse device is deployed directly within healthcare provider facilities — such as hospitals, urgent care centers, or physician offices — and the Company accesses, creates, receives, maintains, or transmits PHI on behalf of those providers through its cloud-connected software platform, Meridian will likely function as a "Business Associate" as defined in 45 C.F.R. § 160.103. In this scenario, the healthcare provider operates as the Covered Entity, and Meridian, by providing a platform that processes and stores PHI in connection with the provider's treatment, payment, or healthcare operations activities, would be performing functions that bring it within the Business Associate definition. This is the deployment model most consistent with the Company's current business plans.

(ii) Cloud-Connected Analytics or Data Storage. To the extent Meridian offers cloud-connected analytics, remote monitoring, data storage, or reporting services tied to identifiable patient diagnostic results, the Company would be a Business Associate regardless of whether it deploys the physical device or merely provides the software-as-a-service component. The Company's current technical architecture contemplates cloud-based result processing and storage, which further supports the Business Associate classification.

(iii) Direct-to-Consumer Model (Future, Exploratory). If the Company were to pursue a direct-to-consumer model in which individuals purchase or use the MeridianPulse device outside of a healthcare provider relationship, the HIPAA analysis would be more nuanced. In general, a direct-to-consumer health technology company that does not engage in standard transactions (such as claims submission) and does not meet the Covered Entity definitions under 45 C.F.R. § 160.103 would not be subject to HIPAA. However, the specific structure of such a model, including any involvement of healthcare providers in ordering or interpreting tests, could alter this analysis. The Company has not yet developed a detailed direct-to-consumer business plan, and this scenario remains exploratory.

Current Assessment. Based on the Company's anticipated deployment model and technical architecture, we conclude that Meridian is likely to be classified as a Business Associate in the most probable commercial scenarios. The Company should plan and build its compliance program accordingly. Even during the current pre-commercial phase, to the extent the Company is handling any identifiable health data in connection with pilot testing or research activities, HIPAA obligations may already attach depending on the specific arrangements with data sources.

B. HIPAA Privacy Rule Compliance

The HIPAA Privacy Rule (45 C.F.R. Part 164, Subpart E) establishes national standards for the protection of individually identifiable health information. As a likely future Business Associate, Meridian will be required to comply with certain provisions of the Privacy Rule, primarily through the terms of Business Associate Agreements with Covered Entity customers and through compliance with applicable regulatory requirements that the HITECH Act extended directly to Business Associates.

Notice of Privacy Practices. The Company has drafted a Notice of Privacy Practices ("NPP"); however, this document is not yet finalized. Our review of the current draft indicates that the NPP requires revision to address the specific data flows of the MeridianPulse platform, including the categories of PHI collected, the purposes for which PHI is used and disclosed, and individual rights with respect to their health information. We note that, as a Business Associate, Meridian is not independently required to provide a NPP to individuals (that obligation rests with the Covered Entity), but the Company's own NPP draft suggests it may be contemplating scenarios in which it interacts directly with patients. The NPP should be revised to reflect the Company's actual role and data flows with specificity.

Minimum Necessary Standard. The Privacy Rule requires that uses and disclosures of PHI be limited to the minimum necessary to accomplish the intended purpose. The Company has policies in draft form addressing the minimum necessary standard, but these policies have not been finalized, formally adopted, or operationalized through technical controls such as role-based access limitations specific to PHI data elements. We recommend that the Company finalize these policies and implement corresponding technical controls prior to any clinical deployment involving PHI.

Authorization and Consent Forms. The Company is developing authorization and consent forms for clinical validation studies that may involve identifiable patient data. These forms are currently under development and were not available for review in final form. We recommend that company counsel review these forms for compliance with HIPAA authorization requirements under 45 C.F.R. § 164.508, as well as any applicable state law consent requirements and institutional review board ("IRB") protocols.

De-Identification Procedures. The Company is aware of the two permissible methods of de-identification under 45 C.F.R. § 164.514: the Safe Harbor method (removal of eighteen specified identifiers) and the Expert Determination method (a qualified statistical or scientific expert determines that the risk of identification is very small). However, the Company has not yet formally adopted either method, and no formal de-identification protocols or procedures have been documented. Given that certain R&D datasets may contain identifiable health data, the absence of formal de-identification procedures represents a gap that should be addressed. We recommend that the Company select and implement a de-identification methodology appropriate to its data types and use cases, and that the chosen methodology be documented and applied consistently.

Recommendation. The Company should formalize its HIPAA Privacy Rule compliance program prior to any clinical deployment or pilot activities involving identifiable patient data. This includes finalizing the NPP and minimum necessary policies, completing authorization and consent forms, and adopting formal de-identification procedures.

C. HIPAA Security Rule Compliance

The HIPAA Security Rule (45 C.F.R. Part 164, Subpart C) requires Covered Entities and Business Associates to implement administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and availability of electronic protected health information ("ePHI"). Our assessment of the Company's compliance with the Security Rule is set forth below.

Administrative Safeguards. The Company has designated Dr. Julian Ochoa, its Chief Technology Officer, as the interim Security Officer responsible for the Company's information security program. This designation satisfies the Security Rule's requirement under 45 C.F.R. § 164.308(a)(2) that a Covered Entity or Business Associate identify a security official responsible for developing and implementing security policies and procedures. However, Dr. Ochoa's role as CTO encompasses a broad range of responsibilities, and he does not have dedicated privacy or security staff supporting him. The absence of dedicated privacy and security personnel is a recognized gap, though it is not unusual for a company at Meridian's stage. We discuss this further in Section VII.C.

Physical Safeguards. The Company's Cambridge, Massachusetts office is equipped with badge-controlled access at the building and suite level. The Company has represented that any server infrastructure or equipment containing sensitive data is maintained in a restricted-access area within the office, with access limited to authorized personnel. The Company's cloud-hosted development and data environments are maintained by third-party providers whose physical security measures are addressed through their own SOC 2 and ISO 27001 certifications (see Section VI.A). For the MeridianPulse devices themselves, the Company has indicated that prototype units are secured when not in active use, although formal physical security protocols for device storage and transport are not yet documented.

Technical Safeguards. The Company's technical safeguards — including access controls, encryption, audit controls, integrity controls, and transmission security — are discussed in detail in Section VI of this memorandum.

Risk Assessment. A critical requirement of the HIPAA Security Rule is the performance of a formal risk analysis to assess the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI, as required by 45 C.F.R. § 164.308(a)(1)(ii)(A). The Company has not yet conducted such a formal risk analysis. This constitutes a significant gap in the Company's HIPAA compliance posture. A documented risk analysis is not only a regulatory requirement but also serves as the foundation for a risk-based security program, informing decisions about safeguard implementation, resource allocation, and residual risk acceptance. We strongly recommend that the Company conduct a formal HIPAA Security Rule risk analysis prior to any deployment involving ePHI. The Company should consider engaging a qualified security consultant with experience in healthcare and medical device environments to assist with this analysis.

Recommendation. Conduct a formal HIPAA Security Rule risk analysis as a priority item. Engage a qualified security consultant to assist. Use the risk analysis to inform the development and implementation of a comprehensive security management process, including risk management planning and sanction policies for workforce members who violate security policies.

D. Business Associate Agreements (BAAs)

The Company has executed Business Associate Agreements with two cloud infrastructure providers that are used for the Company's development environments. These BAAs were provided for our review and are discussed below.

The existing BAAs are generally conforming to HIPAA requirements under 45 C.F.R. § 164.504(e). Both agreements include provisions requiring the cloud providers to: (i) use or disclose PHI only as permitted or required by the agreement or as required by law; (ii) implement appropriate safeguards to prevent unauthorized use or disclosure of PHI; (iii) report to the Company any use or disclosure of PHI not provided for by the agreement; (iv) ensure that any subcontractors agree to the same restrictions and conditions; (v) make PHI available to individuals exercising their rights under the Privacy Rule; and (vi) make their practices and records available to the Secretary of the U.S. Department of Health and Human Services ("HHS") for compliance determination purposes.

However, we have identified certain areas where the existing BAAs could be strengthened to reflect current regulatory guidance and best practices. Specifically, the breach notification provisions in both BAAs should be updated to include more specific timelines for notification (the current language references "prompt" notification without specifying a maximum timeframe), and the agreements should be updated to reflect the HITECH Act's direct applicability of Security Rule and certain Privacy Rule provisions to Business Associates. Additionally, the agreements should include provisions addressing the return or destruction of PHI upon termination of the agreement and should more clearly define the permitted uses and disclosures.

The Company has not yet executed BAAs with anticipated downstream healthcare provider customers, as it is pre-commercial and has not yet entered into any commercial agreements. This is expected at this stage and does not represent a current compliance gap, but the Company will need to establish BAAs with healthcare provider customers as it moves toward commercial deployment.

Recommendation. The Company should develop a standard-form BAA template for use in future customer and vendor relationships. The template should be prepared by the Company's counsel (or by Calderwood & Harkness at Cobalt's request) and should reflect current HIPAA and HITECH Act requirements and regulatory guidance. Additionally, the Company should ensure that all current and future subcontractors that access, create, receive, maintain, or transmit PHI on the Company's behalf are parties to compliant BAAs. The existing BAAs with cloud infrastructure providers should be updated to address the specific gaps identified above.

E. HIPAA Breach Notification Preparedness

The HIPAA Breach Notification Rule (45 C.F.R. Part 164, Subpart D) requires Business Associates to notify Covered Entities of any breach of unsecured PHI without unreasonable delay and no later than sixty (60) days after discovery of the breach. Covered Entities, in turn, are required to notify affected individuals, the Secretary of HHS, and, in the case of breaches affecting 500 or more individuals, prominent media outlets serving the relevant state or jurisdiction.

The Company has a draft incident response plan, which is discussed in detail in Section VIII of this memorandum. However, the draft plan does not specifically address HIPAA breach notification timelines or the specific requirements applicable to Business Associates under the Breach Notification Rule. The plan does not include procedures for: (i) assessing whether an incident constitutes a "breach" under HIPAA, including the application of the four-factor risk assessment set forth in 45 C.F.R. § 164.402; (ii) determining whether the "low probability" exception to the breach definition applies; (iii) notifying the relevant Covered Entity within the required timeframe; or (iv) documenting the breach investigation and notification process.

The Company has reported that no breaches of PHI or other security incidents have occurred to date. This is consistent with the Company's early stage and limited data processing activities.

Recommendation. The Company should integrate HIPAA breach notification requirements into its incident response plan, including specific procedures for breach assessment, Covered Entity notification, and documentation. The plan should clearly identify the roles and responsibilities of personnel involved in breach assessment and notification, and should include template notification letters and regulatory reporting forms.

V. STATE PRIVACY LAW COMPLIANCE

A. Massachusetts — 201 CMR 17.00

As a company with its principal office in Cambridge, Massachusetts, Meridian is subject to the Massachusetts Standards for the Protection of Personal Information of Residents of the Commonwealth, codified at 201 CMR 17.00. These regulations apply to any person or entity that owns or licenses personal information about a resident of the Commonwealth of Massachusetts. "Personal information" under the regulation includes a Massachusetts resident's first and last name (or first initial and last name) in combination with any of the following: Social Security number, driver's license number, state-issued identification card number, or financial account number or credit/debit card number.

A central requirement of 201 CMR 17.00 is that covered entities develop, implement, and maintain a comprehensive Written Information Security Program ("WISP") that contains administrative, technical, and physical safeguards appropriate to the size, scope, and type of business of the entity, the amount of resources available to the entity, the amount of stored data, and the need for security and confidentiality of both consumer and employee information. The regulation specifies minimum requirements that a WISP must address, including designation of responsible employees, identification of internal and external risks, employee training, security policies for personnel with access to personal information, disciplinary measures for violations, restricted access controls, encryption requirements for transmitted records containing personal information, monitoring of systems, regular review of the WISP's effectiveness, and documentation of responsive actions to security breaches.

Current Status. The Company has a general information security policy (version 1.2, dated September 2025) that addresses certain security topics at a high level. However, this document does not constitute a WISP that satisfies the specific requirements of 201 CMR 17.00. The policy does not address all of the mandatory elements specified in the regulation, does not specifically reference Massachusetts law, and has not been reviewed or updated with the regulation's requirements in mind. Given that the Company maintains personal information of its Massachusetts-based employees (including, at a minimum, Social Security numbers and financial account information for payroll purposes), compliance with 201 CMR 17.00 is currently required.

Recommendation. The Company should prepare and adopt a compliant WISP that addresses all requirements of 201 CMR 17.00, including encryption requirements for personal information transmitted across public networks or stored on portable devices, access control measures, monitoring and audit procedures, employee training requirements, and provisions for regular review and updating of the program. This is identified as an immediate priority in our remediation timeline (Section XIII).

B. California — CCPA/CPRA

The California Consumer Privacy Act of 2018, as amended by the California Privacy Rights Act of 2020 (collectively, "CCPA/CPRA"), applies to for-profit businesses that collect personal information of California residents and that meet one or more of the following thresholds: (i) annual gross revenues in excess of $25 million; (ii) buying, selling, or sharing the personal information of 100,000 or more California residents, households, or devices annually; or (iii) deriving 50% or more of annual revenues from selling or sharing California residents' personal information.

Current Assessment. Based on the Company's current profile — eighteen (18) employees, pre-revenue status, and pre-commercial operations — Meridian does not currently meet any of the CCPA/CPRA applicability thresholds. The Company does not generate annual gross revenues in excess of $25 million, does not buy, sell, or share the personal information of 100,000 or more California residents, and does not derive revenue from selling or sharing personal information. While Cobalt Ventures LP is headquartered in Menlo Park, California, and Cobalt personnel may interact with the Company in various capacities, these interactions would not independently trigger CCPA/CPRA applicability for Meridian.

We note, however, that the CCPA/CPRA exempts certain categories of health information from its scope, including protected health information governed by HIPAA, medical information governed by the California Confidentiality of Medical Information Act ("CMIA"), and clinical trial data. To the extent Meridian's data processing activities involve such exempt data categories, those activities may fall outside the CCPA/CPRA even if the Company were to meet the applicability thresholds in the future.

Recommendation. The Company should monitor CCPA/CPRA applicability as it scales, particularly as it approaches commercial launch and begins generating revenue and collecting data from California residents. Foundational privacy practices implemented now — such as data mapping, privacy notices, and individual rights request procedures — will facilitate future CCPA/CPRA compliance if and when the applicability thresholds are met.

C. Other State Laws

The state privacy law landscape in the United States continues to evolve rapidly, with a growing number of states enacting comprehensive consumer privacy laws and, in some cases, laws specifically addressing health data. Several of these laws may be relevant to Meridian as it moves toward commercial deployment of the MeridianPulse platform on a multi-state or nationwide basis.

Notable examples include the Washington My Health My Data Act (RCW 19.373), which creates consumer health data protections outside the HIPAA framework and applies broadly to entities that collect, process, or share consumer health data of Washington residents; the Connecticut Data Privacy Act (Conn. Gen. Stat. § 42-515 et seq.); the Colorado Privacy Act (C.R.S. § 6-1-1301 et seq.); the Virginia Consumer Data Protection Act (Va. Code Ann. § 59.1-575 et seq.); and the Texas Data Privacy and Security Act (Tex. Bus. & Com. Code § 541.001 et seq.). Each of these laws has distinct applicability thresholds, exemptions, consumer rights provisions, and enforcement mechanisms. The Washington My Health My Data Act is of particular note because it applies broadly to consumer health data and does not include HIPAA-related exemptions that are common in other state privacy laws.

Recommendation. Prior to multi-state commercial launch, the Company should develop a comprehensive state law compliance matrix that maps the Company's anticipated data processing activities against the requirements of each applicable state law. This matrix should be maintained as a living document and updated as new laws are enacted or existing laws are amended. Calderwood & Harkness is available to assist in the preparation of such a compliance matrix.

VI. CYBERSECURITY POSTURE AND TECHNICAL CONTROLS

A. Network and Infrastructure Security

The Company's technical infrastructure is primarily cloud-hosted. The Company does not maintain an on-premises data center and has limited local network infrastructure at its Cambridge, Massachusetts office. Development environments, data storage, and application hosting are provided through third-party cloud infrastructure providers.

We have reviewed the security certifications and compliance attestations of the Company's primary cloud infrastructure providers. Both providers maintain SOC 2 Type II attestations and ISO 27001 certifications, indicating that their infrastructure and operational controls have been independently assessed and found to meet recognized security standards. The Company has represented that it has reviewed these attestation reports and has selected its providers in part based on their security posture.

Firewall protection, intrusion detection, and intrusion prevention systems for the Company's cloud environments are managed by the cloud providers as part of their infrastructure services. The Company has configured its cloud environments with network segmentation, access control lists, and security groups to limit network-level access to authorized users and services, although the maturity and comprehensiveness of these configurations have not been independently verified through technical testing.

At the Cambridge office, the local network infrastructure is limited to a standard commercial internet connection, Wi-Fi access points, and employee workstations. The Company has represented that the office Wi-Fi network is encrypted (WPA3) and that guest and corporate networks are segregated. No sensitive data processing occurs on local infrastructure; all development and data processing activities are conducted in the cloud environment.

The Company's endpoint protection posture includes the deployment of antivirus and anti-malware software on all company-issued laptops. The Company has a mobile device management ("MDM") policy in draft form but has not yet fully implemented an MDM solution. Given the Company's remote and hybrid work arrangements, the absence of a fully deployed MDM solution represents a gap that should be addressed to ensure that company-issued and any authorized personal devices accessing company systems are subject to appropriate security controls, including remote wipe capability, encryption enforcement, and compliance monitoring.

B. Encryption. Data at Rest. The Company has represented that diagnostic data and other sensitive information stored in its cloud environment is encrypted at rest using AES-256 encryption, which is a widely accepted and NIST-recommended encryption standard. This encryption is provided through the cloud infrastructure providers' storage services, with encryption keys managed through the providers' key management services. The Company has the option to implement customer-managed encryption keys ("CMEK") for additional control over key management, but has not yet elected to do so.

Data in Transit. All data transmissions between the MeridianPulse device and the Company's cloud backend are secured using Transport Layer Security ("TLS") version 1.2 or higher. The Company has represented that earlier, deprecated versions of TLS and SSL are not supported. API endpoints are secured with TLS, and certificate pinning is being evaluated for the device-to-cloud communication channel. Internal communications between cloud services are also encrypted in transit.

Encryption Key Management. The Company's current approach to encryption key management relies primarily on the key management services provided by its cloud infrastructure providers. While this approach is common and acceptable for early-stage companies, it means that key rotation, key access controls, and key storage are subject to the cloud providers' standard configurations. The Company has not yet implemented a formal encryption key management policy that addresses key generation, distribution, storage, rotation, revocation, and destruction. As the Company matures and begins handling PHI in production environments, a more robust key management framework should be developed.

Device-Level Encryption. The MeridianPulse device is designed to store diagnostic results locally on the device for a limited period before transmission to the cloud backend. Based on our review of the device architecture documentation, the Company has implemented on-device encryption for locally stored data using hardware-backed cryptographic modules. The specific implementation details are covered by the Company's issued patents and were reviewed in the context of the broader IP diligence. We note that the robustness of the device-level encryption implementation has not been independently tested or verified.

C. Access Controls and Authentication

The Company has implemented role-based access controls ("RBAC") in its cloud development environments, with access levels defined based on job function. Administrative access to cloud infrastructure is limited to Dr. Ochoa and two senior engineers. Application-level access controls for the MeridianPulse software platform are in development and will be critical for controlling access to PHI in clinical deployment scenarios.

Multi-Factor Authentication (MFA). Multi-factor authentication is currently enabled for access to the Company's cloud infrastructure management console and certain administrative functions. However, MFA is not yet uniformly deployed across all employee accounts and systems, including email, collaboration platforms, and code repositories. The inconsistent deployment of MFA across the organization represents a security gap. Compromised credentials remain one of the most common vectors for unauthorized access, and the implementation of MFA across all systems is a widely recognized and cost-effective security control.

Privileged Access Management. Dr. Ochoa, as CTO, and a small number of senior engineering team members maintain privileged (administrative) access to the Company's cloud environments, code repositories, and device firmware. The Company does not currently employ a formal privileged access management ("PAM") solution, such as a dedicated PAM tool with session monitoring, just-in-time access provisioning, or credential vaulting. At the Company's current scale, this is not uncommon, but formalized privileged access controls should be implemented as the team and the attack surface grow.

Recommendation. Implement MFA across all Company systems and accounts without exception. Formalize access provisioning and de-provisioning procedures, including procedures for promptly revoking access upon employee departure or role change. As the Company scales, evaluate and implement a PAM solution for administrative and privileged accounts.

D. Data Transmission Protocols

The MeridianPulse device communicates with the Company's cloud backend through a series of APIs that handle the transmission of diagnostic results, device telemetry, calibration data, and firmware updates. Our review of the Company's API documentation and data transmission architecture identified the following relevant considerations:

API Security. The device-to-cloud communication channel uses RESTful APIs secured with TLS 1.2+ and authenticated using API keys and OAuth 2.0 tokens. API rate limiting and input validation are implemented to mitigate common API-based attack vectors. The Company has represented that API security testing is conducted as part of its development process, although formal API security audits have not been performed by an independent third party.

Authentication Tokens. Device authentication tokens are generated during the device provisioning process and are stored in the device's hardware security module ("HSM"). Token rotation policies are documented in the device firmware specification, with tokens set to expire and require renewal at configurable intervals.

Data Integrity Verification. The Company implements checksums and digital signatures to verify the integrity of data transmitted between the device and the cloud backend. These mechanisms are designed to detect data corruption or tampering during transmission.

De-Identified vs. Identifiable Transmission. Based on our review, the current device architecture transmits diagnostic results along with a device identifier and, depending on the integration model, potentially patient-identifying information. The Company has indicated that it is evaluating a "split architecture" in which patient-identifying information is maintained by the healthcare provider's EHR system and only a pseudonymized or tokenized identifier is transmitted to the Company's cloud environment. This approach, if implemented, would significantly reduce the Company's exposure to identifiable PHI and simplify its HIPAA compliance obligations. We recommend that the Company finalize this architectural decision before clinical deployment and ensure that the chosen approach is reflected in its BAAs and privacy policies.

Third-Party Data Sharing. The Company has represented that it does not currently have any third-party data sharing arrangements beyond its cloud hosting providers. No diagnostic data is shared with external research institutions, pharmaceutical companies, or other third parties. If the Company contemplates such arrangements in the future, they will need to be structured in compliance with HIPAA, applicable state laws, and any consent or authorization requirements.

E. Vulnerability Management

The Company does not currently have a formal vulnerability management or patch management program documented in writing. Vulnerability management activities — including the application of security patches to cloud environments, operating systems, and application software — are handled on an ad hoc basis by the engineering team. While the Company has represented that critical patches are applied promptly, the absence of a formal program with documented procedures, scanning cadence, and remediation timelines represents a significant gap, particularly as the Company approaches clinical deployment.

No third-party penetration testing of the Company's cloud environment, APIs, or MeridianPulse device has been conducted to date. Penetration testing by an independent, qualified firm is an industry best practice and is increasingly expected by regulators, customers, and business partners in the healthcare and medical device sectors. The FDA's pre-market cybersecurity guidance also contemplates the submission of penetration testing results as part of the cybersecurity documentation for medical device regulatory submissions.

Recommendation. The Company should establish a formal vulnerability management program that includes: (i) regular automated vulnerability scanning of cloud environments and endpoints; (ii) a documented patch management process with defined timelines for the application of critical, high, medium, and low severity patches; (iii) an initial penetration test conducted by an independent, qualified firm before any clinical deployment of the MeridianPulse platform; and (iv) a recurring penetration testing cadence (at least annually, with additional testing following significant changes to the environment). The results of vulnerability scans and penetration tests should be documented, and identified vulnerabilities should be tracked through a formal remediation process.

F. Data Retention and Destruction

The Company has not yet formalized a data retention and destruction policy. Currently, R&D data, device telemetry data, and other information are retained indefinitely in the Company's cloud storage environment. No documented procedures exist for the periodic review and deletion of data that is no longer required for business, legal, or regulatory purposes.

The absence of a formal data retention and destruction policy creates both regulatory and practical risks. From a regulatory perspective, HIPAA requires Business Associates to return or destroy PHI upon termination of the Business Associate Agreement, and many state data protection laws impose limitations on the retention of personal information beyond the period necessary for the purpose for which it was collected. From a practical perspective, the indefinite retention of data increases the volume of information that could be compromised in the event of a security incident.

Recommendation. The Company should develop a data retention schedule that specifies the retention periods for each category of data, aligned with applicable regulatory requirements (including HIPAA, state laws, and FDA recordkeeping requirements) and business needs. The Company should also implement secure data destruction procedures, including procedures for the secure deletion of electronic data and the destruction of physical media, and should document the execution of data destruction activities. The retention schedule should be reviewed and updated on an annual basis.

VII. ORGANIZATIONAL AND PERSONNEL MEASURES

A. Employee Privacy and Security Training

Employee awareness and training is a critical component of any data privacy and security program. Human error and insider threats consistently rank among the leading causes of data breaches and security incidents, and a well-designed training program is one of the most effective measures for mitigating these risks.

The Company has conducted informal privacy and security awareness training for its engineering staff, primarily through presentations and discussions led by Dr. Ochoa. However, the Company does not have a formal, documented training program with a regular cadence. No training completion records are maintained, and training content has not been standardized or memorialized in a curriculum. Additionally, the Company has not implemented role-specific training modules that differentiate between the training needs of employees who will have access to health data and those who do not.

With a current headcount of eighteen (18) full-time employees, the Company is at a manageable scale for the implementation of a comprehensive training program. The relatively small size of the organization provides an opportunity to establish a strong culture of privacy and security awareness from the outset, which will serve the Company well as it grows.

Recommendation. The Company should implement a formal privacy and security training program that includes the following elements: (i) initial training for all new hires, to be completed within the first thirty (30) days of employment; (ii) annual refresher training for all employees; (iii) documented completion records maintained in employee files; (iv) role-specific training modules for employees with access to health data, including HIPAA awareness training; and (v) periodic supplemental training addressing emerging threats, such as phishing and social engineering. Training materials should be developed in consultation with the Company's counsel and should be updated annually to reflect changes in applicable laws, regulations, and the Company's operations.

B. Proprietary Information and Inventions Assignment Agreements (PIIAs)

As part of our diligence review, we reviewed the Company's standard form PIIA and the executed PIIAs for current employees. The Company's PIIA form includes confidentiality obligations covering patient and health data, proprietary information, trade secrets, and inventions assignment provisions. The PIIA form is generally consistent with market standards for early-stage life sciences and technology companies.

Our review indicates that most current employees have executed the Company's standard PIIA form. Verification of complete coverage across all eighteen (18) full-time employees was in process at the time of this memorandum, and we expect this verification to be completed prior to closing. We have been informed by Whitfield & Ames that two recently hired employees may not yet have executed PIIAs; this should be confirmed and remedied promptly.

As part of the broader closing deliverables for the Series Seed financing, Calderwood & Harkness has prepared a revised PIIA form that strengthens certain provisions related to data privacy and security obligations, clarifies the scope of inventions assignment for employees engaged in medical device and software development, and incorporates updated non-solicitation and non-competition provisions consistent with applicable state law requirements.

Recommendation. Ensure that all current employees execute the updated PIIA form prepared by Calderwood & Harkness. All future hires should be required to execute the updated PIIA as a condition of employment. The Company should maintain a centralized record of all executed PIIAs and include PIIA compliance as part of the onboarding checklist.

C. Designated Privacy and Security Personnel

As noted in Section IV.C above, Dr. Julian Ochoa, the Company's Chief Technology Officer, serves as the interim Security Officer responsible for the Company's information security program. While this designation satisfies the formal requirements of the HIPAA Security Rule, it is important to recognize that Dr. Ochoa's primary responsibilities as CTO — including overseeing product development, engineering, and technical operations — necessarily limit the time and attention he can devote to privacy and security compliance matters. The Company does not currently have a dedicated Chief Information Security Officer ("CISO"), Data Protection Officer ("DPO"), or any other employee whose primary responsibility is data privacy and security.

Nadia Chen, the Company's Vice President of Operations, handles certain operational compliance matters, including coordination with external auditors, management of vendor relationships, and oversight of employee onboarding processes. Ms. Chen has been responsive and engaged during the diligence process, but her role does not include dedi

CALDERWOOD & HARKNESS LLP Attorneys at Law
1800 Page Mill Road, Suite 200 Menlo Park, California 94025 Telephone: (650) 493-7200 Facsimile: (650) 493-7201 www.calderwoodharkness.com
PRIVILEGED AND CONFIDENTIAL ATTORNEY-CLIENT COMMUNICATION / ATTORNEY WORK PRODUCT
PRIVACY & DATA SECURITY DILIGENCE MEMORANDUM
MERIDIAN DIAGNOSTICS, INC.
TO: Elaine Cho, Managing Partner, Cobalt Ventures LP David Hargrove, Partner, Cobalt Ventures LP Morgan Tsai, VP of Legal Affairs, Cobalt Ventures LP
FROM: Kevin Ostrowski, Partner, Privacy & Data Security, Calderwood & Harkness LLP
DATE: January 28, 2026
RE: Privacy and Data Security Diligence Assessment — Meridian Diagnostics, Inc.
Matter No.: 1004-00001
This memorandum is a privileged and confidential attorney-client communication and constitutes attorney work product prepared in anticipation of litigation and in connection with the provision of legal advice. This memorandum is intended solely for the use of the addressees and should not be disclosed, distributed, or reproduced without the prior written consent of Calderwood & Harkness LLP.
Right-click to update Table of Contents
I. EXECUTIVE SUMMARY
This memorandum sets forth the findings and recommendations of Calderwood & Harkness LLP ("Calderwood & Harkness" or the "Firm") with respect to its assessment of the data privacy and data security practices of Meridian Diagnostics, Inc. (the "Company" or "Meridian"). This assessment has been conducted in connection with the proposed lead investment by Cobalt Ventures Fund III, LP ("Cobalt" or the "Fund") of Seven Million Two Hundred Thousand Dollars ($7,200,000) as part of a Twelve Million Dollar ($12,000,000) Series Seed Preferred Stock financing round (the "Financing").
Meridian Diagnostics, Inc. is a Delaware C-corporation headquartered at 225 Binney Street, Suite 400, Cambridge, Massachusetts 02142. The Company was founded on June 15, 2023, by Dr. Priya Ramaswamy, who serves as Chief Executive Officer, and Dr. Julian Ochoa, who serves as Chief Technology Officer. The Company is developing the "MeridianPulse" platform — a microfluidic point-of-care diagnostic device capable of running a 14-marker blood panel in under eight minutes from a small-volume blood sample. The MeridianPulse platform represents a potentially significant advance in rapid point-of-care diagnostics, with anticipated applications in clinical settings including hospitals, urgent care facilities, and physician offices.
As of the date of this memorandum, the Company employs eighteen (18) full-time employees and maintains a monthly burn rate of approximately One Hundred Eighty-Five Thousand Dollars ($185,000). The Company has approximately One Million Four Hundred Thousand Dollars ($1,400,000) in remaining cash from a prior friends-and-family convertible note round, which, absent the closing of the Financing, provides the Company with an estimated runway of approximately seven to eight months.
This memorandum evaluates Meridian's current data privacy and security posture across several critical dimensions, including compliance with the Health Insurance Portability and Accountability Act of 1996, as amended ("HIPAA"), including the Privacy Rule, Security Rule, and Breach Notification Rule; the Health Information Technology for Economic and Clinical Health Act ("HITECH Act"); applicable state health privacy and data security laws, with particular focus on Massachusetts and California; cybersecurity infrastructure and technical controls; organizational readiness and personnel measures; incident response and breach preparedness; third-party vendor risk management; and considerations arising from the Company's anticipated regulatory pathway with the U.S. Food and Drug Administration ("FDA").
Overall Assessment. Meridian is an early-stage, pre-commercial company with foundational privacy and security practices in place that will require meaningful maturation as the Company progresses toward clinical deployment and commercialization. The Company's leadership demonstrates awareness of the applicable regulatory landscape, and preliminary steps have been taken to establish baseline policies and procedures. However, several significant gaps have been identified — most notably, the absence of a formal HIPAA Security Rule risk analysis, the lack of a Massachusetts Written Information Security Program ("WISP"), incomplete incident response planning, and the absence of formal employee training and vendor risk management programs. These gaps are addressable and are generally consistent with the Company's early stage of development. Specific recommendations and a proposed remediation timeline are provided in Section XIII of this memorandum.
Importantly, we note that no issues have been identified in this assessment that would constitute a closing impediment for the Financing. The identified gaps are remediable and can be addressed through a structured post-closing remediation plan, the execution of which can be monitored through the annual compliance audit right that Cobalt has negotiated in the proposed Cobalt Side Letter (between the Company and Cobalt Ventures Fund III, LP, to be executed at the closing of the Financing currently scheduled for February 9, 2026). This annual audit right, which is discussed in detail in Section XI of this memorandum, will provide Cobalt with an ongoing contractual mechanism to assess and monitor the Company's privacy and security posture following the investment. The audit right complements additional information and governance rights negotiated in the Cobalt Side Letter, including a monthly KPI dashboard, cap table access, and a board observer right, all of which will enhance Cobalt's ability to monitor Company operations in the post-closing period.
II. SCOPE AND METHODOLOGY
A. Scope of Review
This privacy and data security diligence review was conducted as part of a broader legal due diligence engagement commenced on January 6, 2026, with a target completion date of January 31, 2026. Calderwood & Harkness's privacy and data security practice group was engaged specifically to evaluate those aspects of the Company's operations, policies, procedures, and technical infrastructure that pertain to the collection, use, storage, processing, transmission, and protection of personal data and health information.
The scope of this review was focused on data privacy and security matters relevant to the Company's ongoing development and anticipated commercialization of the MeridianPulse diagnostic platform. Given the Company's pre-commercial status, the assessment necessarily encompasses both the Company's current practices and its preparedness for the regulatory and compliance obligations that will attach as the platform moves into clinical validation, regulatory approval, and commercial deployment.
The regulatory frameworks examined in connection with this assessment include the following:
(a) HIPAA — including the Privacy Rule (45 C.F.R. Parts 160 and 164, Subparts A and E), the Security Rule (45 C.F.R. Parts 160 and 164, Subparts A and C), and the Breach Notification Rule (45 C.F.R. Part 164, Subpart D);
(b) HITECH Act — Subtitle D of the Health Information Technology for Economic and Clinical Health Act (Public Law 111-5), including enhanced enforcement provisions and breach notification requirements;
(c) Massachusetts Data Security Regulations — 201 CMR 17.00, Standards for the Protection of Personal Information of Residents of the Commonwealth, including the requirement to develop, implement, and maintain a comprehensive Written Information Security Program;
(d) California Consumer Privacy Act / California Privacy Rights Act — Cal. Civ. Code §§ 1798.100–1798.199.100, as amended by the CPRA (Proposition 24), including its applicability thresholds and consumer rights framework;
(e) FDA Regulations — applicable requirements regarding medical device data integrity, cybersecurity, and software validation under pre-market and post-market regulatory frameworks, including relevant FDA guidance documents on cybersecurity in medical devices; and
(f) General cybersecurity best practices — including standards and frameworks published by the National Institute of Standards and Technology ("NIST"), the International Organization for Standardization ("ISO"), and other recognized authorities.
In conducting this review, Calderwood & Harkness coordinated with Whitfield & Ames LLP, the Company's outside legal counsel, through Catherine Devereaux and Thomas Whitaker of that firm, regarding document production and responses to diligence requests. We appreciate the responsiveness and cooperation of both the Company and Whitfield & Ames throughout the diligence process.
B. Materials Reviewed
In preparing this memorandum, Calderwood & Harkness reviewed the following categories of documents and information:
1. The Company's privacy policies, including both internal-facing policies and any external-facing or patient-facing privacy notices in draft or final form;
2. Data flow diagrams and architecture documentation for the MeridianPulse platform, including depictions of data collection points, transmission pathways, storage locations, and processing workflows;
3. The Company's information security policies and procedures manual (version 1.2, dated September 2025);
4. Relevant provisions of the Company's employee handbook pertaining to data privacy, confidentiality, acceptable use of technology, and information security;
5. Executed confidentiality and Proprietary Information and Inventions Assignment Agreements ("PIIAs") for current employees, to the extent available;
6. Third-party vendor and service provider agreements, including cloud hosting agreements, software licensing agreements, and professional services engagement letters;
7. Existing Business Associate Agreements ("BAAs") executed between the Company and its cloud infrastructure providers;
8. The Company's draft incident response plan (version 0.8, dated November 2025), prepared by Dr. Julian Ochoa;
9. IT infrastructure documentation, including cloud environment configurations, network architecture descriptions, and any cybersecurity audit reports or assessments (noting that no formal external audit has been conducted to date);
10. The Company's responses to the Calderwood & Harkness Privacy and Security Diligence Questionnaire (submitted January 10, 2026; responses received January 17, 2026, with supplemental responses received January 22, 2026);
11. Memoranda and notes from discussions conducted by Calderwood & Harkness attorneys with Dr. Julian Ochoa (CTO) on January 14, 2026, and Nadia Chen (VP of Operations) on January 15, 2026, regarding the Company's current data privacy and security practices; and
12. The Company's intellectual property portfolio documentation, including five (5) issued U.S. utility patents and three (3) pending PCT applications, which were reviewed for data-related claims and embedded security features relevant to the MeridianPulse platform.
A complete itemized list of all documents reviewed is set forth in Appendix A to this memorandum.
C. Limitations. Several limitations apply to this assessment, which should be taken into account in evaluating the findings and recommendations set forth herein.
First, Meridian is a pre-commercial, early-stage company. Many of the Company's data privacy and security practices are still under active development, and the Company has not yet reached the stage of maturity at which a fully developed compliance infrastructure would be expected. The findings in this memorandum should be understood in that context.
Second, no independent penetration testing, vulnerability scanning, or technical security audit was conducted by Calderwood & Harkness or by any third party engaged by the Firm in connection with this assessment. This review was limited to a documentary and interview-based assessment of the Company's policies, procedures, technical controls, and organizational measures. The technical findings set forth herein are based on the Company's representations and documentation, and have not been independently verified through technical testing.
Third, the Company's auditors, Graystone & Pallister CPAs, LLP, have not performed a Service Organization Control ("SOC") 2 examination or any similar information security audit of the Company's systems or controls. Accordingly, no independent third-party assurance report regarding the design or operating effectiveness of the Company's security controls was available for review.
Fourth, this assessment reflects the Company's data privacy and security posture as of January 2026. The Company's practices and risk profile will necessarily evolve as it progresses toward clinical validation, regulatory submissions, and commercial deployment. The recommendations set forth in this memorandum are intended to guide that evolution, but ongoing monitoring and reassessment will be required.
III. COMPANY OVERVIEW AND DATA ENVIRONMENT
A. Business Overview
Meridian Diagnostics, Inc. is developing the MeridianPulse platform, a microfluidic point-of-care diagnostic device designed to perform a 14-marker blood panel from a small-volume capillary or venous blood sample in under eight minutes. The platform integrates a disposable microfluidic cartridge with a compact, bench-top analyzer unit and associated cloud-connected software for result processing, storage, and reporting.
The Company's technology is currently in the development and pre-commercial stage. The Company has not yet submitted a pre-market notification (510(k)) or pre-market approval (PMA) application to the FDA, although it is actively preparing for regulatory engagement. The Company's initial target deployment model contemplates placement of MeridianPulse devices in clinical settings, including hospitals, urgent care centers, and physician offices, where the device would be operated by clinical personnel in connection with patient care. The Company has indicated that it may also explore a direct-to-consumer model in future development phases, although this pathway remains exploratory and is not reflected in current business plans.
On the intellectual property front, the Company holds five (5) issued U.S. utility patents and has three (3) pending Patent Cooperation Treaty ("PCT") applications. These patents and applications cover various aspects of the microfluidic technology, as well as associated software analytics and data processing methods employed by the platform. Certain of these patents include claims related to on-device data processing and security features that are relevant to the Company's overall data protection architecture.
B. Types of Data Collected and Processed
Based on our review of the Company's data flow diagrams, architecture documentation, and discussions with the CTO and VP of Operations, the Company collects, generates, or processes the following categories of data in connection with the MeridianPulse platform and its business operations:
Patient-Identifiable Diagnostic Data. The MeridianPulse platform is designed to generate blood panel results across 14 biomarkers from patient blood samples. These results constitute clinical diagnostic data that, when associated with an identifiable patient, will constitute protected health information ("PHI") under HIPAA. The specific biomarkers tested and the clinical significance of the panel are described in the Company's technical documentation.
Patient Demographic and Identifying Information. Depending on the deployment model and the degree of integration with healthcare provider electronic health record ("EHR") systems, the platform may receive, process, or store patient demographic and identifying information, including patient name, date of birth, sex, medical record number, and other identifying data elements. The extent of such data collection will vary based on the specific integration architecture implemented at each deployment site.
Device Telemetry and Calibration Data. The MeridianPulse device generates operational telemetry data, including performance metrics, error logs, calibration records, and quality control data. This data is transmitted to the Company's cloud environment for monitoring, quality assurance, and device management purposes. To the extent that such telemetry data does not include patient-identifiable information, it may fall outside the scope of HIPAA and similar health privacy regulations, although this determination will depend on the specific data elements captured and their potential for linkage to patient records.
Clinical Validation and Research Data. The Company is currently in the research and development phase and is generating data in connection with internal testing and early-stage clinical validation studies. Based on our review, certain R&D datasets may include data derived from human blood samples, and the identifiability of such data is discussed further in Section III.C below.
Employee Data. The Company maintains standard human resources and payroll records for its eighteen (18) full-time employees, including personally identifiable information such as names, Social Security numbers, addresses, bank account information for direct deposit, and tax withholding information.
Business and Operational Data. The Company generates and maintains standard business records, including financial data, corporate records, intellectual property documentation, business plans, investor communications, and other operational data.
C. Data Classification
A critical aspect of any privacy and data security assessment is the accurate classification of data types to determine the applicable regulatory requirements. Based on our review, the following classifications are relevant:
Protected Health Information (PHI) under HIPAA. Once the MeridianPulse platform reaches clinical deployment and is used in connection with patient care by healthcare providers, diagnostic results and associated patient-identifying data will constitute PHI as defined in 45 C.F.R. § 160.103. At present, the Company is in the R&D phase, and the primary question is whether current research datasets contain PHI. Based on our discussions with Dr. Ochoa and our review of the Company's data flow documentation, certain pilot testing activities have involved the analysis of blood samples from identifiable individuals under informal arrangements. The Company has represented that it maintains these datasets on its secured cloud environment and limits access to authorized engineering and scientific personnel. However, the Company has not formally assessed whether these datasets meet the definition of PHI or whether the data has been properly de-identified under applicable HIPAA standards. This represents a gap that should be addressed promptly.
Personally Identifiable Information (PII). Employee records and any identifiable pilot patient data constitute PII subject to applicable state data protection laws, including Massachusetts 201 CMR 17.00 and, potentially, the CCPA/CPRA. The Company's employee PII is maintained through standard payroll and HR systems.
Proprietary and Trade Secret Data. The Company's device specifications, algorithms, software code, manufacturing processes, and patent-related data constitute proprietary information and trade secrets. The protection of this data is addressed through the Company's PIIAs, confidentiality agreements, and access controls, and is relevant to the Company's overall information security posture.
With respect to the question of whether current R&D datasets contain de-identified versus identifiable health data, the Company has not yet formally adopted either the Safe Harbor or Expert Determination method of de-identification under 45 C.F.R. § 164.514. We discuss this further in Section IV.B below and recommend that the Company formalize its de-identification procedures before expanding any pilot testing or research activities involving human samples.
IV. HIPAA COMPLIANCE ASSESSMENT
A. Covered Entity / Business Associate Status
A threshold question in any HIPAA compliance assessment is whether the entity under review is a "Covered Entity" or a "Business Associate" under the statute. The applicability of HIPAA's Privacy Rule, Security Rule, and Breach Notification Rule depends on this classification.
Current Status Analysis. Meridian's classification under HIPAA will depend on its deployment model for the MeridianPulse platform. We have analyzed the most likely deployment scenarios as follows:
(i) Deployment by Healthcare Providers (Most Likely Scenario). If the MeridianPulse device is deployed directly within healthcare provider facilities — such as hospitals, urgent care centers, or physician offices — and the Company accesses, creates, receives, maintains, or transmits PHI on behalf of those providers through its cloud-connected software platform, Meridian will likely function as a "Business Associate" as defined in 45 C.F.R. § 160.103. In this scenario, the healthcare provider operates as the Covered Entity, and Meridian, by providing a platform that processes and stores PHI in connection with the provider's treatment, payment, or healthcare operations activities, would be performing functions that bring it within the Business Associate definition. This is the deployment model most consistent with the Company's current business plans.
(ii) Cloud-Connected Analytics or Data Storage. To the extent Meridian offers cloud-connected analytics, remote monitoring, data storage, or reporting services tied to identifiable patient diagnostic results, the Company would be a Business Associate regardless of whether it deploys the physical device or merely provides the software-as-a-service component. The Company's current technical architecture contemplates cloud-based result processing and storage, which further supports the Business Associate classification.
(iii) Direct-to-Consumer Model (Future, Exploratory). If the Company were to pursue a direct-to-consumer model in which individuals purchase or use the MeridianPulse device outside of a healthcare provider relationship, the HIPAA analysis would be more nuanced. In general, a direct-to-consumer health technology company that does not engage in standard transactions (such as claims submission) and does not meet the Covered Entity definitions under 45 C.F.R. § 160.103 would not be subject to HIPAA. However, the specific structure of such a model, including any involvement of healthcare providers in ordering or interpreting tests, could alter this analysis. The Company has not yet developed a detailed direct-to-consumer business plan, and this scenario remains exploratory.
Current Assessment. Based on the Company's anticipated deployment model and technical architecture, we conclude that Meridian is likely to be classified as a Business Associate in the most probable commercial scenarios. The Company should plan and build its compliance program accordingly. Even during the current pre-commercial phase, to the extent the Company is handling any identifiable health data in connection with pilot testing or research activities, HIPAA obligations may already attach depending on the specific arrangements with data sources.
B. HIPAA Privacy Rule Compliance
The HIPAA Privacy Rule (45 C.F.R. Part 164, Subpart E) establishes national standards for the protection of individually identifiable health information. As a likely future Business Associate, Meridian will be required to comply with certain provisions of the Privacy Rule, primarily through the terms of Business Associate Agreements with Covered Entity customers and through compliance with applicable regulatory requirements that the HITECH Act extended directly to Business Associates.
Notice of Privacy Practices. The Company has drafted a Notice of Privacy Practices ("NPP"); however, this document is not yet finalized. Our review of the current draft indicates that the NPP requires revision to address the specific data flows of the MeridianPulse platform, including the categories of PHI collected, the purposes for which PHI is used and disclosed, and individual rights with respect to their health information. We note that, as a Business Associate, Meridian is not independently required to provide a NPP to individuals (that obligation rests with the Covered Entity), but the Company's own NPP draft suggests it may be contemplating scenarios in which it interacts directly with patients. The NPP should be revised to reflect the Company's actual role and data flows with specificity.
Minimum Necessary Standard. The Privacy Rule requires that uses and disclosures of PHI be limited to the minimum necessary to accomplish the intended purpose. The Company has policies in draft form addressing the minimum necessary standard, but these policies have not been finalized, formally adopted, or operationalized through technical controls such as role-based access limitations specific to PHI data elements. We recommend that the Company finalize these policies and implement corresponding technical controls prior to any clinical deployment involving PHI.
Authorization and Consent Forms. The Company is developing authorization and consent forms for clinical validation studies that may involve identifiable patient data. These forms are currently under development and were not available for review in final form. We recommend that company counsel review these forms for compliance with HIPAA authorization requirements under 45 C.F.R. § 164.508, as well as any applicable state law consent requirements and institutional review board ("IRB") protocols.
De-Identification Procedures. The Company is aware of the two permissible methods of de-identification under 45 C.F.R. § 164.514: the Safe Harbor method (removal of eighteen specified identifiers) and the Expert Determination method (a qualified statistical or scientific expert determines that the risk of identification is very small). However, the Company has not yet formally adopted either method, and no formal de-identification protocols or procedures have been documented. Given that certain R&D datasets may contain identifiable health data, the absence of formal de-identification procedures represents a gap that should be addressed. We recommend that the Company select and implement a de-identification methodology appropriate to its data types and use cases, and that the chosen methodology be documented and applied consistently.
Recommendation. The Company should formalize its HIPAA Privacy Rule compliance program prior to any clinical deployment or pilot activities involving identifiable patient data. This includes finalizing the NPP and minimum necessary policies, completing authorization and consent forms, and adopting formal de-identification procedures.
C. HIPAA Security Rule Compliance
The HIPAA Security Rule (45 C.F.R. Part 164, Subpart C) requires Covered Entities and Business Associates to implement administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and availability of electronic protected health information ("ePHI"). Our assessment of the Company's compliance with the Security Rule is set forth below.
Administrative Safeguards. The Company has designated Dr. Julian Ochoa, its Chief Technology Officer, as the interim Security Officer responsible for the Company's information security program. This designation satisfies the Security Rule's requirement under 45 C.F.R. § 164.308(a)(2) that a Covered Entity or Business Associate identify a security official responsible for developing and implementing security policies and procedures. However, Dr. Ochoa's role as CTO encompasses a broad range of responsibilities, and he does not have dedicated privacy or security staff supporting him. The absence of dedicated privacy and security personnel is a recognized gap, though it is not unusual for a company at Meridian's stage. We discuss this further in Section VII.C.
Physical Safeguards. The Company's Cambridge, Massachusetts office is equipped with badge-controlled access at the building and suite level. The Company has represented that any server infrastructure or equipment containing sensitive data is maintained in a restricted-access area within the office, with access limited to authorized personnel. The Company's cloud-hosted development and data environments are maintained by third-party providers whose physical security measures are addressed through their own SOC 2 and ISO 27001 certifications (see Section VI.A). For the MeridianPulse devices themselves, the Company has indicated that prototype units are secured when not in active use, although formal physical security protocols for device storage and transport are not yet documented.
Technical Safeguards. The Company's technical safeguards — including access controls, encryption, audit controls, integrity controls, and transmission security — are discussed in detail in Section VI of this memorandum.
Risk Assessment. A critical requirement of the HIPAA Security Rule is the performance of a formal risk analysis to assess the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI, as required by 45 C.F.R. § 164.308(a)(1)(ii)(A). The Company has not yet conducted such a formal risk analysis. This constitutes a significant gap in the Company's HIPAA compliance posture. A documented risk analysis is not only a regulatory requirement but also serves as the foundation for a risk-based security program, informing decisions about safeguard implementation, resource allocation, and residual risk acceptance. We strongly recommend that the Company conduct a formal HIPAA Security Rule risk analysis prior to any deployment involving ePHI. The Company should consider engaging a qualified security consultant with experience in healthcare and medical device environments to assist with this analysis.
Recommendation. Conduct a formal HIPAA Security Rule risk analysis as a priority item. Engage a qualified security consultant to assist. Use the risk analysis to inform the development and implementation of a comprehensive security management process, including risk management planning and sanction policies for workforce members who violate security policies.
D. Business Associate Agreements (BAAs)
The Company has executed Business Associate Agreements with two cloud infrastructure providers that are used for the Company's development environments. These BAAs were provided for our review and are discussed below.
The existing BAAs are generally conforming to HIPAA requirements under 45 C.F.R. § 164.504(e). Both agreements include provisions requiring the cloud providers to: (i) use or disclose PHI only as permitted or required by the agreement or as required by law; (ii) implement appropriate safeguards to prevent unauthorized use or disclosure of PHI; (iii) report to the Company any use or disclosure of PHI not provided for by the agreement; (iv) ensure that any subcontractors agree to the same restrictions and conditions; (v) make PHI available to individuals exercising their rights under the Privacy Rule; and (vi) make their practices and records available to the Secretary of the U.S. Department of Health and Human Services ("HHS") for compliance determination purposes.
However, we have identified certain areas where the existing BAAs could be strengthened to reflect current regulatory guidance and best practices. Specifically, the breach notification provisions in both BAAs should be updated to include more specific timelines for notification (the current language references "prompt" notification without specifying a maximum timeframe), and the agreements should be updated to reflect the HITECH Act's direct applicability of Security Rule and certain Privacy Rule provisions to Business Associates. Additionally, the agreements should include provisions addressing the return or destruction of PHI upon termination of the agreement and should more clearly define the permitted uses and disclosures.
The Company has not yet executed BAAs with anticipated downstream healthcare provider customers, as it is pre-commercial and has not yet entered into any commercial agreements. This is expected at this stage and does not represent a current compliance gap, but the Company will need to establish BAAs with healthcare provider customers as it moves toward commercial deployment.
Recommendation. The Company should develop a standard-form BAA template for use in future customer and vendor relationships. The template should be prepared by the Company's counsel (or by Calderwood & Harkness at Cobalt's request) and should reflect current HIPAA and HITECH Act requirements and regulatory guidance. Additionally, the Company should ensure that all current and future subcontractors that access, create, receive, maintain, or transmit PHI on the Company's behalf are parties to compliant BAAs. The existing BAAs with cloud infrastructure providers should be updated to address the specific gaps identified above.
E. HIPAA Breach Notification Preparedness
The HIPAA Breach Notification Rule (45 C.F.R. Part 164, Subpart D) requires Business Associates to notify Covered Entities of any breach of unsecured PHI without unreasonable delay and no later than sixty (60) days after discovery of the breach. Covered Entities, in turn, are required to notify affected individuals, the Secretary of HHS, and, in the case of breaches affecting 500 or more individuals, prominent media outlets serving the relevant state or jurisdiction.
The Company has a draft incident response plan, which is discussed in detail in Section VIII of this memorandum. However, the draft plan does not specifically address HIPAA breach notification timelines or the specific requirements applicable to Business Associates under the Breach Notification Rule. The plan does not include procedures for: (i) assessing whether an incident constitutes a "breach" under HIPAA, including the application of the four-factor risk assessment set forth in 45 C.F.R. § 164.402; (ii) determining whether the "low probability" exception to the breach definition applies; (iii) notifying the relevant Covered Entity within the required timeframe; or (iv) documenting the breach investigation and notification process.
The Company has reported that no breaches of PHI or other security incidents have occurred to date. This is consistent with the Company's early stage and limited data processing activities.
Recommendation. The Company should integrate HIPAA breach notification requirements into its incident response plan, including specific procedures for breach assessment, Covered Entity notification, and documentation. The plan should clearly identify the roles and responsibilities of personnel involved in breach assessment and notification, and should include template notification letters and regulatory reporting forms.
V. STATE PRIVACY LAW COMPLIANCE
A. Massachusetts — 201 CMR 17.00
As a company with its principal office in Cambridge, Massachusetts, Meridian is subject to the Massachusetts Standards for the Protection of Personal Information of Residents of the Commonwealth, codified at 201 CMR 17.00. These regulations apply to any person or entity that owns or licenses personal information about a resident of the Commonwealth of Massachusetts. "Personal information" under the regulation includes a Massachusetts resident's first and last name (or first initial and last name) in combination with any of the following: Social Security number, driver's license number, state-issued identification card number, or financial account number or credit/debit card number.
A central requirement of 201 CMR 17.00 is that covered entities develop, implement, and maintain a comprehensive Written Information Security Program ("WISP") that contains administrative, technical, and physical safeguards appropriate to the size, scope, and type of business of the entity, the amount of resources available to the entity, the amount of stored data, and the need for security and confidentiality of both consumer and employee information. The regulation specifies minimum requirements that a WISP must address, including designation of responsible employees, identification of internal and external risks, employee training, security policies for personnel with access to personal information, disciplinary measures for violations, restricted access controls, encryption requirements for transmitted records containing personal information, monitoring of systems, regular review of the WISP's effectiveness, and documentation of responsive actions to security breaches.
Current Status. The Company has a general information security policy (version 1.2, dated September 2025) that addresses certain security topics at a high level. However, this document does not constitute a WISP that satisfies the specific requirements of 201 CMR 17.00. The policy does not address all of the mandatory elements specified in the regulation, does not specifically reference Massachusetts law, and has not been reviewed or updated with the regulation's requirements in mind. Given that the Company maintains personal information of its Massachusetts-based employees (including, at a minimum, Social Security numbers and financial account information for payroll purposes), compliance with 201 CMR 17.00 is currently required.
Recommendation. The Company should prepare and adopt a compliant WISP that addresses all requirements of 201 CMR 17.00, including encryption requirements for personal information transmitted across public networks or stored on portable devices, access control measures, monitoring and audit procedures, employee training requirements, and provisions for regular review and updating of the program. This is identified as an immediate priority in our remediation timeline (Section XIII).
B. California — CCPA/CPRA
The California Consumer Privacy Act of 2018, as amended by the California Privacy Rights Act of 2020 (collectively, "CCPA/CPRA"), applies to for-profit businesses that collect personal information of California residents and that meet one or more of the following thresholds: (i) annual gross revenues in excess of $25 million; (ii) buying, selling, or sharing the personal information of 100,000 or more California residents, households, or devices annually; or (iii) deriving 50% or more of annual revenues from selling or sharing California residents' personal information.
Current Assessment. Based on the Company's current profile — eighteen (18) employees, pre-revenue status, and pre-commercial operations — Meridian does not currently meet any of the CCPA/CPRA applicability thresholds. The Company does not generate annual gross revenues in excess of $25 million, does not buy, sell, or share the personal information of 100,000 or more California residents, and does not derive revenue from selling or sharing personal information. While Cobalt Ventures LP is headquartered in Menlo Park, California, and Cobalt personnel may interact with the Company in various capacities, these interactions would not independently trigger CCPA/CPRA applicability for Meridian.
We note, however, that the CCPA/CPRA exempts certain categories of health information from its scope, including protected health information governed by HIPAA, medical information governed by the California Confidentiality of Medical Information Act ("CMIA"), and clinical trial data. To the extent Meridian's data processing activities involve such exempt data categories, those activities may fall outside the CCPA/CPRA even if the Company were to meet the applicability thresholds in the future.
Recommendation. The Company should monitor CCPA/CPRA applicability as it scales, particularly as it approaches commercial launch and begins generating revenue and collecting data from California residents. Foundational privacy practices implemented now — such as data mapping, privacy notices, and individual rights request procedures — will facilitate future CCPA/CPRA compliance if and when the applicability thresholds are met.
C. Other State Laws
The state privacy law landscape in the United States continues to evolve rapidly, with a growing number of states enacting comprehensive consumer privacy laws and, in some cases, laws specifically addressing health data. Several of these laws may be relevant to Meridian as it moves toward commercial deployment of the MeridianPulse platform on a multi-state or nationwide basis.
Notable examples include the Washington My Health My Data Act (RCW 19.373), which creates consumer health data protections outside the HIPAA framework and applies broadly to entities that collect, process, or share consumer health data of Washington residents; the Connecticut Data Privacy Act (Conn. Gen. Stat. § 42-515 et seq.); the Colorado Privacy Act (C.R.S. § 6-1-1301 et seq.); the Virginia Consumer Data Protection Act (Va. Code Ann. § 59.1-575 et seq.); and the Texas Data Privacy and Security Act (Tex. Bus. & Com. Code § 541.001 et seq.). Each of these laws has distinct applicability thresholds, exemptions, consumer rights provisions, and enforcement mechanisms. The Washington My Health My Data Act is of particular note because it applies broadly to consumer health data and does not include HIPAA-related exemptions that are common in other state privacy laws.
Recommendation. Prior to multi-state commercial launch, the Company should develop a comprehensive state law compliance matrix that maps the Company's anticipated data processing activities against the requirements of each applicable state law. This matrix should be maintained as a living document and updated as new laws are enacted or existing laws are amended. Calderwood & Harkness is available to assist in the preparation of such a compliance matrix.
VI. CYBERSECURITY POSTURE AND TECHNICAL CONTROLS
A. Network and Infrastructure Security
The Company's technical infrastructure is primarily cloud-hosted. The Company does not maintain an on-premises data center and has limited local network infrastructure at its Cambridge, Massachusetts office. Development environments, data storage, and application hosting are provided through third-party cloud infrastructure providers.
We have reviewed the security certifications and compliance attestations of the Company's primary cloud infrastructure providers. Both providers maintain SOC 2 Type II attestations and ISO 27001 certifications, indicating that their infrastructure and operational controls have been independently assessed and found to meet recognized security standards. The Company has represented that it has reviewed these attestation reports and has selected its providers in part based on their security posture.
Firewall protection, intrusion detection, and intrusion prevention systems for the Company's cloud environments are managed by the cloud providers as part of their infrastructure services. The Company has configured its cloud environments with network segmentation, access control lists, and security groups to limit network-level access to authorized users and services, although the maturity and comprehensiveness of these configurations have not been independently verified through technical testing.
At the Cambridge office, the local network infrastructure is limited to a standard commercial internet connection, Wi-Fi access points, and employee workstations. The Company has represented that the office Wi-Fi network is encrypted (WPA3) and that guest and corporate networks are segregated. No sensitive data processing occurs on local infrastructure; all development and data processing activities are conducted in the cloud environment.
The Company's endpoint protection posture includes the deployment of antivirus and anti-malware software on all company-issued laptops. The Company has a mobile device management ("MDM") policy in draft form but has not yet fully implemented an MDM solution. Given the Company's remote and hybrid work arrangements, the absence of a fully deployed MDM solution represents a gap that should be addressed to ensure that company-issued and any authorized personal devices accessing company systems are subject to appropriate security controls, including remote wipe capability, encryption enforcement, and compliance monitoring.
B. Encryption. Data at Rest. The Company has represented that diagnostic data and other sensitive information stored in its cloud environment is encrypted at rest using AES-256 encryption, which is a widely accepted and NIST-recommended encryption standard. This encryption is provided through the cloud infrastructure providers' storage services, with encryption keys managed through the providers' key management services. The Company has the option to implement customer-managed encryption keys ("CMEK") for additional control over key management, but has not yet elected to do so.
Data in Transit. All data transmissions between the MeridianPulse device and the Company's cloud backend are secured using Transport Layer Security ("TLS") version 1.2 or higher. The Company has represented that earlier, deprecated versions of TLS and SSL are not supported. API endpoints are secured with TLS, and certificate pinning is being evaluated for the device-to-cloud communication channel. Internal communications between cloud services are also encrypted in transit.
Encryption Key Management. The Company's current approach to encryption key management relies primarily on the key management services provided by its cloud infrastructure providers. While this approach is common and acceptable for early-stage companies, it means that key rotation, key access controls, and key storage are subject to the cloud providers' standard configurations. The Company has not yet implemented a formal encryption key management policy that addresses key generation, distribution, storage, rotation, revocation, and destruction. As the Company matures and begins handling PHI in production environments, a more robust key management framework should be developed.
Device-Level Encryption. The MeridianPulse device is designed to store diagnostic results locally on the device for a limited period before transmission to the cloud backend. Based on our review of the device architecture documentation, the Company has implemented on-device encryption for locally stored data using hardware-backed cryptographic modules. The specific implementation details are covered by the Company's issued patents and were reviewed in the context of the broader IP diligence. We note that the robustness of the device-level encryption implementation has not been independently tested or verified.
C. Access Controls and Authentication
The Company has implemented role-based access controls ("RBAC") in its cloud development environments, with access levels defined based on job function. Administrative access to cloud infrastructure is limited to Dr. Ochoa and two senior engineers. Application-level access controls for the MeridianPulse software platform are in development and will be critical for controlling access to PHI in clinical deployment scenarios.
Multi-Factor Authentication (MFA). Multi-factor authentication is currently enabled for access to the Company's cloud infrastructure management console and certain administrative functions. However, MFA is not yet uniformly deployed across all employee accounts and systems, including email, collaboration platforms, and code repositories. The inconsistent deployment of MFA across the organization represents a security gap. Compromised credentials remain one of the most common vectors for unauthorized access, and the implementation of MFA across all systems is a widely recognized and cost-effective security control.
Privileged Access Management. Dr. Ochoa, as CTO, and a small number of senior engineering team members maintain privileged (administrative) access to the Company's cloud environments, code repositories, and device firmware. The Company does not currently employ a formal privileged access management ("PAM") solution, such as a dedicated PAM tool with session monitoring, just-in-time access provisioning, or credential vaulting. At the Company's current scale, this is not uncommon, but formalized privileged access controls should be implemented as the team and the attack surface grow.
Recommendation. Implement MFA across all Company systems and accounts without exception. Formalize access provisioning and de-provisioning procedures, including procedures for promptly revoking access upon employee departure or role change. As the Company scales, evaluate and implement a PAM solution for administrative and privileged accounts.
D. Data Transmission Protocols
The MeridianPulse device communicates with the Company's cloud backend through a series of APIs that handle the transmission of diagnostic results, device telemetry, calibration data, and firmware updates. Our review of the Company's API documentation and data transmission architecture identified the following relevant considerations:
API Security. The device-to-cloud communication channel uses RESTful APIs secured with TLS 1.2+ and authenticated using API keys and OAuth 2.0 tokens. API rate limiting and input validation are implemented to mitigate common API-based attack vectors. The Company has represented that API security testing is conducted as part of its development process, although formal API security audits have not been performed by an independent third party.
Authentication Tokens. Device authentication tokens are generated during the device provisioning process and are stored in the device's hardware security module ("HSM"). Token rotation policies are documented in the device firmware specification, with tokens set to expire and require renewal at configurable intervals.
Data Integrity Verification. The Company implements checksums and digital signatures to verify the integrity of data transmitted between the device and the cloud backend. These mechanisms are designed to detect data corruption or tampering during transmission.
De-Identified vs. Identifiable Transmission. Based on our review, the current device architecture transmits diagnostic results along with a device identifier and, depending on the integration model, potentially patient-identifying information. The Company has indicated that it is evaluating a "split architecture" in which patient-identifying information is maintained by the healthcare provider's EHR system and only a pseudonymized or tokenized identifier is transmitted to the Company's cloud environment. This approach, if implemented, would significantly reduce the Company's exposure to identifiable PHI and simplify its HIPAA compliance obligations. We recommend that the Company finalize this architectural decision before clinical deployment and ensure that the chosen approach is reflected in its BAAs and privacy policies.
Third-Party Data Sharing. The Company has represented that it does not currently have any third-party data sharing arrangements beyond its cloud hosting providers. No diagnostic data is shared with external research institutions, pharmaceutical companies, or other third parties. If the Company contemplates such arrangements in the future, they will need to be structured in compliance with HIPAA, applicable state laws, and any consent or authorization requirements.
E. Vulnerability Management
The Company does not currently have a formal vulnerability management or patch management program documented in writing. Vulnerability management activities — including the application of security patches to cloud environments, operating systems, and application software — are handled on an ad hoc basis by the engineering team. While the Company has represented that critical patches are applied promptly, the absence of a formal program with documented procedures, scanning cadence, and remediation timelines represents a significant gap, particularly as the Company approaches clinical deployment.
No third-party penetration testing of the Company's cloud environment, APIs, or MeridianPulse device has been conducted to date. Penetration testing by an independent, qualified firm is an industry best practice and is increasingly expected by regulators, customers, and business partners in the healthcare and medical device sectors. The FDA's pre-market cybersecurity guidance also contemplates the submission of penetration testing results as part of the cybersecurity documentation for medical device regulatory submissions.
Recommendation. The Company should establish a formal vulnerability management program that includes: (i) regular automated vulnerability scanning of cloud environments and endpoints; (ii) a documented patch management process with defined timelines for the application of critical, high, medium, and low severity patches; (iii) an initial penetration test conducted by an independent, qualified firm before any clinical deployment of the MeridianPulse platform; and (iv) a recurring penetration testing cadence (at least annually, with additional testing following significant changes to the environment). The results of vulnerability scans and penetration tests should be documented, and identified vulnerabilities should be tracked through a formal remediation process.
F. Data Retention and Destruction
The Company has not yet formalized a data retention and destruction policy. Currently, R&D data, device telemetry data, and other information are retained indefinitely in the Company's cloud storage environment. No documented procedures exist for the periodic review and deletion of data that is no longer required for business, legal, or regulatory purposes.
The absence of a formal data retention and destruction policy creates both regulatory and practical risks. From a regulatory perspective, HIPAA requires Business Associates to return or destroy PHI upon termination of the Business Associate Agreement, and many state data protection laws impose limitations on the retention of personal information beyond the period necessary for the purpose for which it was collected. From a practical perspective, the indefinite retention of data increases the volume of information that could be compromised in the event of a security incident.
Recommendation. The Company should develop a data retention schedule that specifies the retention periods for each category of data, aligned with applicable regulatory requirements (including HIPAA, state laws, and FDA recordkeeping requirements) and business needs. The Company should also implement secure data destruction procedures, including procedures for the secure deletion of electronic data and the destruction of physical media, and should document the execution of data destruction activities. The retention schedule should be reviewed and updated on an annual basis.
VII. ORGANIZATIONAL AND PERSONNEL MEASURES
A. Employee Privacy and Security Training
Employee awareness and training is a critical component of any data privacy and security program. Human error and insider threats consistently rank among the leading causes of data breaches and security incidents, and a well-designed training program is one of the most effective measures for mitigating these risks.
The Company has conducted informal privacy and security awareness training for its engineering staff, primarily through presentations and discussions led by Dr. Ochoa. However, the Company does not have a formal, documented training program with a regular cadence. No training completion records are maintained, and training content has not been standardized or memorialized in a curriculum. Additionally, the Company has not implemented role-specific training modules that differentiate between the training needs of employees who will have access to health data and those who do not.
With a current headcount of eighteen (18) full-time employees, the Company is at a manageable scale for the implementation of a comprehensive training program. The relatively small size of the organization provides an opportunity to establish a strong culture of privacy and security awareness from the outset, which will serve the Company well as it grows.
Recommendation. The Company should implement a formal privacy and security training program that includes the following elements: (i) initial training for all new hires, to be completed within the first thirty (30) days of employment; (ii) annual refresher training for all employees; (iii) documented completion records maintained in employee files; (iv) role-specific training modules for employees with access to health data, including HIPAA awareness training; and (v) periodic supplemental training addressing emerging threats, such as phishing and social engineering. Training materials should be developed in consultation with the Company's counsel and should be updated annually to reflect changes in applicable laws, regulations, and the Company's operations.
B. Proprietary Information and Inventions Assignment Agreements (PIIAs)
As part of our diligence review, we reviewed the Company's standard form PIIA and the executed PIIAs for current employees. The Company's PIIA form includes confidentiality obligations covering patient and health data, proprietary information, trade secrets, and inventions assignment provisions. The PIIA form is generally consistent with market standards for early-stage life sciences and technology companies.
Our review indicates that most current employees have executed the Company's standard PIIA form. Verification of complete coverage across all eighteen (18) full-time employees was in process at the time of this memorandum, and we expect this verification to be completed prior to closing. We have been informed by Whitfield & Ames that two recently hired employees may not yet have executed PIIAs; this should be confirmed and remedied promptly.
As part of the broader closing deliverables for the Series Seed financing, Calderwood & Harkness has prepared a revised PIIA form that strengthens certain provisions related to data privacy and security obligations, clarifies the scope of inventions assignment for employees engaged in medical device and software development, and incorporates updated non-solicitation and non-competition provisions consistent with applicable state law requirements.
Recommendation. Ensure that all current employees execute the updated PIIA form prepared by Calderwood & Harkness. All future hires should be required to execute the updated PIIA as a condition of employment. The Company should maintain a centralized record of all executed PIIAs and include PIIA compliance as part of the onboarding checklist.
C. Designated Privacy and Security Personnel
As noted in Section IV.C above, Dr. Julian Ochoa, the Company's Chief Technology Officer, serves as the interim Security Officer responsible for the Company's information security program. While this designation satisfies the formal requirements of the HIPAA Security Rule, it is important to recognize that Dr. Ochoa's primary responsibilities as CTO — including overseeing product development, engineering, and technical operations — necessarily limit the time and attention he can devote to privacy and security compliance matters. The Company does not currently have a dedicated Chief Information Security Officer ("CISO"), Data Protection Officer ("DPO"), or any other employee whose primary responsibility is data privacy and security.
Nadia Chen, the Company's Vice President of Operations, handles certain operational compliance matters, including coordination with external auditors, management of vendor relationships, and oversight of employee onboarding processes. Ms. Chen has been responsive and engaged during the diligence process, but her role does not include dedi