Task Tracker for Banks and Fintech in Kazakhstan: Security and Setup

A bank or fintech in Kazakhstan needs a task tracker that runs inside its own perimeter: data is stored in the country, users come from the corporate directory via SSO or LDAP, permissions are separated by role and project, and actions are recorded in a log. Cloud trackers from foreign vendors usually do not meet these requirements. In 2026 there are two realistic options: Jira Data Center, which lives until March 2029, and self-hosted Plane in the Commercial or Airgapped editions.

This article is for IT leaders, fintech CTOs and anyone preparing a tracker choice for approval by the information security team. We cover security requirements, Jira’s limitations, Plane’s capabilities, the installation architecture, the approval process and a checklist.

How a bank differs from a regular IT team

A product team chooses a tracker for convenience and price. A bank chooses based on whether the system will pass approval and audit. That changes the order of questions.

For a bank, a task tracker is more than a board with tasks. It holds descriptions of payment system changes, links to incidents, architecture decisions, correspondence with contractors, and sometimes exports and screenshots. Even if customer personal data is not supposed to end up there, the security team assumes that one day it will. So the system is assessed as a store of sensitive information.

A fintech without a banking license usually has an easier time, but if the company works with payments, loans or partner banks, the partners’ security requirements for a contractor often turn out to be just as strict.

Security requirements for a task tracker

The typical set of requirements we see in the financial sector looks like this:

1. Data in Kazakhstan. The database with employees’ personal data and any customer data is stored within the country. This is the standard security position.
2. Role model. Permissions by role and project, the principle of least privilege, separate roles for contractors.
3. Single sign-on. Users from the corporate directory via LDAP or SSO, with a departing employee blocked in one place.
4. Logging. Who changed what in a task and when, who logged in, who changed permissions.
5. Network segmentation. The tracker sits in a defined segment, accessible only from the corporate network or via VPN.
6. Closed perimeter. For some systems, outbound internet connections are forbidden, including for updates and licensing.
7. Backup and recovery. Regular backups, tested recovery, clear timelines.
8. Update management. Updates go through a test environment and a change window.
9. Vendor assessment. Secure development documentation, certifications, a clear support model.

Why Jira Cloud is problematic

Jira Cloud is a strong product, but inside a banking perimeter it has three systemic problems.

Data residency. Atlassian lets you choose a storage region: the US, the EU, Germany, the UK, Switzerland, Australia, Singapore, Japan, India, South Korea and Canada. Kazakhstan is not on the list. If the bank needs to keep data in the country, the cloud does not fit.

External dependency. The vendor controls access to the system, updates and feature changes. The bank’s security team cannot place a cloud service in its own network segment and block outbound connections.

Security costs extra. SSO, access policies and extended audit in Atlassian’s cloud come through Atlassian Guard: Standard costs $4.20 per user per month as of October 2026, on top of Jira Standard at $7.91 or Premium at $14.54. Payment is by card in dollars, without closing documents that meet Kazakhstani standards.

If the bank is currently on Jira Data Center

Jira Data Center solved these issues, but new licenses have not been sold since March 30, 2026. According to Atlassian partners, renewals and expansions for existing customers are possible until March 30, 2028, and support ends on March 28, 2029. After that the license switches to read-only mode, and Marketplace apps stop working.

For a bank this means the choice must be made with enough time for approval, a pilot and migration. There are three options: move to Jira Cloud and solve the data residency question, switch to a self-hosted alternative, or run Data Center until the last day with a migration plan ready. The third option is the riskiest: the final months before end of support will turn into a rush, and the security team’s findings on the new system will still need to be addressed.

When moving to Plane, the built-in importer transfers projects, tasks, comments, attachments, statuses, links, sprints and users. Automations, dashboards, JQL filters, ScriptRunner scripts and permission schemes are not transferred; you will have to rebuild them and get them approved by security again. We covered timelines and options in detail in our article on the end of Jira Data Center.

Plane Commercial and Airgapped: what they cover

Plane is an open source task tracker whose self-hosted version matches the cloud in features. Two paid editions are of interest to banks:

• Commercial: installation inside your perimeter with a connection to Plane’s license server. Commercial v3.0.0 was released in July 2026.
• Airgapped: installation with no internet access: offline licenses, updates without connecting to external servers, and a local AI model so AI features do not send data outside.

Security features that matter to the security team: SSO via SAML and OIDC from the Pro plan, LDAP and IdP groups, and Granular Access Control for fine-grained permissions in the higher plans. The vendor states SOC 2 Type II and ISO 27001:2022 certifications, as well as GDPR and HIPAA compliance for cloud and self-hosted.

There are limitations too. The integration ecosystem is smaller than Atlassian’s. The Russian interface is community-maintained, and its completeness depends on the version. There is still little Plane expertise in the Kazakhstan market, so support needs to be planned in advance.

Security requirements and how they are met

Requirement	How self-hosted Plane meets it	What to check in the pilot
Data in Kazakhstan	Installation on the bank’s servers or in a Kazakhstani data center	Where the database, files and backups are stored
Single sign-on	SSO via SAML or OIDC, LDAP	Blocking a departing user through the directory
Role model	Workspace and project roles, Granular Access Control	Contractor access limited to their own project
Logging	Change history in tasks, application and web server logs sent to SIEM	Completeness of the audit log for your edition
Segmentation	Placement in an internal segment, access via corporate network or VPN	No unnecessary open ports
Closed perimeter	Airgapped edition with offline license and updates	The procedure for bringing updates into the perimeter
AI without data leakage	Local AI model in Airgapped, or AI features disabled	What goes outside when AI is enabled
Backup and recovery	Backups of PostgreSQL and file storage	Recovery on a test environment
Updates	Test environment and change window	Rollback time and procedure
Vendor assessment	SOC 2 Type II, ISO 27001:2022	Requesting documents from the vendor or partner

A separate note on logging. Every task has a change history, but the security team usually also wants to see system events: logins, permission changes, exports. Check the contents of the system audit log in your edition during the pilot, and in any case send application, reverse proxy and database logs to the bank’s SIEM.

Kazakhstan context. Banks and fintech companies usually want data stored in Kazakhstan, and bank security teams are strict about it. The practical takeaway: the tracker is installed inside the bank’s perimeter or in a Kazakhstani data center, and hosting is paid in tenge under a contract.

Installation architecture inside the bank perimeter

The typical design we submit to the security team for approval:

• Segment. The application server sits in an internal segment, with user access through a reverse proxy with TLS. There is no public access from the internet.
• Components. The Plane application, PostgreSQL, Redis, a message queue and S3-compatible file storage. The database and files live on the bank’s resources.
• User directory. Connection to the corporate IdP via SAML or OIDC, or to LDAP. Directory groups map to roles in the tracker.
• Environments. A test environment for updates and a production environment. An update first passes testing, then goes through a change window.
• Backups. Regular backups of the database and files to separate storage, with scheduled recovery tests.
• Monitoring and logs. Server metrics go to the bank’s monitoring system, logs go to SIEM.
• Integrations. Internal only: GitLab inside the perimeter, the corporate messenger if it is deployed internally. Each integration is described separately: what data is transferred and in which direction.

The rule for data inside the tracker: tasks contain no customer names, account or card numbers, or screenshots from production systems. Instead, use a link to a record in the system of record or an anonymized identifier. This rule is written into the team’s policy and checked at retrospectives.

How to pass security approval

Approval drags on when the security team sees the project for the first time at final sign-off. The reverse order works: involve security in the first week and get approval piece by piece.

Stage	What we prepare	Who is involved
Scoping	Goals, user base, classification of data in the tracker	IT, security, process owner
Choosing the edition	Comparison of Commercial and Airgapped, perimeter requirements	IT, security
Architecture	Deployment diagram, segments, data flows, integrations	IT, security, network team
Access model	Roles, directory groups, contractor access	Security, team leads
Operations	Backups, updates, monitoring, logging	IT, security
Pilot	One team, checking every item in the requirements table	Pilot team, security
Go-live	Pilot report, policy, go-live order	IT, security, management

We covered which Plane edition to choose for a specific perimeter in our article on Plane editions.

Pre-launch checklist

• The classification of data allowed in the tracker is defined, and the rule is written into the policy.
• The edition is chosen: Commercial if a connection to the license server is acceptable, Airgapped for a fully closed perimeter.
• The server, database, files and backups are located in Kazakhstan.
• Users come from the corporate directory; there are no local accounts, or they are under control.
• Roles and contractor access are approved by security.
• Logs go to SIEM, and the contents of the audit log have been checked.
• Recovery from backup has been tested on a test environment.
• The update and rollback procedure is documented.
• AI features either run on a local model or are disabled.
• A system owner and a support engineer are assigned.

How we do it

We start with a diagnostic: which teams will work in the tracker, what data will go into it, which security requirements are already defined and what is left from the previous system. Then we prepare the approval package and run a two- to four-week pilot with one team in the bank’s test environment. After the pilot we close the security team’s findings, migrate data from Jira with Plane’s built-in importer and scale to the remaining teams.

If you are choosing a tracker for a bank or fintech, start with our Jira and Plane task tracker implementation page: it describes the process, timelines and what is included in the result.

---

Sources. Data Center timeline: atlassian.com/enterprise/data-center. Atlassian Cloud data residency regions: Atlassian documentation. Jira pricing: Atlassian price list. Plane editions and pricing: plane.so/pricing. Prices are as of October 2026 and may change.

Terms in plain words

Bank perimeter

The bank's internal network with its own servers and access rules. A tracker inside the perimeter means data never leaves the bank's infrastructure.

SSO and LDAP

Ways to log in with a corporate account from a single employee directory. A departing employee is blocked in one place, and their tracker access disappears automatically.

Airgapped (air-gapped)

An installation in a network with no internet access. In Plane's Airgapped edition, licenses and updates work offline, and AI features use a local model.

SIEM

A security team system that collects event logs from all of the bank's systems and looks for suspicious activity. Tracker logs need to be sent there too.

IdP (identity provider)

The corporate system that stores employee accounts and confirms their logins to other services. Its groups are mapped to roles in the tracker.

Granular Access Control

Fine-grained permission settings in Plane's higher plans. For example, it lets you give a contractor access only to their own project, following the principle of least privilege.

SOC 2 Type II and ISO 27001

International certifications confirming that a vendor has established information security processes. They help with vendor assessment but do not relieve the bank of responsibility for its own server.

Jira Data Center

The version of Jira for installation on your own servers. New licenses have not been sold since March 30, 2026, and support ends on March 28, 2029.