Security & Compliance
In This Blog
Jira security reviews often focus on the obvious controls: who has admin access, whether SSO is enforced, how user provisioning is managed. Those are important. But for organizations managing sensitive data inside Jira workflows, there’s a layer of security that most reviews miss entirely: what happens at the field level, inside issues that authorized users can already access.
This checklist is designed for Jira administrators and platform owners who want to assess the current state of field-level security across their instance. It covers access control, data protection, governance, and audit readiness. Work through each section and note where gaps exist. The results will tell you where to focus first.
Section 1: Know what sensitive data lives in your instance
Before configuring any controls, you need to know what you’re protecting.
Have you inventoried which custom fields contain sensitive data (PII, compensation, legal details, financial figures, credentials, health-related information)?
Do you know which projects those fields are active in?
Do you know which user groups or roles currently have access to issues containing those fields?
Have you identified fields that were originally created for general use but now hold sensitive values?
Is there a process for reviewing new custom fields before they go live, to assess whether they require access restrictions?
Why it matters: You cannot protect data you haven’t identified. Most field-level security gaps exist in fields that were never evaluated for sensitivity in the first place.
Section 2: Access control at the field level
This section tests whether your current controls actually protect sensitive field data, or whether they rely on workarounds.
Do any sensitive fields have field-level view permissions applied, restricting which users or groups can see the value?
Do any sensitive fields have field-level edit permissions applied, separate from view permissions?
Are you relying on project-level permissions to protect field data, rather than field-level controls?
Are any sensitive fields currently “hidden” using screen configurations rather than access controls?
Do you have duplicate projects or split workflows created specifically to isolate sensitive fields from broader project access?
Is sensitive data being stored in internal comments instead of properly restricted custom fields?
Why it matters: Project permissions, screen configurations, and internal comments are not field security controls. If any of these are your primary mechanism for protecting sensitive field data, the data is not adequately protected.
Section 3: Data visibility and masking
When an unauthorized user opens an issue containing a restricted field, is the field value withheld? (Default behavior: the field label is visible, and the value displays “You don’t have permission to view the value.”)
For fields where acknowledging the existence of a value is appropriate but the value itself must be hidden, have you configured masked display?
Have you tested the unauthorized user experience across different Jira views: issue view, board, backlog, and issue navigator?
Are there any views or contexts where restricted field values are visible to users who should not have access?
Why it matters: Access controls are only as reliable as their implementation. Testing the actual user experience across different views confirms that restrictions behave as expected and that no unintended exposure paths exist.
Section 4: Automation and integrations
Have you reviewed existing Jira Automation rules for interactions with sensitive fields?
Do any automation rules include sensitive field values in notification emails, comments, or linked issue descriptions that could surface data to unauthorized users?
Do any webhook or third-party integration payloads include sensitive field values that are sent to external systems?
Have you confirmed that CSV exports of sensitive fields are accessible only to authorized users?
Are REST API calls that return sensitive field values authenticated and scoped appropriately?
Why it matters: Field-level access controls apply within the Jira interface. Automation rules, webhooks, and API calls can bypass the interface layer and expose field values to unintended recipients if they have not been reviewed.
Section 5: Governance and administration
Is there a defined owner for field-level security configuration across your Jira instance?
Do project admins have the ability to modify field permissions locally, and if so, are there global guardrails that prevent them from over-granting access?
Is there a documented process for onboarding new sensitive fields, including access control configuration as a required step?
When users change roles or leave the organization, is there a process for reviewing and updating field-level permissions?
Are field security configurations documented so that a new admin can understand and maintain them without starting from scratch?
Why it matters: Access controls degrade over time without active governance. Permission configurations that were correct at setup become outdated as teams change, roles shift, and new workflows are introduced.
Section 6: Audit readiness
Do you have field-level audit logs that record who viewed or modified sensitive field values?
Can you produce a report showing which users had access to a specific sensitive field during a given time period?
If your organization is subject to GDPR, SOC 2, ISO 27001, or HIPAA, have you mapped your Jira field security controls to the specific requirements of those frameworks?
Have your field-level security controls been reviewed by your compliance or information security team?
In the event of an audit or data incident, do you have the documentation needed to demonstrate that sensitive field data was appropriately controlled?
Why it matters: For regulated organizations, the ability to demonstrate access controls is as important as having them. Logs and documentation are the evidence layer. Without them, a control that exists in practice cannot be proven in an audit.
Interpreting your results
If most of your answers in Sections 2 and 3 are no, your sensitive field data is currently protected by workarounds rather than controls. The risk is real, and the fix is achievable without rebuilding your Jira environment.
If you have gaps in Sections 4 and 5, your controls may be correct at the point of configuration but leaking data through automation and integrations, or degrading over time due to insufficient governance.
If Section 6 is incomplete, you have controls that cannot be demonstrated. For regulated industries, that is a compliance gap regardless of how well the controls themselves are working.
The most common finding is a combination of all three: some fields are protected, some are not, automation hasn’t been reviewed, and there’s no audit trail. That’s a normal starting point. Field-level security can be rolled out incrementally, starting with the highest-priority fields, without disrupting the workflows already running.
Secure Custom Fields for Jira adds field-level view and edit permissions, configurable data masking, and audit-ready access logs to Jira Cloud. No scripts, no duplicate projects.