Security & Compliance
In This Blog
Most Jira administrators don’t go looking for a field security problem. They find it because something happened: a user saw data they shouldn’t have, an auditor flagged a gap, or a team lead asked why salary figures were showing up on a shared board.
By then, the workarounds are already in place. A duplicate project here. An Excel tracker there. Sensitive fields stripped out of issues and managed offline. The workflow is fragmented, the data is split across tools, and nobody is particularly happy with the arrangement.
Field security matters because the gap it addresses isn’t theoretical; it shows up in the daily friction of teams trying to do real work with sensitive data inside Jira.
The assumption that causes most of the problems
When Jira admins configure a project, they typically set up permission schemes that control who can view issues, who can edit them, and who can transition them through a workflow. That’s the security model most teams rely on, and for most data, it works fine.
The assumption underneath it is: if you can see the issue, you’re authorized to see everything on it.
That assumption holds until it doesn’t. The moment an issue contains a mix of general project data and something genuinely sensitive: a compensation figure, a legal settlement, a vendor credential, a patient-adjacent note, the assumption breaks down. Everyone with issue access sees everything, regardless of whether they need to or whether they’re authorized to.
This isn’t a configuration error. It’s a design boundary.
Jira’s permission model was built to govern access to issues and projects, not to individual fields within them. Working around that boundary is where things get complicated.
What teams actually do about it, and why it creates new problems
When teams run into this wall, they adapt. The adaptations are understandable, but each one introduces a new set of problems.
Separate projects for sensitive data. The most common workaround. A team creates a restricted project specifically for sensitive information, then tries to maintain some link between the sensitive project and the main workflow. The result is duplicated effort, broken context, and issues that are never quite in sync. Auditing becomes a question of which project has the authoritative version.
Internal comments instead of fields. Some teams move sensitive data into internal comments or description fields with an informal “restricted” label. This is security through convention, not configuration. There’s no enforcement, no access log, and no way to prove to an auditor that the data was actually restricted.
Spreadsheets and external tools. Pulling sensitive data out of Jira entirely and managing it in a spreadsheet or a separate system is common, particularly in HR and legal teams. It solves the visibility problem but destroys the operational benefit of having everything in one place; and creates its own data governance questions about who has access to the file, how it’s backed up, and how it connects back to the Jira workflow.
Every one of these workarounds is a symptom of the same underlying gap. And they all make the admin’s job harder: more systems to maintain, more places for data to drift, more surface area to explain during an audit.
Where the risk is real
For some teams, this is an operational inconvenience. For others, it’s a compliance exposure.
In healthcare, workflows increasingly run through Jira: onboarding, IT service requests, operations. When those workflows touch any data related to patients or employees, access control isn’t optional. It needs to be demonstrable and auditable.
In financial services, Jira is used for deal tracking, regulatory workflows, and internal approvals. Budget figures, counterparty details, and approval thresholds sitting in openly visible custom fields are a routine audit finding waiting to happen.
In regulated industries broadly: insurance, government, pharmaceuticals; The question isn’t just “who can see this?” It’s “can you prove who could see this, and demonstrate that access was appropriate?” That requires access controls at the field level and logs to support them.
Even outside regulated industries, the risk is real.
Employee performance data, contractor rates, client-specific pricing, and M&A-related information all pass through Jira at organizations where Jira is the operational backbone. The assumption that project-level permissions are sufficient doesn’t hold up once you look at what’s actually in the fields.
What field security actually protects
Field-level security doesn’t replace Jira’s existing permission model, it extends it downward, to the field level. The two layers work together:
- Project and issue permissions control who can access the issue at all.
- Field-level permissions control what those users can see and edit within the issue.
A user who can view an issue will only see the fields they’re authorized to see. Fields they don’t have access to aren’t shown as blank, they simply aren’t rendered. A user who can view a field but not edit it gets a read-only view. These controls apply per user, per group, or per role, and they persist through Jira Automation, CSV exports, and API calls.
The practical outcome: a single issue can hold both general project data and restricted sensitive data. The right people see what they need to. Nobody sees what they shouldn’t. The issue stays intact, the workflow stays intact, and there’s an audit trail to prove it.
The moment it becomes urgent
For most teams, field security moves from “nice to have” to “need to have” at a predictable moment: the first time they have to explain their Jira configuration to an auditor, a security review, or a new compliance requirement. At that point, “we use project-level permissions” isn’t a sufficient answer.
The earlier that gap gets addressed, the less disruptive it is. Retrofitting field security onto a mature Jira instance is significantly more work than building it in from the start, or migrating to a structured solution before the audit arrives.
Secure Custom Fields for Jira adds field-level view and edit permissions directly to your Jira custom fields. No scripts, no duplicate projects, no workarounds.