How to handle treat sensitive information in Service Portal. PII, PCI, HIPPA information?

Jason_Meyer

Any recommendations/advice on how to handle treat sensitive information in Service Portal.  PII, PCI, HIPPA information?

Adrian_Paech

We have the same challenge,

We were thinking about filtering all jobs in a separate queue associated with our "ICT Security" support group, and then only ICT Security can see those jobs.

Outside of that, I have no idea how you would do it.

Personally im not a big fan of how SCSM / the Cireson Portal is designed from this perspective, its very clunky when it comes to segregating access to objects / work items.

Would be keen to hear what Cireson has to offer here.

Regards,

Adrian

Jason_Meyer

We tried using queues that only certain staff had access to, it works, sort of.  If the ticket gets assigned anywhere else either accidentally or intentionally the information is exposed.

Peter_Settle

Have you though about using a temple specifically aimed at ICT, as when submitted it would automatically assign to the correct group. You would need to advertise it and promote it to your user base correctly, but you should be able to restrict the template fields to read only in order for the calls not to wander off.

Jason_Meyer

Yes, we tried Request Offerings that routed tickets specifically to 'protected' queues, the challenge was we were too 'generic' with the requests and ones with 'sensitive' information would be assigned elsewhere if a different team needed to work on it, thus exposing the data.  Or, the support group didn't know it had sensitive information in the ticket and routed it elsewhere.  I believe we need to be able to do this at the work item level, not the queue, or support group, or customer level.

Jason_Meyer

How are other organizations handling 'sensitive' information with Cireson Portal?

Candice_Yeudall

We are a healthcare organization so everything that we do falls under HIPPA. Initially I tried to set-up security would allow only those who needed to the information access it but of course this is not doable with SCSM and the Cireson portal. It was also suggested to us that we create custom forms that could only be seen by some of the queues which would not work for us our desk never know who the ticket will need to go to before they take the call. We also did not want certain groups of users to have to be Analysis within the portal but still be able to edit tickets that were assigned to their group (again something that we were unable to achieve).

In the end we went with a hope and a prayer that our confidentiality agreements where strong enough and made the Cireson Portal inward facing only.

Tom_Hendricks

We handle incredibly sensitive data as a core part of our business, but do our best to keep it completely out of the system.  Our portal is also internal-facing for this and many other reasons.

What we are left with is that some tickets still need to be handled with discretion and the protected queue approach is really the only one that seems to work (even noting the challenges that @Jason_Meyer mentioned above).  I dislike this intensely, but find it necessary to create different versions of a support team, one secured and one unsecured, if I want to treat the ticket that way.

What I would rather have is fields that are obfuscated on the server-side, that only unlock when authorized users are viewing them.

Adrian_Paech

What I would like to see is the ability to add certain users into an AD group so that when these users access the system they will 'only' be granted analyst access to a ticket when the ticket is assigned to a support group they are a member of, otherwise it will only provide end-user access to the ticket.This would allow for better segregation between tickets, depending on your support group, and prevents end-users from seeing 'private notes', and other extended information unless the ticket is assigned to their support group.

Further to this, I would like to see the ability to mark a work item as 'sensitive'. And this would lock access to a work item, so that is can only be accessed by the assigned support group, not other end-users (except administrators) can access the ticket at all. This would assist with PII, PCI, HIPPA compliance etc.

I have logged a feature request here, if you want to vote, or add other ideas.

https://community.cireson.com/discussion/3003/muliti-tennancy-hippa-compliance-via-more-granular-analyst-access-to-portal-work-items/p1?new=1

Tom_Hendricks

That's not exactly my ideal scenario, but definitely close enough for a +1.  I could live with that process much easier than this one. 

Adrian_Paech

I agree. To be honest, its a bit difficult to come up with an idea that entirely covers what we are all after.. I guess I was looking for a compromise that would probably be fairly easy to implement.