Jira as ISMS and GRC

[Pavol Harvanka]

Our company is in the process of formalizing an ISMS to later apply for ISO 27001 certification.

While searching for suitable ISMS tool, I have stumbled onto the below youtube video and articles by atlassian's (former?) security Guy:

https://community.atlassian.com/t5/Agile-articles/How-Atlassian-uses-Jira-to-manage-risks-and-compliance/ba-p/896891

https://community.atlassian.com/t5/Agile-articles/How-Atlassian-uses-Jira-to-manage-risks-and-compliance/ba-p/896891

https://youtu.be/FvjhskeEg_M

The presentation on youtube convinced me that Jira+Confluence would be the best choice for our company. However Guy stopped responding to questions a while back and there are some open questions - the provided data on community forum isn't really exhausting. Just a rough cut to setup main things in Jira.

I  would like to know if anyone is operating ISMS based on setup from Guy or own setup and if they can share their view of pros / cons for Jira as an ISMS and/or GRC tool and how to best get started.

Ideally, more support from atlassian would be welcome - if they document this better or even package a solution, it could be a very good selling proposition.

I am aware of some companies that sell confluence addons in atlassian market - I may ultimately use some of these, but my question is mainly about Jira as ISMS and GRC tool/platform.

[Alice White]

Great question and option for a future product offering!

At a company I previously worked at (large Aussie Telco) the Quality and Security team partnered, to start the ISO27001 certification journey. I managed the ISO9001 certification, which ISO27001 borrows from. We had a few requirements already 'certified' as part of ISO9001 Quality Management System audit and just pointed to the evidence provided in the last audit. We thought the most simple way to start would be to setup a Confluence space for ISO27001 with all the requirements as child pages and started developing responses to each requirement. Each requirement had a status allocated (something like Non-Compliant, Partially Compliant & Compliant), we could see the gaps, JIRA cards were created for Stakeholders who needed to contribute (drives transparent accountability) and were linked back to Confluence. Evidence (PDF of meeting minutes or spreadsheets) could also be added to the Confluence page to demonstrate the requirement. JIRA tracked the timelines and milestones of the project and reporting to Execs was based on % of requirements met + overdue responses or evidence + proposals to meet the requirements or risk accept partial compliance status.

One of the main reasons we set it up like this was actually for the Auditor. It makes the Auditors experience and review more streamlined and hopefully easy for them to say yes! The Auditor had all the pre-populated responses available before arriving on site (or zooming-in these days!). They could print the pages they wanted as evidence and get on with interviewing stakeholders and management teams. 

Another important thing to note is that the company's employees were pretty fluent with both the Confluence and JIRA products and their functionality. Not sure this would have worked so well if this wasn't the case.

One more consideration is grouping 'like' requirements from multiple compliance frameworks, if it's not just ISO27001 Certification that you're focused on attaining. This would be especially advantageous if you work in/or provide products and service to regulated industries. The Atlassian Trust Team works with the Atlassian Control Framework team to group all the 'like' requirements across many compliance standards.

[Elena Radu]

Hi Alice, thank you for sharing some tips!

We're doing something similar and to manage multiple compliance frameworks, we created different projects whose issues we map/link to each other. Is this similar to what you did? 

Another question I have relates to risk management (incl. acceptance). Here we struggle a bit due to increased linked issues, which makes it difficult for risk owners to assess a risk. How do you document your risks?

[Alice White]

Hi Elena, no a problem, happy to share.

You approach sounds very similar, mid you my recollection is a bit hazy as it was 5+years ago.

Documenting risk is usually very company specific. Some of the companies I've worked for have 100+ page documents about how to document and risk-rate risks for 6 different types of consequences/impacts. Atlassain's Enterprise Risk Management program is modeled after ISO31000-2009 "Risk Management - Principles and Guidelines".

I think you're also asking about your risk owners being concerned about aggregate risk, if there are lots of linked risk events or issues, to a top level risk. That's a tricky one, especially if risk issues are duplicated across multiple business units but actually represent the same risk to the company. Sounds like a deep dive might need to be done to recommend a way to bubble up aggregate risk.

[Elena Radu]

Hi Alice, thanks a lot for your answer! Would it be possible to discuss with you via a DM? 

[Roger Barnes]

Hi Pavol,

I explored the possibility of a more streamlined/opinionated GRC system built upon Jira and Confluence last year. Unfortunately that exploration didn't go on for further development at the time.

I do hope we'll return to the idea at some point, as it has merit. In the meantime the existing material, community support and some Atlassian Solution Partners that advertise GRC solutions would be your best bet to customise Jira and Confluence. There are a few risk and compliance pros from Atlassian checking in here from time to time also.

[Tom Kakanowski]

I have nothing concrete to add for you, but we are already using Confluence/Jira as part of our ISMS model and use this to support our continued ISO27001 certification, so I too am interested in what I might learn in this thread.