How Atlassian uses Jira to manage risks and compliance obligations - Part 1

[#1]

Who am I?

My name is Guy Herbert and I am part of the Risk and Compliance team at Atlassian.  I have been with Atlassian for about 5 years and have worked in Risk and Compliance for over 25 years.  George Totev is the head of our team and we have a great group of people that work to make Risk and Compliance a fun place to be.  Our team is pretty small (Brad Coons, Nick Deitz, Nick Miller and Raul Lucky) but we make up for that with enthusiasm and crazy ideas.  We all love talking about what we do and take great pride in the feedback we get from the teams that we support (they say that we are not as boring as they thought we would be).  

The background

At Atlassian we believe that information is better shared and so our Governance, Risk and Compliance (GRC) tool is open to everyone.  We also believe that a GRC tool needs to be flexible enough to handle the changes in our organisation without going back to the vendor to incorporate those changes.  When we first started to manage risk at Atlassian we looked at a few of the tools that were out there and they did not really do what we wanted - so we put our risks in Jira as a way to track them.  Our project has grown organically over time, adding new issuetypes as we realised that we needed to track something more.  And we have changed the approaches on somethings as we have gone along.  Where we are now is pretty stable - we make minor changes to workflow - but nothing major.  

Two of the reasons that I love using Jira for Risk and Compliance management is that it is really flexible - I can get our admin to make changes and they are able to do that - and the second is that anyone can access the information - creating a filter is super easy and then putting that on a dashboard is a 5 minute task.   

This is a project in our existing Jira instance - it is likely to be a project in your existing Jira instance as well instead of setting up a new instance for the GRC.  To avoid unintended consequences of field changes we use custom fields for some of the GRC specific information.  We try to use standard fields as much as possible because we can then take advantage of standard functionality - due date is a good example of this.  

What type of Project?

We use a service desk project. The reason was that we wanted to provide a service desk for anyone to be able to raise a risk and bring it to our attention.

Create the issuetypes

Within the project create each of the issuetypes:

• Risk
• Risk Driver
• Policy
• Standard
• Control objective
• Control activity
• Control test
• Finding
• Remediation
• Exception
• Control activity performance
• Documentation request

Create the custom fields

These are the fields that the GRC uses to hold information on each of the issue types.  There are quite a few and some of the them have lots of options so I have put them in a jpeg to make it easy to access. 

Coming Next

The workflows that we used for the issuetypes, covered in Part 2 of this series.

Hope that you are enjoying the journey so far. We would love your feedback and questions in the comments below.

Thanks,

Guy 

[Danny Gershman]

Are there definitions for each of the issue types and examples of what they translate to?

[Guy]

Part 2 has all the information about the fields, workflows etc.

[Leandro Barreto [e-Core]]

Thanks for sharing, it was really helpful!! :) 

[Nesia]

Hello Guy - would like to chat with you about using Jira as a GRC tool mostly for SOX purposes at this stage. How can I get in touch with you?

[Guy]

Nesia - absolutely - we love to share. email me at guy@atlassian.com

[Janice Barbieri]

Hi Guy, Would you be available to chat? I'd love to know more about how you & the team use JIRA as a GRC tool, the change management process, and Altassian's Controls Framework. 

Janice

[Evan]

Hi Guy, looking at your control domains it looks like you used a tweaked version of ISO 27001 control domains. How did you arrive at this and did you map ISO to SOC 2 using the files produced by AICPA https://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/mappingsrelevanttothesocsuiteofservices.html or with another method? 

[tsvenbla]

@Guy , do you have any demo on how this works at Atlassian? I would be tremendously interested to implement something similar in our organization. If I'm not mistaken, this URL (http://riskmanagement.atlassian.net) was supposed to be a demo, but it doesn't allow me to see anything.

If there is no demo available, would you mind sharing pictures of what information each issue type contains? For example, do you store the whole standard control requirement in the Standard issue type? Do you keep all information in the same project, or have you split up each issue type in its own project?

[Pavol Harvanka]

@Guy 
I am also very interested in details of how this works.

Not just the workflow, but how you choose to use the listed fields with their respective options.

Some of them are easy to understand, others not so much.

Very helpful would be also screens of which fields are displayed in each issue type - just knowing the fields without the Jira issue type (workflow domain) is not sufficient to me.

Now there are template suggestions in Jira when creating a new project. That should make it possible to package this.  You have written in part 2 that you are looking for ways to package this concept - is it still the case?

Or are you instead trying to make this a new Atlassian solution that will be sold separately and that is why you don't wish to share anymore? 

Here are the above 2 pictures converted to tables if you are like me and need to make notes/changes while planning the implementation.

https://docs.google.com/spreadsheets/d/1iSBH1G2aeq-fhHTCJiafISmYmQtgMEgCwI6YucrN_os/edit?usp=sharing

[Guy]

@Pavol Harvanka  We looked at turning this into a product and as an org decided against it. This has sort of reached the limit of my technical knowledge - I will see if I can find someone that can help with screens/transitions and fields to help you.

[Brian Hill]

Interesting, thanks @Guy - whilst Atlassian might have discarded the idea of developing as a product, doesn't mean others in ecosystem aren't interested. Assemblient have been watching and considering the merits of productising some of these patterns given our client base in RegTech, had held back a bit knowing Atlassian could apply some effort into the space and blow anything we'd developed out of the water, so we'd be interested in hearing from others wanting a packaged offering here.

[Pavol Harvanka]

Thanks much @Guy , 

Help with understanding how you work with all these fields within the workflows would be very much appreciated. 

I am glad that you are alive and well still with Atlassian.
I wasn't sure because you have not responded on the forum for a while - based on info from your profile.

[RSavage_stellarindustrial_com]

It would be create if you created a template for security and compliance.