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

[#1]

This is the second instalment on how Atlassian manages our risks and compliance obligations using Jira.  

In Part 1 we created the issue types and the custom fields - now we need to create the workflows and the screen transitions.

Create the workflows

We really tried to keep the workflows simple for all the issuetypes.  The reason was that we often found ourselves clicking through workflow as a way of evidencing that work had been done - when the actual work had happened in a meeting with the business teams.  If you need to add steps to evidence approval then put them in - but consider using comments as a way to make that easier on yourselves.  

Risk and Risk driver

Policy

Standard

Control Objective

Control Activity

 

Control Test

Finding

Remediation

Exception

Control activity performance

Documentation request

 

Workflow scheme information

Create the workflow transition screens

We tried to keep the information requested at each of the transitions really simple.  We also made most of it non mandatory - the reason was that we wanted to get people using the system and capturing information - we then reported on the missing data and used that as an excuse to go and talk to people about their risks and controls.  

WorkflowTransitionScreenFields

GRC_Control Activity Workflow	Activate	GRC_Control Activity Activate Screen	Summary
			Description
			GRC_Compliance
			GRC_Owner
			ACF Domain
			ACF Sub-Domain
			GRC_Control Type
			GRC_Control Effective Date
GRC_Control Test Workflow	Verified	GRC Control Test Verified Screen	Summary
			Description
			Result
			GRC_Conclusion
GRC_Control Workflow	Activate	GRC Control Activate Screen	Summary
			Description
			GRC_Compliance
			GRC_Owner
			AFC Domain
			AFC Sub-Domain
GRC_Exception Workflow	Approved	GRC Exception Approve Screen	Compensating Control
			Policy Type
			Policy Name
			Linked Issues
			Reporter
			Assignee
			Owner
			Due date
GRC_Policy Workflow	Approve	GRC Policy Approve Screen	Assignee
			Labels
			Department
			GRC_Owner
			Policy Type
GRC_Risk Workflow	Active	RM Risk Active Transition Screen	Required Fields
			Summary
			Description
			GRC_Decision
			GRC_Risk Domain
			GRC_Owner
			GRC_Inherent Likelihood
			GRC_Inherent Impact
			GRC_Inherent Score

Coming next

We will be sharing information on the control objectives that we have and how we went about building them - we have really enjoyed the risk and compliance journey so far and want to share our travel stories. 

We hope you enjoyed this piece and would love to hear your risk and compliance stories as well.  

[David Pinn]

Since I don't have access to {{hello.atlassian.net}}, I'm not seeing the images on this post. Is it just me?

[Guy]

Thanks for pointing that out - fixed

[njbuch]

I am missing some of your thoughts on where to have the asset repository, all risks are related to some type of asset, right?

[Guy]

We have our asset repository in another Jira project and we link to those where we think it is appropriate.  At the moment we don't have a strong linkage between them - the risks are higher level than that in the GRC project.  We do more at the team level and the control activities for that team.

[Andrew Millward]

Hey Guy. This is awesome, thanks for sharing :) Quick question - what's the background behind having a different risk and risk driver issue type? Is the idea to abstract the causes of a risk from the risk event, so each cause has a set of controls?

[Sharon Connell]

Hi Guy,

Thanks for sharing the set up. Can you share reporting you find most helpful?

[njbuch]

Hi again, I have been working on this and I am still wondering if you can share the overall GRC landscape you have deployed at Atlassian. These two post focus on some of the fundamental processes around risks, but I am still wondering where the documentation is, how the policies related to specific processes, and how the new employees are introduced to this. Its seems very substantial, and there are a lot of custom fields for very custom purposes - over to say it differently, do you anything more overview focused? 

[Guy]

Will do a couple of posts in the new year to talk about the general background of how we manage risk and compliance and how we report what we have in the data.  Great feedback and thanks

[njbuch]

Im interested in seeing how people actually interact with for example Control Activity issue type. To generate Control Activity Performance or Finding... how elegantly can that be made?

[Eric Mortenson CISSP]

Great presentation. Looking forward to future posts that you mention in the Dec 13 post especially the reports.

[Sahar Shayestehmehr]

Hi Guy, thanks for the great articles. Here are a few questions:

1) Are the custom fields and workflows that you've listed in the two articles already exist in the Jira instance for customers, or is this something that needs to be built/customized for each customer?

2) Are the "GRC_Compliance", and "GRC_SOC2 Common Criteria" or other control objectives from various compliance frameworks (e.g. ISO 27001, PCI) already populated in Jira?

3) Are there any other resources (e.g. white papers, guidance docs) available for implementing the "Atlassian Manages Risk and Compliance" project in Jira/confluence?

Thanks!

[Guy]

Everyone - thanks for the questions - I know that I have been a bit quiet - but lets fix that.

Andrew - We created a set of fairly generic risks - if you get too specific on these you end up with a million risks and people saying - no, my risk is a bit different to that.  The risk drivers were a way for us to look closer at what factors go into the risks.  Still a bit of a work in progress there.

Sharon - yes I will - a later post as it really is a combination of Jira and Confluence - and it iterates as well.  Probably later this month.

Niels - I will do a post on this - realised you are so right - needs context.  Again - probably this month - but might be early March.

Sahar - 

1. the fields are custom fields - but your admin can create them - you don't need anyone outside to build anything.
2. We have them in our instance - but due to licencing problems we are not sure how to share these (ISO as an example is something that is owned by someone else)
3. At the moment no - but we are developing playbooks to help with that.  If you have an admin looking after your instance they would be able to take our custom fields and workflows and implement them.  The - how do we use it is also coming - probably after after the 2 blogs above.

[Brian Hill]

Watched this get presented in your Summit2019 preview last night - really enjoyed it. As a CISA, I appreciated the hard work that's gone on behind the scenes in keeping this a transparent activity across Atlassian and the focus on simplifying. Worth noting that the Control Objectives referenced are from SOC, Sarbanes Oxley, but could equally be from COBIT, ISO27001, HIPAA etc - as you noted in your presentation, they're CSV based and = import candidates into JIRA.

[Guy]

Something that is really important and I am not sure that I have highlighted - when you bring in a new compliance obligation DON'T create a whole new set of control objectives. 

Bring it in as a compliance obligation and then work out which existing control objectives map to the new obligation. 

For obligations not covered by existing control objectives - create the new control objective and then go back out to the teams to see if they have a control activity that covers it.  

[Brian Hill]

@guy - all well and good until you spend time working across a range of the different standardisation models for IT Governance/Control and start wrestling with the cross mappings or overlaps that are evident across ITSM/COBIT/SOX/SOC/HIPAA/ISO2700-n. If you've tackled that element, will be interested to hear how you did it.

[Andrew Millward]

@Brian Hill Might be worth looking into the Common Controls Hub as it helps with that. You select what regulations/frameworks you want to comply with and it spits out a set of relevant control objectives and the mappings. They have a free preview available on their website: https://commoncontrolshub.com/overview/.

[Mike Tocci]

Since nobody else has the guts to admit to laziness...could this fantastic workflow be available as a template??

[Jesper Reenberg]

@Guy interesting work. I know you are probably busy, but any update on the follow up articles, you referred to, should have been published in late Feb and Mar? :-)

[Frank Weltlich]

@GuyIs there a mapping of fields for the create screens. Which fields are relevant? I assume not all fields are relevant for every tcket type.

[Guy]

I wish that we had a way to template this - we are working on it. In the meantime - sorry but that is all we have. For the mapping of fields to screens - will find out what we can generate and let you know.

And I am working on the other blogs (have had some risk and compliance work to do as well). 

[mburgess]

I would love a template or plugin for this

[Jenny Hagstrom]

Hi,

@Guy Have you managed to create a white papers, guidance docs? 

At the moment all fields, screens, workflows are implemented in my Jira service desk. But Im lacking information on how it all should be connected in the project. What Im after is there any WoW for implementing the CRTs in Jira service desk?

[Shuichi Sakai]

Thank you for sharing these two blog posts @Guy 

Is the risk heat map (risks mapped onto the risk matrix) that was shown in the presentation a custom gadget that you created? 

[jimmi.handoko]

@Guy thank you very much. currently looking for a solution for RCSA and found this might be very helpful instead of acquiring new application.

[Guy]

@jimmi.handoko It takes about a half a day for an experienced Jira admin to set up the fields, flows and screens. After that the work is in creating your obligations and objectives - and spending time with the teams to understand their control activities. But you will have to do that with any tool that you purchase (even ones that promise all the data is already there).