Red Flag Alert Technology Group Data Security Notice

This Security Notice is incorporated into and made a part of any Red Flag Alert’s Information Security Management System and as such an Agreements that RFA may have with its Vendors and Clients RFA. RFA maintains a comprehensive documented security program that is based on industry standard security frameworks including ISO 27001 and ISO 27018 (the “ISMS”). Pursuant to the Security Program, RFA implements and maintains administrative, physical, and technical security measures to protect its Data and internal systems and processes and Support Services and the security and confidentiality of Customer Content (including any Customer Personal Data that may be contained therein) (each as defined in the Agreement) under RFA’ control that is processed by RFA in its provisioning of its Services (the “ISMS”). RFA’ compliance with this Notice shall be deemed to satisfy any more general measures included within any Agreement, including the Specific Terms. In accordance with its Security Program, RFA will, when any Customer Content is under its control: (i) comply with the Security Measures identified below with respect to such Customer Content, and (ii) where relevant, keep documentation of such Security Measures. RFA regularly tests and evaluates its Security Program and may review and update this Security Notice at any time without notice, provided that such updates are equivalent (or enhance) security and do not materially diminish the level of protection afforded to Customer Content by these Security Measures.

1. Deployment Model

1. Shared Responsibility. RFA operates in a shared responsibility model, where both RFA and the Customer maintain security responsibilities. This is covered in more detail in our Documentation.

2. Architecture. RFA is a hybrid platform-as-a-service offering. The components responsible for managing and controlling the Platform Services are referred to as the ‘RFA Control Plane’ and are hosted within a RFA Cloud Service Provider account. The compute resources that perform data processing operations are referred to as the “Data Plane”. For certain Cloud Service Providers, the Data Plane may either be deployed in the Customer’s Cloud Service Provider account (known as the ‘Customer Data Plane’) or, for RFA Serverless Compute, in a RFA-controlled Cloud Service Provider account (known as the ‘RFA Data Plane’).  Data Plane shall refer to both Customer Data Plane and RFA Data Plane unless otherwise specified.

3. Compute Resources. Compute resources are created and coordinated by the RFA Control Plane and deployed into the Data Plane. Compute resources are launched as new virtual machines that leverage the latest base image and RFA source code and do not have data from previous machines. When compute resources terminate, the data on their local hard drives is overwritten by RFA or by the Cloud Service Provider.

4. Data Storage of Customer Content.

Customer Data and Customer Results.

1. 1. 1. 1. Customer Control. Most Customer Data is stored within the Customer’s own Cloud Service Provider account at rest or within other Systems under Customer’s control.  Customer may choose where this Customer Data resides (other than the DBFS root, which is deployed into a storage bucket within the applicable Cloud Service Provider in the region in which the Data Plane is deployed).
         2. RFA Control.  Small amounts of Customer Data may be stored within the RFA Control Plane, including Customer Results and metadata about Customer Data (e.g., contained within the metastore). RFA offers Customers options regarding the storage of certain Customer Content within the Platform Services (e.g., the location of Customer Results created by the use of interactive notebooks).
                                 3.  RFA’ Audits & Certifications. RFA uses independent third-party auditors to assess the RFA Security Program at least annually, as described in the following audits, regulatory standards, and certifications:
   1. ISO 27001
   2. ISO 27018
   3. ISO 9001
   4. Cyber Essentials +
2. Administrative Controls
   1. Governance. RFA’ Chief Compliance Officer in conjunction with the Chief Technical Officer leads the RFA’ Information Security Program and develops, reviews, and approves (together with other stakeholders, such as Legal, Human Resources and Finance as well as IT) RFA’ Security Policies (as defined below).
   2. Change Management. RFA maintains a documented change management policy, reviewed annually, which includes but is not limited to, evaluating changes of or relating to systems authentication.
   3. ISMS; Policies and Procedures. RFA has implemented a formal Information Security Management System (“ISMS”) in order to protect the confidentiality, integrity, authenticity, and availability of RFA' data and information systems, and to ensure the effectiveness of security controls over data and information systems that support operations. The RFA Security Program implemented under the ISMS includes a comprehensive set of privacy and security policies and procedures developed and maintained by the security, legal, privacy, and information security teams (“Security Policies”). The Security Policies are aligned with information security standards (such as ISO 27001 and Cyber Essentials +) and cover topics including but not limited to: security controls when accessing RFA Services and Systems; confidentiality of Customer Content; acceptable use of company technology, systems and data; processes for reporting security incidents; and privacy and security best practices. The Security Policies are reviewed and updated annually.
   4. Employee Training. Employees receive comprehensive training on the Security Policies upon recruitment and refresher trainings are given annually. Employees are required to certify and agree to the Security Policies and Employees who violate the Security Policies are subject to disciplinary action, including warnings, suspension and up to (and including) termination.
   5. Employees Screening and Evaluation. All Employees undergo background checks prior to onboarding (as permitted by local law), which may include, but are not limited to, criminal record checks, employment history verification, education verification, and global sanctions and enforcement checks. Employees are required to sign confidentiality agreements.
   6. Monitoring & Logging. RFA employs monitoring and logging technology to help detect and prevent unauthorised access attempts to its network and equipment.
   7. Access Review. Active users with access to the Systems and Services are reviewed at least quarterly and are promptly removed upon termination of employment. As part of the Employees offboarding process, all accesses are revoked and data assets are securely wiped.
   8. Third Party Risk Management. RFA assesses the security compliance of applicable third parties, including vendors and sub-processors, in order to measure and manage risk. This includes, but is not limited to, conducting a security risk assessment and due diligence prior to engagement and reviewing external audit reports from critical vendors at least annually. In addition, applicable vendors and sub-processors are required to sign a data processing agreement that includes compliance with applicable data protection laws, as well as confidentiality requirements.
3. Physical and Environmental Controls
   1. RFA Offices. RFA has implemented administrative, physical, and technical safeguards for its office. These include, but are not limited to, the below:

Visitors are required to sign in, acknowledge and accept an NDA, and be escorted by RFA Employees while on premises

1. RFA Employees use allocated and recorded key fobs to access the offices
2. Key fobs and security passwords are not shared or loaned to others without authorisation
3. Equipment and other RFA-issued assets are inventoried and tracked
4. Office Wi-Fi networks are protected with encryption, wireless rogue detection, and Network Access Control

Systems & Network Security
5.1 Platform Controls.

5.1.1 Isolation. RFA leverages multiple layers of network security controls, including network-level isolation, for separation between the RFA Control Plane and Customer Data Plane, and between Workspaces within the RFA Data Plane.
 
5.1.2 Firewalls & Security Groups. Firewalls are implemented as network access control lists or security groups within the Cloud Service Provider's account. RFA also configures local firewalls or security groups within the Customer Data Plane.

5.2 Hardening. 

5.2.1 RFA employs industry standards to harden images and operating systems under its control that are deployed within the Platform Services, including deploying baseline images with hardened security configuration such as disabled remote root login, isolation of user code, and images are regularly updated and refreshed.

5.2.2 For Systems under RFA control supporting the production data processing environment, RFA tracks security configurations against industry standard baselines such as CIS and STIG.

 

5.3 Encryption.

5.3 .1    Encryption of data-in-transit. Customer Content is encrypted using cryptographically secure protocols (TLS v.1.2 or higher) in transit between (1) Customer and the RFA Control Plane and (2) the RFA Control Plane and the Data Plane.  Additionally, depending on functionality provided by the Cloud Service Provider, Customers may optionally encrypt communications between clusters within the Data Plane

5.3.1 Review. Cryptographic standards are periodically reviewed and selected technologies and ciphers are updated in accordance with assessed risk and market acceptance of new standards.

 

5.3.2 Customer Options; Responsibilities. Customers may choose to leverage additional encryption options for data in transit within the Customer Data Plane or RFA Data Plane as described in the Documentation. Customer shall, based on the sensitivity of the Customer Content, configure the Platform Services and Customer Systems to encrypt Customer Content where appropriate.

 

5.4 Monitoring & Logging
5.4.1 Intrusion Detection Systems. RFA leverages security capabilities provided natively by Cloud Service Providers for security detection.
5.4.2 Generation. RFA generates audit logs from Customer’s use of the Platform Services. The logs are designed to store information about material events within the Platform Services.
5.4.3 Integrity.  RFA stores audit logs in a manner designed to protect the audit logs from tampering.
5.4.4 Retention. RFA stores audit logs for at least one year.

 

5.5 Penetration Testing. RFA conducts third-party penetration tests at least annually, employs in-house offensive security Employees, and also maintains a public bug bounty program.

 

5.6 Vulnerability Management & Remediation. RFA regularly runs authenticated scans against representative hosts in the SDLC pipeline to identify vulnerabilities and emerging security threats that may impact the Data Plane and RFA Control Plane. RFA will use commercially reasonable efforts to address critical vulnerabilities within 14 days, high severity within 30 days, and medium severity within 60 days measured from, with respect to publicly declared third party vulnerabilities, the date of availability of a compatible, vendor-supplied patch, or for internal vulnerabilities, from the date such vulnerability is confirmed.

 

5.7 Patching.

5.7.1 Control Plane. RFA deploys new code to the RFA Control on an ongoing basis.

5.8 Corporate Controls.
5.8.1 Access Controls
5.8.1.1 Authentication. RFA Employees are authenticated through single sign-on (SSO), 802.1x (or similar) where applicable, and use a unique user ID and password combination and multi-factor authentication. Privileges are consistent with least privilege principles. Security Policies prohibits Employees from sharing or reusing credentials, passwords, IDs, or other authentication information.
5.8.1.2 Role-Based Access Controls (RBACs). Only authorised roles are allowed to access systems processing customer and personal data. RFA enforces RBACs (based on security groups and access control lists) and restricts access to Customer Content based on the principle of 'least privilege' and segregation of responsibilities and duties.

 

5.9 Pseudonymization. Information stored in activity logs and databases are protected where appropriate using a unique randomized user identifier to mitigate risk of re-identification of data subjects.

 5.10 Workstation Controls: RFA enforces certain security controls on its workstations used by Employees, including:

1. 1. Full-disk encryption
   2. Anti-malware software
   3. Automatic screen lock after 15 minutes of inactivity
   4. Secure VPN
      
      

Incident Detection & Response
6.1 Detection & Investigation. RFA’ dedicated Detection engineering team deploys and develops intrusion detection monitoring across its computing resources, with alert notifications sent to the Security Incident Response Team (SIRT) for triage and response. The SIRT employs an incident response framework to manage and minimise the effects of unplanned security events.

6.2 Security Incidents; Security Breaches. “Security Breach” means a breach of security leading to any accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to Customer Data under RFA control. A “Security Incident” is any actual or attempted breach of security that does not rise to the level of a Security Breach. A Security Breach shall not include an unsuccessful attempt or activity that does not compromise the security of Customer Data, including (without limitation) pings and other broadcast attacks of firewalls or edge servers, port scans, unsuccessful log-on attempts, denial of service attacks, packet sniffing (or other unauthorized access to traffic data that does not result in access beyond headers) or similar incidents. RFA maintains a record of known Security Incidents and Security Breaches that includes description, dates and times of relevant activities, and incident disposition. Suspected and confirmed Security Incidents are investigated by security, operations, or support Employees; and appropriate resolution steps are identified and documented. For any confirmed Security Incidents, RFA will take appropriate, reasonable steps to minimise product and Customer damage or unauthorised disclosure. All incidents are logged in an incident tracking system that is subject to auditing on an annual basis.

6.3 Communications & Cooperation. In accordance with applicable data protection laws, RFA will notify Customer of a Security Breach for which that Customer is impacted without undue delay after becoming aware of the Security Breach, and take appropriate measures to address the Security Breach, including measures to mitigate any adverse effects resulting from the Security Breach.

7 Backups, Business Continuity, and Disaster Recovery

7.1 Business Continuity and Disaster Recovery. RFA Business Continuity (BC) and Disaster Recovery (DR) plans are reviewed, and drills are conducted annually.

7.2 Data Resiliency. RFA performs backups for the RFA Control Plane (including any Customer Instructional Input stored therein), generally managed by the Cloud Service Provider capabilities, for data resiliency purposes in the case of a critical systems failure.

7.3 No Data Restoration. Due to the hybrid nature of the RFA Platform, RFA does not provide backup for Customer Content, and RFA is unable to restore an individual Customer’s Instructional Input upon request. To assist Customers in backing up Customer Instructional Input, RFA provides certain features within the Platform Services.

7.4 Customer Managed Backups. Customers retain ownership of their Customer Content and must manage their own backups, including to the extent applicable, enabling backup within the Systems in which the Customer Data is stored

 

8 Data Deletion.
8.1 On termination. On termination of any existing contracts and agreements with RFA requires full deletion of all data provided by RFA to its clients.

 

9 Secure Software Development Lifecycle (“SDLC”)
9.1 Security Design Review. Feature designs are assessed by security Employees for their security impact to the RFA Platform, for example, additions or modifications to access controls, data flows, and logging.
9.2 Security Training. Architects are required to take Secure SDLC training.
9.3 Change Control. RFA’ controls are designed to securely manage assets, configurations, and changes throughout the SDLC.
9.4 Code Scanning. Static and dynamic code scans are regularly run and reviewed.
9.5 Penetration Testing. As part of the Security Design Review process, certain features are identified and subjected to penetration testing prior to release.
9.6 Code Approval. Functional owners are required to approve code in their area of responsibility prior to the code being merged for production.
9.7 Multi-Factor Authentication. Accessing the RFA code repository requires Multi-Factor Authentication.
9.8 Code Deployment. Production code is deployed via automated continuous integration / continuous deployment pipeline processes.  The release management teams are separated from the engineering teams that build the product.
9.9 Production Separation. RFA separates production Platform Services Systems from testing and development Platform Services Systems.

10 Certificates

ISO and all other certificates are provided upon request and as part of any auditing process.