Read-Only Matters: Why Your CTO Should Care How Financial Tools Connect to Jira

The first time I had this conversation in detail with a CTO, the agency had already signed a year-long contract with a financial tool. The CFO had run the procurement, had been satisfied with the price, the features, the demo. The CTO came in for the integration session and discovered three things in the same hour that none of them had been on the procurement page.

The first thing: the tool wanted Jira admin credentials, not project-level access. The second thing: the tool would install a Jira plugin to read worklog data more efficiently. The third thing: the tool wrote back to Jira when the agency’s project managers updated certain fields in the tool’s UI — specifically, project budget changes propagated back to the corresponding Jira project.

None of those three were discussed during procurement. None of them were on the marketing page. The CTO spent the next two weeks renegotiating the integration to a less invasive shape and the CFO spent the same two weeks wondering why a procurement that had been signed off was now being re-opened.

This is not a one-off. The conversation repeats often enough that I now think of read-only-and-no-Jira-state as a deliberate procurement preference, not an integration detail. This piece is the trade-off list the CTO would have wanted before the contract was signed.

Question 1: read-only or read-write?

A financial tool that connects read-only pulls data out of Jira and writes nothing back. A read-write tool changes Jira’s state when the agency’s users do certain actions in the tool’s UI. The most common write-backs are: budget changes (the tool updates the corresponding Jira project budget field), worklog edits (the tool changes a Jira worklog entry), or workflow transitions (the tool moves a Jira issue between statuses).

Each write-back is a coupling between two systems’ states, and couplings are debt. If the tool’s UI lets a project manager change a budget number, and that change propagates back to Jira, then any other source of truth in Jira’s ecosystem — a custom dashboard, a downstream automation, a board configuration — has to know about the tool’s ability to write that field. If the tool ever writes incorrectly, the recovery is not just “fix the bug in the tool”: it is “reconcile the resulting Jira state across every downstream consumer”.

For a financial layer specifically, the case for write access is weak. The financial layer is reading hours, projects, statuses and producing analysis. It is not the place where work is created or modified. The places where work is created and modified are: Jira’s native UI, sometimes a project-management tool, sometimes a service-desk integration. A financial tool that writes back is reaching into a layer it has no operational reason to author.

The CTO question to the procurement: does this tool write back to Jira? If yes, what fields, on what triggers, with what reversal capability? If the answer is anything more than “nothing, ever”, the tool is competing with Jira’s ecosystem of authors and the agency now has two systems whose state can drift.

Question 2: do we install a plugin inside Jira?

Some financial tools require an Atlassian Marketplace plugin to be installed inside the Jira instance to deliver their value. The plugin runs as a first-class component of Jira: it has its own permissions, it can intercept Jira API calls, it can render UI inside Jira issues, and it is updated through the Marketplace pipeline rather than the financial vendor’s own deployment.

Plugins are not bad in themselves. The Atlassian Marketplace ecosystem is mature, the security review is meaningful, and the per-plugin cost is small relative to the overall stack. But every Jira plugin is a long-term commitment. It needs to be kept up to date with Jira version upgrades. Its UI surface needs to be supported by the agency’s own runbook when something breaks. Its permission model needs to be understood by whoever administers Jira.

For a 100-person agency, the operational cost of an additional Jira plugin is somewhere between 8 and 24 hours a year of platform-engineering attention — upgrade testing, incident handling, security questionnaire updates, integration reviews. None of that is on the financial plugin’s subscription line.

The CTO question to the procurement: does this tool require a Jira plugin to be installed? If yes, what does the plugin do, what permissions does it need, and is the same value available from a tool that connects through the standard REST API and runs entirely outside Jira? If the second tool exists and the gap on functionality is small, the plugin-free path is the lower-debt path.

Question 3: admin credentials or scoped service account?

The third question is the one that keeps security teams up at night. A financial tool that needs to read worklogs across the whole company can connect through a scoped service account with read-only worklog and project access, or through a global Jira admin account with permission to do anything in the instance.

The lazy procurement default, in many financial tools, is the second: ask for an admin account. The reasons given are usually some combination of “it makes the integration simpler”, “the tool needs to read across all projects”, and “the admin account is what we set up in our docs”. None of those reasons survive a security review.

The right default is a scoped service account: a dedicated account that exists only to run the integration, with project-level read access to the projects the agency wants the tool to see, and no other permissions. If the tool needs OAuth, a scoped OAuth app with worklog-read and project-read scopes is the equivalent. The blast radius of a credential leak is bounded to what the tool legitimately needs to read.

The CTO question to the procurement: what credentials does this tool need to function? If the answer is “a Jira admin account”, the right next question is “why?”, and if the answer is anything other than a specific technical reason that the agency’s own engineering judges valid, the procurement preference is a tool that runs on a scoped service account.

Question 4: where does the data live, and under whose jurisdiction?

The fourth question is one the CFO often raises but rarely with the CTO’s technical lens. Where does the data the tool ingests live, who hosts it, in what jurisdiction, with what backup and retention guarantees, with what process for export if the agency leaves?

For an agency on Jira, the worklog data is already in Atlassian’s cloud (or in the agency’s own data centre, if Data Centre). When a financial tool ingests that data, it makes a copy into the financial vendor’s own data store. From that point on there are two copies: the original in Jira, and the analysis copy at the vendor.

The architectural decisions the CTO should be asking about are: which cloud region the analysis copy lives in (EU, UK, US, somewhere else); whether the backup policy matches the agency’s own RTO and RPO requirements; whether the data is encrypted at rest with vendor-managed or customer-managed keys; whether the agency can request a complete export at any time; and what the deletion process looks like at the end of the contract.

For an agency whose clients are in regulated industries — financial services, healthcare, legal — these questions are not optional. They are the difference between a financial tool that survives the agency’s next client security review and one that has to be torn out before the renewal. A vendor whose answer to “where does my data live” is anything less than a specific region with a specific encryption posture and a specific export and deletion process is a vendor that has not yet had this question asked of them seriously.

Question 5: how does the tool fail?

The fifth and quietest question is operational. Every integration fails sometimes. Auth tokens expire, API rate limits are hit, network partitions happen, the vendor has incidents. The question worth asking is what shape the failure takes from the agency’s side.

A read-only tool that fails in a partial-data state still leaves Jira itself untouched. The financial reports may be stale or incomplete for the duration of the failure, but the work itself, in Jira, continues. The recovery is a back-fill: when the tool is healthy again, it pulls the worklogs that were missed and produces the right reports retroactively.

A read-write tool that fails in a partial-data state can leave Jira in an inconsistent state. A budget update was attempted, the propagation back to Jira completed, but the corresponding state in the financial tool was never persisted. Now the two sources disagree, and reconciliation is manual.

A tool that runs as a Jira plugin can have failure modes inside Jira itself. The plugin processes a hook on every issue update. If the plugin’s server is down, the hook either fails the operation or queues for retry, depending on the integration design. Either way, the work being done in Jira is now coupled to the financial vendor’s availability.

The CTO question to the procurement: what is the worst-case failure mode of this integration, and how does it affect the team’s ability to keep working in Jira during the failure? A tool whose worst case is “reports are stale until we recover” is operationally cheap to live with. A tool whose worst case is “Jira itself is degraded until the vendor recovers” has a different cost profile entirely.

What we built around this on Saldo

Saldo’s integration was designed around the read-only-and-no-Jira-state principle from the first commit, because every other architectural pattern I considered had a cost I did not want to carry inside the agency I was CTO of.

The connection is read-only. We pull worklogs, issues, projects, epics and statuses through the standard Jira REST API on a scoped service account or scoped OAuth app. We do not write to Jira, we do not install a Jira plugin, and we do not require admin credentials. The setup is fifteen minutes once the credentials are in hand.

The data lives in AWS, in EU and UK regions, with customer-managed encryption available on the Enterprise plan. The export and deletion processes are documented on the Trust page. We support both Jira Cloud and Jira Data Centre with the same architecture.

This is one valid pattern among others, but it is the pattern that survives the CTO sign-off conversation with the smallest list of follow-up questions. The trade-off is that we cannot push budget changes back into Jira, and we cannot run automation triggers against Jira state changes — both of which are features other tools offer. The choice we made was to keep Jira as the single author of Jira state and to focus on what the financial layer is actually for: reading what the team is already logging and producing the analysis the financial-plugin category does not.

What to ask before the next procurement

Five questions, in the order a CTO would ask them. Does this tool write back to Jira? Does it require a Jira plugin? Does it ask for admin credentials? Where does the data live, and how does it leave? How does the integration fail, and what does that mean for the team in Jira during the failure?

A vendor that answers all five with the lower-debt option is a vendor that has thought about the procurement from the CTO’s side. A vendor that has clean answers to four out of five and a specific technical justification for the fifth is doing fine. A vendor whose answers surface as surprises during the integration session has either not had this conversation before or hopes it will not come up again.

If the financial tool you are looking at has not surfaced these answers on its trust page, the procurement question is whether the answers exist somewhere else — on a security questionnaire, in a paid SOC 2 report, in a contractual addendum — or whether they have not been formalised at all. The first is an effort question. The second is a procurement red flag.

Saldo was built specifically to answer all five with the lower-debt option, and the trust page lays out the answers in detail. If the architecture matters to you and you would like to see it running, a 15-minute demo connects read-only to your real Jira on a scoped service account or OAuth app, in your region of choice, with no plugin to install — and we walk you through the relevant security questions on the call itself. No card details up front, no follow-up if it does not land.