MailTag Incident Response Policy

This Incident Response Policy describes how MailTag will respond to potential information security incidents.

This policy covers all security incidents (as defined below) affecting any MailTag information systems. All MailTag staff and contractors must ensure that they carry out any identified responsibilities under this policy.

A security incident is an adverse event that compromises the security of a system, a network, information, physical assets, and/or the safety of employees. A security incident includes malicious activities such as viruses, intrusion by outsiders into physically or logically protected spaces, theft of hardware, software, or other information assets, and unauthorized access to classified information.

MailTag will establish an Incident Response Plan containing:

• Contact information for key personnel, including:
  • Technical Leadership
  • Outside Counsel
  • Others, if necessary
• Information on how to deploy critical infrastructure, including how to redeploy on other providers and/or provider regions, as appropriate;
• Information on how to create an incident communications channel, alert key personnel, and record relevant information.

All staff are responsible for reporting security incidents, or potential security incidents, to their manager or the Head of Engineering. External parties can report security concerns by sending email to security@mailtag.io, which will send email to the Head of Engineering and other appropriate parties.

In the event of a reported security incident, MailTag staff, led by [Security Lead] or other personnel they designate, will perform the following steps:

• Confirm the incident: ensure that the report is correct, and that an incident appears to have been detected.
• Containment: Limit the scope of the incident to its current boundaries. For instance, in the event of a data leak event, stop additional data from being leaked. In the event of an attacker compromising systems, cut the compromised systems off from all other systems through applying firewall or security group rules.
• Determine the root cause: Using logs (see Operational Security Policy) or other available information, investigate and determine the source or sources of the incident.
• unauthorized cloud systems, then terminate and redeploy them with patches to fix the root cause(s).
• Restoration: Return systems to normal operations and communicate the end of the incident with relevant stakeholders.

Throughout a security incident, the response team will keep a written (electronic) record of all actions taken, along with timestamps, in addition to notes on decision-making, electronic records of the investigation (such as links to snapshots of compromised systems), and any other relevant information. This record will be retained after the incident.

In the event of a security incident that compromises (internal or external) customer-facing systems, [Security Lead] will coordinate with MailTag leadership to communicate with appropriate customers regarding any downtime or service interruptions. Once services have been restored, that will be communicated through the same method(s). These communications will be retained along with the incident documentation (above).

MailTag leadership will determine if an incident merits law enforcement contact, in conjunction with legal counsel. All such communication will go through or be directed by counsel.

After system restoration has been completed and appropriate documentation finalized, MailTag will hold a meeting with stakeholders and the incident response team to determine:

• What were the root cause(s) and contributing causes to the incident?
• Are there ways to prevent similar incidents in the future?
• What (human and/or technical) systems can be strengthened to increase resilience against this type of incident?
• How can the incident response process be improved?

Documentation from this meeting will be retained, and action items prioritized for work.

Periodically and not less than annually, management will review the documentation of security incidents to ensure that lessons learned are being taken into account, and any changes needed to the information security program are being made.

Periodically and not less than annually, all incident response plans shall be tested either with responsible parties gathered to walk through a hypothetical scenario and their responses (tabletop testing) or with a mock incident (full-dress testing). Documentation and post-incident review of the incident will occur as with a true incident.

All staff are responsible for:

• Reporting suspected security incidents to Ben Cohen, Partner.
• Assisting the incident response team as requested.

The Head of Engineering is responsible for:

• Leading the incident response process.
• Facilitating executive communication and any communications with counsel that may become necessary.
• Ensuring that documentation of the incident response process is made and retained.
• Working with any outside security or technical advisors as part of the incident response process.