Hey there - Sounds like an interesting use-case.
There are certain configurations that can help here to support this, as you balance one experience across the different Teams.
Certain configurations, such as below can be tailored to the different Teams sharing the SIR Application:
- Playbooks
- Form views
- SLAs
- Metrics
- Scoring Calculators
- Reports, Dashboards
- etc.
Whereas, other configurations would be suggested to stick to the same configurations - think about technical debt, consistent reporting, normalized data here...
- State models
- Category, Sub-Category choices
- Source choices
- List Category on the SIR Workspace (UX)
You can investigate adding a new Form Section to the Security Incident Table, and have it dynamically shown / hidden for certain conditions, if the Teams need different data points / objects.
For PAD (Process Automation Design) Playbooks - the benefit here, is you can have different Playbooks for the Different Teams and their flavor of Work .. it is condition driven...
"Restrictions" is where this may get interesting
- Would really evaluate your requirements, and look at the need to actually restrict the SIR data between the Teams
- Though it might be possible in a few different ways, it will introduce overhead and potentially some technical debt
- Security Tags (SecOps Feature) have an interesting component of access restriction that can help - would suggest taking a look at what is there today for Traffic-Light Protocol (TLP) - to get an idea of how the restriction can work - as a reference for one approach
