What DORA Really Asks of Your Approvals

The regulation does not want a policy document. It wants evidence that the control still works. That turns out to be a harder question than it sounds, and your Jira history is where the answer lives.

For years, a compliance question about a software change had a short answer. Who approved this deployment, and when? You opened the ticket, found the approval, produced the name and the timestamp, and the conversation was over.

Since January 2025, that answer has quietly stopped being enough. Not because anyone changed how Jira works, but because a European regulation changed what a control is expected to prove.

What DORA changed, in one idea

DORA, the Digital Operational Resilience Act, is Regulation (EU) 2022/2554. It has applied directly across the EU since 17 January 2025, and it governs how financial entities, and increasingly the technology providers they depend on, keep their operations resilient.

Behind its many articles sits one idea worth holding onto. DORA cares less about whether a control exists on paper and more about whether it keeps working in practice, as the organization grows, reorganizes, and comes under pressure. The regulator learned an uncomfortable lesson from years of incidents: impressive documentation and actual resilience are not the same thing. So DORA moves the question from "can you show the control exists" to "can you show it still works".

That shift sounds small. It changes almost everything about how you have to think about evidence.

Where approvals enter the picture

You do not have to read far into DORA to find yourself in it. Article 9, headed "Protection and Prevention", asks financial entities to maintain high standards for the integrity of their data, meaning you can trust that nothing was changed without authorization. And it requires that changes to IT systems be, in its own words:

recorded, tested, assessed, approved, implemented and verified in a controlled manner.

Read that list again. Approval sits inside it, named explicitly, right next to testing and verification. An approval that gets skipped, or a value quietly changed after the approval was granted, is no longer just untidy practice. It is a gap in a control the regulation names outright.

DORA does not mention Jira, or any product. It sets the principle and leaves the implementation to you. But if your changes and approvals live in Jira, then Jira is where this obligation is met or missed, every day, across thousands of small actions.

The gap between the policy and the behavior

Here is where it gets difficult, and where a lot of organizations quietly fall short without noticing.

A written approval policy demonstrates intent. It says: this is how we mean to work. DORA asks for something harder. It asks whether the way you actually work still matches that intent, and whether it keeps matching as time passes.

Those two things start out aligned and rarely stay that way. An urgent release gets approved a little more loosely. A team adopts a shortcut that works. An exception becomes routine, routine becomes the way things are done, and no one ever chose that, which is exactly why no one noticed it happening. The policy on the wall still reads beautifully. The behavior underneath it has drifted.

And you cannot see that drift in any single ticket. Each individual approval, looked at on its own, is fine. The problem only shows up in the pattern across thousands of them. One field edited after approval is a harmless correction. The same edit, recurring week after week across several teams, is telling you that "approved" no longer means "settled" in your organization. Same event, completely different meaning, and only the second version is visible from above.

What "a controlled manner" looks like on a Tuesday

Before the regulation talk gets too abstract, the practical part. Most of what DORA expects here comes down to a handful of habits that any team can hold, and that are worth holding whether or not you are formally in scope.

Do not bypass approvals, not even once to save time. The exception feels reasonable in the moment. It also becomes a data point in a pattern later. When a genuine emergency needs a fast path, use the exception route that exists rather than working around it.

Do not change things silently after approval. If something has to be corrected once it is signed off, make the correction visible, and re-approve where it matters. A value that moves unnoticed after approval is precisely the integrity problem Article 9 is about.

Treat access and permissions as part of the control, not as paperwork. Who is allowed to approve what is not a formality. A permission that is broader than it needs to be is a quiet risk sitting in plain sight.

And remember what the visibility is for. The point is never to watch individuals. It is to see whether the system as a whole still behaves the way it was designed. An honest, complete history protects the people working inside it, because it shows the work was done properly.

Why the usual evidence does not answer DORA’s question

The instinct, when a regulation asks about a control, is to reach for the tools you already have. For approvals that usually means two things, and neither one quite fits.

The first is reconstructing individual approvals on demand. Jira is excellent at this. Open the issue, read the history, produce the name and timestamp. But this only ever answers a question about one ticket. DORA is asking about the behavior of the control across the whole environment, over time. A thousand individual reconstructions do not add up to that answer, because the pattern is not visible one ticket at a time.

The second is the periodic audit. Audits are thorough, but they are retrospective and they sample. By the time a drifting pattern is large enough to surface in an audit, the organization has usually been living with it for a year or more. An audit tells you what already happened. DORA also wants you to notice what is changing, while it is still changing.

Both are necessary. Neither was built to show whether a control is holding as behavior evolves.

The question you are actually being asked

Strip DORA back to what it wants from your approvals, and it comes down to this. Not "can you find the approval for this change", but "can you show that approvals across your environment still behave the way you designed them to".

Answering that means reading your Jira history in a way most organizations never do. Not ticket by ticket, and not as a snapshot of how things look today, but as a timeline of events across the whole environment, correlated over time. Who did what, in what order, and how that has changed from last quarter to this one. The information is already there. Every transition, every field change, every approval is recorded. What is usually missing is the reading, not the data.

Where this connects to the work we do

This is the point where the operational and the regulatory meet, and it is worth being plain about it.

MetaFrazo was built to make exactly this readable, and how it is built matters here. It does not work from backups, nightly exports, or a snapshot of how the workspace looks today. It subscribes directly to Jira’s own trigger events through a Forge-native connector and reads them close to the moment they happen. Every event carries who did it, when, and what changed. Strung together, they are not a photograph of the present but a timeline: who did what, in what order, and how that has shifted from one quarter to the next. If the connector loses its link for a while, events are held and delivered afterwards, so the record does not quietly grow the gaps that make an audit trail untrustworthy.

That is the difference between comparing snapshots and actually watching behavior, and it happens to be the exact shape of the question DORA asks. Reconstructing a single approval is a snapshot problem. Showing that approvals across the environment still behave as they were designed to is a timeline problem, and the event stream is already a timeline.

None of this is software deciding anything for you. It is classical analytics on data you already own, with around a hundred and fifty ready-made views over it, surfacing patterns that a person then reads and judges: issues that keep reopening, custom fields quietly multiplying, the same status name meaning different things across projects, workflows changing shape over time. It does not make you compliant. It makes the behavior of your controls visible, so that you and your auditors can see whether they are holding. The data shows the drift. A human still decides what it means.

And it is built, on purpose, not to become surveillance. It works from anonymized Jira identifiers rather than names and inboxes, and without exporting personal data, because the aim is to see how the system behaves, not to watch the people inside it. For a room that has to answer to DORA and to its own works council in the same breath, that is not a footnote. It is close to the whole point.

The quiet part

DORA did something subtle. It took a truth that operations people have always half-known, that a control is only as good as the behavior underneath it, and turned it into a legal expectation. "Approved" now has to mean something, and consistently, and you have to be able to show that it does.

The reassuring part is that the evidence already exists. It has been accumulating in your Jira history all along, one event at a time. The only real question DORA leaves you with is whether anyone is reading it that way, before an auditor has to.

This piece is for information and is not legal advice for the individual case. What governs is the text of Regulation (EU) 2022/2554 and its technical standards, together with your internal policies.