Security & Compliance
In This Blog
Most Jira field security gaps aren’t the result of negligence.
They’re the result of reasonable decisions made under constraints: time pressure, limited native options, and workflows that grew faster than the governance around them.
The mistakes below are common precisely because they make sense at the time. Each one solves an immediate problem while creating a larger one downstream. If any of these patterns look familiar, you’re not alone; and the fix is more straightforward than dismantling what you’ve already built.
Mistake #1: Treating project-level permissions as field-level security
This is the most widespread one. A team realizes that certain fields contain sensitive data, so they restrict the entire project to a smaller group of authorized users. Problem solved. Except now the people who need to collaborate on the non-sensitive parts of the same workflow can’t access the project at all.
The response is usually one of two things: either the project gets opened back up (and the sensitive fields are exposed again), or a second project gets created specifically for the restricted data. Neither outcome is what anyone wanted.
Project permissions control who can access an issue. They were never designed to control what an authorized user can see within that issue. Conflating the two forces a false choice between collaboration and confidentiality: a choice that field-level security removes entirely.
Mistake #2: Using internal comments to store sensitive data
Internal comments in Jira are invisible to customers and portal users, which makes them feel like a secure container for sensitive information. In practice, they’re not a security control — they’re a visibility filter with no access governance, no audit trail specific to the data, and no enforcement mechanism.
Anyone with “View Issue” permission and the ability to see internal comments can read everything stored there. There’s no way to restrict an internal comment to a specific role or group. And if your audit requirement is to demonstrate that sensitive data was accessible only to authorized users, internal comments give you nothing to show.
If data is sensitive enough to hide from some users, it needs a proper access control, not an informal convention.
Mistake #3: Duplicating projects to isolate sensitive workflows
The duplicate project workaround is understandable. You need HR or legal data to live somewhere that isn’t visible to the whole team, so you create a parallel project with restricted access. It works, technically. But it immediately creates a maintenance problem.
Two projects for the same workflow means two sets of issues to keep synchronized, two places to look for the authoritative record, and two sets of boards, filters, and automation rules to maintain. As the workflow evolves, the two projects drift. Context gets lost. Work gets duplicated. And at some point, someone has to reconcile which project has the correct version of a given record.
The root cause is always the same: there was no way to protect individual fields within a single issue, so the entire issue had to be moved somewhere else. Field-level security eliminates the need for the workaround by securing the fields in place.
Mistake #4: Relying on screen configurations to hide fields
Jira screen configurations control which fields appear on create, edit, and view screens. Removing a field from a screen is not a security control, it’s a UI configuration. A user who knows the field exists can still query it via the REST API, find it in issue exports, or see it in the issue navigator if the field has a value.
Screen configuration is useful for reducing clutter and guiding users toward the fields relevant to their workflow. It is not a substitute for access control. If a field contains data that shouldn’t be visible to certain users, removing it from a screen doesn’t protect the data, it just makes it slightly less convenient to find.
Mistake #5: Assuming automation rules won’t expose restricted data
Jira Automation is powerful, and most admins use it extensively. The mistake here isn’t using automation. It’s not considering what happens when automation rules interact with fields that are supposed to be restricted.
A common scenario: an automation rule sends a notification or creates a linked issue that includes field values from the original issue. If the rule was built before field-level restrictions were in place, it may be surfacing restricted values in notification emails, linked issue descriptions, or external webhooks to users who were never supposed to see them.
Reviewing automation rules for unintended data exposure is a step that most field security implementations skip. It’s worth doing before assuming that field restrictions alone close every gap.
Mistake #6: No audit trail for sensitive field access
For teams in regulated industries, access control is only half the requirement. The other half is demonstrability: being able to show, during an audit, who had access to sensitive fields, when they accessed them, and whether any changes were made.
Most Jira configurations that rely on project permissions, screen configurations, or informal workarounds have no field-level audit trail. If an auditor asks for evidence that salary data was accessible only to HR, “we restricted the project” is not the same as “here is a log of who viewed and edited that field.”
Implementing field-level security with audit-ready access logs addresses both requirements simultaneously: the control and the evidence.
Mistake #7: Leaving field security as a future project
This one isn’t a technical mistake, it’s a timing one. Field security gets added to the backlog, where it sits until an audit, a data incident, or a compliance review moves it up the priority list.
The cost of waiting is rarely obvious until something goes wrong. Retrofitting field-level security onto a mature Jira instance — with established workflows, complex automation rules, and years of accumulated field data — is significantly more work than implementing it proactively. Migrating existing custom fields to secure field types, auditing automation rules for exposure, and reconfiguring project structures takes time that an urgent compliance deadline doesn’t allow.
The right time to implement field security is before it becomes urgent. Not because the implementation is difficult, but because doing it under pressure increases the risk of getting it wrong.
The pattern underneath all of these mistakes
Every mistake on this list is a variation on the same problem: Jira’s native permission model doesn’t extend to individual fields, so teams improvise with the tools they have. The improvisations work well enough until they don’t: until an audit, a data incident, or a scaling team exposes the gap.
Field-level security doesn’t require rebuilding your Jira environment. It adds the missing layer of control to the fields that need it, within the workflows already running, without disrupting the automation and integrations already in place.
Secure Custom Fields for Jira adds true field-level view and edit permissions to Jira Cloud so sensitive data stays protected without the workarounds.