Every Commit Tells a Story. Your Auditor Wants to Know Which Ticket It Belongs To.

Here's a commit that shipped last Tuesday. It fixed a real bug — a double-charge when a payment was retried — passed review, and went out clean.

Good change. Real fix. Now — which ticket authorized it? If you can't answer that in five seconds, neither can your auditor.

Your code is fine. Your paper trail isn't.

Audits rarely fail on bad code. They fail on unprovable process — a change that reached production with nothing connecting it back to a request, an approval, or a reason. The code can be flawless. If you can't show why it shipped and who said it could, that gap is the finding.

This is change management and traceability, and it isn't a SOC2 quirk — it's a control that shows up, in almost identical language, in ISO 27001, SOX, and PCI DSS. They all want the same thing: a documented line from “someone asked for this” to “this exact change went live.” The linked ticket is how you draw that line. SOC2 is just where it bites most teams first — usually the first real audit a growing company sits through — so that's where we'll focus. The gap itself is everywhere.

We've written before about the kind of history questions auditors ask — who moved this, and when. This is the same instinct one layer down: not just who advanced the ticket, but whether there was a ticket at all.

What the auditor actually asks for

An audit of your change process is usually a sampling exercise. The auditor points at a sample of your production changes and says: show me these twenty-five, and for each one, the ticket that authorized it, who approved it, and the trail that connects them.

The linked ticket is the spine of that evidence. It's what turns “we deployed something” into “we deployed an approved, reviewed change, for a documented reason, requested by a real person.” A commit that points at MARS-123 clears the sample in seconds — there's the issue, the discussion, the approval. A commit that points at nothing becomes an exception the auditor has to chase, and every exception is a question you end up answering by hand.

Why this is so hard to catch by hand

Here's the trap: nobody decides to skip the ticket. Everyone means to reference one. The failure is silent and statistical — at fifty commits a day across a dozen repos, the one that slipped through looks exactly like the forty-nine that didn't, right up until someone goes looking.

And the ways they slip are mundane. The 2 a.m. hotfix, where linking a ticket was the last thing on anyone's mind. The “tiny” one-line doc fix that felt too small to bother. The typo'd key — MARS-132 instead of MARS-123 — pointing at an issue that doesn't exist. The push straight to main that skipped the pull request, the review, and the link all at once.

None of it surfaces until audit season, when someone exports a year of git history into a spreadsheet and starts reading commit messages by eye. By then it's archaeology: reconstructing the context for a change from eight months ago whose author has long since paged it out. Manual review finds these problems after they're already findings — which is backwards. You want to catch the missing link the day the change lands, while the author still remembers what it was for.

Enter Dike: the check that runs while you commit

That's the gap Dike closes. It's a Forge-native Jira app that watches your GitHub commits and pull requests and flags the ones that break the traceability trail — automatically, continuously, without anyone exporting anything to a spreadsheet. (It's named for the Greek goddess of justice, the one holding the scales. Fitting, for a tool whose whole job is accountability.)

The mechanism is simple to describe: Dike scans commit and pull-request activity against a set of compliance rules, and every violation becomes a Jira issue. Here's the shape of it.

The two rules that close the gap

Dike ships a whole set of change-management rules — we'll get to the others in a moment — but two of them map straight onto the problem we've been building: Commits without issues and Pull requests without issues. Like the rest, both ship disabled by default — you switch on the ones you want, so Dike never starts filing tickets you didn't ask for.

What makes them more than a regex is that they catch two genuinely different failures:

• Missing Issue Key — the commit message or PR title references no issue at all. The bare commit from the top of this post.
• Missing Issue — it references a key like MARS-132, but that issue doesn't exist in Jira. The typo, the copy-paste from another project, the key that was deleted. A naive “does this contain something shaped like a key?” check waves these through; Dike resolves the key and notices when it points at nothing.

The matching lands where you'd expect: for a pull request the issue key has to appear in the title; for a commit, Dike reads the message. Reference a real issue and the change passes quietly. Don't, and it gets flagged.

Every violation becomes a Jira issue you can query

When Dike flags a change it doesn't bury an alert in a dashboard you'll never open. It creates a real Jira issue — a custom Compliance Violation type, in a project you nominate when you set Dike up. A missing link lands in the same system as the rest of your work: assignable, triageable, with a status and a history. The person who can fix it gets a ticket, not a notification they'll archive.

And because they're Jira issues, they're JQL-queryable. “Show me every untracked change this quarter” stops being a git-history spreadsheet and becomes one line:

That query is your audit evidence — the exception list you used to assemble by hand, generated on demand. For the at-a-glance view, the Dike dashboard pivots the same violations by status, severity, and type.

And it checks more than missing tickets

Missing links are the sharpest example, but they're one rule in a set — the same engine enforces the rest of your change-management controls. Turn on the ones that match how you ship: PRs merged without an approval (no second set of eyes), PRs merged with a failing build (shipped despite red CI), or commits pushed straight to main (skipping the pull request altogether). Same class of problem — a change that skipped a control — caught the same way.

And it isn't rigid. Rules live in groups scoped to specific repositories, with branch patterns (main, release/*) and file exclusions (*.md, docs/**) — so you can stop flagging documentation-only commits without loosening anything that matters. Dike scans up to the last year of history when you connect a repo, then re-checks every few minutes with a deeper pass each hour, so new gaps surface close to when they happen rather than at audit time.

Compliance tooling that doesn't widen your compliance scope

A fair caveat: Dike isn't Vanta, Drata, or Sprinto, and it isn't trying to be. Those are full compliance platforms spanning dozens of controls — access reviews, vendor management, policy tracking, the lot. Dike does one thing: it watches your code changes for the traceability gaps an auditor will land on. So this isn't “the cheap version of Vanta” — it's the one control those platforms leave to manual process, automated and filed as a Jira ticket.

Where the data goes matters too, because that's what your auditor will ask about. Dike reads your commits and pull requests from GitHub and pulls them into Jira, where the analysis runs on Atlassian Forge. Your code history lands in your own Atlassian tenant and stays there — it never touches an Orbiscend server. You're still buying a tool from us, yes, but it's cheap, it does the one job you switched it on for, and it runs inside infrastructure your auditor has already scoped — so it doesn't add a new third party holding your data. That's the whole reason we build on Atlassian Forge.

And the evidence is permanent in a way that matters: a violation isn't locked inside our app — it's a native Jira ticket. It runs through the workflow you already trust (assign, review, route for approval, close), and it stays in Jira long after you stop paying for Dike. Your audit trail is just Jira data: queryable, exportable, and still there whether or not Dike is installed. Nothing important leaves with the vendor.

To be clear about what that buys you: Dike doesn't make you SOC2-compliant — no tool does. It monitors a specific, high-value control and hands you the evidence that you're holding it. That's the part teams usually scramble to reconstruct at audit time, and the part Dike makes routine.

Start catching them today

Go back to that commit at the top — the clean fix with no ticket, invisible until someone went looking eight months later. With the right rule switched on, it files its own Compliance Violation the moment it lands, while the fix is still fresh and adding the link takes ten seconds. You're not bolting on a new compliance process. You're making the one you already have provable.

Dike is on the Atlassian Marketplace and free for teams up to ten users. Install it, connect a repo, switch on the two “without issues” rules, and run a rescan — then look at what a year of your own history turns up. It's usually more than you'd guess, and a lot less than your auditor would have found.