On 25 May 2018, the most significant piece of European data protection legislation to be introduced in 20 years will come into force. The EU General Data Protection Regulation (GDPR) replaces the 1995 EU Data Protection Directive. The GDPR strengthens the rights that individuals have regarding personal data relating to them and seeks to unify data protection laws across Europe, regardless of where that data is processed.
PII data obtained through billing would only be used by us, in relation to the service(s) the customer has purchased from us. We track and record name/email address of all customers making purchases with us directly, as part of the transaction. We are legally required to retain history of such transactions for 7years, that includes email traffic, quotes, invoices, purchase orders, in addition to order-related spread sheets. Where 3rd parties require details of our activities relating to sales (accounting) , personal details are removed.
This is the largest area. We have a cloud version of the Enterprise Mail Handler for Jira Cloud (JEMHC) that processes email from customer mailboxes and drives issue creation/update in customer Jira instances.
JEMHC on installation gets the billing contact user email address, we use this to populate the JEMHC > Licensing > System Notifications > Email Addresses field. This field is CSV, and is maintained by the Jira instance administrator not us. We do not have functional access to your data to make changes. We have a back office system that exposes basic system contact details to us. JEMHC mails out to this list every month a status email summarizing JEMHC usage, if there is any.
JEMHC uses credentials you supply (user/password) in order to retrieve mail from, and send mail through your specified mail servers, we don't use this in any way beyond that scenario.
JEMHC uses tokens you supply for Hipchat and other notifications, we don't use these in any way beyond that scenario.
JEMHC can retain copies of incoming and outbound emails, for short-term auditing and fault-finding by the Jira instance administrator. The Jira instance owner can opt out of this entirely. We can only gain access to 'inbound' emails when the Jira instance administrator flags such messages for Support, in such cases the senders full email content would be available to us for support purposes.
JEMHC system email notifications are sent through our (Plugin People) mailbox, which tends to retain a copy in 'sent' items. We don't use this in any way.
JEMHC system statistics are periodically reviewed and sometimes notice particular customers instances having problems in some way (excessive maintenance mail typically). We do try to proactively reach out to customers directly based on the limited information available. We don't currently have an opt-in. Not being able to be proactive because of GDPR seems a bad thing, and is likely to be detrimental to customers usage of JEMHC (e.g. you may consume your Plan Capacity much sooner than you expect, resulting in system not operating as you would like).
JEMHC Database is backed up daily on a rotating schedule, we retain 7days of history.
JEMHC Subscriptions must remain licensed and active to be retained in our database. Once lapsed, you'll loose access to JEMHC functionality interactively and through scheduled jobs. After 30days JEMHC automatically purges ALL retained data about your instance. On expiry, JEMHC does nothing to your Jira instance, the data that was sent through JEMHC resides in your Jira instance, and is owned by the instance owner.
JEMHC tracks system throughput, we retain Atlassian host URL references indefinitely, as they form part of aggregated usage over time, no PII is involved.
JEMHC software build validates core data processing functionality through unit tests. Due to the complexities of email, sometimes we use customer emails that have been made available to us, sometimes the data is left untouched (eg sender name and email address). The data we collect is very limited, and it must be provided by the customer in the first place. We do not use this data in any other way beyond testing. The email content, along with our source code, is stored in source control. Due to source control, it will be retained indefinitely.
The online shop hosted with http://www.e-junkie.com (privacy statement here) and the payment processor https://www.paypal.co.uk/ (privacy statement here) that enables purchasing of DataPacks for JEMHC. We are copied by email on all Data Pack purchases with transaction details and information from the PayPal user account (including registered name, email, IP). For tax reasons we retain all communications relating to purchases for 7 years.
Operationally, and this is the tricky point. JEMHC receives email from ANYONE, maybe a Jira registered user, maybe a Portal user, maybe an email user who has never even heard of Jira. In the latter case, its probably expected by the sender, that their email address would be used to communicate back to them (e.g. a support response), and in order for that to happen, the email address (and possibly name, and additional email recipients) would need to be retained (stored on the issue), but we have no way to request permission to store their data. This only applies to EU senders but its impossible to accurately determine.
Do We process personal data?
Can We assist my company with responding to an Individual Rights Request (Subject Access Request)?
Yes, where data is 'owned' by us (part of billing, part of support). In cases where data is not owned by us we will still help. Typically data stored by JEMHC will be 'owned' by the customer, for whom we may have limited contact capability. Data JEMHC 'uses' can also be 'owned' by Atlassian such as the Billing Contact for the subscription to JEMHC.
Where do We store and send customer data?
Today, we store data in data centers located in the US.
Can you host customer data in the EU?
Not yet, In the future, when the platform supports it (there can only be one deployed JEMHC application at this time) we hope to store EU customer data into an EU data center.
How do We handle onward transfers of data outside of the EU?
This applies to JEMHC only, in a few parts:
Email: The system sends a variety of email to involved parties, located anywhere. Messages that aren't processed are forwarded to JEMHC instance admins, any or all could be located outside the EU. The delivery of such email is done using the onward mail server system that the JEMHC instance administrator has defined, typically secured by SSL.
Files: If the JEMHC administrator configures External Storage it is possible for JEMHC to enable Jira users to store attachments in remote cloud storage. Users with access to the issue can download resources related to that issue through that issue. Different mechanisms for accessing downloaded resources exist (e.g. "time-limited-validity multi-use links", or streamed content delivery). Such delivery is always done over an SSL protocol link.
Logs: JEMHC application generates logs, we can retrieve these remotely, but even in that case, the logs have been obfuscated in terms of PII (email subjects and the vast majority of email addresses are hashed - non happy-path scenarios may show up email addresses to aid diagnosis)
Can I opt out of having customer data collected or shared?
JEMHC needs email addresses in order to function. When an Issue is created, email addresses are stored in the issue, either through the reporter or in a custom field. When issues are closed out, the reporter/email address remains. Management of the Jira instance is not Our responsibility. JEMHC Instance administrators such as ourselves would routinely retain such information in order to better support the customer by being able to understand prior problems.
JEMHC instance administrators can control whether auditing is on that would cause recent email content to be retained within JEMH for a short time (100 records).
JEMHC supports a per-issue unsubscribe feature, enabling email users to self-remove themselves on a per-issue basis. System notifications also have a per-recipient unsubscribe feature.
How do We secure customer data?
We break this down into the various sections:
Data is stored in cloud servers, secured by SSL. Access is named party only.
All communication between JEMHC and Jira cloud is also done over SSL. All Outbound SMTP mail can be sent over SSL but every mail hop beyond cannot be guaranteed to be SSL, same in reverse for inbound IMAP/POPs/EWS traffic.
JEMHC audit data is encrypted and stored in a database not directly accessible to the Internet. Sensitive configuration data fields are encrypted within the database.
Customer email addresses for non-account holders can be stored in plain text, visible to anyone who can view the issue or retrieve the issue through REST. This is more a data privacy issue for the Jira instance administrator than us as the JEMHC service provider.
As part of support we encounter customer data regularly in the form of Email content that has processing problems. Such information is shared by the JEMHC customer in confidence, on behalf of the sender for the sole purpose of diagnosing processing problems and improving JEMHC's ability to handle such messages. That information is not shared with 3rd parties, and not retained by us for any reason. We will manufacture test data as needed to replicate customer problem scenarios for internal testing purposes.
External Storage: As part of support ticket lifecycle, we automatically purge all issue-files when an issue is resolved. We are considering extending this to include actual issue attachments as well, such that all JEMHC customers can do the same, if desired.
Jira attachments: TODO, as part of our support ticket lifecycle, we will be implementing features within JEMHC to enable attachment data to be expired after a certain amount of time, ie, giving such data a guaranteed lifespan in our system. We won't delete comments or issues as this is needed to trace recurring customer problems.
How You want to change and remove your information or to ask for it not to be used
JEMHC lists contact email addresses in the System Notifications section (its CSV), but have left the related company and continue to be notified of JEMHC specific aspects (e.g. usage alerts, monthly status etc). Such notifications now include an unsubscribe feature, allowing recipients to remove themselves without involving the instance owner (who we may not be able to contact either, due to limited contact details being available).
JEMHC Profiles contain a Forward user email address. Potentially that user could leave the company and want to be forgotten. We do not configure customer instances. Again the same problem we have is that in order to even communicate with the business we need to get more contact information about the Jira instance, than we currently have access too. Sometimes even the billing contact is a dead end, in such cases, even Atlassian has in the past been unable to help. We have discussed this with Atlassian and logged it as a scenario affecting us.
JEMHC needs to implement a simple unsubscribe feature that will remove the sender from a given issue, or opt out for automated emails: