Uma política clara de procurement de TI controla a despesa, gere o risco e garante que cada compra de TI está alinhada com os requisitos de segurança e conformidade. Com a Trupeer, pode poupar horas na elaboração de políticas começando com um modelo gratuito de política de procurement de TI, personalizando-o com as suas diretrizes de marca e transformando a política num vídeo passo a passo que os colaboradores e fornecedores conseguem compreender rapidamente.

O que é uma política de procurement de TI e o que não é

Uma política de procurement de TI é a regra escrita que define quem pode comprometer a empresa com um fornecedor de tecnologia, o que tem de ser verificado antes de esse compromisso ser assumido e o que acontece à relação depois. Não é um processo de compras, uma lista de fornecedores nem um contrato — tudo isso fica a jusante.

Também não é uma política geral de procurement com a palavra "TI" à frente. O procurement geral parte do pressuposto de que o que está a ser comprado é entregue uma vez, fica algures e se deprecia. A tecnologia quebra esse pressuposto quatro vezes. Ela renova-se, pelo que um compromisso de três anos é assinado uma vez e pago trinta e seis vezes, sem ninguém voltar a aprovar nada. Mantém os seus dados, pelo que a compra entrega registos de clientes ou colaboradores a um terceiro por um preço que não tem relação com o valor do que entregou. Pode ser gratuita, e uma ferramenta gratuita passa todos os limites de despesa alguma vez definidos. E não acaba: o hardware é abatido, enquanto o software continua a faturar depois de a pessoa que o escolheu ter saído da empresa.

Porque é que a maioria das políticas de procurement de TI falha no dinheiro

Quase todos os modelos de política de procurement têm a mesma estrutura: objetivo, âmbito, funções, limites, matriz de aprovação, exceções. A matriz de aprovação está sempre associada a um único número, que é quanto custa isto. Esse desenho assume que o momento caro e o momento arriscado são o mesmo momento. Em TI, quase nunca são.

O momento caro é a renovação, porque as renovações acontecem automaticamente, a um preço definido pelo fornecedor, para um número de lugares que o fornecedor contabiliza, sem qualquer decisão humana. Numa relação de cinco anos, a compra original é normalmente a decisão mais pequena da sequência e a única que alguém analisou.

O momento arriscado é o dos dados. Uma ferramenta de notas de doze dólares por utilizador que incorpora gravações de reuniões tem mais exposição do que uma matriz de armazenamento de sessenta mil dólares que nunca sai do edifício. Os limites de despesa encaminham a matriz para o CFO e a ferramenta de notas para ninguém.

Por isso, este modelo faz duas coisas de forma diferente. Encaminha os pedidos em dois eixos, despesa e exposição dos dados, em vez de um. E trata a renovação como uma decisão de procurement nova, e não como um evento contabilístico. O resto é standard, e o standard é suficiente. As partes que importam são a tabela de encaminhamento, a cláusula 9 e o registo.

Como personalizar este modelo na Trupeer

Passo 1: Abra a secção de Modelos

Vá à secção de Modelos no menu principal.

Passo 2: Selecione e abra um modelo

Clique em qualquer modelo com que queira trabalhar para o abrir.

Passo 3: Expanda a visualização do modelo

Se necessário, expanda a visualização do modelo para ver o layout completo e os detalhes com clareza.

Passo 4: Edite o modelo

Clique em Editar para começar a modificar o modelo selecionado.

No editor, pode:

• Adicionar novas secções

• Definir ou atualizar regras de formatação

• Adicionar um logótipo e ajustar a sua posição e definições relacionadas

Passo 5: Guarde o seu modelo personalizado

Depois de fazer todas as alterações necessárias, clique em Guardar para guardar o modelo atualizado como seu.

Passo 6: Pré-visualize e ajuste o modelo

Quando quiser ver como fica o seu modelo personalizado, abra a Pré-visualização.

No ecrã de pré-visualização, pode continuar a fazer ajustes diretamente, se necessário, garantindo que o modelo aparece exatamente como o pretende.

Com um modelo de política de procurement de TI pode:

• Poupar horas na escrita: Ignore a página em branco com uma estrutura criada para procurement de TI.

• Controlar a despesa: Os limites de aprovação integrados evitam compras não autorizadas.

• Manter-se alinhado com a marca: Aplique o seu logótipo, fontes e cores usando o kit de marca da Trupeer.

• Gerir o risco dos fornecedores: Critérios integrados de avaliação de segurança e conformidade.

• Manter-se pronto para auditorias: Alinhado com frameworks como SOC 2, ISO 27001 e semelhantes.

• Abranger equipas globais: Traduza políticas de procurement para 65+ idiomas com um clique.

  
  

Como encaminhar aprovações quando a ferramenta mais barata tem o maior risco

A tabela de encaminhamento abaixo substitui a matriz de limite numa única coluna. Leia da esquerda para a direita para a despesa, de cima para baixo para a exposição dos dados e utilize a célula onde termina. A regra que faz isto funcionar é que a exposição dos dados pode aumentar o nível de aprovação, mas nunca o reduz. Uma ferramenta gratuita que toque em dados pessoais de clientes é encaminhada para revisão de segurança, e o facto de não custar nada é irrelevante.

Revisão completa significa Segurança, Jurídico, Finanças e o responsável executivo de tecnologia, em conjunto, antes de qualquer assinatura ou introdução de cartão.

A moeda e as faixas são suas para definir, e importam muito menos do que as colunas. Se não alterar mais nada aqui, altere os seus limites de um eixo para dois. Note também que "despesa anual comprometida" é o total de doze meses, e não o tamanho da transação. Uma cobrança mensal de quatrocentos e quarenta e cinco dólares é um compromisso de cinco mil trezentos e quarenta dólares, e políticas que leem a transação em vez do compromisso são a razão pela qual o exemplo trabalhado abaixo aconteceu.

O modelo de política de procurement de TI, parte um: objetivo, âmbito, funções

Copie daqui. Substitua tudo o que estiver entre parêntesis retos.

1. Objetivo

Esta política define como [Empresa] avalia, aprova, compra, renova e desativa produtos e serviços de tecnologia da informação. Existe para garantir que a despesa com tecnologia é intencional, que os dados entregues a terceiros são avaliados antes de serem entregues e que cada relação ativa com fornecedores tem um responsável nomeado dentro da empresa.

2. Âmbito

Esta política aplica-se a todos os colaboradores, prestadores de serviços e pessoal temporário de [Empresa] e a todas as aquisições de tecnologia, independentemente do valor ou do método de pagamento. Abrange subscrições e licenças de software, serviços de cloud e alojamento, hardware e dispositivos, serviços profissionais e de implementação, feeds de dados e de conteúdos, e ferramentas de desenvolvimento e APIs.

Esta política aplica-se a produtos oferecidos sem custo, desde que esses produtos processem dados de [Empresa], e a produtos adquiridos através de um cartão da empresa, uma declaração de despesas pessoais, um período experimental gratuito ou o checkout de autosserviço de um fornecedor.

Esta política não cobre recrutamento de pessoal, instalações, compra de media de marketing, nem serviços jurídicos, que são regidos por [política relacionada].

3. Definições

Despesa anual comprometida: o total a pagar a um fornecedor em qualquer período de doze meses, incluindo taxas de licenciamento, cobranças por lugar, cobranças de utilização, taxas de suporte e custos de implementação.

Exposição dos dados: a categoria mais sensível dos dados de [Empresa] que o produto irá armazenar, processar ou transmitir, avaliada ao nível do que o produto é capaz de receber, e não do que o requerente pretende colocar nele.

Responsável: o indivíduo nomeado responsável por uma relação com fornecedor, pelo seu custo, pela decisão de renovação e pela sua eventual desativação.

Shadow IT: qualquer tecnologia em uso que não esteja registada no registo de tecnologia.

4. Funções e responsabilidades

O requerente declara a necessidade do negócio, as alternativas consideradas e os dados que o produto irá tocar.

O responsável, que pode ser o requerente, mantém a relação durante a sua vida, confirma a decisão de renovação e inicia a desativação.

A TI avalia a adequação técnica, o custo de integração, a sobreposição com ferramentas já detidas e o esforço de suporte.

A Segurança avalia os controlos do fornecedor, certificações, sub-processadores e histórico de incidentes, e determina se é necessário um acordo de processamento de dados.

As Finanças confirmam o orçamento, registam o compromisso e controlam o método de pagamento.

O Jurídico analisa os termos quanto a responsabilidade, indemnização, direitos de rescisão, linguagem de renovação automática e jurisdição.

O responsável pela política, [função], mantém esta política e o registo, e reporta ambos a [comité] cada [trimestre].

O modelo de política de procurement de TI, parte dois: pedido, revisão e compra

5. Requerer

Todos os pedidos são submetidos através de [formulário de pedido ou fila de tickets] antes de qualquer conta experimental ser criada, antes de qualquer contrato ser assinado e antes de qualquer pagamento ser efetuado. Os pedidos submetidos depois de um compromisso ter sido assumido são tratados como exceções ao abrigo da cláusula 12.

Cada pedido indica o resultado do negócio pretendido, as categorias de dados que o produto irá tocar, o número de utilizadores esperado ao longo de doze meses, a despesa anual comprometida, o período do contrato e se alguma ferramenta já detida por [Empresa] poderia satisfazer a necessidade.

6. Revisão e aprovação

Os pedidos são encaminhados usando a tabela de encaminhamento de aprovações em [Apêndice A]. A aprovação é registada em [sistema] com o aprovador, a data e a despesa anual comprometida aprovada. A aprovação é concedida para um período definido e uma despesa definida. Não é transferida para uma renovação, uma extensão de período ou um aumento de despesa superior a [15] por cento.

7. Revisão de segurança e dados

Qualquer produto que irá processar dados pessoais ou dados regulamentados é revisto pela Segurança antes da aprovação. A revisão abrange as certificações de segurança do fornecedor e o seu âmbito, sub-processadores e os países onde os dados são armazenados, controlos de autenticação e acesso, compromissos de notificação de incidentes, mecanismos de exportação e eliminação de dados e qualquer histórico de incidentes.

Quando os dados pessoais são processados, um acordo de processamento de dados é executado antes de o produto receber dados em direto. Quando os dados regulamentados são processados, [Empresa] irá adicionalmente [inserir a avaliação que o seu regulador ou framework exige].

8. Contratação e pagamento

Apenas [funções nomeadas] podem assinar um contrato ou aceitar termos de serviço em nome de [Empresa]. Aceitar um acordo de clique é assinar um contrato.

O Jurídico analisa todos os acordos acima de [15,000] de despesa anual comprometida e quaisquer acordos de qualquer valor que incluam renovação automática, processamento de dados pessoais, um compromisso de exclusividade ou volume mínimo, ou um período superior a doze meses.

O pagamento é feito por [ordem de compra ou cartão corporativo detido pelas Finanças]. Cartões pessoais e reembolso de despesas não são um encaminhamento aprovado para compras de tecnologia, independentemente do valor. Os cartões emitidos a indivíduos não podem ser usados para cobranças recorrentes de tecnologia.

Cada produto aprovado é registado no registo de tecnologia antes de o primeiro pagamento ser libertado.

O modelo de política de procurement de TI, parte três: renovação, saída e exceções

9. Renovação

Uma renovação é uma decisão de procurement, não um evento contabilístico.

Nenhum acordo é celebrado quando a notificação de não renovação é exigida mais de [60] dias antes da data de renovação, a menos que seja aprovado ao abrigo da cláusula 12.

[Noventa] dias antes de cada data de renovação, o responsável completa uma revisão de renovação que cobre lugares ativos face a lugares licenciados ao longo dos noventa dias anteriores, a despesa real face à despesa aprovada, se o resultado do negócio original foi alcançado, se alguma outra ferramenta agora detida por [Empresa] cobre a mesma necessidade e quaisquer alterações aos dados que o produto trata.

A revisão de renovação é aprovada pelo mesmo nível que aprovou a compra original, usando a despesa atual e a exposição atual dos dados. Quando qualquer um deles tiver movido o produto para um nível superior, o nível superior aprova.

As renovações não revistas por [30] dias antes da data de renovação são escaladas para [função]. Quando um responsável tiver saído de [Empresa] e não tiver sido nomeado um sucessor, a renovação não é aprovada por defeito e o produto é tratado como candidato à desativação.

10. Propriedade e o registo de tecnologia

[Empresa] mantém um registo de tecnologia que regista, para cada produto ativo: o fornecedor, o produto, o responsável, a autoridade de aprovação e a data, a despesa anual comprometida, a data de renovação, o período de notificação, as categorias de dados processadas, se existe um acordo de processamento de dados, os lugares licenciados e o titular da conta administrativa.

O registo é revisto [trimestralmente]. Qualquer cobrança num cartão da empresa ou extrato bancário que não possa ser associada a uma entrada no registo é investigada no prazo de [30] dias.

Quando um colaborador sai, [função] verifica o registo dos produtos que possui e reassigna a propriedade antes do último dia. O acesso administrativo a qualquer conta de fornecedor é transferido para uma conta baseada em função, em vez de um indivíduo nomeado.

11. Desativação

Quando um produto é desativado, o responsável exporta os dados de [Empresa] num formato utilizável, emite um pedido de eliminação documentado ao fornecedor e regista a resposta, remove todas as contas de utilizador, cancela o instrumento de pagamento ou a ordem de compra, atualiza o registo e confirma que nenhum sistema dependente continua a chamar o produto.

A desativação não está concluída até que a confirmação de eliminação seja registada.

12. Exceções e compras de emergência

Uma compra de emergência pode avançar sem aprovação total quando uma falha de serviço, um incidente de segurança ou uma obrigação legal torna o atraso inaceitável. [Função] pode autorizar isto. O caminho de aprovação completo é concluído no prazo de [10] dias úteis e a compra é registada no registo de exceções.

Todas as outras exceções exigem aprovação por escrito de [função] e são registadas com um motivo e uma data de validade. As exceções não são renovadas.

13. Não conformidade

As compras de tecnologia não aprovadas não podem ser reembolsadas e os produtos não aprovados que processem dados de [Empresa] serão desativados aquando da descoberta. A não conformidade repetida é tratada ao abrigo de [política disciplinar].

14. Revisão

Esta política é revista [anualmente] por [função], ou mais cedo após um incidente material, uma alteração na obrigação regulamentar, ou uma alteração na estrutura da empresa.

Copie para aqui.

Um exemplo prático e o seu custo

Meridian Freight, trezentos e dez colaboradores, tinha uma política de procurement com um limite de aprovação de cinco mil dólares. Era uma política razoável. Veja como falhou.

Em março de 2024, um líder de equipa de suporte comprou uma ferramenta de analytics de tickets, cinco lugares a oitenta e nove dólares por lugar por mês, quatrocentos e quarenta e cinco dólares por mês num cartão da empresa. A política lia a transação em vez do compromisso, e quatrocentos e quarenta e cinco nunca chegou perto de cinco mil, pelo que nada foi acionado. O compromisso anual era de cinco mil trezentos e quarenta dólares, o que estava acima do limite.

A ferramenta incorporou corpos completos de tickets, e os tickets da Meridian incluem nomes de clientes, moradas de entrega, números de telefone e detalhes de consignação. Não houve revisão de segurança, não foi assinado um acordo de processamento de dados e a lista de sub-processadores do fornecedor nunca foi lida.

O líder saiu em novembro de 2024 e o cartão foi reemitido ao seu sucessor numa transferência financeira de rotina, pelo que a cobrança transitou com ele.

A ferramenta renovou em março de 2025. A definição de preços por lugar tinha passado de oitenta e nove para cento e dezanove dólares, e a faturação era baseada na utilização, pelo que os lugares cresceram para onze à medida que as pessoas foram adicionadas a filas partilhadas. O custo mensal foi para cerca de mil e trezentos dólares. Ninguém aprovou isto, porque não havia nada para aprovar. Era uma cobrança de cartão que estava sempre lá.

Uma auditoria ao cartão em fevereiro de 2026 encontrou isso. Dos onze lugares, três tinham iniciado sessão durante os noventa dias anteriores. O total pago ao longo de vinte e quatro meses foi de cerca de dezoito mil e duzentos dólares, dos quais cinco mil trezentos e quarenta foram o resultado de uma decisão tomada por alguém. Os restantes doze mil oitocentos e cinquenta e dois foram gastos por ninguém.

O custo que importava não era o dinheiro. Vinte meses de dados pessoais de clientes estiveram com um fornecedor não avaliado e, como a conta administrativa pertencia a um colaborador que tinha saído, a Meridian não conseguiu exportar nem eliminar os seus próprios dados sem abrir um ticket de suporte e provar a propriedade. Isso demorou onze dias.

Todas as cláusulas aqui que parecem overhead existem por causa de alguma versão disto. A cláusula 8 impede o cartão pessoal. A cláusula 9 torna março de 2025 uma decisão. A cláusula 10 apanha a cobrança sem correspondência e reassigna a propriedade na saída. A cláusula 11 significa que o pedido de eliminação não é a primeira vez que alguém pensa nisso.

Escrever e implementar isto em duas semanas

Na primeira semana, estabeleça a verdade antes de escrever a regra. Recolha doze meses de dados de cartões e bancos e liste todas as cobranças recorrentes de tecnologia; depois, pergunte a cada líder de equipa o que utiliza que não está nessa lista — é isso que faz aparecer as ferramentas gratuitas. Dê um responsável a cada linha. Tudo o que ninguém reivindica é o seu primeiro candidato à desativação. Esse inventário torna-se a primeira versão do seu registo.

Na segunda semana, defina os seus limites usando a distribuição que acabou de encontrar, em vez de um número redondo. Adapte as cláusulas acima, peça ao Jurídico e à Segurança para reverem as cláusulas 7, 8 e 11 e acordem a tabela de encaminhamento com as pessoas que terão de viver com ela. Publique-a com o registo, não antes. Uma política sem registo é um documento; uma política com registo é um controlo.

Trate a implementação como uma mudança de comportamento, e não como um anúncio. As pessoas não compram ferramentas fora do processo porque são descuidadas; fazem-no porque o processo é mais lento do que o prazo. Se o seu caminho de aprovação não conseguir ultrapassar um pedido de baixo risco em dois dias úteis, a sua política será contornada. Defina um nível de serviço para as aprovações e publique o seu desempenho face a esse nível, o que o nosso guia de gestão da mudança aborda com mais detalhe.

O que deixar de fora

Os critérios de seleção de fornecedores e as matrizes de pontuação pertencem a um guia de sourcing. Uma política que especifica como ponderar demonstrações de fornecedores ficará desatualizada em menos de um ano e será demasiado longa para ler antes disso.

Uma lista de fornecedores pertence ao registo, porque nomear fornecedores aprovados na política significa um controlo de alterações sempre que muda de ferramenta.

Instruções passo a passo para o seu sistema de compras pertencem a um IT SOP. A política diz que é necessária uma ordem de compra; o SOP diz qual botão faz subir um nível; e mantê-los separados significa que pode alterar o sistema sem voltar a abrir a política.

Documentos relacionados que vale a pena construir em paralelo com este: um modelo de documentação de TI para os sistemas que acaba por comprar, um registo de aplicações e credenciais que é o local natural para o registo de tecnologia descrito na cláusula 10, um SOP de transferência de conhecimento para a passagem de propriedade na cláusula 10 e um modelo de plano de projeto de TI para qualquer coisa suficientemente grande para precisar de implementação.

Nota sobre revisão legal e regulamentar

Este modelo é um ponto de partida, não é aconselhamento jurídico. As obrigações de procurement variam consideravelmente consoante a jurisdição e o setor. As entidades do setor público, as instituições financeiras regulamentadas, os prestadores de cuidados de saúde e as organizações sujeitas a regras de concurso público têm todos requisitos legais que este modelo não tenta reproduzir. As cláusulas de processamento de dados interagem com o RGPD, UK GDPR, CCPA e regras específicas do setor de forma diferente, dependendo de onde estão os seus titulares de dados e os seus fornecedores.

Peça ao seu departamento jurídico e ao responsável por proteção de dados ou conformidade para reverem as cláusulas 7, 8 e 11 antes de as publicar e peça-lhes que confirmem os seus limites face a qualquer delegação de autoridade já aprovada pelo seu conselho.

Transformar uma política numa coisa que as pessoas realmente seguem

Uma política que vive numa drive partilhada é lida uma vez. A versão que as pessoas seguem é a que está associada ao momento em que precisam dela — o momento em que estão prestes a comprar algo.

A Trupeer AI transforma uma gravação de ecrã num processo documentado, pelo que o caminho do pedido na cláusula 5 se torna um walkthrough do seu formulário de pedido real, em vez de um parágrafo a descrever um. Registe o fluxo uma vez e obtém um guia passo a passo, um vídeo e um documento na sua base de conhecimento, a partir da mesma gravação, com a sua própria identidade de marca.

Registe. Dê marca. Traduza. Trupeer.

Para equipas que mantêm uma biblioteca de políticas, a documentação e o SOP creator mantêm a política, o registo e os procedimentos juntos, e a tradução significa que uma equipa global de finanças lê a tabela de encaminhamento de aprovações na sua própria língua. As instruções de configuração estão no guia de configuração do modelo de documento.

Perguntas Frequentes

Existe uma versão em Word deste modelo de política de procurement de TI?

O texto completo da política está nesta página entre os dois marcadores de "copiar" e foi escrito para sobreviver a um copiar e colar. Selecione a cláusula 1 até à cláusula 14, cole no Word ou no Google Docs e a numeração e os títulos a negrito mantêm-se. Não existe um download em Word bloqueado para solicitar, o que também significa que não há um formulário de email entre si e o texto.

Existe uma versão em PDF, ou um PDF de política de procurement de TI que eu possa distribuir?

Cole o texto no seu editor de documentos e exporte para PDF a partir daí. Isto é melhor do que um PDF fixo para este documento, porque uma política de procurement precisa dos seus limites, dos nomes das suas funções e da sua moeda substituídos nos parêntesis retos antes de significar qualquer coisa. Um PDF que ainda diz [Empresa] na cláusula 2 não é uma política, e distribuí-lo ensina as pessoas que a política é apenas decorativa.

Posso descarregar este modelo gratuitamente?

O texto é gratuito e sem restrições. Use-o, edite-o e publique-o internamente com o seu próprio nome. Não precisa de dar crédito à Trupeer AI no documento da sua política.

O que é o COBIT APO10 e este modelo cumpre-o?

APO10 é o objetivo do COBIT que cobre fornecedores geridos, abrangendo seleção de fornecedores, gestão de relações, gestão de contratos e monitorização de desempenho ao longo de todo o ciclo de vida do fornecedor. Uma política de procurement é uma entrada para APO10, não é a mesma coisa.

Este modelo cobre bem as partes de aquisição e contratação, e as cláusulas 9 e 10 cobrem alguma gestão contínua da relação. Não cobre scorecards de desempenho de fornecedores, monitorização de nível de serviço nem classificação de risco de fornecedores a nível de portefólio, todos os quais o APO10 espera. Se estiver a trabalhar para uma avaliação COBIT, trate isto como um dos vários documentos de que vai precisar, e não como um controlo que fecha o objetivo.

O que é uma política de procurement simples e quando é que uma é suficiente?

Uma política de procurement simples tem normalmente duas a três páginas: objetivo, âmbito, uma tabela de limites de despesa e quem assina. Para uma empresa com cerca de cinquenta pessoas a comprar apenas ferramentas comuns sem dados regulamentados, isto é realmente suficiente, e uma política com catorze cláusulas não será seguida.

Se quiser a versão curta, mantenha as cláusulas 1, 2, 4, 6, 8 e 9 e elimine o resto. Não elimine a cláusula 9. A disciplina de renovação é o único controlo que se paga a si próprio em qualquer dimensão de empresa, e é a cláusula que mais frequentemente falta nas políticas curtas.

Isto abrange SaaS e serviços cloud, ou apenas hardware?

Abrange ambos, e o âmbito na cláusula 2 está escrito para o tornar explícito, porque é na ambiguidade que a maioria das políticas falha. Cloud e SaaS são o caso mais difícil, razão pela qual a tabela de encaminhamento tem uma linha para despesa zero e uma coluna para exposição dos dados. As compras de hardware são encaminhadas de forma limpa apenas pela despesa na maioria das empresas.

Quem deve ser o responsável por esta política?

Quem quer que seja responsável pela despesa com tecnologia — na maioria das empresas é o CIO, o Diretor de TI ou o Chefe de TI, e em empresas mais pequenas é frequentemente o COO ou o Diretor de Finanças. O que importa mais do que o cargo é que o responsável tenha visibilidade sobre os dados do cartão e do banco descritos na cláusula 10. Um responsável por política que não consegue ver as cobranças não consegue aplicá-la.

Com que frequência devemos revê-la?

Anualmente é a opção sensata por defeito na cláusula 14. Reveja-a mais cedo se tiver tido um incidente de segurança envolvendo um fornecedor, se um regulador tiver alterado obrigações que se aplicam a si, se adquiriu ou foi adquirido, ou se a revisão trimestral do registo tiver encontrado cobranças sem correspondência em dois trimestres consecutivos. A última situação é um sinal de que a tabela de encaminhamento ou o nível de serviço de aprovação não está a funcionar, e não de que as pessoas precisam de ser lembradas da política.