Table of Contents
The problem
Jira’s permission model is built around two controls: who can access a project, and who can see a specific issue. For most workflows, that coverage is enough.
For teams managing sensitive data inside Jira issues, it is not.
When a user has permission to view an issue, they see every field on it. Compensation figures in an HR issue. Settlement amounts in a legal case. Budget thresholds in a finance approval. Vendor credentials in an IT service ticket.
Jira has no native mechanism to show certain fields to some users and withhold them from others within the same issue.
The result is a permission model that stops at the container level — the project, the issue — and leaves everything inside the container equally visible to anyone who gets in.
What happens without field-level control
Jira administrators handling this gap typically land on one of three workarounds. Each solves the immediate problem and introduces a new one.
Separate projects for sensitive data. A restricted project keeps sensitive workflows away from the broader team. It also creates a synchronization problem: two projects for the same piece of work, two sets of automation rules to maintain, and a fragmented record that becomes harder to govern as workflows evolve.
Internal comments for confidential notes. Internal comments are invisible to portal users but have no access governance. Anyone with issue access and internal comment visibility can read them. There is no field-level audit trail, and no enforcement mechanism beyond convention.
Screen configurations to reduce visibility. Removing a field from a screen hides it from the interface. It does not restrict access to the underlying data through the REST API, CSV exports, or the issue navigator. It is a UI decision, not a security control.
None of these workarounds constitute field-level access control. In a compliance review, none of them provide the evidence that access to specific sensitive fields was restricted to authorized users.
How Secure Custom Fields for Jira extends the permission model
Secure Custom Fields for Jira adds a third layer of control to Jira’s existing permission architecture: field-level permissions, applied directly to individual custom fields, independent of project and issue permissions already in place.
Each field gets its own view permissions and edit permissions, configured by user, group, or role. A user who opens an issue sees only the fields they are authorized to see. For fields they are not permitted to view, the field label is visible but the value is withheld — displaying “You don’t have permission to view the value.” Admins can alternatively configure a masked display, useful when acknowledging the existence of a value is appropriate without revealing the underlying data.
View and edit permissions are configured independently. A line manager can see a performance rating without being able to modify it. A finance director can view approved budget figures without being able to change them. A compliance officer can read a regulatory finding without being able to alter the record. The level of access is determined by the field, not by the issue.
The configuration integrates with what is already there. Permissions are assigned using existing Jira groups and roles — no new user management constructs are required. Jira Automation rules continue to function. CSV import and export handles secured fields as part of the standard field set. REST API integrations are unaffected at the programmatic level. Existing project and issue permission schemes remain in place; field-level permissions add a layer rather than replacing what is already configured.
Project admins can be delegated local permission management under global guardrails set by the Jira administrator — so governance scales across teams and projects without every change requiring central IT involvement.
The compliance dimension
For organizations subject to GDPR, SOC 2, ISO 27001, or HIPAA, field-level permissions address a specific gap that project-level controls leave open.
GDPR’s data minimization principle requires that personal data is accessible only to users with a legitimate need. SOC 2’s CC6 criteria require least-privilege access controls for sensitive information. ISO 27001 Annex A Control 8.3 requires information access restrictions aligned to organizational access control policy. In each case, the requirement is not satisfied by project membership alone when an issue contains a mix of sensitive and general data visible to all project members.
Field-level permissions implement least-privilege access at the data level within Jira. Combined with field-level audit logs (a timestamped record of who viewed or modified each sensitive field) they give compliance teams the controls and evidence layer their frameworks require, without those controls living outside the workflows where the data is generated.
What this looks like in practice
A single Jira issue can contain both general workflow fields (status, assignee, due date, task description) and restricted fields (salary figures, legal notes, budget thresholds, or system credentials) with each user seeing only what their role authorizes.
The HR business partner sees the compensation fields. The line manager sees the performance summary but not the salary. The IT coordinator sees the provisioning tasks but not the HR notes. The legal stakeholder sees the case timeline but not the settlement amount. Everyone works in the same issue. The data governance is enforced at the field level.
The workaround projects, the offline spreadsheets, and the screen configuration approximations become unnecessary. The permission model extends to where it was always needed: the individual field.
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.