nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

JSM PCI-DSS Certification & Sensitive Data Vaults - EAP & Co-design

Ash Young

Hi Community 👋

I'm Ash, a Product Manager on the Jira Service Management (JSM) team. We're looking for customers to help shape how JSM handles payment card data and other sensitive information.

JSM will be pursuing our own PCI-DSS certification so we can provide you with a Attestation of Compliance (AOC)

The problem we're exploring

Some service teams need to collect sensitive details as part of their work. This includes payment disputes, refunds, card replacements, identity checks and contact centre escalations. Today, if you capture card numbers or other sensitive data in a standard JSM field, that data is stored in JSM. That can bring your service desk into your PCI-DSS assessment scope. As a result, many teams either keep these workflows out of JSM or rely on manual workarounds.

What we're exploring

We're investigating a tokenisation-first approach. The goal is to keep raw sensitive values out of JSM entirely. Early concepts include:

Secure fields for card numbers and other sensitive data (for example, government IDs or account numbers). The value is turned into a token before it reaches JSM.
Secure file uploads for sensitive documents and images.
Masked by default. Agents see a masked value, such as •••• 4242, and only people with permission can reveal the full value.
Audit logs that record every reveal, to support your compliance evidence.
Coverage across the portal, the agent view and the API.

The aim is to help you meet your PCI-DSS obligations whist using JSM.

Who we'd love to talk to

JSM Cloud customers, or customers evaluating JSM Cloud, who handle cardholder data or other regulated personal data in service workflows
Financial services, retail, payments, insurance, telecommunications, travel and other regulated industries
IT, security, compliance and service desk leaders, plus JSM admins who manage these workflows
eCommerce companies looking to manage their support/refunds/disputes processes.

How to get involved

Sign up for our early access program here
We'll reach out to show you some early experiences to validate and build towards your compliance requirements
You'll also be given early access to our Sensitive Data Vaults features in preparation for PCI-DSS certification

Also leave us a reply here!

What type of sensitive data your service teams handle today
Where that data comes in (portal, email, phone or API integrations)
How you deal with it today, and what's not working

Look forward to hearing from you soon!

Comments

Viswanathan Ramachandran

Looks like a promising initiative. 😀

However, I like to know where will be the vault hosted and who will control it?
- do you have inbuilt vault or integrated 3rd party vault?
What do you mean by reveal by here operationally?
What happens to existing data and how they are handled?

re:
What type of sensitive data your service teams handle today

In my previous company, need to handle sensitive data like credentials stored in plain text 😂

Where that data comes in (portal, email, phone or API integrations)

Manual input, attachments

How you deal with it today, and what's not working

using 3rd party to monitor and then remediate the information, later remove them and recommend alternative options like passvault to store the sensitive data. What's not working is way to user's stop entering the data. We educate them not to store sensitive data, we have a announcement banner, we conduct workshops, CoP and we only action it to remove the sensitive info.

Ash Young

@Viswanathan Ramachandran Sharing more on our plans

However, I like to know where will be the vault hosted and who will control it?
do you have inbuilt vault or integrated 3rd party vault?

We are to provide JSM Sensitive Data Vaults by using PCI-DSS compliant "data privacy vaults" with a 3rd party vendor that holds their own independent PCI-DSS Certification (AoC). This is an industry recognised certified approach with auditors.

Atlassian will also undergo our independent PCI-DSS Certification to obtain our standalone AoC as well.

Atlassian retains full control of the vault and customers retain the rights to this data (storage/destruction/access)

We are looking to make the sensitive data vaults compatible with Atlassian's Data Residency regions

What do you mean by reveal by here operationally?

When we refer to reveal in this context - JSM would only ever hold non-reversible tokens and your users would be able to on-demand detokenise sensitive data from vaults for their specific workflow.

This "detokenisation" process is what we refer to as reveal. An additional note is - the data is never stored on JSM during and after this reveal process, confirmation from the user is captured and access is logged to ensure strict compliance.

What happens to existing data and how they are handled?

We are still working on this solution and your insight/expectations would be helpful here. We initially building the experiences for a new JSM service desk and new tickets being created - but also recognise that customers would have historical tickets and data to manage.

If you were to adopt this feature, what existing data would you need to manage and what are your expectations for a migration process?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

compliance

jira-service-management

regulatory-compliance

data-compliance-atlassian

pci