Security & Compliance
In This Blog
What is Field-Level Security in Jira?
Field-level security is the ability to control who can view or edit individual custom fields within a Jira issue, independently of the project and issue permissions already in place.
In a standard Jira configuration, access control works at the project and issue level. A user who has permission to view an issue can see everything on it: every field, every value, every piece of data attached to that issue. There is no native mechanism in Jira to restrict a specific field to a subset of users while keeping the rest of the issue accessible to the broader team.
Field-level security adds that missing layer. Each custom field can be assigned its own view permissions and edit permissions, applied by user, group, or role. A user who opens an issue sees only the fields they are authorized to see. Fields they are not authorized to view show the field label but the value is withheld. Admins can alternatively configure a masked display for fields where acknowledging the existence of a value is appropriate without revealing the underlying data.
The result is a single Jira issue that presents different information to different users, based on their role and authorization, without duplicating the issue or splitting the workflow across multiple projects.
Why Jira’s Native Permissions are not Enough
Jira’s permission model is well-designed for what it was built to do: control access to projects, issues, and workflows. For the majority of Jira use cases, project-level and issue-level permissions are sufficient.
The gap appears when teams use Jira to manage workflows that contain genuinely sensitive data alongside general project data. This happens across virtually every department that adopts Jira as an operational platform.
HR teams run onboarding, offboarding, and performance review workflows in Jira. Those workflows contain compensation figures, performance ratings, and employee personal data that should be visible only to specific HR roles and line managers, not to every project member.
Legal teams track contract disputes, regulatory filings, and external counsel engagements in Jira. Issues contain settlement amounts, privileged notes, and legal risk classifications that must be restricted to authorized legal roles while other workflow data remains accessible to broader stakeholders.
Finance teams manage budget approvals, procurement workflows, and cost allocations in Jira. Budget figures and approval thresholds need to be visible to finance management without being readable by every team member with project access.
IT and service desk teams handle tickets that include internal diagnostic notes, vendor credentials, and system access details that should never be visible to requesters or third-party vendors with portal access.
In each case, the standard workaround is to create a separate restricted project for sensitive data, move confidential information to internal comments, or remove fields from screens to reduce visibility.
These workarounds solve the immediate problem but create new ones: duplicated workflows, fragmented issue context, maintenance overhead, and in the case of screen configurations, a false sense of security. Removing a field from a screen does not restrict access to its data through the API, exports, or the issue navigator.
Field-level security addresses the root cause rather than working around it. Sensitive fields are secured in place, within the workflow where they belong, without requiring structural workarounds.
Related reading:
- Common Jira Field Security Mistakes (And How to Avoid Them)
- What Happens When Field-Level Permissions Don’t Exist
The Three-Layer Security Model: Where Field-Level Control Fits
Understanding where field-level security sits within Jira’s overall security architecture helps clarify what it does and does not replace.
Layer 1: Project permissions. Controls who can interact with a project at all. Who can view it, create issues, edit issues, and manage workflows. This is where most admin configuration lives and where the majority of Jira’s access control is applied.
Layer 2: Issue security schemes. Allows restriction of specific issues to defined users or roles. Useful for high-sensitivity tickets where the entire issue needs to be hidden from certain users. Operates at the issue level, not the field level.
Layer 3: Field-level permissions. Controls what individual users can see or edit within an issue they already have access to. This is the layer that most Jira instances do not have, and the layer that matters most for teams managing sensitive data within shared workflows.
These three layers are complementary, not alternatives.
A well-governed Jira environment uses all three: project permissions to control who can access workflows, issue security schemes for high-sensitivity tickets, and field-level permissions to govern sensitive data within issues that authorized users can access.
Without Layer 3, any user who can view an issue sees every field on it. With it, access to sensitive field values is governed at the appropriate level of granularity, regardless of the broader project and issue permissions already in place.
Related reading: Controlling Field Visibility in Jira: The Security Layer Most Teams Overlook
How Field-Level Security Works in Practice
View permissions and edit permissions
Field-level security applies two distinct controls to each custom field: view permissions and edit permissions. These are configured independently, which matters for workflows that require asymmetric access.
View permissions define which users, groups, or roles can see a field’s value. Users without view permission see the field label but the value is replaced with “You don’t have permission to view the value.” Admins can alternatively configure a masked display, which is useful when acknowledging that a value exists is appropriate without revealing the underlying data.
Edit permissions define which users, groups, or roles can modify a field’s value. A user who has view permission but not edit permission sees the field as read-only. This is useful for approval workflows, audit fields, and any scenario where visibility is required but write access needs to be restricted to a specific role.
The combination of separate view and edit controls allows for precise, role-specific configurations. A line manager can see a performance rating without being able to change it. A finance director can view approved budget figures without being able to modify them. A compliance officer can read a regulatory finding without being able to alter the record.
Permission assignment
Permissions are assigned at three levels, consistent with Jira’s existing access control constructs:
User-level permissions assign access to specific named users. Useful for small, stable access lists where named individuals are the right scope.
Group-level permissions assign access to Jira user groups. The most common configuration for role-based access, since groups can be managed centrally and updated without modifying individual field configurations.
Role-level permissions assign access based on project roles. Useful for configurations that need to scale across multiple projects without managing permissions project by project.
Dynamic field rules
Static permissions, applied once and applied consistently, handle most use cases. For workflows that require conditional logic, dynamic field rules allow visibility to change based on context: issue type, project, workflow status, or user role.
Examples of dynamic rule configurations:
A compensation field is visible only when the issue type is “HR Request” and the viewing user belongs to the Compensation team. The same field in a general project issue is hidden entirely.
A vendor credential field is hidden until the issue transitions to the “Procurement Review” workflow stage, at which point it becomes visible to procurement roles.
A legal risk classification field is visible to legal roles across all projects, but to project managers only within the Legal Operations project.
Dynamic rules allow governance to follow the workflow rather than requiring admins to maintain a static permission configuration for every edge case.
Integration compatibility
A common concern when introducing field-level security is whether it disrupts existing Jira workflows. For a solution built on Atlassian Forge, which runs within Jira Cloud’s infrastructure rather than routing data to external systems, the impact on existing workflows is designed to be minimal.
Jira Automation rules that read or write secure fields continue to function. The automation engine operates under admin-level permissions and is not subject to end-user field visibility restrictions.
CSV import and export handles secure fields as part of the standard field set. Bulk operations work as expected for authorized users.
REST API calls made by authorized integrations continue to return field data. Field-level permissions apply at the user level within the application interface, not at the API level for programmatic integrations.
Existing permission schemes remain in place. Field-level security adds a layer without replacing or interfering with project or issue-level permissions already configured.
One area that does require review: existing Jira Automation rules should be audited for interactions with sensitive fields before field-level permissions are considered fully in place. Rules that include field values in notification emails, linked issue descriptions, or webhook payloads may surface restricted values to unintended recipients if they were built before field-level restrictions were applied.
Related reading: Is Your Jira Instance Secure? A Field-Level Security Checklist for Admins
Compliance and Regulatory Applications
For organizations operating under data protection and compliance frameworks, field-level security in Jira addresses requirements that project-level permissions cannot meet.
GDPR
GDPR’s data minimization and purpose limitation principles require that personal data is accessible only to users with a legitimate need. For Jira environments that contain personal data in custom fields, project-level permissions do not satisfy this requirement when an issue contains both personal data and general workflow data visible to all project members. Field-level view restrictions applied to personal data fields are a direct implementation of the data minimization principle within Jira.
SOC 2
SOC 2 Trust Services Criteria CC6 requires logical access controls that restrict access to sensitive information based on the principle of least privilege. A Jira environment where all users with issue access can see all field values, including sensitive ones, is a control gap that SOC 2 auditors will identify. Field-level permissions implement least-privilege access at the data level within Jira.
ISO 27001
ISO 27001 Annex A Control 8.3 requires information access restrictions aligned to an organization’s access control policy. Custom field data in Jira falls within the scope of this requirement, and access to it needs to be governed by the same policy framework as other information assets. Field-level permissions provide the technical enforcement mechanism for that policy within Jira.
HIPAA
For healthcare organizations using Jira for operational workflows adjacent to clinical systems, HIPAA’s Security Rule requires appropriate technical safeguards for electronic protected health information. Workflows that touch patient-adjacent data, system access management, or clinical operations benefit from field-level access controls that restrict sensitive operational data to authorized roles.
The audit trail requirement
Access control is only half the compliance requirement.
The other half is demonstrability: being able to show, during an audit, who had access to sensitive fields, when values were viewed or modified, and that access was appropriate throughout the audit period.
Field-level audit logs provide this evidence layer.
When an auditor asks for documentation that access to specific sensitive fields was restricted to authorized users, field-level logs provide a specific, timestamped record. That documentation is what distinguishes a controlled Jira environment from one that is assumed to be controlled.
Related reading:
- From Permissions to Compliance: Aligning Jira Field Security with Regulations
- What Regulated Industries Get Wrong About Jira Security
- How Healthcare Teams Can Protect Patient-Adjacent Data in Jira
- Why Financial Teams Are Running Sensitive Workflows in Jira
Use Cases by Team
HR Operations
HR workflows in Jira typically mix general workflow fields, issue status, assignee, due date, with fields that are genuinely sensitive: salary, performance rating, disciplinary notes, termination reason, and personal employee data.
With field-level security, HR teams can run complete onboarding, offboarding, performance review, and compensation workflows in a single Jira project. Sensitive fields are restricted to the HR roles and line managers who need them. General workflow fields remain visible to coordinators and stakeholders who are part of the workflow but do not require access to the sensitive data. No separate projects, no offline spreadsheets, one authoritative record per employee workflow.
Legal and Contract Management
Legal teams track cases, contracts, regulatory filings, and disputes in Jira. Issues contain a mix of workflow data visible to project managers and finance stakeholders, and privileged data, settlement amounts, legal risk classifications, privileged correspondence, that must be restricted to legal roles.
Field-level security allows legal teams to collaborate on cases within a shared project while maintaining strict control over privileged and confidential fields. Access to sensitive legal fields is restricted by role. Audit logs provide the access trail that legal and compliance teams require for matter management and regulatory purposes.
ITSM and Service Desk
IT service tickets frequently contain a mix of data appropriate for different audiences: issue description and status visible to requesters, internal diagnostic notes and configuration details restricted to agents, and sensitive system credentials or escalation details visible only to senior engineers or security staff.
Field-level security in Jira Service Management allows a single ticket to serve all three audiences simultaneously. Requesters see their request and its status. Agents see the operational fields they need to work the ticket. Restricted technical fields are visible only to the roles authorized to access them. No workaround tickets, no internal comment conventions, one ticket with visibility calibrated to each role.
Finance and Audit
Finance workflows in Jira handle budget approvals, procurement sign-offs, cost allocations, and financial reporting workflows. Budget figures, cost centre data, and approval thresholds need to be accessible to finance management and approvers without being visible to every project member.
Field-level security applies view and edit restrictions to financial fields based on role. Finance management sees and can edit budget figures. Project managers see approved totals but not underlying cost detail. Audit teams have read access to financial fields for review purposes without edit access that could compromise the audit trail. The workflow stays in Jira. The access is governed at the appropriate level.
Implementation: How to Get Started
Step 1: Inventory sensitive fields
Before configuring any field-level controls, identify which custom fields across your Jira instance contain sensitive data. Useful categories to assess: personal data (names, contact details, employment information), financial data (salary, budget figures, cost allocations), legal and privileged information (case details, settlement amounts, counsel correspondence), system and credential data (access details, configuration information), regulated data (any information subject to GDPR, HIPAA, SOC 2, or other applicable frameworks).
For each identified field, note which projects it is active in and which user groups currently have issue access in those projects.
Step 2: Define access rules
For each sensitive field, define who should have view access and who should have edit access. Map this to existing Jira groups and roles where possible. Avoid creating new permission constructs unless necessary: using existing groups keeps the configuration maintainable and aligned with your broader user provisioning process.
Identify any fields that require dynamic rules, where visibility needs to change based on issue type, workflow stage, or project context. Note these separately for configuration after the static permissions are in place.
Step 3: Apply field-level permissions
Configure field-level view and edit permissions for the priority fields identified in Step 1. Start with the highest-risk fields: the ones that have prompted duplicate projects, offline spreadsheets, or compliance concerns. Validate the behavior across the relevant user roles before extending the configuration to additional fields.
Test the unauthorized user experience in the issue view, board view, backlog, and issue navigator to confirm that restrictions behave consistently across all Jira surfaces.
Step 4: Audit existing automation rules
Before considering the implementation complete, review all Jira Automation rules that interact with projects containing newly secured fields. Identify rules that include field values in notification emails, comments, linked issues, or webhook payloads. Update or scope those rules appropriately to prevent restricted values from surfacing through automation pathways.
Step 5: Establish governance
Assign ownership of field-level security configuration. Define a process for reviewing new custom fields against the sensitive data classification criteria before they go live. Establish a schedule for reviewing field permissions as teams change and roles evolve. Ensure that field-level audit logs are retained for the period required by your applicable compliance frameworks.
Related reading: Is Your Jira Instance Secure? A Field-Level Security Checklist for Admins
Frequently Asked Questions
Does field-level security replace Jira’s existing permission model?
No. Field-level security extends Jira’s permission model to the field level. Project permissions, issue security schemes, and workflow conditions remain in place. Field-level permissions add a further layer of control within issues that authorized users can already access.
Can field-level permissions be delegated to project admins?
Yes. Global guardrails can be established by the Jira administrator, within which project admins can configure field permissions for their specific projects. This allows local governance without requiring central IT involvement for every permission change, while maintaining consistency across the instance.
Does field-level security work with Jira Automation?
Yes. Jira Automation rules continue to function with secured fields. The automation engine operates under admin-level permissions. The one area requiring attention is existing rules that surface field values in notifications, comments, or webhooks: these should be reviewed to ensure they do not inadvertently expose restricted values.
What do unauthorized users see when they encounter a restricted field?
By default, the field label is visible and the value is replaced with “You don’t have permission to view the value.” Admins can alternatively configure a masked display, which shows a placeholder value rather than the permission message. This is useful when acknowledging the existence of a value is appropriate without revealing its content.
Does field-level security apply to Jira Service Management?
Yes. Field-level permissions work within JSM projects, allowing admins to configure different field visibility for agents, requesters, and other roles within a single service ticket.
Is field data encrypted?
With Secure Custom Fields for Jira, sensitive field data is encrypted at rest and in transit using AES-256 encryption. This applies to the stored field values, independent of the interface-level access controls.
Where is the field data stored?
Secure Custom Fields for Jira is built on Atlassian Forge, which means all data stays within Jira Cloud infrastructure. No data is routed to or stored on external servers.
Get Started with Field-Level Security in Jira
Secure Custom Fields for Jira adds true field-level view and edit permissions, configurable data masking, AES-256 encryption, and audit-ready access logs to Jira Cloud. It is built on Atlassian Forge, runs within your Jira Cloud infrastructure, and works with your existing Jira Automation rules, CSV workflows, and REST API integrations.
Teams across HR, Legal, Finance, ITSM, and regulated industries use it to manage sensitive and non-sensitive data in a single Jira issue, with access calibrated to each user’s role and authorization.
See how it works: watch a short demo
Download the one-pager: Protect Sensitive Data in Jira with Field-Level Security