I want to configure the jira ticketing for Security operation center

[rmanikandan428]

**Subject/Title:**
How to configure escalation from L1 to L2 with fresh SLA restart, same OPEN status, and lock L1 from editing after escalation (JSM)

**Body:**

Hi Atlassian Community,

I'm working on optimizing our SOC (Security Operations Center) ticket workflow in Jira Service Management (Cloud). Currently, we have a somewhat complex workflow with many statuses for escalation, but we want to simplify it while meeting these specific requirements.

**Current Workflow Summary (simplified):**
- Create → OPEN
- OPEN → Active → WORK IN PROGRESS
- WORK IN PROGRESS → Resolved
- WORK IN PROGRESS → Escalate to I2 → ESCALATED
- From ESCALATED: branches into Awaiting L2 Response → PENDING FOR L2 → L2 IN PROGRESS → L2 Closure → RESOLVED
- Also direct Resolved from ESCALATED
- Reopen loops back to OPEN

**What we want to achieve (new behavior):**

1. When L1 clicks "Escalate to L2" (from WORK IN PROGRESS or OPEN):
- Ticket should go to **OPEN** status again (same status, not a new one like ESCALATED)
- SLA should **start fresh** for L2 (L1's SLA stops at escalation)
- Ticket appears in SOC L2 queue as OPEN
- L1 sees it only in an "Escalated Tickets" queue (not in their normal OPEN/WIP queues)

2. After escalation:
- L1 **cannot edit fields, transition, or re-assign** the ticket anymore
- L2 has full control (edit, transition to Active/WIP, Resolved, or Escalate to L3)
- L2 should only see/use these statuses: OPEN, Active/WIP, Resolved (optional: Escalate to L3)
- Comments added by L1 during escalation (internal) and the "Escalated By" field should be visible to L2

3. We already have:
- Custom fields: "Escalate To" (select list: L2, L3), "Escalated By" (user picker), "Investigation reason" (select list)
- Escalation screen attached to the transition
- Automation rule that runs on transition to set fields

**What we've tried / questions:**

- We changed the "Escalate to L2" transition destination to OPEN (instead of ESCALATED) → this helps with queue visibility
- Created a new SLA that starts when "Escalate To" = L2 and field changed
- Set queues with JQL: status = OPEN AND "Escalate To" = L2
- Permission scheme: Edit Issues → Assignee + SOC L2 group only (removed L1 group)
- Workflow conditions: Only Assignee on most transitions + User in group SOC L2 on L2 transitions

**Specific questions / where we need help:**

1. Is reusing **OPEN** status for both new L1 tickets and escalated-to-L2 tickets the best way to get a fresh SLA? Or is there a better trigger (e.g., status = OPEN AND "Escalate To" changed)?
2. How to reliably prevent L1 from seeing/editing escalated tickets in their normal queues, while still showing them in a read-only "Escalated" queue?
3. Best way to auto-set "Escalated By" = the user who performed the escalation (we're using {{initiator.accountId}} in automation JSON — is this correct/reliable)?
4. Any risks/drawbacks of looping back to the same OPEN status on escalation (e.g., SLA confusion, reporting issues, queue overlap)?
5. Recommended way to handle L3 escalation in a similar clean way?

We want to avoid too many statuses (current has ~8–9) and prefer using queues + custom fields + permissions over creating separate statuses for each tier.

Jira version: Cloud
Using: Automation for Jira, custom fields, screens on transitions, separate permission schemes/groups for L1 and L2

Any advice, screenshots, or alternative approaches would be greatly appreciated!

Thanks in advance,
Manikandan
SOC Team

[Matteo Vecchiato]

Hi @rmanikandan428 ,

Thank you for your detailed explanation. 

Obviously reducing the workflow statuses you increase the complexity to calculate the current macro situation; for instance, if you need to calculate how many tickets have been resolved without L2, it is a bit tricky, but it is possible.

To figure out question 2, I would suggest use a group custom field named like "Team assigned" with L1,L2, ... linked to user groups. That field can be used in the permission scheme, in "edit permission".

Hope it helps 

[Arkadiusz Wroblewski]

Hello @rmanikandan428 

Jira Service Management can be configured for a Security Operations team.

I would start with one JSM service project and define a few clear request types such as Security Incident, Phishing Report, and Vulnerability / Suspicious Activity. Then build the setup around queues, SLAs, automation, and restricted visibility where needed.

If alerts from external tools are part of the process, JSM also supports alerts and incident management, so that can be added after the basic ticketing flow is stable.

My advice would be to keep the first version simple and not try to model the whole SOC process in one big workflow from day one.

Step by step.