Incident Response and Cybersecurity Breach Policy

Purpose and Scope

This policy establishes a comprehensive framework for responding to cybersecurity incidents and data breaches at Humanics Global Advisors (HGA). Its purpose is to ensure a rapid, organized, and effective response to any digital security incident, minimizing harm to HGA’s digital platform, data, and stakeholders. This policy applies to all internal HGA staff and external consultants who use the Humanics Global Advisors Digital Platform (formerly known as DevTender), and it addresses incidents affecting the confidentiality, integrity, or availability of HGA’s information systems and data. Physical security incidents are outside the scope of this policy unless they directly compromise digital systems or data (e.g. theft of a laptop containing HGA data).

Global Compliance: HGA is committed to complying with applicable cybersecurity and data protection laws and regulations in all jurisdictions where it operates. This policy is designed to align with U.S. and EU standards (including the EU General Data Protection Regulation and U.S. state laws such as California’s CCPA) and to adopt international best practices even where local laws may not explicitly define requirements[1]. In particular, HGA handles personal data in line with GDPR and CCPA principles, and both HGA and its consultants agree to promptly notify each other of any breach or security incident involving personal data[2]. By following this policy, HGA staff and consultants will fulfill their contractual confidentiality and data protection obligations and maintain compliance with global standards.

Definitions

For the purposes of this policy, the following definitions apply:

Cybersecurity Incident: Any attempted or actual event that compromises the confidentiality, integrity, or availability of HGA’s digital information or systems. Examples include unauthorized access or use of systems, data breaches (theft or exposure of sensitive data), malware infections, denial-of-service attacks, insider threats, or any suspicious digital activity that could harm HGA’s systems or data.
Data Breach: A type of cybersecurity incident that results in unauthorized access, disclosure, or theft of sensitive information. Under GDPR, a “personal data breach” is a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. For example, unauthorized acquisition of personal information (such as client or consultant data) is considered a data breach[3]. Data breaches may require special notification procedures as outlined in Section 5.
HGA Digital Platform (the Platform): The secure online system (previously called DevTender) used by HGA staff and external consultants for managing profiles, projects, and related data. The Platform includes robust security measures such as encryption of data in transit (SSL/TLS) and at rest (AES), multi-factor authentication, and role-based access controls[4][5] to protect user data and transactions.
Incident Response Team (IRT): A designated group of individuals (internal staff and advisors) responsible for managing the response to an incident. The IRT is led by an Incident Response Coordinator (or Security Officer) and includes members with defined roles as detailed in Section 3. The IRT may coordinate with external experts or service providers (e.g. cloud security support or forensic consultants) as needed.
Incident Severity Classification: A rating of an incident’s impact level used to determine the urgency and scale of response. HGA classifies incidents (after initial assessment) typically as:
Low: Minor security events that do not appear to compromise data or services (e.g. a single failed login attempt, spam email).
Medium: Incidents with localized or limited impact that can be contained quickly (e.g. malware detected and removed on one device with no evidence of data loss).
High: Serious incidents affecting critical systems or sensitive data, or causing significant downtime (e.g. a server compromise, database breach, widespread malware outbreak).
Critical: Severe incidents causing major disruption or data compromise (e.g. large-scale data breach of personal data, ongoing cyberattack across the network). Critical incidents trigger full IRT mobilization and likely require regulatory or client notification.
Containment, Eradication, Recovery: Key phases of incident response. Containment refers to actions taken to limit an incident’s spread and impact (e.g. isolating affected systems). Eradication means removing the threat (e.g. eliminating malware, closing vulnerabilities). Recovery involves restoring systems and data to normal operation and verifying security (e.g. restoring from backups, rebuilding systems, and verifying that systems are clean).

Chain of Custody: A formal process for preserving and documenting evidence handling. Maintaining chain of custody means tracking how digital evidence (log files, disk images, etc.) is collected, transferred, stored, and analyzed, to ensure it remains authentic and admissible. Each piece of evidence must be protected from alteration, clearly labeled, and its handling recorded to prove it has not been tampered with[6].

Incident Response Team Roles and Responsibilities

HGA maintains an Incident Response Team (IRT) to handle cybersecurity incidents. The team structure and roles are defined below. Each member may fulfill multiple roles if our organization size requires it, but all responsibilities must be covered:

Incident Response Coordinator (Team Lead): Coordinates all incident response activities and decision-making. This is typically HGA’s IT Security Manager or designated Security Officer. Responsibilities include assembling the team during an incident, leading the investigation, ensuring procedures are followed, and communicating status to senior management. The Coordinator also serves as the primary point of contact with external parties (e.g. law enforcement, regulators) and has authority to make urgent decisions (such as system shutdowns or public disclosures) in consultation with HGA’s executive management.
Technical Lead / Security Engineer: This role (often part of HGA’s IT or DevOps staff) is responsible for the technical investigation and containment of the incident. The Technical Lead analyzes logs and alerts to determine the nature and scope of the incident, preserves forensic evidence, identifies affected systems or accounts, and implements technical containment measures (such as disconnecting servers, revoking credentials, or applying patches). They coordinate any additional IT personnel needed to remediate issues (systems administrators, developers, etc.) and document all technical actions taken.
Systems/Platform Administrator: The platform’s System Manager or admin, who has deep knowledge of the HGA Digital Platform infrastructure, assists in containment and recovery specific to the platform. They manage user accounts and access controls (RBAC)[5], enforce encryption and backup restoration procedures, and help implement security configuration changes (e.g. disabling a vulnerable API endpoint or adjusting firewall rules). They also monitor system logs for unusual activities[7] and support analysis of any platform-specific security events.
Legal & Compliance Officer: A representative from HGA’s legal counsel or compliance team ensures that all regulatory and contractual obligations are met during and after an incident. This role advises on breach notification requirements (GDPR, CCPA, etc.), liaises with data protection authorities or other regulators as needed, and ensures evidence collection and documentation meet legal standards. The Legal Officer will confirm whether an incident triggers obligations under laws or the HGA Consultant Agreement (for example, the duty to notify consultants or clients of a breach of their data[8]). They also guide the communication content to ensure accuracy and legal compliance.
Communications Lead: A staff member (e.g. from communications or a senior manager) designated to manage incident communications. They prepare internal notifications to employees and external communications to consultants, clients, or the public as appropriate. This role works closely with Legal to craft breach notification messages that satisfy legal requirements (such as including the nature of the breach, what data was involved, and mitigation steps) and with the Coordinator for timing of communications. The Communications Lead is responsible for handling any media inquiries and ensuring that only authorized, accurate information is released, preserving HGA’s reputation and transparency commitments.
Privacy Officer / Data Protection Officer (if appointed): If HGA has a designated DPO or Privacy Officer, that person will oversee personal data breach handling. They ensure that privacy laws (GDPR, etc.) are adhered to, help assess risk to individuals from any personal data breach, and coordinate notifications to data subjects (affected individuals) when required. This role overlaps with Legal/Compliance but is focused on protecting individuals’ data rights and documenting the incident’s impact on personal data.
Human Resources (HR) Representative: For incidents involving an internal employee or consultant misconduct (e.g. an insider threat or violation of security policy), HR may be involved to manage any disciplinary process and to ensure fair handling of personnel issues. HR also ensures that staff privacy is respected during investigations and can coordinate any necessary support or training for employees after an incident.
External Consultants/Forensic Specialists: In some cases, HGA may engage external cybersecurity consultants or digital forensics experts to assist the IRT. These specialists operate under the direction of the Incident Response Coordinator and provide expertise in investigating complex attacks or conducting deep forensic analysis. If engaged, they must follow HGA’s evidence handling procedures and maintain confidentiality. Any external consultant must also sign confidentiality agreements consistent with HGA’s standards if not already bound (per the Consultant Agreement, all HGA consultants and subcontractors are required to adhere to HGA’s confidentiality and compliance obligations[9]).

Responsibilities of All Staff and Consultants: All HGA employees and consultants have a duty to report suspected security incidents immediately (see Section 4.1) and to assist the IRT as needed. They must refrain from disclosing incident details to unauthorized parties and must preserve any evidence in their possession. Consultants are specifically reminded that under the HGA Consultant Agreement, they are obligated to maintain confidentiality of HGA data and to notify HGA promptly if they discover any breach or security incident involving HGA’s or a client’s data[2]. Non-compliance with this policy or failure to report incidents may result in disciplinary action or contract termination, in line with HGA’s agreements and HR policies.

Incident Response Team Roles and Responsibilities

Incident Response Coordinator (Team Lead): Coordinates all incident response activities and decision-making. This is typically HGA’s IT Security Manager or designated Security Officer. Responsibilities include assembling the team during an incident, leading the investigation, ensuring procedures are followed, and communicating status to senior management. The Coordinator also serves as the primary point of contact with external parties (e.g. law enforcement, regulators) and has authority to make urgent decisions (such as system shutdowns or public disclosures) in consultation with HGA’s executive management.
Technical Lead / Security Engineer: This role (often part of HGA’s IT or DevOps staff) is responsible for the technical investigation and containment of the incident. The Technical Lead analyzes logs and alerts to determine the nature and scope of the incident, preserves forensic evidence, identifies affected systems or accounts, and implements technical containment measures (such as disconnecting servers, revoking credentials, or applying patches). They coordinate any additional IT personnel needed to remediate issues (systems administrators, developers, etc.) and document all technical actions taken.
Systems/Platform Administrator: The platform’s System Manager or admin, who has deep knowledge of the HGA Digital Platform infrastructure, assists in containment and recovery specific to the platform. They manage user accounts and access controls (RBAC)[5], enforce encryption and backup restoration procedures, and help implement security configuration changes (e.g. disabling a vulnerable API endpoint or adjusting firewall rules). They also monitor system logs for unusual activities[7] and support analysis of any platform-specific security events.
Legal & Compliance Officer: A representative from HGA’s legal counsel or compliance team ensures that all regulatory and contractual obligations are met during and after an incident. This role advises on breach notification requirements (GDPR, CCPA, etc.), liaises with data protection authorities or other regulators as needed, and ensures evidence collection and documentation meet legal standards. The Legal Officer will confirm whether an incident triggers obligations under laws or the HGA Consultant Agreement (for example, the duty to notify consultants or clients of a breach of their data[8]). They also guide the communication content to ensure accuracy and legal compliance.
Communications Lead: A staff member (e.g. from communications or a senior manager) designated to manage incident communications. They prepare internal notifications to employees and external communications to consultants, clients, or the public as appropriate. This role works closely with Legal to craft breach notification messages that satisfy legal requirements (such as including the nature of the breach, what data was involved, and mitigation steps) and with the Coordinator for timing of communications. The Communications Lead is responsible for handling any media inquiries and ensuring that only authorized, accurate information is released, preserving HGA’s reputation and transparency commitments.
Privacy Officer / Data Protection Officer (if appointed): If HGA has a designated DPO or Privacy Officer, that person will oversee personal data breach handling. They ensure that privacy laws (GDPR, etc.) are adhered to, help assess risk to individuals from any personal data breach, and coordinate notifications to data subjects (affected individuals) when required. This role overlaps with Legal/Compliance but is focused on protecting individuals’ data rights and documenting the incident’s impact on personal data.
Human Resources (HR) Representative: For incidents involving an internal employee or consultant misconduct (e.g. an insider threat or violation of security policy), HR may be involved to manage any disciplinary process and to ensure fair handling of personnel issues. HR also ensures that staff privacy is respected during investigations and can coordinate any necessary support or training for employees after an incident.
External Consultants/Forensic Specialists: In some cases, HGA may engage external cybersecurity consultants or digital forensics experts to assist the IRT. These specialists operate under the direction of the Incident Response Coordinator and provide expertise in investigating complex attacks or conducting deep forensic analysis. If engaged, they must follow HGA’s evidence handling procedures and maintain confidentiality. Any external consultant must also sign confidentiality agreements consistent with HGA’s standards if not already bound (per the Consultant Agreement, all HGA consultants and subcontractors are required to adhere to HGA’s confidentiality and compliance obligations[9]).

Breach Notification and Regulatory Compliance

In the event of a data breach (particularly involving personal data or other sensitive information), HGA will fulfill all legal and contractual breach notification obligations. This section outlines the requirements under major regulations and the standards HGA follows for notifying authorities, individuals, and other parties.

General Principle: HGA will notify the appropriate parties without undue delay once a data breach is confirmed and sufficient information is available to provide a meaningful notice. Notifications will include all required information about the breach, and will be handled in coordination with Legal/Compliance and Communications teams to ensure accuracy and compliance.

1. Notification to Regulatory Authorities (EU GDPR)

If the security incident qualifies as a personal data breach under the EU General Data Protection Regulation (GDPR) – meaning personal data we control has been accidentally or unlawfully destroyed, lost, altered, unauthorizedly disclosed, or accessed – HGA (as a data controller) will notify the relevant Data Protection Authority (DPA) within 72 hours of becoming aware of the breach. The 72-hour clock starts when HGA has a reasonable degree of certainty that a breach compromising personal data has occurred (awareness). If notification cannot be made within 72 hours, the notification will include reasons for the delay as required.

The notification to the supervisory authority will contain the information mandated by GDPR Article 33: – A description of the nature of the personal data breach including, if known, the categories and approximate number of affected data subjects and data records. – The name and contact details of HGA’s Data Protection Officer (or other relevant contact point) for further information. – A description of the likely consequences of the breach (e.g. risk of identity theft, fraud, privacy risks to individuals). – A description of the measures taken or proposed by HGA to address the breach and mitigate its effects (such as containment measures, data recovery, and steps to prevent recurrence).

HGA will document all personal data breaches, regardless of whether notification was required, to comply with GDPR’s record-keeping requirement. These records (part of the incident report) may be requested by authorities to verify compliance.

If HGA acts as a data processor for certain data (processing on behalf of a client who is the controller), then HGA will notify that client/controller without undue delay after becoming aware of a personal data breach, as per GDPR Article 33(2). It will then be the controller’s responsibility to notify authorities, but HGA will assist as needed to provide information.

2. Notification to Individuals (Data Subjects)

Under GDPR and analogous regulations, if a personal data breach is likely to result in a high risk to the rights and freedoms of individuals, HGA will also communicate the breach to the affected individuals without undue delay. In practice, “without undue delay” means as soon as possible, after understanding the breach sufficiently to provide useful information to the individuals and after taking initial containment measures.

Criteria for notifying individuals include the severity and sensitivity of the data impacted and potential harm (e.g., breaches involving financial information, login credentials, or government ID numbers pose high risk and typically warrant individual notice). The Legal/Privacy Officer will assess risk factors such as whether data was encrypted (if data was properly encrypted, risk is lower and notification to individuals might not be required under GDPR), and whether misuse of the data is likely.

If individual notice is required, the communication will be made in clear, plain language and will include: – The nature of the breach (what happened and what data is involved, in general terms). – HGA contact information (point of contact for inquiries, such as the DPO or a support line). – The likely consequences of the breach for the individual (e.g. risk of identity theft, need to monitor accounts). – Actions HGA has taken or is taking to mitigate the breach and prevent further harm (e.g., forced password resets, offering credit monitoring if financial data was exposed, etc.). – Steps or recommendations for the individual to protect themselves, if applicable (for example, “We recommend you change your passwords and enable 2FA on your accounts,” or “Be vigilant for phishing attempts.”).

The method of communication will be appropriate to reach the individuals directly – typically email or letter. In urgent cases where immediate action by individuals is needed (e.g., to change a password), we may use multiple methods (email and an in-app notification or SMS if available). The content and format will follow best practices and any legal requirements (for instance, California law specifies the notice title “Notice of Data Breach” and specific content headings for notices to residents).

If contacting individuals directly would involve disproportionate effort (for example, if we do not have current contact info for all affected persons), GDPR allows alternative measures such as public communication. However, HGA will strive to directly notify whenever possible, as it maintains trust.

It’s important to note that notification to individuals might be delayed if a law enforcement authority requests a delay (e.g., if notification would impede a criminal investigation). In such cases, we document the request and defer communication until cleared to proceed.

3. United States (CCPA and State Data Breach Laws)

In the United States, data breach notification is governed primarily by state laws. California’s CCPA/CPRA and existing California data breach statutes set the tone for high standards of consumer protection. HGA will comply with all relevant state laws for any incident involving personal information of U.S. residents: – Timing: Most state laws (including California’s Civil Code §1798.82) require notification to affected individuals “in the most expedient time possible and without unreasonable delay” after discovery of a breach, consistent with the needs of law enforcement and measures to determine the scope of the breach and restore system integrity. HGA will not unnecessarily delay notifications; once we have reasonably confirmed a breach and prepared the notice with required details, we will send it out. As a best practice, HGA aims to notify affected U.S. individuals within 30 days of discovery of a breach, or sooner if feasible, even if the law in some jurisdictions allows a longer period (some states specify outer limits like 45 days). – Content: State laws specify content for breach notices. HGA’s notices to U.S. individuals will include at minimum: – A general description of the incident (date or date range of breach, and nature of incident in broad terms). – The types of personal information involved (e.g., name and social security number, financial account info, driver’s license number, medical information, etc., as defined by the particular state law). – What HGA is doing to remediate the situation (containment and recovery measures, and what we are doing to protect individuals, such as offering identity theft protection services if required; note some states like California require offering at least 12 months of credit monitoring if certain data like SSN was breached). – What actions individuals can take to protect themselves (like placing fraud alerts, contacting credit bureaus – California mandates including contact info for credit reporting agencies if SSN or ID numbers were leaked). – Contact information where individuals can get more info (toll-free number or website). – Possibly a reference to where they can find more information (some notices include a reference to state resources or the company’s FAQ page on the incident). – The notice will be titled “Notice of Data Breach” and use clear headings as required by California law.

Method: Notices to U.S. individuals will typically be sent in writing to the last known postal mailing address or electronically if the individual has consented to electronic notice (and the notice complies with E-SIGN). If a subset of data like online account credentials were breached, special notification methods might apply (for example, instructing the user to change their password online, per CA law). If a law permits substitute notice due to large numbers or outdated contact info (e.g., an email notice plus conspicuous posting on our website for 30 days), HGA will follow those provisions only as a last resort when direct notice is impractical.
Regulator Notice: Certain U.S. laws require notifying government agencies. For instance, if a breach affects more than 500 California residents, HGA will submit a sample copy of the notice to the California Attorney General’s office. Other states have similar thresholds or require notifying state Attorneys General or consumer protection offices. We will coordinate such notifications through our Legal Officer, ensuring they occur in the required timeframes (often concurrent with or before individual notice).
Third-Party Notice: If HGA maintains data on behalf of another entity (i.e., we are a service provider for client data), and that data is breached, we will notify the client (the data owner) immediately, so that they can fulfill their notification obligations. This aligns with both legal requirements and contractual expectations.
CCPA Specifics: The California Consumer Privacy Act (as amended by CPRA) gives consumers the right to sue for certain data breaches if they resulted from failure to implement reasonable security. While CCPA doesn’t set a specific notification timeframe, compliance with the general breach law as above is expected. Additionally, under CCPA, if HGA issues a consumer breach notice, we will include an offer of identity theft protection if required and ensure our response is part of maintaining “reasonable security procedures.” CCPA also requires that if we offer any compensation or services to affected individuals, we do so uniformly and without unjustified conditions.

HGA’s breach notification process will also take into account other jurisdictions as needed (for example, if data of individuals in Canada, Asia, or Africa is involved, we will refer to relevant laws like Canada’s PIPEDA which has its own breach notification rules, or otherwise follow the closest equivalent standard).

4. International Best Practices and Other Jurisdictions

In jurisdictions without specific breach notification laws, HGA will adhere to international best practices: – We will still notify affected individuals and business partners transparently and promptly, as doing so is crucial for maintaining trust and is ethically responsible. – We will follow timelines similar to GDPR’s 72-hour rule for authorities and general prompt notification for individuals. For example, if an incident involves a country with no explicit law, we may still notify a relevant industry regulator or simply default to informing individuals within 72 hours to one week, depending on severity. – We align with standards such as ISO/IEC 27002 and 29100 guidance on breach handling, ensuring our process is globally sound. If any industry-specific standards apply (for example, if handling credit card data, PCI-DSS requirements for breach response, or if working on projects under particular donor regulations), those will be incorporated.

We also consider contract requirements: many client contracts or our own Consultant Agreement might require notifying the client or other stakeholders in certain ways. For instance, if a client’s data is involved, we will notify that client according to contract terms (often immediately or within 24 hours of discovery).

Documentation of Notifications: For every incident that triggers notifications, HGA will document: – When and how authorities were notified (with copies of the report if applicable). – When and how individuals were notified (with a copy of the notice content). – Any responses or follow-up from authorities (like if a DPA provides guidance or follow-up questions). – This documentation is important to demonstrate compliance and will be saved with the incident records.

Finally, it’s worth emphasizing that speed is important, but accuracy is also crucial in breach notification. HGA will strive to gather enough facts to provide accurate notices. If some information is not yet available within the notification timeframe, we will send an initial notification with what we know and state that further information will follow (as GDPR permits phased notification). We prefer not to speculate or provide incorrect numbers that later need correction. Follow-up updates will be provided to authorities or individuals as more details emerge.

Communication Protocols

Effective communication during a cybersecurity incident is critical to ensure the right information reaches the right people at the right time, and to maintain confidence among stakeholders. This section covers internal and external communication protocols, including how incidents are reported (some of which was touched on in Section 4.1) and how information is disseminated throughout the incident lifecycle.

1. Internal Communication and Escalation:

Confidentiality: All incident communications are to be treated as confidential. Only involve personnel who are part of the response or need-to-know (such as management or specific technical staff). We use clear headers like “CONFIDENTIAL – INCIDENT RESPONSE” in emails or messages to denote sensitivity. Team members should avoid using public or insecure channels to discuss incident details. Prefer approved communication tools (company email, secure messaging, or dedicated incident response chat channels if available) that are not compromised. If the corporate email system is suspected to be part of the incident (e.g., email server compromise), the Coordinator will direct the team to use an out-of-band communication method (such as phone calls or personal emails, or a cloud-based chat not tied to corporate single sign-on) until it’s safe.
Escalation Path: The Incident Response Coordinator will keep HGA’s senior leadership informed at appropriate intervals. For major incidents, the CEO or relevant executives should be briefed at least once initially (when the incident is confirmed and major actions are planned) and subsequently as milestones are reached (containment, etc.). For less severe incidents that are contained quickly, a summary after resolution may suffice. The Coordinator also decides if/when to involve the Board or external advisors in communications, depending on the severity.
Team Coordination: The IRT will have regular update meetings or calls during an active incident (e.g., a daily stand-up or more frequently if needed). In these internal meetings, each role updates status: what has been done, what is in progress, blockers, and next steps. The Communications Lead or Coordinator will also ensure that any wider internal notifications (for example, telling the general staff not directly involved that “we are experiencing technical difficulties” if needed) are issued.
Record Keeping: All decisions and communications should be logged. If verbal decisions are made in calls, they should be documented afterwards in the incident log or minutes. This ensures clarity and accountability.

2. External Communication:

External communication must be carefully managed to fulfill legal obligations and maintain HGA’s reputation, while not disclosing information that could further harm security (like technical details attackers could exploit).

Clients and Partners: If the incident has potential impact on any HGA clients or partner organizations (for example, if a project’s data is involved, or if a client’s system is connected to our platform via API), the IRT will coordinate notifying those parties promptly. The Account Manager or relevant business relationship owner, together with the IRT, will contact the client’s designated contact. The communication should honestly explain what happened and what is being done, without speculation. Emphasize our commitment to resolving the issue and to transparency. These notifications might be required contractually and are separate from individual or regulatory notices.
Consultants and Users: For incidents affecting the external consultants using the platform (e.g., a breach of consultant profile data or a platform outage due to a security event), HGA will communicate with the consulting community. Typically, an email from info@humanicsgroup.org or support@humanicsgroup.org will be sent to affected consultants. Additionally, a notice on the platform (or a banner on the login page) may be used if appropriate (for example, “We are currently investigating a security issue – some features may be temporarily disabled.”). The tone should be professional, reassuring, and instruct users on any actions they need to take (such as resetting passwords, as mentioned). These messages should be reviewed by the Communications Lead and Legal to ensure consistency and compliance.
Public Statements and Media: The Communications Lead will prepare any public statement if needed, such as a press release or a notice on HGA’s website. HGA will generally only go public if the incident is major and likely to become public knowledge (for instance, if a large number of individuals are affected or if required by law). The statement will focus on the facts and the steps taken. It’s important to neither downplay nor exaggerate the incident. Typically, the statement might include: when we discovered the incident, what kind of data was involved (if any), that we engaged our incident response, notified law enforcement or authorities (if applicable), and that we are supporting affected individuals. We will express regret and the steps we are taking to prevent future incidents. No blaming of individuals will be done publicly; the message should convey responsibility and accountability by HGA.
Media and Inquiry Handling: Any inquiries from media, stakeholders, or the public must be directed to the Communications Lead or a specific spokesperson (such as the CEO or a PR representative) as designated. Staff and consultants are instructed not to speak about the incident externally on social media or to any inquirer. A Q&A or “talking points” document may be created by Communications/Legal to guide the spokesperson on likely questions. The goal is one consistent voice.
Law Enforcement: If the incident involves criminal activity (e.g., an external cyberattack, fraud, or any situation we are obligated or choose to report to law enforcement), the Legal Officer or Coordinator will handle outreach. Communication with law enforcement (local police, cybercrime units, the FBI or relevant agency if appropriate) should be done as soon as feasible for serious incidents like deliberate hacking, extortion (ransomware), or theft of sensitive personal information. When law enforcement is involved, we cooperate fully, providing logs and evidence under chain of custody. We also may need to follow their guidance if they ask us to delay certain notifications or actions in order not to impede their investigation (as noted in Section 5).
Contact Channels for Reporting (Reiterating): As given in Section 4.1, external consultants or users who need to report incidents should use info@humanicsgroup.org or the web contact form[11]. Those channels are monitored by HGA’s support/security team. Internally, staff may have a direct number or messaging channel for the IT helpdesk or security team. We ensure these contact points are clearly published internally and on the platform’s user resources (perhaps in a security policy or support page) so that anyone can find how to report a problem at any time.

3. Communication Do’s and Don’ts:

Do communicate promptly, truthfully, and empathetically. Acknowledge what is known and not known. For example, if data is confirmed to be breached, say so; if investigation is ongoing, it’s okay to say “we are still determining the full extent.”
Don’t speculate or provide unconfirmed figures (like “perhaps 1,000 records were taken” unless sure). This can cause confusion if revised later.
Do ensure communications are accessible (e.g., provide translation if a large portion of affected users speak other languages, or ensure alternative formats if needed). HGA is a global entity, so consider multilingual notices if necessary.
Don’t include sensitive technical details in public/individual communications that could aid attackers (for instance, we wouldn’t publish the exact vulnerability used until it’s fully remediated everywhere).
Do keep authorities in the loop. If we notify individuals and media, it’s wise to also notify relevant authorities (even beyond legal minimum) so they are not caught off guard.
Don’t forget to follow-up. A single notice might not be enough; if further details emerge, a second notice or update may be warranted to keep trust (e.g., “Upon further analysis, we discovered additional accounts were affected; here’s what we’re doing for those users…”).

By adhering to these communication protocols, HGA ensures a coordinated approach that supports the incident response goals, keeps stakeholders informed, and meets our legal and ethical obligations.

Logging, Evidence Preservation, and Chain of Custody

Accurate logs and preserved evidence form the backbone of any effective incident investigation and are vital for any potential legal proceedings. HGA has established practices for comprehensive logging, secure evidence preservation, and maintaining chain of custody, as outlined below.

1. System Logging and Monitoring:

HGA’s Digital Platform and IT infrastructure are configured to generate logs for security-relevant events: – User Activity Logs: The platform logs user authentication events (logins, MFA challenges, password changes) with timestamps and source details[39][40]. It also logs critical user actions, such as access to sensitive pages (e.g., financial transaction views by Payables/Receivables Officers are logged with date/time and justification)[41][42], changes to system configurations by admins, creation of new accounts, etc. These audit logs provide a trail of who did what and when on the platform. – Server and Network Logs: Servers maintain logs of system events, errors, and security alerts. Network devices (firewalls, VPN, etc.) log connection attempts, traffic patterns, and blocked activities. Application logs capture errors and unusual behaviors in software. – Security Tools Logs: Any intrusion detection systems (IDS), anti-malware consoles, or cloud security services produce logs and alerts (for example, AWS CloudTrail or Azure logs if our platform is cloud-hosted, and any Web Application Firewall logs for the platform). – Physical Access and Other Logs: While primarily digital focused, if physical access systems (like keycard logs) are relevant (e.g., a server room breach that led to a digital compromise), those logs would be collected as well.

All these logs are time-synchronized (using NTP or similar) to ensure correlation is accurate. Logs are retained for a sufficient period (as per compliance requirements and HGA’s retention policy – typically at least one year or more for security logs) so that historical analysis is possible.

During an incident, the IRT will pull relevant logs to piece together the incident timeline. Logs are protected from tampering: for example, the platform’s audit logs and system logs may be stored in append-only formats or backed up to a secure, access-controlled location so that even an attacker or malicious insider cannot easily erase their tracks. There is also regular log review and automated alerting for certain events, as part of continuous monitoring[43].

2. Evidence Collection and Preservation:

When an incident is identified, preserving evidence is a priority (even as we contain the incident). Key steps: – Imaging Drives/Systems: If a system is compromised, the IRT may create a forensic image of its disk or memory before making changes. This bit-by-bit copy captures the exact state, which can later be analyzed without risking altering original data. For memory (RAM), which is volatile, a dump should be taken if possible prior to powering a system down (especially in cases of complex malware). – Collecting Log Files: All relevant logs (as described above) are aggregated and secured. We might export logs from a server to a separate secure storage. The platform’s database or log tables for user actions might be dumped to a file for analysis. These files are then checksumed (e.g., compute an SHA-256 hash) to ensure integrity going forward. – Capturing Network Traffic: If an incident is ongoing (e.g., data exfiltration), network monitoring tools or packet captures may be initiated to record traffic. These captures can serve as evidence of what data left and where it went. – Gathering Other Digital Evidence: This includes chat records if an insider communicated about the incident, emails (like phishing emails received), or malware files. If phishing was the vector, the email with full headers is preserved. If malware was found, copies of the malicious file are stored in a secure evidence repository for analysis (and possibly later provided to law enforcement or antivirus vendors).

Each piece of evidence is clearly labeled (with date, time, person collecting, and brief description) and stored in a secure location with limited access. For example, forensic images might be kept on encrypted drives in a secure safe or secure cloud storage accessible only to the IRT lead and forensic analyst.

3. Chain of Custody:

Maintaining chain of custody means that from the moment evidence is collected until it is either destroyed or presented in proceedings, we have a documented log of who has handled it and that it was handled securely[6]. Our chain of custody procedures include: – Using a standardized Evidence Log Form for each item. The form (or digital equivalent) records: – Unique evidence ID – Description of item (e.g., “Disk image of Server X’s C: drive”) – Date/time of collection – Collected by (name and signature) – For digital, cryptographic hash (to later verify it’s the same data) – Every transfer or access: date/time, from whom to whom, purpose of transfer, and receiving party signature. – Secure Storage: Evidence is stored in a tamper-evident manner. If physical (like a USB drive with an image), it’s sealed in an envelope with evidence ID, or if digital, it’s in a write-protected repository. Access to evidence is limited to authorized IRT members or investigators. For example, a locked cabinet or safe is used for physical media; for digital repositories, strong access controls and audit logging of access are in place. – If evidence needs to be sent to an external party (like law enforcement or a forensic lab), copies are sent and original remains with us when possible. The transfer is documented with details of the courier or method, and confirmation of receipt by the external party. If law enforcement seizes original hardware, we document serial numbers and get a receipt from them. – We avoid altering evidence: work off copies for analysis. For instance, forensic analysts will mount images as read-only. If we must boot a system up for analysis, we document that and the changes it might incur, but generally, we try to do analysis on copies.

Following these chain of custody protocols ensures that if HGA ever needs to present the evidence (for legal action against an attacker, for insurance claims, or compliance audits), we can demonstrate the evidence’s integrity and handling history. It also prevents internal mishandling – everyone knows they must sign out evidence, which deters any unauthorized tampering.

4. Logging of the Incident Itself:

In addition to technical evidence, the process of handling the incident is documented thoroughly. This includes minutes of IRT meetings, decisions made, actions taken (with timestamps and who executed them), and communications sent. This meta-documentation is also evidence – evidence of our response. We preserve this along with technical evidence as part of the incident record. GDPR actually requires documenting breaches and response for accountability[13], and other standards similarly expect that.

These records may be needed later for post-incident analysis, regulatory inquiries, or if any legal disputes arise (e.g., a client questions whether HGA took appropriate action; our detailed timeline and logs will be our defense to show due diligence).

5. Audit and Review of Logs:

As part of both incident response and general security maintenance, HGA performs regular audit of logs: – The System Security Management Process includes monitoring system logs for unusual activities and reviewing audit logs for critical changes[7][44]. – Periodic audits ensure that logging is functioning correctly (no critical system is “logging blind”). Also, we test that log integrity mechanisms are working (ensuring logs haven’t been tampered). – In the aftermath of an incident, we may institute more aggressive log retention or turn on additional logging if we found gaps (for example, “we didn’t log outbound DNS queries and we needed that to detect something – enable that going forward”).

By rigorously logging and preserving evidence with a clear chain of custody, HGA not only enhances its ability to respond and learn from incidents, but also stands prepared to provide necessary proof to any stakeholders that might require it (be it investigators or clients). This disciplined approach to evidence also reinforces a culture of accountability and professionalism in our incident response process.

Integration with Platform Security Controls and Infrastructure

HGA’s Digital Platform (DevTender) and its overall IT infrastructure incorporate numerous security controls by design. This incident response policy is tightly integrated with those controls – leveraging them to prevent incidents, detect and contain issues faster, and remediate effectively. Below, we highlight how key technical security measures support incident response:

Role-Based Access Control (RBAC): The platform enforces RBAC, meaning users (consultants, organizations, internal roles) only have the permissions necessary for their role[16]. In incident response, this principle of least privilege limits the potential impact of a compromised account (an intruder is less likely to get domain-wide admin rights if they only stole a consultant’s credentials). During containment, RBAC allows the System Admin to quickly modify or revoke access for roles or specific users. For example, if we suspect an internal admin account is abused, we can temporarily reduce that account’s privileges or disable the role until secure again. RBAC logs also help identify if someone accessed areas beyond their normal role, which is a red flag for misuse.
Multi-Factor Authentication (MFA): MFA is implemented for all user logins on the platform[17]. This significantly reduces the risk of credential compromise incidents, as an attacker would need the second factor. If an incident involves unauthorized access, one of the first questions is “How did they get in?” If MFA was somehow bypassed or not used, that’s investigated. During incident response, we might require a reset/re-enrollment of MFA for users (for instance, if a user’s phone with an authenticator app was stolen along with their password). We can also force step-up authentication in real-time if suspicious activity is detected: e.g., challenge the user with MFA again before allowing a sensitive action. The presence of MFA means that if, say, a consultant reports an unusual login alert but they didn’t approve any second-factor, we know to suspect phishing of tokens or a SIM swap – guiding our response.
Data Encryption (In-Transit and At-Rest): All data in transit is protected by SSL/TLS[4], and sensitive data at rest (like personal data, credentials, etc.) is encrypted, e.g., using AES[18]. In an incident where data might be stolen, encryption provides a mitigating factor – if the keys remain secure, the stolen data may be unusable to an attacker. Our incident response will still treat it as a breach, but when communicating to authorities or individuals, we can honestly say “the data was encrypted, which reduces risks.” We also ensure encryption keys are securely managed; if we suspect a key compromise (very rare), that’s an incident in itself and would trigger key rotation. During recovery, we verify that encryption is still functioning properly (no unauthorized changes to crypto settings). Also, if an attacker got database files, the fact that columns like passwords are hashed and data fields encrypted means our forensic analysis might focus on whether they could have gotten keys from the server memory, etc. – we’ll check audit logs of key-access or configuration changes.
Backups and Disaster Recovery: Regular backups are part of our security controls[19], and a Disaster Recovery Plan exists to restore operations in case of major incidents. In incident response, these come into play in recovery: if data is corrupted or wiped, we pull from backups. The policy of storing backups off-site and encrypted means that even if production systems are hit by ransomware, our backups are safe, allowing recovery without paying ransoms. The DR plan is tested periodically[45], and those drills align with incident response drills (Section 10). For example, an incident drill may include practicing a database restore from backup to ensure we know the steps and timing. The integration here is that our IR team coordinates with IT ops to invoke the backup restoration procedures as needed – knowing exactly where backups are, who has access, and how long it takes.
Monitoring and Intrusion Detection: The platform’s design includes continuous monitoring and automated security tooling[46][10]. For instance, if unusual behavior is detected (like multiple failed logins or odd administrator actions), alerts are generated. Our incident response relies on these alerts for early detection. The Security Management module allows System Managers to watch security logs and receive reports[47]. Integration means that the IRT will receive or have access to these alerts. We ensure that alerting mechanisms have an on-call procedure (so if an after-hours alert triggers, someone from the team is paged). Additionally, vulnerability scanning tools might run continuously; if they ever detect a critical flaw, it’s treated proactively like an incident (patch it before exploitation). The ProjectSecurity API services mentioned in technical specs[22] likely provide extra monitoring layers – the IR plan will use data from these services (like if ProjectSecurity flags an IP or account, we incorporate that in our analysis/containment).
API Security Controls: The platform uses APIs (with configurations stored in the system)[23]. We have controls such as API authentication keys, secrets, and endpoints management[48]. These are protected (API secrets not exposed to users). In incident response, if we suspect an API abuse (like an attacker obtained an API token), we can quickly revoke or rotate those keys. Our documentation of API configurations[23] ensures we know where to do that. We also implement rate limiting and monitoring on APIs (to catch abnormal usage spikes). If an incident involves one of our integrated third-party APIs (perhaps an API key leakage for a payment gateway), we coordinate with that provider to revoke keys and monitor transactions. The platform’s internal controls can also allow disabling specific API modules if needed (for example, turning off the part of the system dealing with financial transactions if it’s being exploited). Because these controls exist, we can contain certain incidents by configurational switches rather than hard shutdowns.
Logging and Audit Features: As detailed in Section 7, the platform’s auditing features are crucial. The IR process is integrated such that right at detection, we pull relevant audit trails from the platform’s backend. HGA’s System Manager interface even includes the ability to review security reports and logs[47]; this means in a pinch, an authorized admin can use built-in tools to see recent changes or suspicious events. If an admin suspects misuse, they can use the “View as user” feature safely to understand what a compromised account could see[49], helping scope impact (with caution to not inadvertently change anything).
Access Control and Session Management: The platform likely has session timeout policies and abnormal session detection. For example, if a user’s account is logged in from two countries at the same time, that could trigger an alert. Our IR plan takes advantage of this by immediately terminating sessions of compromised accounts (force logouts) and invalidating tokens or cookies. The system’s design enabling session kill or password reset from the admin side is integrated in containment steps.
Incident Response Plan Drills in Platform: Interestingly, the technical documentation explicitly includes Continuous Monitoring and Incident Response in its security section[50][51], and mentions regular drills and updates to the response plan[51]. This shows that the platform and the development team anticipated incident response as an ongoing practice, meaning our policy aligns with what the system was built for. The integration here is literal: we will use the platform’s capabilities to run simulated incidents (e.g., simulate a consultant account breach and see how quickly monitoring catches it). The outcome of those drills might lead to enabling more features or fine-tuning thresholds in the platform’s security configuration.
Role of Technical Documentation: Our incident responders have access to HGA’s platform technical specifications (the document where these security features are described). In a live incident, this documentation is a resource to understand system behaviors. For example, if we consider shutting down a part of the system, the documentation might outline dependencies so we do so safely. The documentation’s enumeration of tables (like an Audit_Logs table[52] or others) guides where to fetch data during forensics. Thus, keeping technical documentation updated is part of preparedness.

In summary, the Incident Response Team works hand-in-hand with HGA’s security infrastructure. Preventive controls (RBAC, MFA, encryption) reduce incident likelihood and impact, while detective controls (logging, monitoring) enable quick incident identification, and responsive controls (backups, admin capabilities to isolate accounts or systems) facilitate effective containment and recovery. Our policy is designed to make maximum use of these tools rather than work around them.

Moreover, this integration reflects a culture: security is “baked in” to our platform, not bolted on. The Incident Response Policy is thus not an isolated document but part of a larger Information Security Management System (ISMS). We ensure that improvements in one (say, we improve RBAC rules) are reflected in our incident procedures (like adjusting our containment playbook for insider misuse accordingly). Conversely, if an incident reveals a gap (say, logs didn’t capture something), we enhance the infrastructure (enable that logging) going forward.

By aligning policy with technology, HGA can respond to incidents in a swift, consistent, and effective manner, minimizing damage and fulfilling our commitments to data security.

Alignment with Consultant Confidentiality & Data Protection Obligations

Humanics Global Advisors engages many independent consultants via its platform, and these relationships are governed by the HGA Consultant Agreement. This Incident Response Policy is aligned with – and supports – the confidentiality and data protection obligations outlined in those agreements, ensuring a cohesive approach to protecting all parties’ information.

Consultant Agreement Obligations: Under HGA’s standard Consultant Representation & Services Agreement, both HGA and the Consultant commit to strong data protection and confidentiality standards. Key points include: – HGA must handle consultants’ personal data in compliance with GDPR, CCPA, and other applicable laws, adopting global best practices even if not strictly required[1]. – Consultants similarly agree to protect any personal or confidential data they receive from HGA or clients, and to abide by applicable data privacy laws. – Crucially, both parties are required to promptly notify each other if they discover any breach or security incident involving the other party’s data[2]. For example, if a consultant realizes their laptop (containing HGA project files or personal data) was stolen or hacked, they must inform HGA immediately; similarly, if HGA suffers a breach that affects consultant data, HGA must inform the consultant.

This policy operationalizes those obligations as follows:

Incident Reporting by Consultants: Section 4.1 of this policy gives consultants clear instructions on how to report security issues (info@humanicsgroup.org or the web form) and emphasizes immediate reporting. This fulfills the contract clause requiring prompt notification – we provide the channels and encourage use without delay. Consultants are made aware (through training and onboarding) that if they suspect any unauthorized access to HGA’s platform or data, they should not investigate alone but report to HGA’s IRT, in line with this policy and their contract.
Protection of Consultant Data: When an incident involves personal data of consultants (such as their CV, contact info, or work details stored on the platform), HGA’s response will treat that with the same priority as client or employee data. We will notify those consultants per breach notification guidelines (Section 5) – indeed the Consultant Agreement explicitly expects HGA to notify the consultant of any breach of their personal data[53]. Our policy’s notification procedures cover notifying “individuals” which includes consultants; in practice, if consultant personal data is breached, HGA will contact those consultants directly to inform them, as required by contract and law.
Confidential Project Data: Consultants often access confidential client projects or HGA proprietary information. They are bound to keep it confidential. If an incident involves such data (e.g., a consultant’s deliverable was leaked or a client document in the platform was accessed improperly), this policy ensures we contain it and then coordinate with the consultant and possibly the client. Consultants should recall their obligation not to further disclose information; during incident handling, if we involve a consultant in investigation (for instance, asking how they shared a file), we remind them that the process is confidential and subject to NDA.
Chain of Communication: If an incident is traced to a consultant’s actions (like an infected file they uploaded, or their credentials being weak), our approach is collaborative, not adversarial. The policy instructs focusing on technical facts and containment. Any potential negligence would be handled per contract terms (possibly as a breach of confidentiality or data protection obligations), but the immediate goal is resolving the incident. Afterward, if needed, HGA may require that consultant to undergo additional training or, in extreme cases, take contractual remedies. The Consultant Agreement provides that serious breaches (like misuse of data or repeated security negligence) could be cause for termination – our post-incident review would feed into any such decisions, always aiming for fairness and due process.
Reference to Contract in Notifications: When notifying consultants of a breach, we may reference their rights and obligations under the contract. For example, “As per our agreement and data protection laws, we are informing you of this incident…” and reassure them we are fulfilling our duties. Likewise, if a consultant causes a breach that affects a client, HGA must potentially notify the client and might have to report that the consultant had an incident. We aim to anonymize or handle that professionally to maintain the consultant’s reputation while still being honest (e.g., “a subcontractor’s account was compromised, but we have addressed it”).
Data Processing Consents: Consultants consented to data use in the contract, and part of that clause states their data will be protected and only used legitimately[54]. By following this IR policy, HGA demonstrates it honors that promise – if something goes wrong, we act swiftly to protect consultant data and inform them. This mitigates potential disputes. It’s also noteworthy that the contract highlights adherence to global best practices for privacy even if not legally required[55] – our policy’s alignment with GDPR/CCPA etc. covers this. Even if a consultant is in a country without strict laws, HGA still commits to treating their data per high standards, which we execute through this policy.
Client Data and Flow-Down: Often consultants might handle client confidential information under donor projects. The contract says consultants must also respect client NDAs and that a breach of a client’s NDA is a breach of our contract[56][57]. Our incident response will coordinate if such data is involved – for instance, if a consultant accidentally leaked a client document, we involve legal and possibly notify the client per the client contract. Meanwhile, we expect the consultant to assist fully and maintain confidentiality. The policy covers involvement of HR/management if an insider is involved, which would include a consultant acting under contract.
Continuous Training and Awareness: Section 10 will discuss training; consultants should be included in security awareness efforts. We’ll provide guidance (perhaps in onboarding or periodic newsletters) about phishing, secure use of the platform, etc., to prevent incidents. The Consultant Agreement can require attending such training[58] (it mentions cooperating with compliance-related efforts, which could include training). So, our policy’s requirement for drills and training extends to the consultant community as appropriate (e.g., we might run a phishing simulation that includes consultants who use our corporate email or platform – making sure we have consent to do so as needed).
Liability and Indemnification: While not the focus of this policy, note that contractually, if a consultant’s negligence causes a breach that harms HGA or a client, the consultant may hold some liability (and vice versa, HGA could be liable if its negligence causes harm to the consultant’s data)[59][60]. By aligning with contract obligations in our IR actions, we reduce the likelihood of such blame. Both parties fulfilling their duties (prompt notice, mitigation) can resolve the issue cooperatively without it escalating to legal claims. If it does escalate, our thorough documentation and timely communication will be crucial evidence to show we met our obligations, and likewise, we’d expect the consultant’s cooperation as evidence of their good faith.

In essence, this Incident Response Policy and the Consultant Agreement are complementary: – The Consultant Agreement sets the expectation of confidentiality, compliance, and mutual notification. – The IR Policy provides the practical roadmap to honor those expectations when an incident hits.

All consultants are either provided with or made aware of the Incident Response and Breach Policy relevant portions (perhaps summarized in a consultant handbook or the platform’s terms of service). By following this policy, HGA not only stays in line with its legal agreements but also reinforces trust with its consultants that their data and work are safeguarded and that if an issue arises, HGA has a professional plan to address it.

Continuous Monitoring, Testing, and Training

A robust incident response capability is not static; it requires ongoing efforts to monitor for threats, test plans, and train personnel. HGA is committed to continuously improving our readiness through proactive monitoring, regular testing (including drills), and comprehensive training programs for both staff and consultants.

1. Continuous Security Monitoring:

As discussed earlier, HGA employs continuous monitoring tools and processes to detect incidents early. This includes: – Automated Scans and Alerts: We run regular vulnerability scans on our systems to catch weaknesses before adversaries do. Configuration compliance tools check that systems remain in hardened states (for example, alert if a critical security setting is changed). The output is reviewed by the security team. – Intrusion Detection/Prevention Systems (IDS/IPS): These systems generate real-time alerts on suspicious network or system activities. The security team ensures these alerts are fine-tuned to reduce false positives yet not miss real threats. They also keep the detection rules updated as new threats emerge (e.g., updating signatures for new malware strains or attack patterns). – Security Information and Event Management (SIEM): HGA plans to utilize a SIEM or similar centralized log management solution that aggregates logs from across the enterprise and uses correlation rules to identify potential incidents. The SIEM can highlight, for example, if one user’s account attempts access to several unrelated modules (which might indicate account misuse) or if a normally dormant account suddenly logs in at 3 AM. – Third-Party Monitoring: For externally facing assets (like our website, platform portals, etc.), we use services that monitor for availability and security (including TLS certificate validity, domain integrity, etc.). We also monitor threat intelligence sources for any mention of HGA (like our data appearing on dark web forums or if our email domain is sending spam, indicating compromise). – Continuous Improvement: Continuous monitoring is not only about tools but also process. After each significant incident or drill, we evaluate if our monitoring missed anything and adjust. For instance, if an incident was discovered by a human and not flagged by tooling, ask why and possibly add a new alert rule.

The outcome of monitoring is fed directly into the detection phase of incident response. As noted in the technical specs, there is an emphasis on continuous security scans and monitoring to detect and mitigate potential threats, and applying regular updates and patches to enhance security[61]. Our policy embraces this by considering monitoring as the first line of defense – effectively giving us the ability to react in near real-time. It also ties into compliance: continuous monitoring helps satisfy certain regulatory requirements (like under various frameworks that require ongoing risk management, e.g., ISO 27001 control sets or NIST CSF “Detect” function).

2. Incident Response Testing and Drills:

To ensure the Incident Response Plan remains effective, HGA conducts regular drills and tests: – Tabletop Exercises: At least annually (and more often if resources permit, or if major system changes occur), we conduct a simulated incident in a meeting format. The IRT and relevant managers gather and walk through a hypothetical scenario (e.g., a ransomware attack on the platform or a major data breach). Each person explains what actions they would take, and we discuss the decisions at each juncture. This tests the understanding of roles, the clarity of procedures, and can reveal gaps (for example, maybe we realize we don’t have an updated phone tree for after-hours contact). – Live Simulations: Periodically, we may perform more active simulations. For example, the IT team could simulate a phishing attack against employees to test awareness (and then follow-up with training). Or we might simulate an outage of a server to see how the team handles the technical recovery under pressure. We ensure any such tests are done carefully to not accidentally cause real damage; typically they’re done in controlled environments. Some organizations hire external firms to do “red team” exercises – essentially ethical hacking attempts – to test detection and response. HGA will consider doing this in the future as we mature, to get a realistic appraisal of our incident detection and response timing. – Drill Involvement: Importantly, our drills will involve not just IT, but also Legal/Comms and management, especially for severe scenarios. This ensures that, say, drafting a press release or notifying authorities is practiced, not just the IT containment. A drill might include preparing a mock breach notification letter in 2 hours and seeing if it passes legal muster. The reason is to pressure-test our ability to meet that 72-hour GDPR deadline, for instance. – Testing Backups/DR: At least twice a year, HGA will test its disaster recovery procedure, which is a type of incident response for large scale incidents. We’ll simulate a loss of a server or data and practice restoring from backups, measuring how long it takes and if data is intact. Any issues found (like a backup file was corrupted or documentation was unclear) will be fixed. This directly feeds into our recovery readiness.

Results from drills and tests are documented and action items are tracked. We treat drill outcomes seriously: if a drill finds a weakness, we update the policy or procedure (just like a post-incident review). For example, a tabletop might reveal confusion over who contacts law enforcement – we’d then explicitly add that step to this policy or our internal checklists.

The technical documentation of the platform explicitly calls for regular drills and updates to the response plan to handle evolving security threats[51]. We comply with that by scheduling these exercises and then refining our plan accordingly. If new threats arise (say supply chain attacks or a new kind of social engineering), we consider adding scenarios around those.

3. Training and Awareness:

Human factors are critical in both preventing and responding to incidents. HGA invests in training programs for all user groups: – Staff Training: All HGA employees (especially those with privileged system access) receive cybersecurity awareness training at least annually. This covers topics like phishing awareness, proper use of passwords and MFA, safe data handling, recognizing and reporting incidents, and their responsibilities under this Incident Response Policy. We include real examples or case studies so they understand the impact (e.g., show how a past breach started with one person clicking a bad link). – Consultant Orientation: External consultants who use our platform or work with us on projects are given guidance on cybersecurity best practices. This can be delivered through an online module when they register or via documentation. Key points include: keeping their platform credentials secure (unique strong password, always use MFA), not sharing accounts, how to handle client confidential data (e.g., store it only on secure devices, not on personal cloud drives), and how to report an incident. Because consultants operate globally and might use various networks, we stress using secure connections (the platform is HTTPS so that’s safe in transit) and encourage them to keep their own devices protected (updated OS, antivirus, etc.). We might require consultants to complete a short security tutorial or quiz as part of onboarding to ensure they understand these points. – Specialized Training for IRT: Members of the Incident Response Team get deeper training in their areas. For example, the Technical Lead may attend digital forensics training or certification courses; the Communications Lead might attend a workshop on crisis communication in cybersecurity. We also ensure the Legal Officer stays current on breach notification law changes (for instance, if new regulations in other countries come up, or if U.S. states tighten laws). The idea is the IRT builds expertise over time. Cross-training is also done so backup personnel can cover a role if someone is unavailable (incidents don’t always happen at convenient times). – Periodic Refreshers and Updates: Threats evolve quickly, so HGA circulates security reminders and updates. If a new phishing campaign is targeting similar organizations, our security team will send out a bulletin to staff/consultants, e.g., “Be aware of emails that look like X, do not click – this is a current threat.” We maintain a page on our intranet or platform with security tips and update it regularly. Also, any changes to this Incident Response Policy or procedures will be communicated through official channels and possibly brief training sessions, so everyone knows what’s new. – Drill Participation: As mentioned, sometimes training occurs via drills. People learn by doing – so participating in an incident simulation can train them on what to do in a real one. We might not involve all consultants in drills (logistically hard), but we can involve a subset or internal staff at least. After any real incident or drill, we often do a quick “lessons shared” to the broader team (without sensitive details) like “We conducted a drill, here are three things everyone should note…”.

Security Culture: Ultimately, continuous training fosters a culture where security and incident response readiness is part of everyone’s job. We encourage employees and consultants to ask questions and report issues – for example, if someone isn’t sure whether something is a security concern, we prefer they err on the side of reporting it (no shame in false alarms). We also reward or acknowledge good security behaviors (like a “kudos” if someone successfully spots and reports a phishing attempt).

4. Keeping the Plan Up-to-Date:

Continuous improvement means this policy itself will be reviewed at least annually, or whenever significant changes in our environment occur (like deploying a new module on the platform, or changes in law). Reviews will take into account: – Results of tests and drills. – Actual incident learnings. – Changes in HGA’s business (new offices, new types of services, etc., which might introduce new risks). – Evolving threat landscape (if, say, supply chain attacks become more common, integrate that into our plan). – Updates in compliance requirements (new laws might impose new steps, for instance some jurisdictions now require notifying affected individuals within shorter time frames or require certain language in notices; we’ll adapt accordingly).

Management will approve updates to the policy, and then we’ll disseminate the updates to staff and consultants (possibly requiring acknowledgment of the updated policy for accountability).

In summary, through continuous monitoring, we stay vigilant; through testing and drills, we stay prepared; and through training and review, we stay smart and responsive. These efforts ensure that when an incident occurs, it won’t be the first time the team is handling such a situation – they will have reference experiences and knowledge to draw upon, reducing panic and errors. It also ensures that HGA’s defenses remain strong to hopefully prevent incidents from occurring in the first place (the best incident is the one that never happens, thanks to proactive measures!).

Policy Maintenance and Review

This Incident Response and Cybersecurity Breach Policy is a living document and will be maintained as such.

Ownership: The policy is owned by HGA’s management, with specific oversight by the Security Officer or Incident Response Coordinator (if such a role is formally established). The owner is responsible for initiating reviews and updates.
Review Cycle: The policy will be reviewed on an annual basis at minimum. Additionally, a review will be triggered after any major security incident or breach, to incorporate lessons learned (as discussed in Section 4.7). Regulatory changes or significant shifts in HGA’s IT environment will also prompt an out-of-cycle review. For example, if a new law in a key jurisdiction requires changes in breach notification, we will update this document accordingly without waiting for the annual cycle.
Approval: All revisions to the policy must be approved by senior management (such as the CEO or CTO, and if we have a Risk or Security Committee, by that body as well). This ensures leadership endorsement and resource support for the policy’s implementation.
Version Control: Each iteration of the policy will be versioned and archived. The document header (if in Word or PDF form) will contain a version number, date of last update, and a brief description of changes. Previous versions will be retained for reference for a period of time, to demonstrate HGA’s evolving compliance posture (useful during audits or if a historical incident has to be understood under the policy of that time).
Accessibility: The current version of the policy will be made accessible to all employees (e.g., on the company intranet or shared drive) and pertinent sections or summary will be available to consultants (perhaps via the consultant portal or provided during onboarding). We ensure it’s presented in a clear format – possibly accompanied by a one-page flowchart for quick reference during an incident. However, the full detail is maintained in this document for completeness.
Related Documents: This policy is part of HGA’s broader information security program. It might reference other policies (Acceptable Use Policy, Data Classification Policy, Business Continuity Plan, etc.). During maintenance, we ensure consistency across these documents. For example, if our Business Continuity/Disaster Recovery plan is updated with new Recovery Time Objectives, we ensure the incident response recovery section aligns.
Compliance and Audit: Adherence to this policy will be subject to internal audits. HGA’s Audit and Compliance process may periodically check if incident response drills are happening, if logs are being kept per policy, if incidents were handled following these steps, etc.[62][20]. Any findings will be used to improve processes. In some cases, external audits or certifications (like ISO 27001 or client security assessments) may review our incident response policy and evidence of its implementation. We maintain documentation (such as incident logs, training records, drill reports) to demonstrate compliance with the policy.
Enforcement: All HGA staff and consultants are expected to comply with this policy. Any willful disregard of the procedures (for instance, an employee hiding an incident or a consultant not reporting a breach of data they hold) can result in disciplinary action, up to termination of employment or contract, in line with our HR policies and contract terms. This is not to be punitive for mistakes (we encourage reporting mistakes), but to enforce that following the procedure is mandatory for the collective good.
Improvement Mechanism: We encourage feedback on this policy from the users of it – the IRT members, employees, and consultants. If someone spots an area that is unclear or impractical, they can report that to the policy owner or during drills. We will consider such feedback in our revisions. The goal is to keep the policy practical, effective, and aligned with best practices rather than let it become stale or overly theoretical.

By diligently maintaining this policy, HGA ensures that it remains prepared for current and future cyber threats. This sustained commitment also signals to clients, partners, and regulators that HGA treats cybersecurity and incident response as an ongoing priority, not a one-time effort.

Conclusion:

HGA’s Incident Response and Cybersecurity Breach Policy provides a comprehensive blueprint for protecting our digital platform and data in the face of cyber incidents. Through clear definitions, well-defined team roles, step-by-step procedures, regulatory compliance measures, and integration with our technical controls, we have established a strong defense and response mechanism. Both our internal staff and external consultants play vital roles in this process, supported by training and clear communication channels.

This policy, coupled with HGA’s technical safeguards and the culture of security awareness, will help minimize incident impacts and fulfill our obligations to all stakeholders. In the ever-changing threat landscape, we remain vigilant and ready – continuously monitoring, learning, and improving – to keep Humanics Global Advisors’ operations secure and reliable.

References (Sources):

HGA Digital Platform Technical Specifications – Security & Compliance features (encryption, MFA, RBAC, backup, monitoring)[63][17][10][64].
HGA Consultant Contract Template – Data Protection commitments and breach notification obligations[1][2].
GDPR Article 33 – 72-hour breach notification requirement to authorities[26].
California Data Breach Notification Law – “without unreasonable delay” requirement for consumer notice[3].
Sumo Logic blog on Evidence Preservation – importance of chain of custody and evidence handling[6].
Thoropass guide on Breach Notification – role definitions and need for prompt data subject notification for high-risk breaches[65][29].

[1] [2] [8] [9] [53] [54] [55] [56] [57] [58] [59] [60] HGA_Consultant_Contract_Template.docx

file://file-GA7v2hdnXhXEYmWj3q3gXG

[3] [30] [31] [32] [33] [34] [35] [36] [37] California – Lewis Brisbois Bisgaard & Smith LLP

https://lewisbrisbois.com/privacy/US/California/data-breach

[4] [5] [7] [10] [14] [16] [17] [18] [19] [20] [22] [23] [24] [25] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [61] [62] [63] [64] HGA_Digital_Platform_Technical_Specifications.pdf

file://file-LERZnDM52Sh8kLN2RatZB5

[6] [21] The importance of evidence preservation in incident response

https://www.sumologic.com/blog/the-importance-of-evidence-preservation-in-incident-response

[11] [12] Contact Us – Humanics Global Advisors LLC

https://humanicsgroup.com/contact-us/

[13] [15] [26] [27] [28] [38] Art. 33 GDPR – Notification of a personal data breach to the supervisory authority – General Data Protection Regulation (GDPR)

https://gdpr-info.eu/art-33-gdpr/

[29] [65] Understanding the GDPR breach notification timeline: A step-by-step guide – Thoropass

https://thoropass.com/blog/compliance/gdpr-breach-notification-timeline/

Purpose and Scope

Definitions

Incident Response Team Roles and Responsibilities

Incident Response Team Roles and Responsibilities

Breach Notification and Regulatory Compliance

Communication Protocols

Logging, Evidence Preservation, and Chain of Custody

Integration with Platform Security Controls and Infrastructure

Alignment with Consultant Confidentiality & Data Protection Obligations

Continuous Monitoring, Testing, and Training

Policy Maintenance and Review

Get Global Consulting Updates

Directly to

Directly to

Overview

Purpose

Contact

Services

Industries

Studies

Insights

Thinking

Career

Humanics Global Advisors

Humanics Sénégal

HGA Policy Framework