Skip to main content
Campaigns Information Privacy
Updated over 8 months ago

Impactive exercises strict information security protocols, continuously improves security practices and prioritizes protecting user data. We work with independent reviewers to assess our systems to spot and further tighten privacy settings. Below, you will find a detailed outline of our practices, as well as answers to some frequently asked questions.

User Information Privacy

Please see our guide on User Information Privacy here.

Who can see my campaign data on Impactive?
Only the administrations on your campaign and a small group of Impactive employees with security training are able to see campaign data. Volunteers cannot see this information.

Can I delete my campaign’s data or data on specific actions?

Clients can request to have their data deleted from our servers, and clients can write custom data deletion terms in both their contracts, and user Terms and Conditions. Data will never be automatically deleted by Impactivee users can delete their contacts at any time from the settings page or by sending a request to [email protected].

Where does action data go when I delete an action?

Actions deleted on Impactive are a "soft delete" for administrative purposes. The data is still backed up in case this was a mistake and a client would like that data restored.

What information can a campaign administrator see after users sync their contacts?

Your campaign cannot see user’s synced contact information unless a user completes reports as part of their contact outreach. You can, however, see how many contacts a user has synced.

What data does Impactive sync back to VAN?

If you have integrated your VAN, PDI, or SALSA with an API key, syncing between Impactive and these platforms will occur automatically.

We sync contacts on your uploaded lists, and the contacts of your users on Impactive, with VAN IDs. If a voter canvassed through Impactive has a VAN ID that matches with our system, you can set up sync instructions to send activist codes, canvasser responses and survey questions back to your VAN license. We cannot add new constituents to VAN using Impactive.

HTTPS

All data sent to and from Impactive servers is sent over HTTPS. Heroku provides Automatic Certificate Management, which includes SSL/TLS handling.

Two-Factor Authentication
Access to production and customer sensitive data is secured using Two-Factor authentication via Google Authenticator, AWS authenticator, and/or Yubikeys.

System Logging
● Logz.io is used for logging and more on the resolution side but can be used for detailed debugging when an issue is suspected.
● We log all attempts to authenticate to Impactive both on the mobile app and the administrative dashboard.
● We log traffic requests, user behavior, and changes to the database.
● These logs are retained for 2 weeks before being transferred to S3 for storage.

System Monitoring
● New Relic is used for detecting anomalies in traffic, database queries, background jobs, and other performance metrics.
● Rack Attack is used to prevent denial of service attacks and smaller scale individual platform abuses.

Secure Development Lifecycle
● All new developers go through a mandatory review of our security documentation (covering topics similar to the questions asked here) and have their code reviewed by senior engineers. Security requirements are written into all initial spec docs and tests are created where applicable to cover those use cases such as authorization tests covering privileges for various user roles.
● Our code is hosted in Github before being deployed to Heroku.
● The production code lives on a master branch but before any code reaches production it must first be developed on a feature branch.
● The feature branch is then merged into a development branch and finally a staging branch for live QA.
● The staging environment is a lightweight clone of our production environment.
● All changes are submitted for approval before being merged into the staging and master branches.
● We use continuous integration testing through Travis CI which runs a test suite to determine if any changes made have introduced any new bugs.
● This code is reviewed by a senior engineer and checked again for any security or data sensitivity issues prior to merging and release.

Incident Response Plan
Our Incident Response Plan includes a checklist of:
● Procedures to be followed in the event of an incident covering detection, analysis, recovery, communications and debriefing.
● Designated personnel with contact info, roles and responsibilities, and owners for decision making and escalation.
● External contacts for legal counsel, law enforcement, vendors, and allied organizations.
● Organizational stakeholders and contact info.
The Impactive Incident Response Plan has been discussed with employees and is rehearsed regularly.

Did this answer your question?