This Security Addendum (this “Security Addendum”) supplements the Platform Agreement between Flux Cap. Corporation, a Delaware corporation (“Provider”), and the customer identified in the applicable Order Form (“Customer”), and describes Provider’s technical, administrative, and organizational security commitments with respect to Customer Data. This Security Addendum is incorporated into and forms part of the Platform Agreement. In the event of any conflict between this Security Addendum and the Platform Agreement with respect to Provider’s security obligations, this Security Addendum controls. The Business Associate Agreement (“BAA”) between Provider and Customer controls over this Security Addendum solely with respect to protected health information (“PHI”) and HIPAA-required safeguards, notices, and procedures. Provider may update this Security Addendum from time to time, provided that if any update materially reduces the security features of the Services taken as a whole during an active Order Form, Customer may terminate the affected Order Form by written notice within five (5) business days after notice of the update. Capitalized terms used but not defined herein have the meanings given to them in the Platform Agreement.
1.DATA HOSTING, RESIDENCY AND SEGREGATION
1.1Hosting. Customer Data will be stored and processed in the geographic region specified in the applicable Order Form or otherwise agreed in writing. Provider will use commercially reasonable efforts to support Customer’s requested region where supported by Provider’s cloud service providers and applicable law.
1.2Subprocessors. Provider maintains a current list of subprocessors used to process Customer Data and shall make such list available to Customer upon reasonable request.
2.THIRD-PARTY CERTIFICATIONS AND TESTING
2.1Third-Party Audit Reports. Provider maintains a SOC 2 Type II report and shall undergo an annual SOC 2 Type II audit conducted by an independent, qualified third-party auditor. Provider maintains certification under the ISO/IEC 27001 Information Security Management System standard.
2.2Penetration Testing. Provider shall have an independent, qualified third party perform annual penetration testing of the Platform and shall remediate material findings in accordance with the remediation timelines set forth in Section 3.5.
3.TECHNICAL CONTROLS
3.1Encryption. Customer Data stored on Provider’s systems shall be encrypted at rest using AES-256 encryption or an equivalent or stronger encryption standard. Customer Data transmitted between Customer (including Authorized Users) and Provider’s systems, and between Provider’s internal systems and services where Customer Data is processed, shall be encrypted in transit using Transport Layer Security version 1.2 or higher (“TLS 1.2+”).
3.2Key Management. Provider stores encryption keys separately from the Customer Data using a dedicated key management service or hardware security module, rotates keys at least annually and securely destroys keys associated with Customer Data following the applicable data deletion and return procedures set forth in the Platform Agreement.
3.3Data Retention and Deletion. Data retention and deletion are governed by the DPA.
3.4Personnel Technical Controls. Provider maintains a least-privilege access control model for all systems and services that store, process, or transmit Customer Data. Provider personnel are authorized to access Customer Data only (a) as necessary to provide the Services or (b) to comply with applicable law. Provider requires multi-factor authentication, endpoint protection (including anti-malware protection), and patch management for all devices used by personnel accessing systems that store, process, or transmit Customer Data.
3.5Network Controls. Provider maintains technical network segmentation controls and regularly reviews its firewall rules and network access policies. Provider conducts regular vulnerability scanning of its production systems and infrastructure, scores vulnerabilities based on the likelihood and potential impact of exploitation using a methodology similar to the Common Vulnerability Scoring System (CVSS), and remediates identified vulnerabilities on timelines commensurate with the associated risk (with “critical” risks addressed within seven (7) days, “high” within thirty (30) days and “medium” within ninety (90) days). Provider shall engage a qualified third party to conduct web-application-level security assessments of the Platform at least annually.
3.6Physical Access Control. Provider uses commercially reasonable diligence to ensure its cloud service providers maintain industry-standard physical data center access controls.
4.ADMINISTRATIVE CONTROLS
4.1Training. Provider requires all personnel with access to Customer Data to complete annual security awareness training covering phishing, data handling, incident reporting, and regulatory requirements. Software developers additionally complete annual secure development training covering OWASP Top Ten risks and applicable coding practices.
4.2Personnel. Provider conducts pre-employment background checks on personnel with access to Customer Data and imposes confidentiality and incident reporting obligations on such personnel. Provider implements separation of duties controls for critical security functions and reviews all accounts with access to Customer Data at least quarterly and promptly revokes access for separated personnel.
4.3Audit Logs. Provider shall create and retain for at least one (1) year audit logs of access to and actions taken with respect to Customer Data sufficient to monitor and investigate unauthorized or inappropriate activity, covering material privileged-environment events and the relevant actor, organization, timestamp, and user agent. Where Customer Data includes PHI under an executed BAA, Provider will maintain audit records reasonably sufficient to support Covered Entity’s accounting, Security Incident, and Breach documentation obligations under the BAA (each such term, as defined in the BAA).
5.INCIDENT DETECTION AND RESPONSE
5.1Security Incident Response Plan. Provider maintains a written Security Incident Response Plan (“SIRP”) governing Provider’s procedures for the detection, investigation, containment, notification, remediation, and post-incident review of Security Incidents.
5.2Notification. Provider shall notify Customer without undue delay and in any event within seventy-two (72) hours after Provider confirms a Security Incident involving (i) unauthorized access to Customer Data, (ii) disclosure of Customer Data, or (iii) disruption or corruption of Customer Data, and shall cooperate with Customer in accordance with the DPA to the extent the Security Incident constitutes a Personal Data Breach.
5.3Remediation. Provider shall take prompt steps to contain, preserve evidence of, and remediate the root cause of a Security Incident. Provider shall conduct a post-incident review to identify root causes, assess Provider’s response capabilities and develop remediation recommendations. Provider shall preserve relevant logs for at least one (1) year.
5.4Business Continuity and Disaster Recovery. Provider maintains business continuity plans that detail how operations will be maintained during an unplanned disruption in service. Plans are approved by senior management and reviewed and tested annually.
6.CUSTOMER AUDIT ACCESS AND RESPONSIBILITIES
6.1Audit Access. Provider will provide Customer access to reasonably requested documentation evidencing its compliance with this Security Addendum in the form of a SOC 2 Type II audit report or equivalent third-party security assessment report covering security controls relevant to the protection of Customer Data.
6.2Customer Responsibilities. Customer is responsible for (a) securing Authorized Users’ credentials; (b) promptly notifying Provider of any suspected unauthorized access or other Security Incident that may affect the security of Customer Data; (c) complying with Provider’s security requirements pursuant to the Platform Agreement or other written communication; (d) ensuring that Authorized Users comply with this Security Addendum; (e) maintaining the security of its own systems and devices; and (f) not disabling, circumventing or interfering with any Platform security feature.
7.DEFINITIONS
As used in this Security Addendum, the following terms have the meanings set forth below:
7.1“Security Incident” means any breach of security leading to the destruction, loss, alteration, unauthorized disclosure of, or access to Customer Data or Content. For the avoidance of doubt, routine, unsuccessful attempts to penetrate Provider's networks or systems (such as port scans, failed login attempts, denial-of-service attacks that do not result in a service disruption, or similar events) do not constitute Security Incidents.