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).
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.
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.
Within the project create each of the issuetypes:
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.
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.