ImpactMapper Policies

← Back to legal documents

1. Introduction

ImpactMapper, PBC ("ImpactMapper") is committed to ensuring the confidentiality, privacy, integrity, and availability of all electronic personal information (PI) it receives, maintains, processes and/or transmits on behalf of its Customers. ImpactMapper strives to maintain compliance, proactively address information security, mitigate risk for its Customers, and assure known breaches are completely and effectively communicated in a timely manner. The following documents address core policies used by ImpactMapper to maintain compliance and assure the proper protections of infrastructure used to store, process, and transmit data for ImpactMapper Customers.

ImpactMapper provides secure and compliant cloud-based software. This software is cited throughout polices also as ImpactMapper System or simply application.

1.2 Compliance Inheritance

ImpactMapper provides secure hosted software infrastructure for its Customers. ImpactMapper has been through internal audits to validate and map organizational policies and technical controls to GDPR rules. ImpactMapper's service offerings are hosted on AWS. ImpactMapper has signed the following agreements through AWS Artifact:

  • AWS Artifact Nondisclosure Agreement
  • AWS Australian Notifiable Data Breach Addendum

1.3 ImpactMapper Organizational Concepts

The physical infrastructure environment is hosted at Amazon Web Services (AWS). The network components and supporting network infrastructure are contained within the AWS infrastructures and managed by AWS (respectively). ImpactMapper does not have physical access into the network components. The ImpactMapper environment consists of nginx web servers; Node and Ruby application servers; PostgreSQL database servers; Logstash logging servers; Linux Ubuntu monitoring servers; Docker containers; and developer tool servers running on Linux Ubuntu.

Within the ImpactMapper System on AWS, all data transmission is encrypted and all hard drives are encrypted so data at rest is also encrypted; this applies to all servers - those hosting Docker containers, databases, APIs, log servers, etc. ImpactMapper assumes all data may contain PI, even though our assessment does not indicate this is the case, and provides appropriate protections based on that assumption.

The data and network segmentation mechanism differs depending on the primitives offered by the underlying cloud provider infrastructure.

AWS Security Groups are configured to restrict access to only justified ports and protocols.

ImpactMapper has implemented strict logical access controls so that only authorized personnel are given access to the internal management servers.

The environment is configured so that data is transmitted from the load balancers to the application servers over an TLS encrypted session.

The nginx web server, and application servers are externally facing and accessible via the Internet. The database servers, where the PI resides, are located on the internal ImpactMapper network and can only be accessed through a bastion host. Access to the internal database is restricted to a limited number of personnel and strictly controlled to only those personnel with a business-justified reason. Remote access to internal servers is not accessible except through load balancers.

All systems and operating systems are tested end-to-end for usability, security, and impact prior to deployment to production.

2. Data Management Policy

ImpactMapper has procedures to create and maintain retrievable exact copies of electronic personal information (PI) stored in conjunction with ImpactMapper Customer Content. The policy and procedures will assure that complete, accurate, retrievable, and tested backups are available for all systems used by ImpactMapper.

Data backup is an important part of the day-to-day operations of ImpactMapper. To protect the confidentiality, integrity, and availability of PI, both for ImpactMapper and ImpactMapper Customers, complete backups are done daily to assure that data remains available when it needed and in case of a disaster.

Violation of this policy and its procedures by workforce members may result in corrective disciplinary action, up to and including termination of employment.

2.1 Backup Policy and Procedures

  1. Perform daily snapshot backups of all systems that process, store, or transmit PI and Customer Content for ImpactMapper Customers.
  2. The ImpactMapper Ops Team is designated to be in charge of backups.
  3. Dev Ops Team members are trained and assigned to complete backups and manage the backup media.
  4. Document backups
    • Name of the system
    • Date & time of backup
    • Where backup stored (or to whom it was provided)
  5. Securely encrypt stored backups in a manner that protects them from loss or environmental damage.
  6. Test backups annually and document that files have been completely and accurately restored from the backup media.

3 System Access Policy

Access to ImpactMapper systems and application is limited for all users, including but not limited to workforce members, volunteers, business associates, contracted providers, and consultants. Access by any other entity is allowable only on a minimum necessary basis. All users are responsible for reporting an incident of unauthorized user or access of the organization's information systems. These safeguards have been established to address the GDPR Security regulations including the following:

3.1 Access Authorization

  • Role based access categories for each ImpactMapper system and application are pre-approved by the Security Officer, or an authorized delegate of the Security Officer.
  • ImpactMapper utilizes hardware and software firewalls to segment data, prevent unauthorized access, and monitor traffic for denial of service attacks.

3.2 Person or Entity Authentication

  1. Each workforce member has and uses a unique user ID and password that identifies him/her as the user of the information system.
  2. Each Customer and Partner has and uses a unique user ID and password that identifies him/her as the user of the information system.
  3. All Customer support desk interactions must be verified before ImpactMapper support personnel will satisfy any request having information security implications.

3.3 Unique User Identification

  1. Access to the ImpactMapper Platform systems and applications is controlled by requiring unique User Login IDs and passwords for each individual user and developer.
  2. Passwords requirements mandate strong password controls (see below).
  3. Passwords are not displayed at any time and are not transmitted or stored in plain text.
  4. Default accounts on all production systems, including root, are disabled.
  5. Shared accounts are not allowed within ImpactMapper systems or networks.
  6. Automated log-on configurations that store user passwords or bypass password entry are not permitted for use with ImpactMapper workstations or production systems.

3.4 Automatic Logoff

  1. Users are required to make information systems inaccessible by any other individual when unattended by the users (ex. by using a password protected screen saver or logging off the system).
  2. Information systems automatically log users off the systems after 24 hours from the last log in.

3.5 Password Management

  1. User IDs and passwords are used to control access to ImpactMapper systems and may not be disclosed to anyone for any reason.
  2. Users may not allow anyone, for any reason, to have access to any information system using another user's unique user ID and password.
  3. On all production systems and applications in the ImpactMapper environment, password configurations are set to require:
    • a minimum length of 8 characters;
    • a mix of upper case characters, lower case characters, and numbers or special characters;
  4. All system and application passwords must be stored and transmitted securely.
    • Where possible, passwords should be stored in a hashed format using a salted cryptographic hash function (SHA-256 or equivalent).
  5. Passwords are inactivated immediately upon an employee's termination.
  6. Upon initial login, users must change any passwords that were automatically generated for them.
  7. Password change methods must use a confirmation method to correct for user input errors.
  8. All passwords used in configuration scripts are secured and encrypted.
  9. If a user believes their user ID has been compromised, they are required to immediately report the incident to the Security Office.
  10. In cases where a user has forgotten their password, the password reset request is logged for auditing purposes.
  11. Two-factor authentication is supported and accomplished using a Counter-based One-Time Password (HOTP) as the second factor.

4 Auditing Policy

ImpactMapper shall audit access and activity of personal information (PI) applications and systems in order to ensure compliance. The Security Rule requires organizations to implement reasonable hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use PI. Audit activities may be limited by application, system, and/or network auditing capabilities and resources. ImpactMapper shall make reasonable and good-faith efforts to safeguard information privacy and security through a well-thought-out approach to auditing that is consistent with available resources.

It is the policy of ImpactMapper to safeguard the confidentiality, integrity, and availability of applications, systems, and networks. To ensure that appropriate safeguards are in place and effective, ImpactMapper shall audit access and activity to detect, report, and guard against:

  • Network vulnerabilities and intrusions;
  • Breaches in confidentiality and security of personal information;
  • Performance problems and flaws in applications;
  • Improper alteration or destruction of PI;
  • Out of date software and/or software known to have vulnerabilities.

This policy applies to all ImpactMapper systems.

4.1 Auditing Policies

  1. Responsibility for auditing information system access and activity is assigned to ImpactMapper's Security Officer. The Security Officer shall:
    • Organize and provide oversight to a team structure charged with audit compliance activities (e.g., parameters, frequency, sample sizes, report formats, evaluation, follow-up, etc.).
    • All connections to ImpactMapper are monitored. Access is limited to certain services, ports, and destinations. Exceptions to these rules, if created, are reviewed on an annual basis.
  2. ImpactMapper's auditing processes shall address access and activity at the following levels listed below. Auditing processes may address date and time of each log-on attempt, date and time of each log-off attempt, devices used, functions performed, etc.
    • User: User level audit trails generally monitor and log all commands directly initiated by the user, all identification and authentication attempts, and data and services accessed.
    • Application: Application level audit trails generally monitor and log all user activities, including data accessed and modified and specific actions.
    • System: System level audit trails generally monitor and log user activities, applications accessed, and other system defined specific actions.
    • Network: Network level audit trails generally monitor information on what is operating, penetrations, and vulnerabilities.
  3. ImpactMapper shall log all incoming and outgoing traffic to into and out of its environment. This includes all successful and failed attempts at data access and editing. Data associated with this data will include origin, destination, time, and other relevant details that are available to ImpactMapper.
  4. Vulnerability testing software may be used to probe the network to identify what is running (e.g., operating system or product versions in place), whether publicly-known vulnerabilities have been corrected, and evaluate whether the system can withstand attacks aimed at circumventing security controls.
    • Testing may be carried out internally or provided through an external third-party vendor. Whenever possible, a third party auditing vendor should not be providing the organization IT oversight services (e.g., vendors providing IT services should not be auditing their own services - separation of duties).
    • Testing shall be done on a routine basis.
  5. Software patches and updates will be applied to all systems in a timely manner.

5. Incident Response Policy

ImpactMapper implements an information security incident response process to consistently detect, respond, and report incidents, minimize loss and destruction, mitigate the weaknesses that were exploited, and restore information system functionality and business continuity as soon as possible.

The incident response process addresses:

  • Continuous monitoring of threats through intrusion detection systems (IDS) and other monitoring applications;
  • Establishment of an information security incident response team;
  • Establishment of procedures to respond to media inquiries;
  • Establishment of clear procedures for identifying, responding, assessing, analyzing, and follow-up of information security incidents;
  • Workforce training, education, and awareness on information security incidents and required responses; and
  • Facilitation of clear communication of information security incidents with internal, as well as external, stakeholders

5.1 Incident Management Policies

ImpactMapper's incident response classifies security-related events into the following categories:

  • Events - Any observable computer security-related occurrence in a system or network with a negative consequence. Examples:
    • Hardware component failing causing service outages.
    • Software error causing service outages.
    • General network or system instability.
  • Precursors - A sign that an incident may occur in the future. Examples:
    • Monitoring system showing unusual behavior.
    • Audit log alerts indicated several failed login attempts.
    • Suspicious emails targeting specific ImpactMapper staff members with administrative access to production systems.
  • Indications - A sign that an incident may have occurred or may be occurring at the present time. Examples:
    • Alerts for modified system files or unusual system accesses.
    • Antivirus alerts for infected files.
    • Excessive network traffic directed at unexpected geographic locations.
  • Incidents - A violation of computer security policies or acceptable use policies, often resulting in data breaches. Examples:
    • Unauthorized disclosure of PII.
    • Unauthorized change or destruction of PII.
    • A data breach accomplished by an internal or external entity.
    • A Denial-of-Service (DoS) attack causing a critical service to become unreachable.

ImpactMapper employees must report any unauthorized or suspicious activity seen on production systems or associated with related communication systems (such as email or Slack). In practice this means keeping an eye out for security events, and letting the Security Officer know about any observed precursors or indications as soon as they are discovered.

5.1.1 Identification Phase

  1. Immediately upon observation members report suspected and known Events, Precursors, Indications, and Incidents in one of the following ways:
    • Direct report to management, the Security Officer, Privacy Officer, or other;
    • Email;
    • Phone call;
    • Secure Chat.
    • Anonymously through workforce members desired channels.
  2. The individual receiving the report facilitates completion of an Incident Identification document and notifies the Security Officer (if not already done).
  3. The Security Officer determines if the issue is an Event, Precursor, Indication, or Incident.
  • If the issue is an event, indication, or precursor the Security Officer forwards it to the appropriate resource for resolution.
    • Non-Technical Event (minor infringement): the Security Officer completes a documents and investigates the incident.
    • Technical Event: Assign the issue to an IT resource for resolution. This resource may also be a contractor or outsourced technical resource, in the event of a small office or lack of expertise in the area.
  • If the issue is a security incident the Security Officer activates the Security Incident Response Team (SIRT) and notifies senior management.
    • If a non-technical security incident is discovered the SIRT completes the investigation, implements preventative measures, and resolves the security incident.
    • Once the investigation is completed, progress to Phase V, Follow-up.
    • If the issue is a technical security incident, commence to Phase II: Containment.
    • The Containment, Eradication, and Recovery Phases are highly technical. It is important to have them completed by a highly qualified technical security resource with oversight by the SIRT team.
    • Each individual on the SIRT and the technical security resource document all measures taken during each phase, including the start and end times of all efforts.
    • The lead member of the SIRT team facilitates the collection of a summary of all events, efforts, and conclusions of each Phase of this policy and procedures.
  1. The Security Officer, Privacy Officer, or ImpactMapper representative appointed notifies any affected Customers and Partners. If no Customers and Partners are affected, notification is at the discretion of the Security and Privacy Officer.
  2. In the case of a threat identified, the Security Officer is to form a team to investigate and involve necessary resources, both internal to ImpactMapper and potentially external.

5.1.2 Containment Phase (Technical)

In this Phase, ImpactMapper's IT department attempts to contain the security incident. It is extremely important to take detailed notes during the security incident response process. This provides that the evidence gathered during the security incident can be used successfully during prosecution, if appropriate.

  1. The SIRT reviews any information that has been collected by the Security Officer or any other individual investigating the security incident.
  2. The SIRT secures the network perimeter.
  3. The IT department performs the following:
  • Securely connect to the affected system over a trusted connection.
  • Retrieve any volatile data from the affected system.
  • Determine the relative integrity and the appropriateness of backing the system up.
  • If appropriate, back up the system.
  • Change the password(s) to the affected system(s).
  • Determine whether it is safe to continue operations with the affect system(s).
  • If it is safe, allow the system to continue to function;
    • Complete any documentation relative to the security incident on the SIR document.
    • Move to Phase V, Follow-up.
  • If it is NOT safe to allow the system to continue operations, discontinue the system(s) operation and move to Phase III, Eradication.
    • The individual completing this phase provides written communication to the SIRT.
  1. Continuously apprise Senior Management of progress.
  2. Continue to notify affected Customers and Partners with relevant updates as needed

5.1.3 Eradication Phase (Technical)

The Eradication Phase represents the SIRT's effort to remove the cause, and the resulting security exposures, that are now on the affected system(s).

  1. Determine symptoms and cause related to the affected system(s).
  2. Strengthen the defenses surrounding the affected system(s), where possible (a risk assessment may be needed and can be determined by the Security Officer). This may include the following:
    • An increase in network perimeter defenses.
    • An increase in system monitoring defenses.
    • Remediation ("fixing") any security issues within the affected system, such as removing unused services/general host hardening techniques.
  3. Conduct a detailed vulnerability assessment to verify all the holes/gaps that can be exploited have been addressed.
    • If additional issues or symptoms are identified, take appropriate preventative measures to eliminate or minimize potential future compromises.
  4. Complete the incident document with the new updates.
  5. Update the documentation with the information learned from the vulnerability assessment, including the cause, symptoms, and the method used to fix the problem with the affected system(s).
  6. Apprise Senior Management of the progress.
  7. Continue to notify affected Customers and Partners with relevant updates as needed.
  8. Move to Phase IV, Recovery.

5.1.4 Recovery Phase (Technical)

The Recovery Phase represents the SIRT's effort to restore the affected system(s) back to operation after the resulting security exposures, if any, have been corrected.

  1. The technical team determines if the affected system(s) have been changed in any way.
    • If they have, the technical team restores the system to its proper, intended functioning ("last known good").
    • Once restored, the team validates that the system functions the way it was intended/had functioned in the past. This may require the involvement of the business unit that owns the affected system(s).
    • If operation of the system(s) had been interrupted (i.e., the system(s) had been taken offline or dropped from the network while triaged), restart the restored and validated system(s) and monitor for behavior.
    • If the system had not been changed in any way, but was taken offline (i.e., operations had been interrupted), restart the system and monitor for proper behavior.
    • Update the documentation with the detail that was determined during this phase.
    • Apprise Senior Management of progress.
    • Continue to notify affected Customers and Partners with relevant updates as needed.
    • Move to Phase V, Follow-up.

5.1.5 Follow-up Phase (Technical and Non-Technical)

The Follow-up Phase represents the review of the security incident to look for "lessons learned" and to determine whether the process that was taken could have been improved in any way. It is recommended all security incidents be reviewed shortly after resolution to determine where response could be improved. Timeframes may extend to one to two weeks post-incident.

  1. Responders to the security incident (SIRT Team and technical security resource) meet to review the documentation collected during the security incident.
  2. Create a "lessons learned" document and attach it to the completed SIR document.
    • Evaluate the cost and impact of the security incident to ImpactMapper using the documents provided by the SIRT and the technical security resource.
    • Determine what could be improved.
    • Communicate these findings to Senior Management for approval and for implementation of any recommendations made post-review of the security incident.
    • Carry out recommendations approved by Senior Management; sufficient budget, time and resources should be committed to this activity.
    • Close the security incident.

5.2 Security Incident Response Team (SIRT)

Current members of the ImpactMapper SIRT:

  • Back-end lead developer

6 Breach Policy

To provide guidance for breach notification when impressive or unauthorized access, acquisition, use and/or disclosure of the PII occurs. Breach notification will be carried out in compliance with the GDPR as well as any other federal or state notification law.

The General Data Protection Regulation (GDPR) (EU) 2016/679 is a regulation in EU law on data protection and privacy for all individuals within the European Union. It addresses the export of personal data outside the EU. The GDPR aims primarily to give control back to citizens and residents over their personal data and to simplify the regulatory environment for international business by unifying the regulation within the EU.

GDPR was adopted on 27 April 2016 and becomes enforceable from 25 May 2018. It will replace the 1995 Data Protection Directive (Directive 95/46/EC).

In the case of a breach, ImpactMapper shall notify all affected Customers. It is the responsibility of the Customers to notify affected individuals.

6.1 ImpactMapper Platform Customer Responsibilities

  1. The ImpactMapper Customer that accesses, maintains, retains, modifies, records, stores, destroys, or otherwise holds, uses, or discloses unsecured PII shall, without unreasonable delay and in no case later than 60 calendar days after discovery of a breach, notify ImpactMapper of such breach. The Customer shall provide ImpactMapper with the following information:
    • A description of what happened, including the date of the breach, the date of the discovery of the breach, and the number of records and Customers affected, if known.
    • A description of the types of unsecured personal information that were involved in the breach (such as full name, phone number, date of birth, address, account number, etc.), if known.
    • A description of the action taken with regard to notification of Customers regarding the breach.
    • Resolution steps taken to mitigate the breach and prevent future occurrences.
  2. Notice to Media: ImpactMapper Customers are responsible for providing notice to prominent media outlets at the Customer's discretion.

7 Data Integrity Policy

ImpactMapper takes data integrity very seriously. As stewards and partners of ImpactMapper Customers, we strive to assure data is protected from unauthorized access and that it is available when needed. The following policies drive many of our procedures and technical settings in support of the ImpactMapper mission of data protection.

Production systems that create, receive, store, or transmit Customer data (hereafter "Production Systems") must follow the guidelines described in this section.

7.1 Monitoring Log-in Attempts

  1. All access to Production Systems must be logged. This is done following the ImpactMapper Auditing Policy.

7.2 Intrusion Detection and Vulnerability Scanning

  1. Production systems are monitored. Suspicious activity is logged and alerts are generated.
  2. Vulnerability scanning of Production Systems must occur on a predetermined, regular basis, no less than annually. Scans are reviewed by Security Officer, with defined steps and retained for future reference.

7.3 Production System Security

  1. System, network, and server security is managed and maintained by the Security Officer in conjunction with the Dev Ops team. production environments.
  2. Access to Production Systems is controlled using centralized tools and two-factor authentication.

7.4 Production Data Security

  1. Reduce the risk of compromise of Production Data.
  2. Implement and/or review controls designed to protect Production Data from improper alteration or destruction.
  3. Ensure that confidential data is stored in a manner that supports user access logs and automated monitoring for potential security incidents.
  4. Ensure ImpactMapper Customer Production Data is only accessible to Customers authorized to access data.
  5. All Production Data at rest is stored on encrypted volumes using encryption keys managed by ImpactMapper. Encryption at rest is ensured through the use of automated deployment scripts.
  6. Volume encryption keys and machines that generate volume encryption keys are protected from unauthorized access. Volume encryption key material is protected with access controls such that the key material is only accessible by privileged accounts.
  7. Encrypted volumes use AES encryption with a minimum of 256-bit keys, or keys and ciphers of equivalent or higher cryptographic strength.

7.5 Transmission Security

  1. All data transmission is encrypted end to end using encryption keys managed by ImpactMapper. Encryption is not terminated at the network end point, and is carried through to the application.
  2. Transmission encryption keys and machines that generate keys are protected from unauthorized access. Transmission encryption key material is protected with access controls such that the key material is only accessible by privileged accounts.
  3. Transmission encryption keys use a minimum of 4096-bit RSA keys, or keys and ciphers of equivalent or higher cryptographic strength.
  4. In the case of ImpactMapper provided APIs, provide mechanisms to assure person sending or receiving data is authorized to send and save data.
  5. System logs of all transmissions of Production Data access. These logs must be available for audit.