Why this matters for compliance teams
Compliance work runs on structured metadata. Control IDs, evidence references, risk ratings, deficiency notes - all of it needs to live on the work item, in a form that survives sampling and audit. Native Jira’s global custom-field model and absence of field-level security make that structured metadata hard to maintain without polluting the wider site.
For compliance teams, the consequences show up every audit cycle. The control ID is on a label, not a field. The evidence reference is in a comment. The risk rating is in a spreadsheet that drifts from the ticket. Auditor sampling has to reconcile across all of it, and the reconciliation work is the bulk of audit prep.
Custom Fields gives compliance teams the structured, scoped, secured fields the work demands. The field sits on the compliance project. The ‘control deficiency notes’ value is visible only to compliance and audit. The control ID is enumerated, not free-text, so JQL and exports stay deterministic. The wider Jira admin team keeps the global schema clean.
Where this fits in the compliance program
- Control mapping - structured ‘Control ID’ fields on ITGC and SOC 2 projects, scoped and permission-controlled.
- Risk register - enumerated ‘Risk rating’ fields drive the quarterly risk review with a single JQL query.
- Audit prep - per-field exports drop into workpapers without manual reconciliation, and restricted fields keep auditor-only notes off broadly-visible tickets.
What “good” looks like
Good is the auditor’s sample arriving with the control ID attached, the evidence reference in a field, and the risk rating enumerated - all on the ticket. Custom Fields exists so compliance teams can run their program on Jira without fighting the global schema or sacrificing field-level visibility.
What compliance teams are dealing with today
- Adding a 'Control ID' or 'Risk rating' field in native Jira makes it visible across the site, polluting unrelated projects with compliance fields they don't need.
- Field-level security is not native - sensitive compliance fields like 'Control deficiency notes' are visible to anyone with issue access.
- Compliance reports depend on consistent, structured metadata - free-text or shared global fields don't give the discipline auditors need.
- Cross-project compliance views (e.g. all SOX-relevant tickets) require fields that scope cleanly to compliance projects without polluting others.
- Auditors ask for field-level evidence (the control ID attached to a sample ticket); the data is often stored in comments or labels rather than structured fields.
- Field-context configuration in native Jira is shared by reference, so a compliance-specific field tweak risks breaking another project's screen.
How Custom Fields helps compliance teams
Scoped compliance fields
Define fields like 'Control ID,' 'Evidence reference,' or 'Risk rating' on compliance projects only. Other projects' screens stay clean; the global schema doesn't bloat.
Field-level security
Restrict who sees and edits compliance fields - so 'Control deficiency notes' or 'Auditor finding ref' are visible only to compliance and audit, even on broadly visible tickets.
Structured audit metadata
Compliance teams capture control IDs, evidence references, and risk ratings as structured fields rather than free-text. JQL, reports, and exports become deterministic.
Auditor-ready exports
Per-field, per-project exports drop into workpapers. The auditor sample includes the structured field data, not a free-text reconstruction.
Schema discipline across the org
Compliance teams get the fields they need; the global Jira admin keeps the site-wide schema manageable. The two no longer have to negotiate every field add.
Use cases
- SOX control-ID tagging on ITGC sample. Compliance team adds 'SOX control ID' to change-management projects, restricted to compliance view. Q4 ITGC sample exports cleanly to workpapers with the control ID attached.
- SOC 2 evidence-reference field. Compliance project tickets carry an 'Evidence ref' field linking to the SOC 2 evidence repository. Field is visible only to compliance and audit; the wider team sees the ticket but not the reference.
- ISO 27001 risk-rating field. Risk register tickets carry a 'Risk rating' field with a defined enumeration. JQL queries by risk rating drive the quarterly risk review.
- HIPAA-relevant ticket flag. Compliance team adds a restricted 'PHI-touched' boolean field on IT-operations tickets. Field is editable only by compliance; visible to compliance and security; supports HIPAA scoping during audit.
Common questions from compliance teams
Why can't we just use native Jira custom fields for compliance metadata?
Native Jira custom fields are globally defined and shared by reference. Adding a 'Control ID' field for compliance often makes it visible across unrelated projects, and tweaking the field context risks breaking other project screens. Custom Fields scopes compliance fields to the projects that need them and adds field-level security - so compliance metadata stays compliance-scoped.
Can we restrict who edits a compliance field?
Yes. Field-level permissions are set per field, by user, group, or project role - separately for view and edit. A 'Control deficiency notes' field can be editable by compliance only, viewable by compliance and audit, and hidden entirely from the ticket reporter and engineering team. The surrounding ticket remains visible normally.
How does this help with audit prep?
Audit prep depends on structured metadata. When the control ID, evidence reference, and risk rating are on the ticket as structured fields, the auditor's sample comes with the metadata attached - no manual reconciliation. Without structured fields, compliance teams reconstruct the same metadata each audit cycle from comments, labels, and external spreadsheets.
Will field-level security affect Jira search?
Field-level security applies consistently to JQL, exports, and the issue view. Users who don't have view permission on a field do not see the field's values in any of those surfaces. JQL queries against the restricted field return no values for those users - which is the expected behavior. Search performance is not measurably affected.
Try Custom Fields for your team
Custom Fields works for compliance teams on Jira Cloud and Data Center. Install from the Atlassian Marketplace, or read the main Custom Fields page for the full feature list.
Try Custom Fields on the Atlassian Marketplace ↗ See the full Custom Fields overview →
Also built for
Custom Fields solves a different problem for each team: