Playbook definition

[josip gomez]

Hello to everybody,

I would like to use Jira Service Management for managing incident response activities. I've defined some use case playbooks in which I defined all the actions that must be performed and the teams responsibles for that action. I would like to know which is the best way that I could do this thing in Jira SM. I've seen that it is possible to define workflows that are made of status and transitions. I've seen that there are also issues and I'm not really understanding the links between all the available component.

For let the things easier I would give you an example. I'm a manufacturing company and I want to manage vulnerabilities inside my products. A customer reports a vulnerability. I would have to do a preliminary triage performed by one team, then if the vulnerability is confirmed I would have to produce a patch and this will be performed by another team. By looking at the template workflow status (open, work in progress, closed, etc.) it seems that every activities will be managed by a workflow. So in the example above, I would have a workflow that manage the preliminary triage, that once it is completed will trigger the mitigation activity that will be another workflow. Is it correct or I can manage all the activities and the teams by one workflow? In this way I will have to create a workflow for each playbook that I have to defined. 

Thanks in advance,

Josip

[Jack Brickey]

What is best is always highly influenced by what works best for you and your team. However let me give you some input that might help you decide.

first if you have two disparate teams, one that does the triage and maybe a development team that would do the patch then often the best option is to use your service management to interface with a customer and triage and then if a patch needs to be formed a linked issue to Jeera software would be created so the development team can create the patch. However if it’s all really one tight team then a single workflow and issue should be fine.

in the case of a single workflow it may look something like this…

To Do - In Progress - Done

                                  - Awaiting Patch - Done

your actual WF will certainly vary.

[josip gomez]

Thank you Jack. We defined in our playbook 6 different use cases each of them composed by four phases: preliminary triage, risk assessment, risk treatment and incident closure. Inside every phase there are specified activities performed by different teams. So, I will have the above status (to do- in progress - done) for every phase. Moreover, I don't know how to move forward activities when one is finished.

[Jack Brickey]

To be honest there’s a lot to unpack here to get to the best solution. I’ll share some questions and thoughts with you below that might help steer you in the right direction. Ultimately my ability to give you a definitive solution is not possible in this forum.

• Do you want or need to maintain communication on the original ticket with the customer? Moreover do you want to separate out any development work from that ticket? If so then I definitely would go with different issues at a minimum if not different projects. That is, you would have a project or issue associated with the customer and any internal activities associated with development would be separate.
• do you have or will you have Jira software or are you thinking of doing everything inside JSM? Keep in mind that anyone that needs to work on a JSM project will require an agent license. JSW might be a better option for the development aspects of your workflow.
• if you have separate issues regardless of whether they’re on the same project or not then you can use the link feature to ensure all issues are linked to the original ticket.

again, without really diving in and understanding your business I don’t feel comfortable in giving you a direct answer here

[josip gomez]

I start with explaining better the process: 

we have to manage six use case related to vulnerabilities and incident that may happen to almost 10 different categories of product component. For every use case it is present a playbook that says what action must be done and by who. The action are grouped in 4 main phases:

1. When a security event happen the first thing to be made is to verify is the security event is a false positive or not. This can be carried out always from the same team.
2. Once that this phase is concluded, an incident handler team is formed based on the use case and in the product involved. A more detailed assessment is done.
3. Then, there is the mitigation phase where other teams may be involved.
4. Finally the incident closure where reports are made.

I would like to automate all this playbook directly from the Jira SM. A possible solution will be the one of creating the following status: open - preliminary assessment - detailed assessment - mitigation - closure - closed. The problem is that in every use case the actions and stakeholders are different. 
So, I don't know if it is better to create this 6 state for every use case, so I can be specific in the definition of the actions and the teams involved (e.g. team A must perform this action and when it is finished team B must do this thing) or I can use just a workflow compose of that 6 state and every time that an incident occurs the stakeholder and the action will be manually inserted following the defined playbook available in a word document.  

In my idea I would like to do something like in the picture below, where all the action are defined:

Regarding your questions:

1.  I don't always need communication with the customers. In the playbook there will be just a notification to the customer when the incident is closed. Moreover, not only the customer can open a ticket, but it can be done internally for example after a vulnerability assessment
2.  The development work is required if a patch will be needed. If that happens, we have Jira Project Management software. Our idea was to open from Jira Service Management a ticket in Jira Project Management and when the mitigation activity is over notify Jira SM and go forward with the playbook.
3. Regarding the question about different issues I don't know the answer, because I don't know which is the best solution as described above.