Topic
- Security & Compliance
Featured Apps
Table of Contents
The problem
HR teams use Jira to manage some of the most sensitive data in the organization: compensation figures, performance ratings, termination details, medical disclosures, and personal employee records. These workflows require collaboration: line managers, IT, legal, and finance all have legitimate roles in onboarding, offboarding, and performance processes.
The problem is that Jira’s permission model doesn’t distinguish between what a user can access and what they should see. A line manager added to an HR issue to complete their onboarding tasks can also read the employee’s salary, performance score, and any confidential HR notes on the same issue. There is no native way to separate those fields.
The workaround most HR teams land on is a restricted project for sensitive data. It keeps the salary field away from unintended eyes, but it also means maintaining two parallel records for the same employee workflow: one for the sensitive fields, one for the general tasks. That synchronization overhead grows with every new hire, review cycle, or departure.
How Secure Custom Fields for Jira addresses this
Secure Custom Fields for Jira applies view and edit permissions directly to individual custom fields, independent of project and issue permissions already in place.
An HR issue can contain both general workflow fields (onboarding task status, assigned IT coordinator, equipment provisioning checklist) and restricted fields (salary, performance rating, termination reason, medical disclosure) within the same issue. Each user sees only the fields their role authorizes.
A line manager working the onboarding tasks sees the workflow fields. The salary and performance fields are present on the issue but the values are withheld — displaying “You don’t have permission to view the value.” The HR business partner, with the appropriate permissions, sees everything. If acknowledging that a field exists without revealing its value is preferable, admins can configure a masked display instead.
View and edit permissions are configured independently. A line manager reviewing a performance rating can be given read access without write access. Only the HRBP can update the score. That asymmetric control is configured at the field level, not worked around through separate projects or manual access reviews.
What this means in practice
A single Jira project handles the complete HR workflow. Compensation, performance, and personal data are governed at the field level. General workflow fields remain visible to the collaborators who need them. There are no parallel projects to synchronize, no offline spreadsheets carrying sensitive data outside Jira, and no informal conventions about which fields “shouldn’t be shared.”
Field-level audit logs record who viewed or modified each sensitive field. When an internal review or data governance assessment asks who had access to compensation data during a given period, the answer is in the log; not reconstructed from project membership records.
The compliance dimension
For organizations subject to GDPR, employee personal data is subject to the data minimization principle: accessible only to users with a legitimate need. A Jira configuration where all project members can view compensation and personal data fields does not satisfy that principle when those members include roles with no business need for that information.
Field-level permissions implement least-privilege access at the data level within Jira. Combined with field-level audit logs, they give HR and compliance teams the access controls and evidence their data governance frameworks require; without those controls sitting outside the workflows where HR work actually happens.
Secure Custom Fields for Jira adds field-level view and edit permissions, configurable data masking, AES-256 encryption, and audit-ready logs to Jira Cloud. Built on Atlassian Forge. Your data stays within Jira Cloud infrastructure.