Sensitivity of Atlassian support team to confidentiality?

Question

Two days ago I raised a pretty simple question regarding a glitch in the new editor of Confluence Cloud to Atlassian support, which got answered within two hours. First of all I was very happy with the quick and right reaction. I asked a followup question to the support contact in India and got a call on the next day on my phone from him personally. So far so surprisingly good.

But what really irritates me is, that the support guy used my own instance of confluence for testing without letting me know in advance. I understand that Atlassians T&Cs  provision that support may access customers' data, but I was surprised it happened without need and further notice.

The support guy is now "part of my team" according to my system and there are changes in the content history generated by him.

The question I had was pretty straightforward and to my understanding could have been easily tested in any other environment. I'm seriously thinking about how to use confluence cloud for sensitive data like customer projects if others can so easily access the data stored in my wiki.

So the question is: Is this standard behaviour of Atlassian support or was the guy deviating from standard routines in my specific case. Any official position from Atlassian or experiences of other users?

Thanks,

Steffen

Jeremy Largman · Answer

Hi Steffen,

Thanks for raising the question in public in our community; it'll help to keep us honest! I'm one of our support managers, and my remit includes our privacy & trust support. I'll weigh in from Atlassian's perspective on what we're doing about this.

First, after reviewing the ticket, I agree that our support engineer should've tried to replicate in a test instance instead of in your own. I think you realize there wasn't anything malicious there, but your point is that it's not the right first step to troubleshoot. It's worth noting that instances of cloud products may differ given our rollout processes, but generally speaking I agree that in this case it should've been a later step. So for just this question - did we need to access your instance in the first place - I'll make sure we've got that piece covered in our training and follow up with the support engineer.

Second, as for what we do when we access your instance, we agree. It is indeed true that we are meeting our Ts and Cs - more on this below - but that it still doesn't quite seem right that we didn't ask you about accessing your instance first. To address this, we're going to begin to require explicit agreement from a customer in order to access their instance, all in the context of the support ticket. We're looking at ways to make this simple (perhaps a check box when an admin opens a ticket) so we don't have extra steps in the support process for those that don't want that, but the point is that it would be some action on the customer's part to say yes you can go ahead. We're pending getting this out in the next few months.

Lastly, just for posterity, you mentioned our Ts & Cs. I'll just post them here for future reference and describe a bit further how the process works. Our trust center has a section specifically on our privacy policy about accessing customer data:

Within Atlassian, only authorized Atlassian employees have access to customer data stored within our applications. Authentication is done via individual passphrase-protected public keys, and the servers only accept incoming SSH connections from Atlassian and internal data center locations.

And:

Support AccessOur support teams will only access customer data when necessary to resolve an open ticket

Our global support team has access to our cloud-based systems and applications to facilitate maintenance and support processes. Hosted applications and data are only able to be accessed for the purpose of application health monitoring and performing system or application maintenance, and upon customer request via our support system.

Also see our privacy policy.

So the way this works, internally we have a requirement to link support tickets to access requests, and then that access expires after a time limit. We have an audit trail that logs every access to your instance (including our own) and we reconcile this against the support ticket record. A support person can't get access to an instance without an open support ticket recorded against the access session.

Thanks again for taking the time to post and for your well-considered thoughts on the subject. I'll stay tuned here if you have any questions or comments for follow-up.

Darryl St. Pierre · Answer

Steffen,

This is not an uncommon practice with Atlassian, and I've seen the same approach by the app (add-on) vendors. My inclination is to trust them. We've vetted Atlassian as best we could, and we review the T&C and security/privacy information for any of the apps we add.

While it may seem like they could have done any testing or verification in their own environment, they have to take into account what apps you have integrated along with what I expect are a handful of other variables.

That said, I've yet to find actual content changes by Support for any issues I've raised. I have seen user adds and deletes for their technicians, and I have had at least one offer to assist in some cleanup needs I had a while back. I would hope and expect that there are logged entries of any activity performed by them.

Hopefully an Atlassian staff member responds to this thread with an official response, but honestly we wouldn't be here if we didn't trust the company with our data.

Hope that helps.

Darryl