Security and Compliance Terms

ARTICLE 1. PURPOSE, SCOPE, AND INCORPORATION

1.1 Purpose. The purpose of this Security and Compliance Exhibit (the "Security Exhibit") is to describe the administrative, technical, and physical security measures, practices, standards, and compliance commitments that Provider maintains in connection with the provision of the Platform and Professional Services under the MSA. The Security Exhibit is intended to provide Customer with transparency regarding Provider's information security program and to satisfy the security-related contractual expectations commonly required in enterprise procurement processes.

1.2 Incorporation. The Security Exhibit is attached to and forms an integral part of the MSA. Capitalized terms used but not defined herein shall have the meanings ascribed to them in the MSA or the DPA, as applicable. In the event of any conflict between the terms of this Security Exhibit and Section 22 of the MSA, the terms of this Security Exhibit shall prevail to the extent of the inconsistency.

1.3 Scope. The security measures described in this Security Exhibit apply to all systems, networks, facilities, personnel, and processes used by Provider to deliver the Platform and to process, store, or transmit Customer Content and Personal Data. Where Customer has selected a Customer-Controlled Infrastructure or Hybrid Deployment Model, Provider's security obligations under this Security Exhibit shall be limited to those components and layers of the environment that remain within Provider's operational control. Customer shall be solely responsible for the security of all infrastructure, systems, and environments that are owned, operated, or managed by Customer or Customer's designated hosting providers, as further described in Section 23.3 of the MSA and the applicable Deployment Model Addendum.

1.4 Regulatory and Framework Alignment. Provider's information security program is designed to align with recognized industry frameworks and applicable legal requirements, including, without limitation:

(a) The NIST Cybersecurity Framework (CSF) 2.0 (NIST CSWP 29, February 2024), encompassing the six core functions of Govern, Identify, Protect, Detect, Respond, and Recover;

(b) NIST Special Publication 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations;

(c) The AICPA Trust Services Criteria (SOC 2), addressing security, availability, processing integrity, confidentiality, and privacy;

(d) ISO/IEC 27001:2022, Information Security Management Systems;

(e) The Delaware Personal Data Privacy Act (6 Del. C. Ch. 12D), particularly the security obligations imposed on controllers and processors;

(f) The Delaware Computer Security Breaches statute (6 Del. C. Ch. 12B); and

(g) Such additional frameworks, standards, or regulations as may be applicable to Provider's operations or as may be specified in the applicable Order Form.

Provider does not represent or warrant that it holds formal certification under every framework listed above; rather, Provider's security program is designed with reference to the principles and controls articulated in such frameworks and is subject to periodic assessment and improvement.

ARTICLE 2. INFORMATION SECURITY GOVERNANCE

2.1 Security Program. Provider shall establish, implement, and maintain a comprehensive, written information security program (the "Security Program") that is commensurate with the nature, scope, and complexity of Provider's operations and the sensitivity of the data processed on behalf of its customers. The Security Program shall address, at a minimum, the governance, risk management, asset protection, threat detection, incident response, and recovery functions contemplated by the NIST CSF 2.0.

2.2 Designated Security Officer. Provider shall designate a senior-level individual (or team, as appropriate) with responsibility for the development, implementation, oversight, and enforcement of the Security Program. Such individual or team shall report to Provider's executive management and shall have the authority and resources necessary to carry out the responsibilities assigned under the Security Program.

2.3 Policies and Procedures. Provider shall maintain and enforce documented information security policies and procedures covering, at a minimum: (a) acceptable use of information systems and data; (b) access control and identity management; (c) data classification, handling, and retention; (d) encryption and key management; (e) network security and segmentation; (f) secure software development; (g) change management and configuration management; (h) vulnerability management and patch management; (i) logging, monitoring, and alerting; (j) incident response and breach notification; (k) business continuity and disaster recovery; (l) third-party and supply chain risk management; (m) physical and environmental security; and (n) employee security awareness and training.

2.4 Risk Assessment. Provider shall conduct formal information security risk assessments at least annually, and more frequently when material changes to the threat landscape, technology environment, or business operations warrant additional evaluation. Risk assessments shall identify, analyze, evaluate, and document threats and vulnerabilities that could affect the confidentiality, integrity, or availability of Customer Content and Personal Data, and shall inform the prioritization of security controls and remediation efforts. Risk assessment methodologies shall be consistent with recognized frameworks, including NIST SP 800-30 Rev. 1 (Guide for Conducting Risk Assessments) or equivalent.

2.5 Board and Executive Oversight. Provider's executive management shall receive periodic reports on the status of the Security Program, including summaries of risk assessments, audit findings, incident trends, and remediation activities. Such reporting shall occur no less frequently than quarterly or upon the occurrence of a material security event.

ARTICLE 3. ACCESS CONTROLS AND IDENTITY MANAGEMENT

3.1 Principle of Least Privilege. Provider shall implement and enforce the principle of least privilege across all systems, applications, and data repositories used to process Customer Content and Personal Data. Access rights shall be granted based on the minimum permissions necessary for an individual to perform the individual's assigned duties and shall be reviewed and adjusted on a regular basis.

3.2 Authentication. Provider shall implement strong authentication mechanisms for all access to systems that process, store, or transmit Customer Content or Personal Data, including:

(a) Unique user identifiers for all personnel, prohibiting the use of shared or generic accounts for access to production systems;

(b) Multi-factor authentication (MFA) for all privileged access (including administrative, root, and database access), remote access to production environments, and access to Provider's internal management consoles;

(c) Password policies requiring minimum complexity thresholds (no fewer than twelve (12) characters, combining uppercase, lowercase, numeric, and special characters), prohibition of previously compromised passwords (verified against recognized breach databases), and mandatory rotation or expiration intervals consistent with current NIST guidance (NIST SP 800-63B); and

(d) Session management controls, including automatic session timeout after a defined period of inactivity and re-authentication requirements for sensitive operations.

3.3 Access Reviews. Provider shall conduct access reviews for all systems containing Customer Content or Personal Data at least quarterly. Such reviews shall verify that access rights are appropriate, that separated or transferred personnel have had their access promptly revoked, and that no unauthorized accounts exist. Findings from access reviews shall be documented and remediated within a commercially reasonable timeframe.

3.4 Privileged Access Management. Provider shall implement enhanced controls for privileged accounts, including: (a) dedicated privileged access workstations or jump servers for administrative access to production environments; (b) logging and monitoring of all privileged account activity; (c) time-limited or just-in-time provisioning of elevated access where technically feasible; and (d) separation of duties between development, operations, and security personnel.

3.5 Deprovisioning. Provider shall revoke access to all systems, applications, and data repositories for any personnel whose access is no longer required (including upon termination of employment, change of role, or conclusion of a contractor engagement) within twenty-four (24) hours of the triggering event. For personnel with privileged access, deprovisioning shall occur immediately upon the triggering event.

ARTICLE 4. ENCRYPTION AND KEY MANAGEMENT

4.1 Encryption in Transit. All Customer Content and Personal Data transmitted between Customer and the Platform, between components of the Platform, or between the Platform and any third-party system shall be encrypted using Transport Layer Security (TLS) version 1.2 or higher, or an equivalent cryptographic protocol providing comparable or superior protection. Provider shall disable support for deprecated or weak cryptographic protocols and cipher suites.

4.2 Encryption at Rest. All Customer Content and Personal Data stored within the Platform (including in databases, file systems, object storage, backups, and archives) shall be encrypted at rest using the Advanced Encryption Standard (AES) with a key length of at least 256 bits, or an equivalent encryption algorithm providing comparable or superior protection, consistent with the requirements of NIST SP 800-175B (Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms) and FIPS 140-2 (or its successor, FIPS 140-3) validated cryptographic modules where available.

4.3 Key Management. Provider shall maintain a documented key management program that addresses the generation, distribution, storage, rotation, revocation, and destruction of cryptographic keys. Key management practices shall include:

(a) Use of hardware security modules (HSMs) or equivalent mechanisms for the protection of master encryption keys;

(b) Separation of key management duties from data access duties;

(c) Regular rotation of encryption keys at intervals consistent with industry best practices and the sensitivity of the data being protected, but no less frequently than annually for data encryption keys;

(d) Secure destruction of keys that are no longer required, in a manner that renders them irrecoverable; and

(e) Access to encryption keys restricted to the minimum number of authorized personnel necessary for operational purposes.

4.4 Third-Party AI Processing. Where Customer Content is transmitted to third-party AI systems in connection with Platform functionality (as described in Section 9.5 of the MSA), Provider shall ensure that such content is encrypted in transit and that only encrypted fragments are processed, minimizing the exposure of unencrypted Customer Content to third-party environments. Provider shall contractually require third-party AI providers to maintain encryption standards no less protective than those described in this Article 4.

ARTICLE 5. NETWORK SECURITY

5.1 Network Architecture. Provider shall implement and maintain a layered network security architecture that incorporates, at a minimum:

(a) Firewalls and network access control lists at all external boundaries and between security zones within the production environment;

(b) Network segmentation to isolate production systems from development, staging, testing, and corporate environments;

(c) Intrusion detection and prevention systems (IDS/IPS) monitoring inbound and outbound network traffic for indicators of compromise;

(d) Web application firewalls (WAFs) protecting customer-facing application interfaces and APIs from common web-based attacks (including those cataloged in the OWASP Top 10); and

(e) Distributed denial-of-service (DDoS) mitigation capabilities, whether implemented through Provider's own infrastructure or through a qualified third-party mitigation service.

5.2 Network Monitoring. Provider shall continuously monitor network traffic and system activity within the production environment for anomalous behavior, unauthorized access attempts, and indicators of compromise. Monitoring shall encompass, at a minimum, firewall logs, IDS/IPS alerts, authentication logs, API access logs, and DNS query logs. Alerts generated by monitoring systems shall be triaged and investigated in accordance with Provider's incident response procedures.

5.3 Secure Remote Access. All remote access to Provider's production environment shall be conducted through encrypted virtual private network (VPN) tunnels or equivalent secure access mechanisms, and shall require multi-factor authentication. Provider shall maintain audit trails of all remote access sessions, including session start and end times, originating IP addresses, and user identifiers.

ARTICLE 6. APPLICATION SECURITY AND SECURE DEVELOPMENT

6.1 Secure Development Lifecycle. Provider shall maintain a documented secure software development lifecycle (SDLC) program that integrates security considerations into every phase of the development process, from requirements gathering through design, coding, testing, deployment, and maintenance. The SDLC program shall be consistent with recognized industry practices, including the principles articulated in the NIST Secure Software Development Framework (SSDF, NIST SP 800-218) and the OWASP Software Assurance Maturity Model (SAMM).

6.2 Code Review and Testing. Provider shall conduct the following security-related activities prior to deploying code to the production environment:

(a) Peer code review for all code changes that affect security-relevant functionality, authentication, authorization, data handling, or cryptographic operations;

(b) Static application security testing (SAST) to identify common coding vulnerabilities, including those identified in the OWASP Top 10 and CWE Top 25 Most Dangerous Software Weaknesses;

(c) Dynamic application security testing (DAST) against staging or pre-production environments, performed no less frequently than quarterly; and

(d) Dependency scanning to identify known vulnerabilities in third-party libraries, open-source components, and software dependencies, with timely remediation of critical and high-severity findings.

6.3 Change Management. Provider shall maintain a formal change management process governing all changes to the production environment, including code deployments, infrastructure modifications, configuration changes, and database schema updates. The change management process shall require documented approval, testing in a non-production environment prior to deployment, rollback procedures, and post-deployment verification.

6.4 API Security. Provider shall implement security controls for all application programming interfaces (APIs) used by or accessible through the Platform, including authentication and authorization enforcement, input validation, rate limiting, logging of API calls, and protection against injection, replay, and man-in-the-middle attacks.

ARTICLE 7. VULNERABILITY MANAGEMENT AND PATCH MANAGEMENT

7.1 Vulnerability Scanning. Provider shall conduct automated vulnerability scans of all systems, applications, and network devices within the production environment on a regular basis, and no less frequently than monthly. Vulnerability scans shall include both internal and external perspectives and shall cover operating systems, middleware, applications, databases, and network infrastructure.

7.2 Penetration Testing. Provider shall engage a qualified, independent third party to conduct penetration testing of the Platform and its supporting infrastructure at least annually, and following any material change to the architecture or security posture of the production environment. Penetration testing shall encompass both network-level and application-level assessments, including tests for common attack vectors such as injection, authentication bypass, privilege escalation, and data exfiltration. Provider shall remediate all critical and high-severity findings identified through penetration testing within the timeframes set forth in Section 7.4 and shall make a summary of penetration testing results available to Customer upon written request, subject to Provider's reasonable confidentiality requirements.

7.3 Patch Management. Provider shall maintain a documented patch management program requiring the identification, evaluation, testing, and deployment of security patches and updates for all systems and software within the production environment. The patch management program shall align with recognized industry practices and shall include:

(a) Monitoring of vendor advisories, CVE databases (including the NIST National Vulnerability Database), and other authoritative sources for newly disclosed vulnerabilities;

(b) Risk-based prioritization of patches based on the severity of the vulnerability (using the Common Vulnerability Scoring System, CVSS, or equivalent), the exploitability of the vulnerability, and the sensitivity of the affected system; and

(c) Timely deployment of patches in accordance with the remediation timeframes set forth in Section 7.4.

7.4 Remediation Timeframes. Provider shall remediate identified vulnerabilities in accordance with the following target timeframes, measured from the date the vulnerability is confirmed and a patch or remediation is available:

Where remediation within the target timeframe is not technically feasible, Provider shall implement compensating controls to mitigate the risk and shall document the rationale for the deviation and the expected remediation timeline.

ARTICLE 8. LOGGING, MONITORING, AND AUDIT TRAILS

8.1 Logging. Provider shall generate and retain audit logs for all security-relevant events occurring within the production environment. Logged events shall include, at a minimum:

(a) Authentication events (successful and failed login attempts, password changes, MFA enrollment and usage);

(b) Authorization events (access grants, denials, and privilege escalations);

(c) Administrative actions (account creation, modification, and deletion; configuration changes; policy modifications);

(d) Data access events (access to, modification of, or deletion of Customer Content or Personal Data by Provider personnel);

(e) System events (system startup and shutdown, service start and stop, error conditions, and hardware failures);

(f) Network events (firewall rule changes, IDS/IPS alerts, VPN connections, and anomalous traffic patterns); and

(g) Application events (API calls, query execution, data export operations, and error logs).

8.2 Log Integrity. Provider shall implement measures to protect the integrity of audit logs against tampering, unauthorized modification, or deletion, including write-once storage mechanisms, cryptographic hashing, centralized log aggregation, and access controls restricting log modification to a minimal set of authorized security personnel.

8.3 Log Retention. Provider shall retain audit logs for a minimum of twelve (12) months in readily accessible storage, and for an additional period sufficient to comply with applicable Law and any regulatory requirements, but in no event less than twenty-four (24) months in aggregate (including archived storage). Customer-specific log retention periods may be specified in the applicable Order Form or Deployment Model Addendum.

8.4 Monitoring and Alerting. Provider shall implement automated monitoring and alerting systems that continuously analyze log data and system telemetry for indicators of compromise, security anomalies, and policy violations. Alert thresholds and correlation rules shall be tuned to minimize false positives while maintaining effective detection of genuine security events. Provider shall maintain documented procedures for the triage, investigation, and escalation of alerts.

8.5 Security Information and Event Management. Provider shall utilize a security information and event management (SIEM) system, or equivalent technology, to aggregate, correlate, and analyze security events across all components of the production environment. The SIEM system shall support real-time alerting, dashboarding, and forensic investigation capabilities.

ARTICLE 9. PHYSICAL AND ENVIRONMENTAL SECURITY

9.1 Data Center Security. Where Customer Content or Personal Data is stored in data centers operated by Provider or by Provider's hosting providers, Provider shall ensure that such facilities maintain physical and environmental security controls consistent with industry standards for enterprise data center operations, including:

(a) Perimeter controls, including fencing, barriers, security lighting, and surveillance cameras with continuous recording and retention for a minimum of ninety (90) calendar days;

(b) Multi-layered access controls, including biometric or card-based entry systems, mantrap or turnstile mechanisms at facility entry points, and visitor management procedures requiring escort by authorized personnel;

(c) Twenty-four-hour, seven-day-per-week (24/7) on-site security personnel or remote monitoring services;

(d) Environmental controls, including fire detection and suppression systems (e.g., pre-action sprinklers, gas-based suppression), temperature and humidity monitoring, water leak detection, and uninterruptible power supplies (UPS) with generator backup; and

(e) Redundant power and cooling infrastructure designed to maintain continuous operations during utility outages or equipment failures.

9.2 Third-Party Hosting Providers. Where Provider utilizes third-party hosting or cloud infrastructure providers (e.g., Amazon Web Services, Google Cloud Platform, Microsoft Azure, or equivalent), Provider shall ensure that such providers maintain physical and environmental security controls that are materially consistent with the requirements described in Section 9.1, as evidenced by the hosting provider's SOC 2 Type II report, ISO 27001 certification, or equivalent third-party assurance. Provider shall make the identity and material security certifications of its primary hosting providers available to Customer upon written request.

9.3 Media Handling and Disposal. Provider shall maintain documented procedures for the secure handling, transportation, storage, and disposal of physical media (including hard drives, solid-state drives, tapes, removable storage devices, and printed documents) that contain or have contained Customer Content or Personal Data. Disposal of such media shall be performed using methods consistent with NIST SP 800-88 Rev. 1 (Guidelines for Media Sanitization), including cryptographic erasure, degaussing, or physical destruction, as appropriate for the media type. Provider shall maintain records of media disposal activities and shall make such records available to Customer upon written request.

ARTICLE 10. PERSONNEL SECURITY

10.1 Background Screening. Provider shall conduct background checks on all personnel who will have access to Customer Content or Personal Data, to the extent permitted by applicable Law and consistent with the nature and sensitivity of the access granted. Background checks shall be completed prior to the commencement of access and shall include, at a minimum, verification of identity, criminal history checks, and employment history verification, in each case to the extent permitted by the laws of the jurisdiction in which the individual resides.

10.2 Security Awareness Training. Provider shall maintain a mandatory information security awareness training program for all personnel, including employees, contractors, and temporary staff. Training shall be conducted upon initial onboarding and no less frequently than annually thereafter. The training program shall address, at a minimum: (a) Provider's information security policies and procedures; (b) recognition of and response to phishing, social engineering, and other common attack vectors; (c) data handling, classification, and protection requirements; (d) incident reporting procedures; (e) secure use of credentials and authentication mechanisms; and (f) regulatory and contractual obligations related to the protection of Customer data.

10.3 Role-Based Training. In addition to general security awareness training, Provider shall provide targeted, role-specific security training to personnel whose responsibilities involve elevated access to systems, data, or security infrastructure. Such training shall cover secure coding practices (for development personnel), privileged access management (for system administrators), and incident response procedures (for security operations personnel).

10.4 Confidentiality Agreements. All Provider personnel who have access to Customer Content or Personal Data shall be bound by written confidentiality obligations, whether through employment agreements, contractor agreements, or standalone non-disclosure agreements, consistent with the requirements of Section 5.1 of the DPA and Section 12 of the MSA.

ARTICLE 11. BUSINESS CONTINUITY AND DISASTER RECOVERY

11.1 Business Continuity Plan. Provider shall maintain a documented business continuity plan ("BCP") designed to ensure the continued availability and integrity of the Platform and Customer Content in the event of a disruptive incident, including natural disasters, infrastructure failures, cyberattacks, and other events that may impair Provider's ability to deliver the services. The BCP shall be reviewed and updated at least annually, and following any material change to Provider's infrastructure, operations, or risk profile.

11.2 Disaster Recovery Plan. Provider shall maintain a documented disaster recovery plan ("DRP") that addresses the restoration of critical systems, data, and services following a disruptive event. The DRP shall define:

(a) Recovery Time Objective (RTO): the maximum tolerable duration of time within which the Platform and its critical functions must be restored following a disruptive event. Unless a different RTO is specified in the applicable Order Form, Provider's target RTO shall be twenty-four (24) hours;

(b) Recovery Point Objective (RPO): the maximum tolerable period of data loss, measured in time, following a disruptive event. Unless a different RPO is specified in the applicable Order Form, Provider's target RPO shall be four (4) hours; and

(c) Recovery procedures, roles, responsibilities, communication protocols, and escalation paths.

11.3 Data Backup. Provider shall maintain a data backup program that includes:

(a) Regular backups of Customer Content and system configurations, performed no less frequently than daily for incremental backups and weekly for full backups;

(b) Storage of backup copies in a geographically separate facility or region from the primary production environment, with protections against simultaneous loss;

(c) Encryption of all backup data in transit and at rest, using standards consistent with Article 4 of this Security Exhibit; and

(d) Regular testing of backup restoration procedures to verify the recoverability and integrity of backed-up data, performed no less frequently than semi-annually.

11.4 Testing. Provider shall test the BCP and DRP no less frequently than annually through tabletop exercises, simulation exercises, or full failover tests, as appropriate. Test results shall be documented, and any deficiencies identified during testing shall be remediated within a commercially reasonable timeframe. Provider shall make a summary of the most recent BCP/DRP test results available to Customer upon written request.

ARTICLE 12. INCIDENT RESPONSE

12.1 Incident Response Plan. Provider shall maintain a documented incident response plan ("IRP") that establishes the procedures, roles, responsibilities, communication protocols, and escalation paths for responding to security incidents. The IRP shall be consistent with the NIST Computer Security Incident Handling Guide (NIST SP 800-61 Rev. 2, or its successor) and shall address the full incident lifecycle: preparation, detection and analysis, containment, eradication and recovery, and post-incident activity.

12.2 Incident Response Team. Provider shall designate an incident response team comprising personnel with the necessary authority, expertise, and resources to manage security incidents. The incident response team shall be reachable at all times (24/7) for Severity 1 security incidents affecting Customer Content or Personal Data.

12.3 Notification. Provider's obligations regarding notification of Personal Data Breaches and security incidents are set forth in Article 9 of the DPA and Section 22.3 of the MSA. The provisions of the DPA and the MSA shall govern in all respects with regard to breach notification timing, content, and procedures.

12.4 Forensic Capability. Provider shall maintain the capability, whether through internal resources or pre-engaged third-party forensic consultants, to conduct forensic investigations of security incidents affecting Customer Content or Personal Data. Forensic investigations shall preserve the chain of custody of evidence and shall be conducted in a manner that supports any subsequent legal, regulatory, or insurance proceedings.

12.5 Post-Incident Review. Following any significant security incident (including any Severity 1 incident or any incident involving a confirmed or reasonably suspected Personal Data Breach), Provider shall conduct a post-incident review, consistent with the post-mortem procedures described in Section 8.3 of the SLA Exhibit, and shall implement corrective actions to address identified root causes and reduce the likelihood of recurrence.

ARTICLE 13. THIRD-PARTY AND SUPPLY CHAIN RISK MANAGEMENT

13.1 Vendor Risk Assessment. Prior to engaging any third-party vendor, Sub-processor, or service provider that will have access to Customer Content or Personal Data, Provider shall conduct a risk assessment of the vendor's security posture, practices, and compliance profile. The assessment shall evaluate, at a minimum, the vendor's data protection practices, encryption standards, access controls, incident response capabilities, and applicable certifications or audit reports.

13.2 Contractual Safeguards. Provider shall enter into written agreements with all third-party vendors, Sub-processors, and service providers that access or process Customer Content or Personal Data, imposing data protection and security obligations no less protective than those set forth in this Security Exhibit and the DPA. Such agreements shall include, at a minimum, confidentiality obligations, security requirements, breach notification obligations, audit rights, and data deletion or return obligations upon termination.

13.3 Ongoing Monitoring. Provider shall monitor the security posture and compliance of its critical third-party vendors and Sub-processors on an ongoing basis, including through periodic review of updated audit reports, certifications, or compliance attestations, and through reassessment following any material security incident involving such vendor.

13.4 Software Supply Chain. Provider shall maintain practices to manage software supply chain risk, including: (a) maintaining an inventory of third-party and open-source software components used in the Platform (a software bill of materials, or "SBOM"); (b) monitoring for newly disclosed vulnerabilities affecting such components; and (c) timely patching or replacement of vulnerable components in accordance with the remediation timeframes set forth in Section 7.4.

ARTICLE 14. DATA ISOLATION AND MULTI-TENANCY

14.1 Logical Separation. In Provider-Hosted SaaS deployments, Provider shall implement logical separation of Customer Content and Personal Data from the data of other customers within multi-tenant environments. Logical separation shall be achieved through a combination of access controls, authentication mechanisms, database-level isolation (e.g., separate schemas, row-level security, or equivalent mechanisms), and application-level controls that prevent unauthorized cross-tenant data access.

14.2 Testing. Provider shall periodically test the effectiveness of its multi-tenant isolation controls to verify that one customer's data cannot be accessed, viewed, modified, or deleted by another customer. Such testing shall be incorporated into Provider's regular penetration testing program described in Section 7.2.

14.3 Customer-Controlled Environments. Where the Platform is deployed on Customer-Controlled Infrastructure, data isolation is achieved through the dedicated nature of the deployment, and Customer shall be responsible for implementing and maintaining isolation controls within its own environment.

ARTICLE 15. AI-SPECIFIC SECURITY CONSIDERATIONS

15.1 Model Security. Provider shall implement security controls to protect the integrity, confidentiality, and availability of the machine learning models, AI agents, and related algorithms used within the Platform. Such controls shall include, at a minimum: (a) access controls restricting model access to authorized personnel and systems; (b) versioning and integrity verification of deployed models; (c) monitoring for model drift, anomalous outputs, or adversarial manipulation; and (d) secure storage of model weights, parameters, and training artifacts.

15.2 Prompt and Input Security. Provider shall implement controls to mitigate the risks associated with adversarial inputs, prompt injection attacks, and other AI-specific attack vectors, including input validation, output filtering, and monitoring for patterns indicative of attempted manipulation of AI system behavior.

15.3 Output Controls. Provider shall implement controls to reduce the risk that AI-generated outputs inadvertently expose Customer Content, Personal Data, or Confidential Information from one customer to another, including through response filtering, output sanitization, and the logical separation mechanisms described in Article 14.

15.4 Third-Party AI Providers. Where the Platform utilizes third-party AI models or services, Provider shall: (a) conduct security assessments of such third-party providers prior to engagement and on an ongoing basis; (b) ensure that data transmitted to third-party AI providers is encrypted in transit and that only the minimum necessary data is shared; (c) contractually prohibit third-party AI providers from using Customer Content for model training or any purpose other than providing the requested service; and (d) maintain documentation of all third-party AI providers integrated into the Platform, which documentation shall be made available to Customer upon written request.

ARTICLE 16. COMPLIANCE CERTIFICATIONS AND ASSURANCE

16.1 SOC 2 Type II. Provider shall obtain and maintain, or shall endeavor to obtain and maintain, a SOC 2 Type II report (or equivalent assurance report) issued by an independent, qualified third-party auditor, covering the Trust Services Criteria for security and availability (and, where applicable, confidentiality and processing integrity). The SOC 2 Type II report shall be refreshed at least annually. Provider shall make the most recent SOC 2 Type II report (or a summary thereof) available to Customer under non-disclosure agreement upon written request. If Provider has not yet obtained a SOC 2 Type II report at the time of execution of this Security Exhibit, Provider shall disclose that fact to Customer and shall provide a projected timeline for obtaining such report.

16.2 Additional Certifications. Provider may, at its discretion, pursue additional security certifications or compliance attestations, including ISO 27001 certification, ISO 27701 certification (privacy information management), CSA STAR certification, or HITRUST certification. Provider shall inform Customer in writing of the attainment or renewal of any such certifications.

16.3 Customer Questionnaires. Provider shall use commercially reasonable efforts to respond to Customer's security questionnaires, vendor assessment forms, and due diligence requests within a commercially reasonable timeframe (not to exceed twenty (20) Business Days of receipt), provided that Customer limits such requests to no more than once per twelve-month period (unless a material security incident or regulatory inquiry necessitates additional assessment). Provider may satisfy such requests by providing its SOC 2 Type II report, completed standardized questionnaires (e.g., SIG Lite, CAIQ), or other documentation that addresses Customer's inquiries.

16.4 Right to Audit. Customer's right to audit Provider's security practices is governed by Article 11 of the DPA. The provisions of the DPA shall apply with respect to audit scope, frequency, conditions, and cost allocation.

ARTICLE 17. SECURITY INCIDENT COORDINATION WITH CUSTOMER

17.2 Coordination Procedures. In the event of a security incident affecting Customer Content or Personal Data, the Parties shall cooperate in accordance with the notification and response procedures set forth in Article 9 of the DPA, Section 22.3 of the MSA, and Article 12 of this Security Exhibit. Provider shall keep Customer reasonably informed throughout the duration of the incident and shall participate in joint incident calls as reasonably requested by Customer.

ARTICLE 18. CONTINUOUS IMPROVEMENT AND UPDATES

18.1 Continuous Improvement. Provider is committed to the continuous improvement of its Security Program and the security measures described in this Security Exhibit. Provider shall monitor developments in the cybersecurity threat landscape, emerging attack techniques, regulatory requirements, and industry best practices, and shall incorporate appropriate enhancements into its Security Program on an ongoing basis.

18.2 Updates to Security Measures. Provider may update the technical and organizational security measures described in this Security Exhibit from time to time to reflect changes in technology, threat landscape, regulatory requirements, or operational practices. Any such update shall not materially diminish the overall level of protection afforded to Customer Content and Personal Data during the then-current Subscription Term. Provider shall notify Customer in writing of any material changes to the security measures described herein at least thirty (30) calendar days prior to implementation, and Customer shall have the right to review and discuss such changes with Provider.

18.3 Regulatory Changes. If changes to applicable Data Protection Laws or security regulations impose additional or modified security requirements affecting the processing of Customer Content or Personal Data, the Parties shall cooperate in good faith to implement the necessary changes within commercially reasonable timeframes.

ARTICLE 19. RELATIONSHIP TO OTHER AGREEMENT DOCUMENTS

19.1 Relationship to the MSA. This Security Exhibit supplements and is subject to the terms of the MSA. Except as expressly modified or supplemented by this Security Exhibit, all terms and conditions of the MSA apply in full, including the provisions relating to limitation of liability (Section 15), indemnification (Section 16), confidentiality (Section 12), and dispute resolution (Section 28).

19.2 Relationship to the DPA. Where this Security Exhibit addresses matters also covered by the DPA (including security measures, breach notification, audits, and Sub-processor oversight), the provisions of this Security Exhibit and the DPA shall be read together. In the event of any conflict between this Security Exhibit and the DPA, the provision that affords the greater degree of protection to Customer Content and Personal Data shall prevail.

19.3 Relationship to the SLA Exhibit. This Security Exhibit addresses the security and compliance dimensions of Provider's service delivery, while the SLA Exhibit addresses service availability, support, and performance. The two documents are complementary. Incident reporting and post-mortem procedures described in the SLA Exhibit shall be coordinated with the incident response procedures described in this Security Exhibit.

ANNEX A TO THE SECURITY AND COMPLIANCE EXHIBIT

SUMMARY OF SECURITY CONTROLS

The following table provides a consolidated reference of the principal security controls and commitments described in this Security Exhibit. In the event of any discrepancy between this Annex and the body of the Security Exhibit, the body shall control.