So you‘re looking into UserVoice but wondering if you‘re even allowed to use it and if it‘s safe. Don‘t worry. The more than 100,000 organizations that use UserVoice asked the same questions, but we understand it‘s still important to find out on your own.

If you‘re interested in our policies, definitely check out our Terms of Service and Privacy Policy. We strive hard to make those as human and readable as possible (while still keeping our lawyers happy). However, if it‘s compliance and security you‘re worried about, then you‘ve come to the right place.


UserVoice is Section 508 Compliant.

Section 508 Compliant

UserVoice is section 508 compliant & WCAG2 AAA compliant. This means we‘ve built UserVoice to modern standards to ensure that UserVoice sites are as accessible as possible to those using screen readers or other accessibility technology.

UserVoice is Safe Harbor Compliant.

Safe Harbor

Our datacenters are all in the United States (Dallas, TX) but we‘re self-certified Safe Harbor compliant. That means all of our friends in the EU won‘t run afoul of EU privacy protection laws by using UserVoice. Don‘t believe us? Check out our record with the US Department of Commerce.

UserVoice is PCI DSS Compliant.


UserVoice doesn‘t store credit card information in our database (all credit card data is stored securely in our payment gateway, Braintree, which is also PCI compliant), but credit card information does transit through our system so we‘ve verified as Payment Card Industry Data Security Standard (PCI DSS) compliant. This compliance is handled by SecurityMetrics and includes a self-questionnaire and quarterly security scan (last scan June 15, 2015) of our servers (details scan results).

UserVoice is able to be used by U.S. Government entities.

We've worked with the GSA to amend our standard Terms of Service to comply with restrictions specific to United States federal laws and regulations. The complete details of this amendment can be found here: Amendment to UserVoice Terms of Service.

Data Security

As is common for software-as-a-service vendors, UserVoice runs on leased servers provided by Softlayer technologies, located in Dallas, TX, to deliver our service.

UserVoice‘s hosting provider Softlayer is SSAE 16 certified.


SSAE 16 (Statement on Standards for Attestation Engagements) has replaced the Statement on Auditing Standards No. 70 (SAS 70) as the primary standard for reporting on controls at service organizations. It is an attestation standard issued by the American Institute of Certified Public Accountants (AICPA). Specifically, SSAE 16 addresses engagements conducted by service auditors on service organizations for purposes of reporting on the design of controls and their operating effectiveness. See Softlayer certifications.

Access to all UserVoice servers is secure.

  • Firewalls (IPTables) on all servers are set to default-deny. The only services that are allowed are SSH (all servers; non-standard port) and HTTP/HTTPS (web servers only).
  • Database connections are only accepted from other UserVoice servers on the internal private subnet. No other organization‘s servers reside on the UserVoice subnets at Softlayer.
  • All communication with servers (outside of public HTTP/HTTPS access) is over encrypted secure shell (SSH) and password authentication is disabled. SSH authentication is available only via public/private key authentication.
  • In-depth information on our SSL implementation is available via this Qualys SSL Report on UserVoice.
  • A network diagram is available upon request.

UserVoice has addressed Heartbleed SSL vulnerabilities.

We addressed this issue on April 9, 2014. Confirmed by the Qualys SSL Report on UserVoice.

UserVoice servers and software are running the latest versions of software and security patches.

  • We strive to keep all server software on the latest version; however, when that‘s not possible we do ensure that the latest security patches are installed/up to date. This is reviewed monthly (though patches are often installed as soon as they come out).
  • We‘re running the latest version of Ruby on Rails 4.0 and we review/apply the latest security patches as they come out.

UserVoice is written to protect against SQL injection attacks.

UserVoice is built on the Ruby on Rails platform and uses all the built-in protections for sanitizing query parameters in SQL statements.

UserVoice is written to protect against cross-site scripting attacks (XSS).

UserVoice runs the XSS plugin for Ruby on Rails that escapes all user-generated data by default to prevent users from embedding malicious Javascript code in customer sites.

Your password is stored securely

For performance reasons our database itself is not encrypted (though backups are; more on that below), but all user passwords are hashed using the SHA1 algorithm with salt. Hashing passwords is actually more secure than encrypting them, because that means we don’t have access to the original passwords, nor does anyone else. So even if our database is compromised, everyone’s passwords will stay secure.

Your access to UserVoice is secure

All access to your UserVoice admin console ( is always over a secure (SSL encrypted) connection.

Your users access to UserVoice is secure

All widgets through which customers submit support tickets are also always over a secure SSL encrypted connection. Only your UserVoice site itself ( is not SSL-only, but you can force that to SSL-only on premium plans (though it does break domain aliasing, which is why we don’t provide it for everyone).

Access is logged.

Server access logs for auditing are kept for seven days. Access logs for web servers are kept for 30 days.

Data is co-mingled but secure.

UserVoice is a multi-tenant SaaS solution: customer data is co-mingled on the same database tables, but all data is scoped by an account ID to ensure that one account cannot access data of another account. Unit, functional, and integration tests are run continuously on our CI servers to ensure that it‘s not possible for account data to leak.

Development and test environments do not use customer data.

We use fake customer data in those environments.

Nightly backups are stored offsite and encrypted.

  • A live backup is performed in near real-time with slave databases.
  • Backups are always full backups of all tables in the UserVoice MySQL database.
  • Backups do not include secondary data (like pageview tracking, denormalized reporting data) that is stored in various NoSQL systems (Mongo, Redis).
  • Backups are done nightly and encrypted with a shared password and stored offsite.
  • Backups are tested and restored daily.
  • Backups are kept for 30 days.
  • Backups are never kept on portable/removable media.

Deleted data is retained for up to 60 days.

All data that‘s deleted in the UserVoice system is soft deleted and can be recovered inside of 30 days. After 30 days that data is hard deleted and can only be recovered via full backup for another 30 days.


Uptime for the last six months was 99.95%.

As of September 1, 2014. We track uptime using Pingdom testing at at a one-minute resolution as well as monthly uptime stats live at

UserVoice assets and widgets load quickly from anywhere in the world.

All static files (JS, CSS, widgets, images) are compressed and served from our CDN (Akamai), which has edge servers located around the world. In addition, all DNS requests are handled by Dyn, which has multiple DNS servers throughout the world.

UserVoice widgets will not impact your page load times.

UserVoice widgets are written in such way that they won‘t block page load and instead only load after the initial page is loaded. This means that your page load times are not impacted by installation of any UserVoice widget.

Domain Name Service (DNS) redundancy.

Provided by our DNS provider Dyn. From their site: “Built on a global IP Anycast network that includes 17 data centers, our enterprise-grade platform boasts an easy-to-use, web-based management portal, advanced logging and reporting, IPv6 and DNSSEC support—all with the backing of our support team that is available 24/7/365.”

Network-level redundancy.

Provided by our hosting provider Softlayer Technologies.

Application-level redundancy.

  • Redundant front-end proxy web servers.
  • Behind them are multiple application servers sitting behind a load balancer that ensures that if a server goes offline requests are immediately funneled to the remaining servers.
  • Database is arrayed in a standard master-slave configuration to provide a live backup and failover database should the master database server go offline.
  • Redundant secondary (NoSQL) databases.

Internal as well as external monitoring means we respond quickly to any service issues.

  • Internal system monitoring tools (Nagios) check on all systems every five minutes, and critical systems or errors are checked every minute.
  • Any critical errors (ex: server offline) triggers SMS alerts to the entire engineering team.
  • Pingdom is used to both monitor uptime of UserVoice sites as well as our internal tools (Nagios). The watcher of the watchers, if you will.
  • Application level monitoring includes custom internal tools (based on statsd) to track application events, tracking all 500 errors (failed requests) using Airbrake and New Relic RPM to track error rates and response times.
  • A critical issue policy is followed to ensure that proper issue escalation occurs. After any critical incident (defined as any incident that impedes end-users from performing core functionality), engineering is required to provide a write-up and retrospective on what went wrong and how it can be prevented in the future. These write-ups are often shared with customers via
  • Real-time notifications about any current service delivery issues are available at

PII and Cookies

Names and emails are the only personally identifiable information (PII) stored in the UserVoice database.

Cookies are required for normal operation of UserVoice; however, no PII is stored in any of the cookies that UserVoice uses:

Cookie Name Expiration Description
__utma, __utmb, __utmc, __utmz, __utmvvariesUsed by Google Analytics.
_session_idend of sessionUsed to track whether you‘re logged in or not. See below for more info.
_uservoice_tz90 daysYour time zone.
_uservoice_utcd6 monthsUsed for analytics tracking. More info below
_uservoice_uid8 weeksUsed to track logged-in state.
uvfend of sessionUsed to track if the user has been saved to the analytics backend.
uvts1 yearUsed to track user usage analytics.
__uvtend of sessionUsed to test whether cookies are enable.
_rfend of sessionUsed to determine if your information is up to date. It‘s usually just a number like 0 or 1.
auth_token1 yearUsed for “remember me” functionality to keep you logged in between sessions (i.e. closing and reopening your browser). Only appears if you log in and click the “Keep me logged in” link, or if you vote anonymously.


The _session_id is something that all apps use in order to determine if you‘re logged in and authorized to do logged-in actions. All apps that require authentication use some version of it. That‘s the reason for those "you have to enable cookies in order to use this site" sort of warnings. If you were to delete it you would be logged out. If you log back in, we put it back with another securely random number.


The _uservoice_uid works in conjunction with the _session_id to help us to verify the security of your session data. If you were to delete your _uservoice_uid it would reappear the next time you loaded the page as a logged-in user.


_uservoice_utcd is another random session number. It‘s what we use to do analytics, like pageviews and such, so we can tie an anonymous user with an identifier. This exists so that it‘s not connected to your _session_id. Therefore, it‘s completely anonymous; we don‘t connect real user information with these utcds. It can be deleted at any time with no effect on your use of our app.

3rd Party Infrastructure Service Providers

3rd Party Infrastructure Service Providers that the UserVoice platform relies on and the data shared with each:

Provider Name Description Handles PII data
SoftLayer Hosts our production servers. Yes
CloudFlare CloudFlare acts as our CDN and as DDOS protection. All HTTP requests pass through CloudFlare. Yes
Amazon We store assets and database backups in Amazon S3 and use EC2 to perform database backups. Yes
Mailgun Incoming emails and outgoing emails pass through Mailgun’s servers. Yes is used in our Knowledge Base product to embed rich media snippets. primarily has access to the embedded snippet URL, which are typically public. No
Pusher We use Pusher to do live updates in admin console for things like ticket counts and the leaderboard. No
Bugsnag Exceptions and errors in our application are sent to Bugsnag. Yes
Akismet We use Akismet to check comments for spam. Yes
Google Analytics Provides anonymous usage tracking. No
Full Story Our UX team uses this to analyze admin sessions in order to improve our product. Yes

Common Questions

We have over _____ pageviews a month. Can we install your widget on our site?

Yes. See the previous section on assets/widget performance. Your traffic will likely be a drop in the ocean for us but if you're expecting over 100MM pageviews per month we'd love to chat with you before you go live. Also, if you expect more than 500,000 widget embed impressions per month you should check our Fair Usage Limits.

Do you have a have a rigorous screening process for your employees that includes credit checks, background checks, reference checks and cavity searches?

No. We will often check references, we will always verify that local standard for proof of eligibility to work, and we‘ll make sure that potential team members fit our company values, but we will do little beyond that. We also have every employee sign a confidentiality agreement before he or she can work for us. We also do performance and peer reviews twice a year and retrospectives after any critical issue. If someone is not meeting our own performance standard, including being the root or contributing cause of a critical issue(s), we will not hesitate to terminate our working relationship with that person.

Do your employees have to sign confidentiality agreements?

Yes, each and every employee.

Do you have a _____ ethics policy?

No. We‘re guided by our company values and good old common sense. We believe that policies around ethics lead to less ethical behavior.

Would you be opposed to us performing penetration testing on your network/systems?

No, but we‘d prefer you tell us first. Not because we‘ll do anything different but so we‘re not surprised by the slew of bad requests (and the notifications that will go with them) that come from such testing. More importantly, by telling us that you‘ll be testing we can make sure you‘re not mistaken for a spammer and blocked.

How can I report security issues?

Please get in touch with our engineers at to responsibly disclose security vulnerabilities or concerns you have.

Phew! Wow, we can‘t believe you‘re still awake. Kudos to you! If you do have additional questions, please contact us and we‘ll help you out.