Jira em sistema cooperativo de crédito: uma instância por cooperativa ou uma para o sistema inteiro?
This is a subtitle for your new post
Em um sistema cooperativo de crédito, a escolha entre uma instância do Jira para o sistema inteiro e uma instância por cooperativa define quem governa processo e dado, e por isso deveria acompanhar a governança que o próprio sistema já escolheu para a segurança cibernética. A Resolução CMN 4.893/2021 admite política de segurança cibernética única para o sistema cooperativo de crédito. Quando o sistema adota essa política única, padrões centrais e evidência consolidada pesam mais do que a autonomia local, e a instância única ou por central tende a servir melhor. Quando cada cooperativa mantém política própria, instâncias separadas fazem mais sentido. No Jira Cloud, só o plano Enterprise reúne várias instâncias em um mesmo plano, com limite de 150.
Como o sistema cooperativo se organiza, e por que isso pesa no Jira
O Banco Central descreve as cooperativas de crédito como organizadas em até três níveis. As singulares operam diretamente com os associados. As centrais prestam serviços às filiadas, como aplicação centralizada de recursos e consultoria técnica. As confederações reúnem as centrais. No levantamento publicado pelo Banco Central no Estudo Especial nº 83, com dados de dezembro de 2019, eram 875 singulares, 34 centrais e quatro confederações, além de 213 singulares independentes, sem vínculo com central.
Essa estrutura faz com que o mesmo processo, uma mudança em sistema, um projeto regulatório ou o atendimento de um incidente, passe por mais de um nível de decisão. A confederação ou a central costuma definir padrões e fornecer tecnologia, enquanto a singular executa e responde ao seu próprio conselho. A arquitetura do Jira precisa refletir quem define o fluxo, quem pode alterá-lo e quem precisa enxergar o resultado consolidado.
Tese da CSP Tech: o desenho certo do Jira em um sistema cooperativo nasce da governança que o sistema já decidiu ter, e o sinal mais objetivo dessa decisão é a política de segurança cibernética. Se o sistema optou por política única, os controles e as evidências precisam ser padronizados e consultáveis de forma consolidada, e espalhar o Jira em dezenas de instâncias autônomas trabalha contra isso. Se cada cooperativa mantém política própria, uma instância única impõe uma centralização que a governança do sistema não pediu.
O que a Resolução 4.893 permite ao sistema cooperativo
A Resolução CMN 4.893, de 26 de fevereiro de 2021, se aplica às instituições autorizadas a funcionar pelo Banco Central, e as cooperativas de crédito não estão entre as exceções do parágrafo único do artigo 1º. O artigo 2º, parágrafo 2º, admite a adoção de política de segurança cibernética única por conglomerado prudencial e por sistema cooperativo de crédito. O parágrafo 3º exige que a instituição que deixa de ter política própria formalize essa opção em reunião do conselho de administração ou, na falta dele, da diretoria.
A política única concentra a definição dos controles, mas cada cooperativa continua sujeita a eles e precisa demonstrar que os aplica. Na prática, isso cria uma demanda por evidência padronizada: os mesmos tipos de registro de incidente, de mudança e de acesso, organizados de forma que a área responsável pela política consiga consultar todas as cooperativas. A revisão da norma pela Resolução CMN 5.274, de dezembro de 2025, reforçou essa necessidade ao exigir trilhas de auditoria do processamento fim a fim dos dados.
Os três desenhos possíveis
Instância única para o sistema inteiro
Todas as cooperativas trabalham no mesmo Jira, separadas por espaços, permissões e esquemas. A Atlassian resume a vantagem desse modelo como ter todo mundo trabalhando junto no mesmo lugar. Para o sistema cooperativo, o ganho prático está em fluxos padronizados, relatórios consolidados sem integração e uma única configuração para auditar. O perfil ideal é o sistema com política de segurança única, tecnologia fornecida pela central ou pela confederação e processos que já são iguais entre as cooperativas. A limitação está na administração: qualquer mudança de esquema afeta todas as cooperativas, e o isolamento entre elas depende inteiramente do desenho de permissões, que precisa ser revisado sempre que uma cooperativa entra, sai ou se incorpora a outra.
Uma instância por cooperativa
Cada singular tem o seu Jira. A Atlassian aponta como vantagens de múltiplas instâncias a administração delegada, o tratamento diferente de tipos de dado, com controle de acesso, nível de auditoria e localização por instância, e a assinatura de apps do Marketplace separada por instância. O perfil ideal é o sistema em que cada cooperativa mantém política própria, decide os próprios processos e tem equipe para administrar a ferramenta. A limitação aparece na escala e na visão consolidada. Nos planos Free, Standard e Premium, cada assinatura dá direito a uma instância, e o Enterprise reúne até 150 instâncias no mesmo plano, limite que um sistema com muitas singulares pode ultrapassar. A visão do sistema passa a depender de uma camada de dados que leia todas as instâncias.
Instância por central, com padrões definidos pela confederação
Cada central opera uma instância para as suas filiadas, seguindo padrões de fluxo, de campos e de nomenclatura definidos pela confederação. O modelo combina autonomia regional com um vocabulário comum, e reduz o número de instâncias a algo próximo do número de centrais. O perfil ideal é o sistema de três níveis em que as centrais já prestam serviços de tecnologia às filiadas. A limitação é que os padrões só se mantêm com governança ativa: sem um dono na confederação que aprove mudanças de esquema, as instâncias divergem em poucos meses e a consolidação volta a exigir tradução de dados.
Critérios para decidir
Política de segurança cibernética. É o primeiro critério porque já foi decidido pelo sistema e registrado em ata. Política única aponta para padronização e evidência consolidada; políticas próprias apontam para autonomia.
Grau de padronização dos processos. Se mudança, incidente e projeto regulatório seguem o mesmo fluxo em todas as cooperativas, uma configuração comum reduz trabalho. Se cada cooperativa tem fluxos próprios por bons motivos, forçar um esquema único gera exceções que ninguém consegue manter.
Quem precisa ver o consolidado. A confederação, a central, a auditoria e a área responsável pela política de segurança precisam consultar dados de várias cooperativas com frequência? Quanto maior essa necessidade, maior o custo de separar instâncias e reconstruir a visão por integração.
Escala e plano. O número de cooperativas que terão Jira, comparado ao limite de 150 instâncias do plano Enterprise, define se o modelo de uma instância por cooperativa é viável dentro de um único plano.
Apps e custo. Apps do Marketplace são assinados por instância. Em muitas instâncias, um app usado por todas as cooperativas é pago muitas vezes, o que precisa entrar na conta antes da decisão.
Localização e tratamento do dado. Instâncias separadas permitem tratar dados de forma diferente, inclusive quanto à localização. A lista de locais de residência de dados da Atlassian muda com o tempo e deve ser conferida no momento da decisão.
Por que a escolha fica cara de reverter
A arquitetura de instâncias costuma ser decidida no início, quando o Jira atende poucas áreas, e revista anos depois, quando o sistema cresceu. Juntar instâncias separadas ou dividir uma instância única exige migrar projetos, usuários, histórico, anexos e configurações de apps, com risco de perder vínculos entre itens e de quebrar automações e relatórios. Em cooperativa, ainda há o efeito das incorporações: quando uma singular incorpora outra, a arquitetura precisa absorver a mudança sem perder a evidência do que cada uma registrou antes. Decidir com base na governança do sistema, e não apenas no número de usuários de hoje, reduz a chance de uma migração forçada.
A camada regulatória, com a ressalva devida
A Resolução 4.893 não trata de ferramentas e não exige nenhum desenho específico de Jira. O que ela exige são controles, registros e evidências, e o desenho da ferramenta só facilita ou dificulta a demonstração. A leitura de que a política única pede evidência padronizada é uma interpretação editorial da CSP Tech sobre o efeito prático da norma, e a definição do que cada cooperativa precisa demonstrar cabe às áreas de compliance, riscos e jurídico do sistema, junto com a auditoria.
Quando essa discussão é desproporcional
Uma singular independente, sem vínculo com central e com uma única área usando o Jira, não precisa desse nível de análise: uma instância própria resolve. O mesmo vale para o sistema em que o Jira atende só o time de desenvolvimento da central, sem uso pelas cooperativas. E, se o sistema está prestes a trocar de ferramenta ou de plataforma de nuvem, a decisão de arquitetura deve esperar essa definição, porque migrar duas vezes custa mais do que esperar alguns meses.
Perguntas frequentes
Uma cooperativa de crédito pode adotar a política de segurança cibernética da central ou do sistema?
Sim. A Resolução CMN 4.893/2021, no artigo 2º, parágrafo 2º, admite política de segurança cibernética única para o sistema cooperativo de crédito. A instituição que deixa de ter política própria precisa formalizar essa opção em reunião do conselho de administração ou, na falta dele, da diretoria, conforme o parágrafo 3º.
Quantas instâncias do Jira Cloud uma organização pode ter?
Nos planos Free, Standard e Premium, cada assinatura dá direito a uma instância. O plano Enterprise permite até 150 instâncias no mesmo plano e inclui os recursos do Atlassian Guard Standard, segundo a documentação da Atlassian. Acima disso, ou em planos sem Enterprise, cada instância adicional é uma assinatura separada.
Instância única do Jira ou uma por cooperativa: qual escolher?
Depende da governança do sistema. Instância única ou por central tende a servir melhor quando o sistema tem política de segurança única, processos padronizados e necessidade de visão consolidada. Uma instância por cooperativa faz mais sentido quando cada uma mantém política própria, processos próprios e equipe para administrar a ferramenta.
É possível juntar ou separar instâncias do Jira depois?
É possível, mas exige migrar projetos, usuários, histórico, anexos e configurações de apps, com risco de perder vínculos entre itens e quebrar automações e relatórios. Por isso a arquitetura deve ser decidida com base na governança do sistema e no crescimento esperado, e não só no número de usuários atual.
Próximo passo
Faça um teste de dez minutos: verifique na ata do conselho se a sua cooperativa adotou a política de segurança cibernética do sistema ou mantém política própria, e compare com a forma como o Jira está organizado hoje. Se a política é única e o Jira está espalhado em instâncias que ninguém consulta em conjunto, ou se a política é própria e a cooperativa depende de uma configuração que não controla, a arquitetura está desalinhada com a governança. Fale com um especialista CSP em consultoria Jira para desenhar a arquitetura do sistema antes que a próxima incorporação ou auditoria force a decisão.
Leituras relacionadas
Jira e regulação no setor financeiro
- Portfólio de projetos regulatórios no Jira: quando o prazo vem do Banco Central, e não do negócio
- Circuit breaker na B3: o que a interrupção de 26 de outubro exige da TI de bancos, corretoras e instituições de pagamento
- O papel do Jira Service Management no gerenciamento de incidentes
Configuração, governança e dados do Jira
- Jira mal implementado: 6 sinais de que a configuração está travando o seu time (e como corrigir)
- Do Jira ao Lakehouse: as 4 fases de maturidade de dados que definem de qual consultoria você precisa agora
- “De onde veio esse número”? Rastreabilidade de dados para decisões mais confiáveis
- Empresa de intranet para banco, cooperativa ou seguradora: como comparar plataforma pronta, SharePoint e desenvolvimento sob medida
Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google, Anthropic e Semrush. Revisão técnica por especialistas Atlassian e de dados da CSP Tech (Atlassian Gold Partner, parceira Databricks, Microsoft Gold Partner, participante do Anthropic Partner Network, 38 anos de mercado, produto próprio Power BI for Jira no Atlassian Marketplace).
Fontes (acesso em 12/11/2026): Banco Central do Brasil, Estudo Especial nº 83/2020, “Modelo de negócios de cooperativas de crédito”, dados de dezembro de 2019. Resolução CMN nº 4.893, de 26/02/2021, art. 1º e art. 2º, §§ 2º e 3º. Resolução CMN nº 5.274, de 18/12/2025. Atlassian Support, “What are the benefits of multiple instances?” e “What is an Enterprise plan?”. Os três desenhos, os critérios de decisão e a leitura da política única como demanda por evidência padronizada são formulação editorial da CSP Tech. Este conteúdo não constitui aconselhamento jurídico ou regulatório.










