Document information and change log

Document Information

Change log

Gender And Entity Neutrality

The masculine form is used solely for the sake of better readability. It always refers to persons of any gender identity (m/f/diverse). This document uses the abbreviation “Give” for all legal entities and subsidiaries.

Table of Contents

Introduction        4

Purpose        4

Scope        4

Key Systems and Disaster Recovery        4

Production and CHD (Cardholder Data) Network        4

Infrastructure        4

Cardholder Data Handling        4

Backup and Recovery        5

Integration APIs and SDKs        5

Communication        5

Onboarding and Payment Processing Platform        5

Onboarding Portals        5

KYC and AML Checks        5

Payment Processing        5

Payment Gateways Integration        5

Settlement and Payout Engines        5

Risk Management and Fraud Detection        6

Transaction Screening        6

Chargeback Management        6

Analytics Platforms        6

Databases        6

Payment Data Storage        6

Merchant & Transaction Info        6

Compliance Documentation        6

Key Personnel        6

Role Identification        6

Operational Knowledge        7

Decision Making        7

Communication        7

Access Control        7

Security Incident Detection and Reporting        7

Incident Response Team (IRT)        7

Incident Response Coordinator (IRC)        7

Network Team        8

Web Application Security Team        8

Compliance Lead        8

Operations Lead        8

Alerts        9

Triage        9

Investigation        9

Containment and Eradication        9

Recovery        10

Reporting        10

Communication        10

Plan Review and Maintenance        10

Inappropriate Stored Cardholder Data        10

Investigation        10

Containment and Eradication        10

Recovery        11

Reporting        11

Communication        11

Plan Review and Maintenance        11

Physical locations and testing        11

Alternative Physical Location of Employees        11

Evacuation Plan        12

Annual Failover Testing        12

Business Impact Analysis (BIA)        12

Introduction to BIA        12

Critical Applications and Systems        12

EKS Hosted Web Application (Critical Application)        12

AWS RDS Database (Critical System)        13

AWS Key Management System (KMS) (Critical Component)        13

Critical Assets        13

AWS Network Infrastructure        13

EKS Cluster Configuration        13

Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs)        13

AWS Service Specific RTOs/RPOs        13

Staffing Considerations for BC/DR        14

Cloud Infrastructure Team        14

Disaster Recovery Responsibilities        14

Bankruptcy Management        15

Overview        15

Definition of Bankruptcy Proceedings        15

Give’s Financial Distress or Bankruptcy        15

Sub-Merchant Bankruptcy        16

Legal and Compliance        16

Bank Failure        16

Conclusion        16

Appendix A: Contact List for Disaster Recovery Team        17

Appendix B: Evacuation Map and Routes        18

Introduction

The ability of GiveCorporation (“Give”) to effectively manage and respond to unforeseen disruptions and disasters is paramount. This Business Continuity and Disaster Recovery (BCDR) Procedure outlines our commitment to ensuring the continued delivery of critical services, safeguarding customer trust, and minimizing the impact of any potential disruptions on our operations.

Purpose

The purpose of this document is to establish a business continuity plan and process to detect, analyze, contain and recover from disasters and security incidents that may impact the confidentiality, integrity, and availability of Give’s networks and data.

Scope

This procedure applies to all employees, contractors, vendors, and other parties who use Give’s network and data resources. There will be resources available 24/7 to respond to disaster and security incidents where they may be reached by electronic communication or telephone. Incident response plan shall be tested at least annually by appropriate (“Incident Response Procedure”) IRP team members. This policy covers a wide range of scenarios, including natural disasters such as snowstorms, pandemics, power outages as well as cyberattacks, employee safety incidents and other unforeseen events, and financial distress situations including bankruptcy. This plan is designed to minimize financial loss to the institution, continue to serve customers and financial market participants, and mitigate the negative effects disruptions can have on our strategic plans, reputation, operations, liquidity, credit quality, market position, and ability to remain in compliance with applicable laws and regulations.

Key Systems and Disaster Recovery

Production and CHD (Cardholder Data) Network

Infrastructure

• Secure and continuous operation of core payment systems.

• DR: Redundant hardware in geographically separate locations to ensure uptime.

Cardholder Data Handling

• Secure storage and transmission mechanisms compliant with PCI DSS.

• DR: Regularly tested encryption protocols and immediate fallback to backup transmission routes.

Backup and Recovery

• Data redundancy and swift recovery systems.

• DR: Periodic backup tests and off-site storage for critical data.

Integration APIs and SDKs

• Tools for third-party access and usage.

• DR: Version control and rollback capabilities.

Communication

• Infrastructure for confirmations and payment alerts.

• DR: Secondary communication channels and backup notification systems.

Onboarding and Payment Processing Platform

Onboarding Portals

• Platforms for seamless sub-merchant integration.

• DR: Cloud-based backup portals to ensure continuous onboarding.

KYC and AML Checks

• Automated validation during onboarding.

• DR: Manual verification processes as a backup.

Payment Processing

• Software for transaction management.

• DR: Secondary processing systems or partnerships with backup processors.

Payment Gateways Integration

• For payment detail transmissions.

• DR: Pre-established agreements with alternative gateways.

Settlement and Payout Engines

• Fund distribution systems.

• DR: Manual settlement processes in place as a contingency.

Risk Management and Fraud Detection

Transaction Screening

• Real-time systems for fraud detection.

• DR: Pre-set rules for manual transaction verification during system downtime.

Chargeback Management

• Tools for dispute resolutions.

• DR: Backup databases of dispute histories and manual resolution protocols.

Analytics Platforms

• Insights into transaction patterns.

• DR: Backup reporting tools and off-site data storage for analytics.

Databases

Payment Data Storage

• Databases with encrypted or tokenized sensitive data.

• DR: Regularly backed up databases in secure, off-site locations with rapid restore capability.

Merchant & Transaction Info

• Storage systems for essential operational data.

• DR: Database replication and mirroring for swift recovery.

Compliance Documentation

• Storage for user rights, data handling protocols, etc.

• DR: Digital and physical backups of critical compliance documentation.

Key Personnel

Role Identification

• Clearly defined roles and responsibilities for vital operations.

• DR: Succession plans detailing temporary or permanent replacements for key roles.

Operational Knowledge

• Understanding of critical systems, partnerships, and business nuances.

• DR: Cross-training initiatives to ensure multiple individuals are familiar with critical operations.

Decision Making

• Authority and capability to make significant decisions during crises.

• DR: Pre-established delegation of authority structures to ensure continuous decision-making capabilities.

Communication

• Responsibility to communicate with stakeholders, partners, and employees during disruptions.

• DR: Backup spokespersons and predefined communication templates for various scenarios.

Access Control

• Key personnel having access to critical systems and data.

• DR: Secure backup access methods and multi-factor authentication to prevent unauthorized access.

Security Incident Detection and Reporting

Security incidents may be detected by automated systems, reports from users or customers, or other means. Anyone who suspects a security incident should report it to the (“Incident Response Coordinator”) IRC at aaron@givecorporation.com or the IRT team at irt@givecorporation.com immediately.

Incident Response Team (IRT)

The IRT is responsible for investigating and responding to security incidents.

As soon as an incident is alerted, discovered, suspected; an email should immediately be sent to the IRT team at irt@givecorporation.com.

The IRT is composed of the following individuals or teams:

Incident Response Coordinator (IRC)

aaron@givecorporation.com

• The IRC is responsible for coordinating the response to a security incident,
• The IRC will be the primary contact for all incident related communication.

Network Team

marian@givecorporation.com

youcef@givecorporation.com

hosni@givecorporation.com^[a]

• The Network Team is responsible for overseeing all network-related aspects of the incident response process.
• The Network Team will ensure that network devices are properly configured and that all network traffic is monitored and analyzed for potential security incidents.
• The Network Team will provide recommendations for containment, eradication, and recovery effort in regards to the network, security, backups, AWS resources, database.

Web Application Security Team

marian@givecorporation.com

youcef@givecorporation.com

abdoo@givecorporation.com^[b][c][d]

• The Web Application Security Team is responsible for conducting technical analysis of security incidents having to do with the Web Application.
• The Web Application Security Team will provide recommendations for containment, eradication, and recovery effort in regards to the web application and database.

Compliance Lead

loraine@givecorporation.com

• The Compliance Lead will provide guidance on compliance-related matters throughout the incident response process.
• The Compliance Lead will provide status updates to key stakeholders and communicate important information throughout the incident response process.

Operations Lead

joshua@givecorporation.com

• The Operations Lead is responsible for coordinating operational activities during a security incident.
• The Operations Lead will ensure that all necessary resources are available to support the incident response process and as necessary implement system wide security measures such as User password changes and 2FA re-authentications.

Alerts

Any security event that triggers an alert having to do with the network or AWS resources should be sent to the IRT and logged in CloudWatch and/or CloudTrail.

Alerts may include but not limited to the following:

• Changes to operating system time configuration, files and NTP
• Change detection to critical files
• AWS GuardDuty High Severity Findings
• AWS VPC Flow Logs detecting DDoS, IP Spoofing, frequent failed attempts to access resources
• Amazon Inspector Critical and High Vulnerabilities
• IAM unusual login locations, failed login attempts, privilege escalation, creation of new IAM users, disabling of MFA
• WAF Block and Alert Events for DDoS, SQL injection and XSS attempts

Triage

The IRC, Network Team and Web Application Security Team will perform an initial assessment of the reported incident to determine its severity and scope.  This sub-team of the IRC will collectively be called the IAT (Initial Assessment Team).

The IAT will classify incidents based on its impact and level of severity. Depending on the impact and level of severity the IRC will determine if the entire IRT needs to be involved.

Investigation

• The IAT will conduct a detailed analysis of the incident.
• The IAT will gather evidence and perform forensics as necessary.
• The IRC may request additional information and review all evidence gathered.

Containment and Eradication

• The IRT will work to contain the incident and prevent further damage.
• The IAT will recommend actions to eradicate the incident.
• If necessary, the Operations Lead will coordinate all necessary activities outside the engineering team to contain the incident.

Recovery

• The IRT will work to restore systems and data to their pre-incident state.
• The IAT will recommend actions to prevent future incidents.
• If necessary, the Operations Lead will coordinate all necessary activities to support the recovery effort.

Reporting

• The IRT will document the incident and all actions taken to respond to it.
• The Compliance Lead will report the incident to appropriate stakeholders, as necessary.

Communication

• The IRC will determine if an incident needs to be communicated to stakeholders.
• The Compliance Lead will be responsible for all incident-related communications.

Plan Review and Maintenance

• The Incident Response Procedure will be reviewed and updated annually.
• Any changes to the plan will be communicated to all relevant stakeholders.
• Lessons learned will append the incident response plan if necessary to adapt to new industry threats.

Inappropriate Stored Cardholder Data

In the event that cardholder data is found outside of the appropriate provisioned areas, the following process will be performed to eradicate the inappropriately stored data and prevent the issue from occurring again.

Investigation

• The IAT will conduct a detailed analysis of the potential leak of cardholder data.
• The IAT will gather evidence and perform forensics as necessary.
• The IRC may request additional information and review all evidence gathered.

Containment and Eradication

• The IRT will work to contain the incident and prevent further inappropriate storage.
• The IAT will recommend actions to eradicate the incident. This includes a secure delete operation and appropriate safety measures to prevent propagation of cardholder data.
• If necessary, the Operations Lead will coordinate all necessary activities outside the engineering team to contain the incident.

Recovery

• The IRT will work to restore systems and data to appropriate order.
• The IAT will recommend actions to prevent future incidents.
• If necessary, the Operations Lead will coordinate all necessary activities to support the recovery effort.

Reporting

• The IRT will document the incident and all actions taken to respond to it.
• The Compliance Lead will report the incident to appropriate stakeholders, as necessary.

Communication

• The IRC will determine if an incident needs to be communicated to stakeholders.
• The Compliance Lead will be responsible for all incident-related communications.

Plan Review and Maintenance

• The Incident Response Procedure will be reviewed and updated annually.
• Any changes to the plan will be communicated to all relevant stakeholders.
• Lessons learned will append the incident response plan if necessary to adapt to new industry threats.

Physical locations and testing

Alternative Physical Location of Employees

In the event of a significant business disruption impacting Give’s office at 3200 E Camelback Rd., STE 275, Phoenix, AZ 85018, the company will move to a back-up location at 1020 E Missouri Ave, Phoenix, AZ 85014. Alternatively, and preferably, Give may decide for staff to work from a remote location. In this event, Give will maintain a list of employees working locations and contact information.

Evacuation Plan

The detailed evacuation procedures are outlined in Appendix B of this document. This plan includes specific routes and exits to be used in different types of emergencies. The highest manager role on a day of emergency is responsible for leading all employees to the respective exits. In case no manager is present, all employees follow the designated evacuation signs present in the building. It is imperative that all employees familiarize themselves with these procedures and the layout of evacuation routes, which are clearly marked and regularly inspected for accessibility and safety. In addition to the outlined procedures, Give is committed to conducting regular evacuation drills to ensure that all staff members are prepared in the event of an actual emergency. These drills will be held annually and will be mandatory for all employees. The drills will be supervised and evaluated to identify any areas for improvement in the evacuation procedures.

Annual Failover Testing^[e][f][g][h]

Give will conduct an annual failover test of its business continuity and disaster recovery procedures to determine whether any modifications are necessary in light of changes to the company’s operations, structure, business, or location. The test must be designed to ensure that the company can continue to provide critical financial services in the event of an unexpected disruption. During the testing, a comprehensive review of the company’s data backup and recovery procedures, all mission-critical systems, financial and operational assessments, alternate communications between customers and the bank, alternate communications between the bank and its employees, alternate physical location of employees, critical business constituents, bank, and counter-party impact, and regulatory reporting is conducted.

Business Impact Analysis (BIA)

Introduction to BIA

The BIA is integral to Give’s BCDR policy, specifically addressing the resilience of our AWS hosted services. It identifies critical operations, services, and assets to establish RTOs and RPOs, which guide our recovery strategies. This section covers Critical Applications and Systems, critical assets, Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs), and Staffing Considerations for BCDR.

Critical Applications and Systems

EKS Hosted Web Application (Critical Application)

Function: Serves as the primary interface for customer interactions and transactions.

RTO: 2 hours

RPO: 15 minutes

Justification: The application's availability is crucial to maintain uninterrupted customer service and support business operations.

AWS RDS Database (Critical System)

Function: Stores all transactional data for the web application.

RTO: 1 hour

RPO: 5 minutes

Justification: The integrity of transaction data is essential for order processing and reporting.

AWS Key Management System (KMS) (Critical Component)

Function: Manages encryption keys for securing sensitive data.

RTO: 4 hours

RPO: 24 hours

Justification: KMS is critical for security but can tolerate a longer RTO as keys are less likely to require immediate rotation/recovery.

Critical Assets

AWS Network Infrastructure

Components: VPC, Internet Gateways, Route Tables, Network ACLs, Subnets.

Asset Description: Backbone of the cloud environment supporting the EKS cluster and web application.

Ownership: Managed by Give Corporation’s Cloud Operations Team.

EKS Cluster Configuration

Configuration Details: Node types, pod configurations, auto scaling settings.

Storage: EBS volumes for persistent storage across cluster nodes.

Backup: Snapshot and backup configurations managed by AWS Backup services.

Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs)

AWS Service Specific RTOs/RPOs

EKS Web Application: RTO of 2 hours, RPO of 15 minutes.

RDS Database: RTO of 1 hour, RPO of 5 minutes.

AWS KMS: RTO of 4 hours, RPO of 24 hours.

Staffing Considerations for BC/DR

Cloud Infrastructure Team

Roles include DevOps Engineers and Network Administrators.

Responsibilities: Implementing recovery strategies, restoring services, and managing AWS configurations during an incident.

Disaster Recovery Responsibilities

Disaster Recovery Lead: Initiates and oversees the DR process within the AWS environment.

Network Administrators: Ensures the web application’s return to operational status.

DevOps Engineer: Focus on restoring RDS instances and ensuring data integrity.

Bankruptcy Management

Overview

This chapter outlines procedures and policies to be followed in the event of financial distress or bankruptcy of either Give or its sub-merchants. The primary aim is to ensure the safeguarding of funds, the continuity of operations, and the minimization of disruptions to all stakeholders involved.

Definition of Bankruptcy Proceedings

Under this policy, "Bankruptcy Proceeding" encompasses:

• The initiation by or against Give or any of its sub-merchants of any bankruptcy, receivership, insolvency, reorganization, dissolution, liquidation, or any similar legal process.
• The institution of such proceedings against a party that are not dismissed within sixty (60) days.
• Any assignment made for the benefit of creditors, or any offer of settlement, extension, or composition made to creditors generally.
• The appointment of a trustee, conservator, receiver, or similar fiduciary for Give or a significant portion of its assets.

Give’s Financial Distress or Bankruptcy

Safeguarding of Funds: Give will take all necessary steps to ensure that funds processed on behalf of sub-merchants are segregated and protected from creditors in the event of bankruptcy. These funds will be held in trust accounts as per regulatory requirements.

Operational Continuity: Give is committed to maintaining operational capabilities to process payments with minimal disruption. This includes:

• Engaging in interim management solutions.
• Exploring the possibility of business reorganization.
• Notifying all stakeholders, including sub-merchants, of the bankruptcy proceedings and the steps being taken to ensure continuity or orderly wind-down.

Disbursement of Funds: The procedures for distributing funds held on behalf of sub-merchants will adhere to the directives issued by the bankruptcy court. This approach guarantees that all parties receive fair and equitable treatment throughout the process, aligning with the established principles and regulations governing bankruptcy proceedings.

Sub-Merchant Bankruptcy

Handling of Funds: Upon learning of a sub-merchant's bankruptcy, Give will review the status of held funds for that sub-merchant. Actions will comply with bankruptcy laws to either return these funds to the sub-merchant, disburse them to lawful claimants, or hold them as required by the bankruptcy court. This ensures a lawful and orderly process in handling the sub-merchant's funds during bankruptcy proceedings.

Liabilities and Chargebacks: Give will manage outstanding liabilities and chargebacks in accordance with merchant agreements and the directives of the bankruptcy court. This includes setting aside reserves for potential chargebacks and disputes to ensure that all financial obligations are met in a manner that is fair and compliant with legal requirements.

Operational Procedures: Give will implement mechanisms for dealing with the customers of the bankrupt sub-merchant, including notifications and the handling of pending transactions. This may involve coordination with other payment processors or financial institutions to ensure minimal disruption to customer transactions, adhering to a structured approach that respects the legal framework of bankruptcy proceedings.

Legal and Compliance

Give will ensure full compliance with all relevant laws and regulations, including those governing bankruptcy proceedings. This encompasses the filing of necessary notices, claims, and documents with the bankruptcy courts, as well as adherence to any court orders or directives. This commitment to legal and regulatory compliance ensures that Give operates within the framework established for financial distress and bankruptcy situations.

Bank Failure

In the case of a bank failure, Give’s strategy is to utilize a local community bank that accesses the IntraFi network. This provides multi-million dollar FDIC insurance, which exceeds the standard per-merchant account coverage.

Conclusion

This bankruptcy management policy is designed to protect the interests of all parties involved, including Give, its sub-merchants, and their respective customers, in the event of financial distress or bankruptcy. By establishing a clear and actionable framework, it ensures adherence to the principles of American law, fostering an environment of transparency, fairness, and continuity in operations.

Appendix A: Contact List for Disaster Recovery Team

CRTO / Disaster Recovery Lead: Aaron Miller, aaron@givecorporation.com

Lead DevOps Engineer: Marian Kopriva, marian@givecorporation.com 

Senior Network Administrator: Youcef Elmerebi, youcef@givecorporation.com

Appendix B: Evacuation Map and Routes

The information contained herein is intended to provide a general overview of the Company’s policies and procedures relating to compliance with this Policy and does not constitute legal advice or a complete description of the laws and regulations relating to this Policy. The Company has made every effort to ensure the accuracy and completeness of this Policy.  This document is intended to provide guidance to employees of Company on how to comply with applicable laws and regulations related to this Policy. Employees should consult with the Legal or Compliance Department if they have any questions about the Policy or how to comply with it. The Company reserves the right to modify or update this Policy at any time without notice. Employees are responsible for reviewing the Policy on a regular basis to ensure that they are aware of any changes. This Policy applies to all employees of Company, regardless of their position or location unless stated otherwise in the Policy. Employees are responsible for complying with the Policy and for reporting any suspected violations to their respective supervisor, the Legal Department, AMLCO or respective recipient of such violation as outlined in this Policy.