Security & Compliance
In This Blog
For most Jira administrators, field-level security starts as an operational problem. A team is managing sensitive data in Jira: salaries, legal details, financial figures, and the native permission model isn’t granular enough to protect it. The immediate goal is straightforward: stop the wrong people from seeing the wrong fields.
That’s a reasonable starting point.
But for organizations operating under data protection regulations, the conversation doesn’t stop at access control. It extends into a set of questions that compliance teams are already asking: What data are we storing? Who can access it? Can we prove that access was appropriate? And what controls are in place to prevent unauthorized exposure?
Field-level security in Jira addresses all of these questions; but only if it’s implemented with compliance requirements in mind, not just operational convenience.
Why Jira is increasingly a compliance surface
Jira started as a developer issue tracker.
Over the past decade, it has evolved into the operational backbone for teams across HR, Legal, Finance, IT, and beyond. That expansion is one of its strengths: a single platform where cross-functional teams coordinate work.
It’s also why Jira has quietly become a compliance surface for many organizations.
When HR tracks onboarding and performance reviews in Jira, employee personal data lives in Jira. When Legal manages contract disputes and settlement negotiations in Jira, privileged information lives in Jira. When Finance runs approval workflows in Jira, budget figures and cost allocations live in Jira.
The data governance requirements that apply to that information don’t disappear because it’s stored in a project management tool. GDPR doesn’t exempt Jira issues. SOC 2 auditors don’t skip Jira when reviewing access controls. ISO 27001 doesn’t carve out exceptions for custom fields.
If sensitive data lives in Jira, the controls protecting it need to meet the same standard as the controls protecting sensitive data anywhere else in your environment.
What the major frameworks actually require
The specific requirements vary by framework, but the common thread across GDPR, SOC 2, ISO 27001, and HIPAA is access control at the appropriate level of granularity, paired with the ability to demonstrate that control.
GDPR requires that personal data is accessible only to those with a legitimate purpose; the data minimization and purpose limitation principles. For Jira, that means a user’s ability to view an issue shouldn’t automatically grant them access to every personal data field on it. Role-based field visibility is a direct implementation of this requirement.
SOC 2 (Trust Services Criteria, specifically 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 flag.
ISO 27001 requires information access restrictions aligned to an organization’s access control policy (Annex A, Control 8.3). Custom field data in Jira falls within scope, and access to it needs to be governed by the same policy framework as other information assets.
HIPAA, for healthcare organizations using Jira for operational workflows, requires appropriate safeguards for protected health information — including access controls that limit exposure to authorized users. Any Jira workflow that touches patient-adjacent data falls within scope of this requirement.
In each case, the requirement isn’t simply “restrict access to the project.” It’s restrict access to the specific data; which means field-level control, not just issue-level control.
The gap between access control and demonstrable compliance
There’s an important distinction between having access controls and being able to demonstrate them.
A Jira admin can configure project permission schemes, restrict issue visibility, and limit who can join a project. Those are access controls, and they’re legitimate. But when an auditor asks for evidence that a specific category of sensitive data (employee compensation, legal settlement amounts, patient-adjacent records) was accessible only to authorized users during a given period, project-level permissions don’t provide that evidence at the field level.
What compliance teams need is a combination of two things: granular access controls applied directly to sensitive fields, and an audit trail that logs who had access to those fields, when values were viewed or modified, and what changes were made.
Without field-level audit logs, the compliance story is incomplete. The control may exist in practice, but it can’t be demonstrated in the way a formal audit or regulatory review requires. That gap between operational control and demonstrable compliance is where organizations get caught.
How field-level security maps to compliance requirements
Implemented correctly, field-level security in Jira addresses compliance requirements at two levels simultaneously.
At the control level, per-field view and edit permissions enforce least-privilege access to sensitive data. Each field can be restricted to specific users, groups, or roles — independently of the issue and project permissions already in place. An employee whose role doesn’t require access to compensation data simply doesn’t have it, regardless of their broader Jira permissions. That’s a concrete, enforceable control aligned to GDPR’s data minimization principle, SOC 2’s least-privilege requirement, and ISO 27001’s access restriction controls.
At the evidence level, audit-ready access logs provide the documentation that compliance reviews require. When an auditor asks who had access to a sensitive field and when, the answer is in the log; Not reconstructed from memory or inferred from project membership.
For regulated industries, this combination: field-level access control plus audit trail, is what moves Jira from a compliance liability to a compliant platform.
Encryption as the next layer
Access control governs who can see sensitive field data. Encryption protects that data regardless of how it’s accessed including scenarios that access controls can’t fully anticipate: infrastructure-level access, data exports, or an unexpected exposure path.
AES-256 encryption of field data at rest and in transit adds a layer of protection that access control alone doesn’t provide. For organizations under frameworks that require encryption of sensitive data — HIPAA, PCI-DSS, and increasingly SOC 2 — this isn’t optional.
The full compliance picture for sensitive Jira data requires both layers: access control that enforces who can view field values within the application, and encryption that protects those values at the data layer. Field-level security and encryption are complementary controls, not alternatives.
A practical starting point
For compliance officers and Jira administrators approaching this together, the starting point is an inventory question: what sensitive data currently lives in Jira custom fields, and what are the access control requirements for that data under your applicable frameworks?
That inventory typically surfaces a short list of high-priority fields: compensation data, legal details, PII, financial figures, where the gap between current access controls and compliance requirements is most acute. Those fields are the right place to start: apply field-level view and edit restrictions, verify the audit log captures the required evidence, and confirm that encryption is in place for fields where your framework requires it.
The broader rollout follows once the pattern is established. Field-level security scales across projects and teams without requiring a Jira rebuild. Perrmissions are applied at the field level, not the project level, so existing workflows stay intact.
Secure Custom Fields for Jira brings field-level access control, configurable data masking, and AES-256 encryption to Jira Cloud; Giving compliance teams the controls and audit trail they need, without disrupting the workflows already running.