# Proposta de Modelo de Central de Serviços e Infraestrutura de TI

**Versão:** 1.2  
**Data:** Abril de 2026  
**Classificação:** Documento de Referência Técnica

---

## Sumário

1. [Premissa Central do Modelo](#1-premissa-central-do-modelo)
2. [Estrutura dos 3 Contratos](#2-estrutura-dos-3-contratos)
3. [Distribuição por domínio de infraestrutura e serviço](#3-distribuição-por-domínio-de-infraestrutura-e-serviço)
4. [Unidades de Remuneração por Ativo Conforme](#4-unidades-de-remuneração-por-ativo-conforme)
5. [Estados de Conformidade e Remuneração](#5-estados-de-conformidade-e-remuneração)
6. [Regra de Glosa e Nexo de Responsabilidade](#6-regra-de-glosa-e-nexo-de-responsabilidade)
7. [Limitação Causada pelo Contratante](#7-limitação-causada-pelo-contratante)
8. [Serviços sob Demanda e Situações Sazonais](#8-serviços-sob-demanda-e-situações-sazonais)
9. [Condição "Sob Ataque"](#9-condição-sob-ataque)
10. [Modelo de RACI Obrigatório](#10-modelo-de-raci-obrigatório)
11. [Regras para Evitar Jogo de Empurra](#11-regras-para-evitar-jogo-de-empurra)
12. [Pontos de Observação Críticos](#12-pontos-de-observação-críticos)
13. [Cláusulas Conceituais Sugeridas](#13-cláusulas-conceituais-sugeridas)
14. [Fechamento do Modelo](#14-fechamento-do-modelo)

**Documento complementar:** [IMR — síntese executiva (unidades, trava trilateral, evidências, Outros 10%)](./IMR-sintese-executiva.md)

**Remissão a SDRs (mitigações operacionais):** prioridade de **restauração** sobre discussão de **nexo** em incidente degradante; **RACI** mínimo nas fronteiras (detalhe no TR); **preferência** por evidência **automatizada** para comprovação de serviço por IC; **transição integrada** (kickoff e rituais conjuntos) — [sdr-0011c](../SDRs/sdr-0011c-c1-trilateralidade-cobranca-mutua.md) §§4–5, [sdr-0011b](../SDRs/sdr-0011b-c1-ciclo-mensal-ateste.md) §4, [sdr-0023d](../SDRs/sdr-0023d-prestacao-efetiva-ic-periodo-faturado.md) §8.2.1, [sdr-0019](../SDRs/sdr-0019-transicao-reversibilidade-encerramento.md) §2. **Governança da fiscalização:** **contrapeso** à cadeia de medição do C1, **prazo e escalada** para decisão da Administração — [sdr-0010](../SDRs/sdr-0010-gestao-fiscalizacao-contratual.md) §4; **validação cruzada semestral** da CMDB — [sdr-0011a](../SDRs/sdr-0011a-c1-itsm-cmdb-noc-medicao.md) §2.2; **ruptura de um dos três contratos** — [sdr-0019](../SDRs/sdr-0019-transicao-reversibilidade-encerramento.md) §2.1.

---

## 1. Premissa Central do Modelo

### 1.1 Objetivo

Organizar a operação de TI em **3 contratos integrados**, com segregação suficiente para preservar governança, segurança, controle e continuidade, mas sem criar excesso de contratos nem duplicidade operacional.

### 1.2 Princípio Estrutural

Cada serviço deve ter:

- **(a)** um único responsável operacional;
- **(b)** um responsável por monitorar e medir;
- **(c)** um responsável por segurança, proteção ou recuperação, quando aplicável;
- **(d)** decisão final sempre preservada à Administração.

### 1.3 Regra de Ouro

> **Um contrato executa. Outro mede. Outro protege/valida. A Administração decide.**

### 1.4 Vedação Essencial

Não deve haver dois contratos com obrigação simultânea de "operar" o mesmo serviço, pois isso gera disputa de responsabilidade, repasse indevido e "jogo de empurra".

### 1.5 Itens Fora do Escopo deste Modelo

Para evitar ambiguidade na execução contratual, ficam expressamente **excluídos** do escopo dos Contratos 1, 2 e 3:

1. **Telefonia e contact center**: PABX IP, ramais, troncos SIP, URA, gravação de chamadas, integração de telefonia com CRM, headsets corporativos, telefonia móvel corporativa associada e demais elementos próprios desse domínio. Esses serviços, quando existirem, são objeto de contrato próprio.

2. **Emissão e renovação de certificados digitais institucionais** em nome da Administração — inclusive ICP-Brasil, A1, A3 e equivalentes vinculados à pessoa jurídica do órgão. A operação desses atos permanece sob responsabilidade direta da Administração.

Os Contratos 1, 2 e 3 não executam os serviços listados acima, ainda que possam recebê-los como insumo via Service Desk para fins de registro, encaminhamento ou correlação na CMDB.

---

## 2. Estrutura dos 3 Contratos

### 2.1 Contrato 1 — Governança, ITSM, NOC, Qualidade e Conformidade

**Natureza:** Contrato de controle, medição, organização, registro, evidência, coordenação e fiscalização técnica auxiliar.

**Não deve fazer:** Executar operação técnica ordinária de infraestrutura, redes, banco, nuvem, endpoints ou aplicações.

**Responsabilidades principais:**

| # | Responsabilidade |
|---|-----------------|
| 1 | Gestão da ferramenta ITSM |
| 2 | Gestão do catálogo de serviços |
| 3 | Gestão da CMDB |
| 4 | Gestão de SLAs e OLAs |
| 5 | Gestão de incidentes |
| 6 | Gestão de problemas |
| 7 | Gestão de mudanças |
| 8 | Gestão de configuração |
| 9 | Gestão de disponibilidade |
| 10 | Gestão de capacidade sob perspectiva gerencial |
| 11 | NOC e monitoramento independente |
| 12 | Observabilidade operacional |
| 13 | Painéis técnicos e executivos |
| 14 | Auditoria de chamados, mudanças e evidências |
| 15 | Consolidação de indicadores |
| 16 | Gestão de conformidade PPSI/LGPD (evidência, controle e acompanhamento) |
| 17 | Coordenação de sala de crise |
| 18 | Relatórios mensais de operação |
| 19 | Controle de planos de ação |
| 20 | Verificação de aderência aos padrões de ativo conforme |
| 21 | Apoio à fiscalização contratual |
| 22 | Controle de consumo de nuvem (governança, orçamento, tendência e alerta) |

> O Contrato 1 **não substitui a Administração**, mas fornece os elementos técnicos para que a Administração fiscalize, decida, cobre e aplique glosas.

---

### 2.2 Contrato 2 — Operação de TI, Infraestrutura, Suporte, Redes, Nuvem, Banco, Endpoints e Aplicações

**Natureza:** Contrato de execução operacional principal.

**Responsabilidade central:** É o **dono operacional dos serviços comuns de TI**.

**Responsabilidades principais:**

| # | Responsabilidade |
|---|-----------------|
| 1–4 | Service Desk, atendimento 1º, 2º e 3º nível |
| 5–9 | Instalação, configuração e suporte de endpoints e softwares |
| 10–16 | Administração de servidores, VMs, SO, virtualização, storage, bancos e middleware |
| 17–18 | Sustentação técnica de aplicações, APIs e integrações |
| 19–21 | Operação de DNS, DHCP e VPN |
| 22–30 | Operação de LAN, WAN, SD-WAN, Wi-Fi, switches, roteadores, APs e balanceadores |
| 31–35 | Operação de nuvem (contas, workloads, serviços gerenciados, otimização, Cloudflare operacional) |
| 36–40 | Execução de mudanças, correção de falhas, correção de vulnerabilidades, apoio a agentes e documentação operacional |

**Ambientes lógicos (ciclo de vida):** a operação aplica-se aos ativos e serviços existentes nas faixas usualmente reconhecidas em TI — **desenvolvimento** (e/ou sandbox), **homologação** (e/ou teste integrado / teste de aceite — UAT), **pré-produção** (quando houver) e **produção** —, conforme ETP, catálogo e ANS (janelas, criticidade e SLAs podem variar por faixa). *Estes ambientes **não** se confundem com o que o item 3 chama de **domínio** (pilha nuvem/rede/endpoint, etc.).*

> O Contrato 2 é controlado pelo **Contrato 1** quanto a SLA, disponibilidade, evidência, chamados e mudanças, e pelo **Contrato 3** quanto a segurança, vulnerabilidades, hardening, logs, identidade, backup e recuperação.

---

### 2.3 Contrato 3 — Segurança Cibernética, SOC, IAM, Backup, Continuidade e Recuperação

**Natureza:** Contrato de proteção, detecção, resposta, identidade, backup e recuperação.

**Responsabilidade central:** É o dono operacional dos serviços especializados de segurança e continuidade.

**Responsabilidades principais:**

| # | Responsabilidade |
|---|-----------------|
| 1–3 | SOC, SIEM e correlação de eventos de segurança |
| 4–5 | EDR/XDR e antimalware corporativo |
| 6–9 | Gestão de vulnerabilidades, varreduras, classificação de riscos e revalidação de correções |
| 10–13 | Hardening, baseline de segurança, logs de segurança e casos de uso de detecção |
| 14–17 | Resposta a incidentes, contenção, isolamento de endpoint e apoio a ransomware |
| 18–22 | IAM, MFA, PAM, revisão de acessos e contas privilegiadas |
| 23–26 | Backup corporativo, monitoramento de jobs, restore e testes de restore |
| 27–30 | DRP, testes de RTO/RPO, simulados e recuperação pós-incidente |
| 31–32 | Cloudflare (WAF, DDoS, bloqueios, proteção de aplicações) e validação de segurança em mudanças críticas |

> O Contrato 3 **não opera a infraestrutura comum**. Ele protege, detecta, orienta, valida e recupera. Quando a correção exige alteração em servidor, rede, banco, aplicação ou nuvem, quem executa é o Contrato 2. O Contrato 3 valida a correção.

---

## 3. Distribuição por domínio de infraestrutura e serviço

A seguir, **domínio** indica a pilha ou camada tecnológica (nuvem, borda, rede, aplicação, etc.). Os **ambientes lógicos** (dev, homolog, pré-prod, produção) atravessam esses domínios e estão detalhados no Contrato 2 (texto de referência, seção de Operação — ambientes lógicos).

### 3.1 Nuvem

**Responsável principal:** Contrato 2.

Abrange contas/subscriptions/projetos, VMs, redes virtuais, storage, bancos gerenciados, serviços serverless, Kubernetes, load balancers, gateways, integrações, cargas em **ambientes lógicos** de homologação e produção (e demais existentes), rotinas operacionais e ajustes técnicos de consumo.

| Papel | Contrato |
|-------|---------|
| Operação | Contrato 2 |
| Governança de consumo (orçamento, alertas, relatórios) | Contrato 1 |
| Avaliação de riscos de segurança e exposição | Contrato 3 |

> **Atenção:** o consumo de crédito de nuvem não deve ficar sem dono. A Administração deve definir orçamento, limites, alertas e regras de autorização para expansão de consumo.

---

### 3.2 Cloudflare

| Função | Responsável |
|--------|-------------|
| DNS, CDN/cache, publicação, roteamento, certificados operacionais | Contrato 2 |
| WAF, proteção DDoS, regras de bloqueio, segurança de borda | Contrato 3 |
| Monitoramento de disponibilidade, SLA e evidências | Contrato 1 |

> Cloudflare é ponto sensível porque mistura disponibilidade e segurança. A operação ordinária fica com o Contrato 2, mas regras de proteção e resposta a ataque ficam com o Contrato 3.

---

### 3.3 Balanceamento

**Responsável principal:** Contrato 2 (balanceadores físicos, virtuais e em nuvem, pools, health checks, certificados, regras de encaminhamento, HA e failover).

O Contrato 3 valida aspectos de segurança, especialmente quando envolver exposição externa, WAF, TLS, segmentação, firewall ou mitigação de ataque.

---

### 3.4 Computadores, Notebooks e Endpoints

**Responsável principal:** Contrato 2 (recebimento, preparação, instalação, configuração, entrega, suporte, substituição e baixa).

| Participação | Escopo |
|-------------|--------|
| Contrato 3 | EDR, antimalware, criptografia, MFA, políticas de segurança, conformidade, isolamento remoto |
| Contrato 1 | CMDB, registro no ITSM, indicador online, SLA de instalação, evidência de aceite, histórico |

---

### 3.5 Redes e Wi-Fi

**Responsável principal:** Contrato 2 (switches, roteadores, APs, controladoras, VLANs, segmentação, cabeamento, links, SD-WAN, VPN, DNS, DHCP, Wi-Fi).

| Participação | Escopo |
|-------------|--------|
| Contrato 3 | Validação de segurança, logs de rede, segmentação, detecção de tráfego suspeito, regras de contenção, resposta a ataque |
| Contrato 1 | Monitoramento, disponibilidade, SLA, evidência de falhas, histórico de incidentes |

---

### 3.6 Servidores

**Responsável principal:** Contrato 2 (SO, patches, configuração, performance, serviços básicos, agentes, capacidade, usuários técnicos, mudanças, correção de falhas).

| Participação | Escopo |
|-------------|--------|
| Contrato 3 | EDR/XDR, logs de segurança, vulnerabilidades, hardening, backup, restore, resposta a incidentes |
| Contrato 1 | CMDB, monitoramento, disponibilidade, SLA, mudanças, relatórios |

---

### 3.7 Bancos de Dados

**Responsável principal:** Contrato 2 (instâncias, performance, usuários técnicos, permissões, replicação, rotinas, manutenção, tuning, apoio a aplicações, diagnóstico).

| Participação | Escopo |
|-------------|--------|
| Contrato 3 | Backup, restore, logs de segurança, acessos privilegiados, vulnerabilidades, criptografia, resposta a incidente |

---

### 3.8 Aplicações, APIs e Serviços Digitais

**Responsável principal:** Contrato 2 (sustentação técnica, middleware, servidores de aplicação, APIs, integrações, logs operacionais, deploy técnico, certificados operacionais, publicação técnica).

| Participação | Escopo |
|-------------|--------|
| Contrato 3 | Segurança de aplicação, logs de segurança, WAF, vulnerabilidades, gestão de exposição, resposta a ataque |
| Contrato 1 | Catálogo de serviço, SLA, observabilidade, mapa de dependências, registro de incidentes, gestão de problemas |

---

### 3.9 Disciplinas Transversais

As disciplinas abaixo atravessam múltiplos domínios de infra e ambientes lógicos e possuem dinâmica operacional, indicadores e SLAs específicos:

#### 3.9.1 Gestão de Impressão

**Responsável principal:** Contrato 2. Inclui operação do parque de impressoras, servidor de impressão, filas, drivers, cotas, interface com outsourcing e registro na CMDB.

O Contrato 3 valida hardening, autenticação (pull printing), logs de auditoria, firmware e criptografia. O Contrato 1 gerencia CMDB, disponibilidade, SLA e histórico de chamados.

#### 3.9.2 Mobile Device Management (MDM)

**Responsável principal:** Contrato 2. Inclui operação da plataforma MDM/UEM, inscrição/descomissionamento, gestão de perfis, distribuição de apps, suporte e vínculo na CMDB.

O Contrato 3 gerencia criptografia, MFA, conformidade de segurança, detecção de jailbreak/root, wipe remoto e resposta a comprometimento.

#### 3.9.3 Certificados Digitais e PKI

> A **emissão e renovação de certificados digitais institucionais** em nome da Administração (ICP-Brasil, A1, A3) **permanecem sob operação direta da Administração** e não fazem parte do escopo dos contratos.

**Responsável principal:** Contrato 2, para certificados operacionais (servidor, balanceador, aplicação, mTLS, nuvem, Cloudflare).

O Contrato 3 define políticas, valida aderência à baseline, opera PKI interna, responde a comprometimentos e aprova exceções. O Contrato 1 mantém inventário, painel de vencimentos, SLA de substituição e histórico de incidentes.

#### 3.9.4 Patch Management

**Responsável principal:** Contrato 2. Inclui ciclo de patching (mensal, emergencial, sob demanda), avaliação técnica, aplicação, exceções, rollback, documentação e SLAs por criticidade.

O Contrato 3 prioriza por risco, indica patches críticos, valida pós-aplicação e aceita formalmente riscos de exceções. O Contrato 1 monitora cobertura, aderência, SLA e gera relatório mensal de conformidade.

> **Patches críticos** devem ter SLA específico (exemplo: 7 dias úteis para servidores expostos), com **glosa direta ao Contrato 2** em caso de descumprimento.

#### 3.9.5 Plataforma de Dados e BI

**Responsável principal:** Contrato 2 (operação de servidores de dados, ferramentas de BI, sustentação de pipelines ETL/ELT, jobs, provisionamento de acesso técnico, capacidade, performance).

**Não inclui:** construção de pipelines, modelagem de dados de negócio, construção de dashboards, curadoria ou governança de dados de negócio.

O Contrato 3 gerencia backup/restore, PAM, logs de segurança, vulnerabilidades, criptografia e resposta a incidente.

#### 3.9.6 Self-Service e Automação Operacional

**Responsável principal:** Contrato 2, com governança e arquitetura pelo Contrato 1.

Inclui portal de autoatendimento, catálogo de serviços auto-acionáveis, automação de provisionamento, reset de senha, instalação de softwares aprovados, bots e workflows no ITSM, base de conhecimento e indicadores.

**Metas progressivas obrigatórias:**
- Cobertura mínima do catálogo auto-acionável, com expansão anual definida
- Taxa de resolução em autoatendimento por categoria de serviço
- Redução percentual anual de chamados manuais para itens automatizáveis
- Disponibilidade do portal
- Atualidade da base de conhecimento

> A ausência ou estagnação do programa de self-service enseja **glosa específica ao Contrato 2**, conforme metas anuais pactuadas.

---

## 4. Unidades de Remuneração por Ativo Conforme

### 4.1 Premissa

A remuneração deve ocorrer prioritariamente por **ativo ou serviço em conformidade operacional**, e não por posto, hora ou mensalidade genérica.

#### 4.1.1 Mesma unidade de medição, preço próprio por contrato

As **unidades** de remuneração (U1–U7) são **as mesmas** para alinhar inventário, IMR, evidência e prestação de contas entre os três fornecedores. Isso **não** implica o **mesmo preço** nem a **mesma fatia** de serviço paga a cada qual: o **valor monetário** por unidade, por **período** e por **contrato (C1, C2 ou C3)**, consta de **tabela de preços** / plano de preço e do **ANS**, e reflete a **entrega** de cada fornecedor (p.ex. medição e ITSM, execução operacional, proteção e continuidade) sobre o **mesmo** ativo ou serviço. O **Termo de Referência** e o edital devem **explicitar o que** está incluído em cada preço (evitando dupla remuneração sobre a **mesma** evidência ou obrigação).

#### 4.1.2 Itens de configuração (IC) e partilha entre contratos

O detalhamento **normativo** de como cada **item de configuração** elegível entra nos **catálogos** dos três contratos, como se calcula o **preço-IC pleno** (fatores) e como se **reparte** o valor entre C1-GOV, C2-OPR e C3-SEC — sem repetir nesta Proposta o texto canônico — está nos SDRs **[sdr-0023-remuneracao-por-ic-modelo](../SDRs/sdr-0023-remuneracao-por-ic-modelo.md)** (hub), **[sdr-0023a-catalogo-ic-por-contrato](../SDRs/sdr-0023a-catalogo-ic-por-contrato.md)**, **[sdr-0023b-fatores-remuneracao-ic](../SDRs/sdr-0023b-fatores-remuneracao-ic.md)**, **[sdr-0023c-aninhamento-ic-isolado-contrapesos](../SDRs/sdr-0023c-aninhamento-ic-isolado-contrapesos.md)**, **[sdr-0023d-prestacao-efetiva-ic-periodo-faturado](../SDRs/sdr-0023d-prestacao-efetiva-ic-periodo-faturado.md)** (nexo serviço × parcela recorrente por período) e **[sdr-0023e-adicional-inclusao-inicial-ic-vedacao-reinstalacao](../SDRs/sdr-0023e-adicional-inclusao-inicial-ic-vedacao-reinstalacao.md)** (adicional de inclusão e vedação de reinstalação remunerada). A política de **ferramentas** de medição de IC no C1-GOV e o prazo de adequação quando a contratante impuser nova ferramenta estão em **[sdr-0011e-c1-ferramentas-coleta-monitoracao-ic](../SDRs/sdr-0011e-c1-ferramentas-coleta-monitoracao-ic.md)** e **[sdr-0011f-c1-ferramentas-iniciativa-contratante-adequacao](../SDRs/sdr-0011f-c1-ferramentas-iniciativa-contratante-adequacao.md)**. Os **números** pactuados (percentuais, tabelas de fatores, tetos) ficam no **ANS/TR** e na **memória de cálculo**, não nos SDRs. Modelo de memória: [`memoria-calculo-remuneracao-ic-modelo.md`](./memoria-calculo-remuneracao-ic-modelo.md).

### 4.2 As seis unidades ordinárias de medição

#### Unidade 1 — Endpoint Conforme

Inclui desktops, notebooks, estações especiais e dispositivos móveis.

**Requisitos mínimos:** registro na CMDB, identificador único, usuário/unidade vinculada, agente de inventário ativo, agente de segurança ativo, atualização dentro do prazo, status online ou check-in válido, scripts de atendimento associados, histórico no ITSM, conformidade mínima de segurança.

---

#### Unidade 2 — Servidor ou Instância Conforme

Inclui servidores físicos, VMs, instâncias em nuvem, hosts e appliances computacionais.

**Requisitos mínimos:** registro na CMDB, identificador único, dono operacional, monitoramento ativo, patch conforme política, agente de segurança ativo (quando aplicável), backup configurado (quando aplicável), logs mínimos, runbook vinculado, relacionamento com serviço digital.

---

#### Unidade 3 — Ativo de Rede Conforme

Inclui switches, roteadores, APs, controladoras, firewalls, links, SD-WAN, VPN e balanceadores.

**Requisitos mínimos:** registro na CMDB, identificador único, unidade/serviço vinculado, monitoramento ativo, configuração documentada, backup de configuração (quando aplicável), firmware/software dentro da política, logs (quando aplicável), topologia vinculada, responsável operacional definido.

---

#### Unidade 4 — Serviço Digital Conforme

Inclui sistemas, portais, APIs, integrações, middleware, serviços de autenticação e bancos associados ao serviço.

**Requisitos mínimos:** registro no catálogo de serviços, dono do serviço, SLA definido, dependências mapeadas, monitoramento de disponibilidade e performance (quando aplicável), runbook, plano de comunicação de indisponibilidade, logs mínimos, histórico de incidentes e problemas.

---

#### Unidade 5 — Ativo Protegido Conforme

Inclui endpoints protegidos, servidores protegidos, serviços digitais protegidos, fontes de log integradas, identidades privilegiadas controladas, ativos com vulnerabilidade monitorada e serviços protegidos por WAF.

**Requisitos mínimos:** ativo na CMDB, cobertura por controle de segurança aplicável, política de segurança aplicada, log de segurança disponível (quando aplicável), vulnerabilidades monitoradas, alertas classificados, exceções formalizadas, plano de tratamento, revalidação de correções, evidência técnica disponível.

---

#### Unidade 6 — Ativo Recuperável Conforme

Inclui servidores com backup, bancos com backup, serviços digitais recuperáveis, volumes protegidos, ambientes críticos com DRP e serviços com RTO/RPO definido.

**Requisitos mínimos:** política de backup definida, job executado com sucesso, retenção conforme, teste de restore no ciclo definido, RPO e RTO definidos (quando aplicável), runbook de recuperação, evidência automática, vínculo com ativo/serviço na CMDB, responsável definido.

---

### 4.3 Unidade residual — Outros (sob demanda)

Complementa as seis unidades ordinárias para **demandas eventuais, sazonais ou extraordinárias** que não devam diluir o modelo de conforme. Remuneração exclusivamente por **catálogo** aprovado, **ordem de serviço** específica, critério de aceite e evidências objetivas, conforme seção **8**. O **teto de 10%** do valor total do contrato por período de faturamento e a **trava trilateral** quando aplicável estão em **8.5** e **6.2.1**. Síntese para IMR/ETP: [IMR-sintese-executiva.md](./IMR-sintese-executiva.md).

---

## 5. Estados de Conformidade e Remuneração

### 5.1 Escala Padrão

| Estado | Descrição | Pagamento sugerido |
|--------|-----------|:-----------------:|
| **Conforme** | Todos os requisitos aplicáveis atendidos | 100% |
| **Não conformidade leve** | Pendência sem impacto relevante | 80% |
| **Não conformidade média** | Pendência com risco operacional moderado | 50% |
| **Não conformidade grave** | Pendência relevante de operação, segurança ou continuidade | 20% |
| **Não governável** | Sem requisito mínimo para gestão e evidência | 0% |

**Vedação de efeito punitivo duplo:** a escala de **ocorrências reincidentes** (seção **6.1.1**), a tabela acima, as glosas específicas (**6.3**) e a glosa por visibilidade (**6.4**) **não** se cumulam de forma a **punir duas vezes o mesmo fato**; o ANS fixa a ordem de aplicação e a prevalência, **sem** somar percentuais injustificados.

### 5.1.1 Criticidade de impacto (patamar inicial)

Classificação, a ratificar e detalhar no **catálogo de serviços** e no **ANS** (e detalhes no TR):

| Nível | Descrição |
|--------|-----------|
| **Baixo** | Falha ou degradação de desempenho **sem** indisponibilidade. |
| **Médio** | Falha ou desempenho afetado **com** indisponibilidade de sistemas **não** críticos. |
| **Alto** (crítico para efeito de remuneração) | Infraestrutura ou serviço que afeta **sistemas críticos** (conforme catálogo) **ou** **dados pessoais sensíveis** / **serviço essencial** (conforme TR e mapeamento institucional). |

### 5.1.2 Escalonamento automático por persistência

A criticidade do **estado anômalo** (distinta da **reincidência** a 90 dias — **6.1.1**) **reclassifica-se** com base no tempo desde o **registro do gatilho** gerador (abertura do incidente ou detecção do desvio, conforme ANS):

- Se o patamar inicial for **baixo** e a situação **persistir mais de 48 horas**, passa a **médio**.
- Se o patamar (inicial ou já reclassificado) for **médio** e a situação **persistir mais de 24 horas**, passa a **alto** (crítico para efeito de remuneração e glosa), salvo regra mais restritiva no ANS.

**Nota:** o **período de 90 dias** usado na **reincidência** (6.1.1) e os **prazos de 24 h / 48 h** de persistência **não** são a mesma regra: o primeiro contabiliza **eventos** de mesma natureza; o segundo mede **duração** de um desvio ainda aberto.

### 5.1.3 Leitura com a tabela 5.1 e o ANS

O **ANS** vincula o nível de criticidade (e o estado após **5.1.2**, quando aplicável) às **faixas** de não conformidade e aos **percentuais** de pagamento, inclusive para ativos e serviços de perfis distintos (p.ex. patch em endpoint comum vs. servidor exposto).

### 5.2 Falhas que Tornam o Ativo Não Governável

1. Ausência de CMDB
2. Ausência de identificador único
3. Ausência de dono operacional
4. Ausência de vínculo com serviço ou unidade
5. Ausência de monitoramento mínimo obrigatório
6. Ausência de evidência automática ou verificável
7. Ativo sem classificação mínima de criticidade (conforme **5.1.1** e catálogo)
8. Serviço digital fora do catálogo
9. Ativo crítico sem registro de dependências
10. Ativo sem possibilidade de fiscalização objetiva

> A condição "não governável" deve ser usada com cuidado, pois gera pagamento zero da unidade. Ela deve estar limitada a situações em que a Administração não consegue comprovar, monitorar ou fiscalizar objetivamente o serviço.

---

## 6. Regra de Glosa e Nexo de Responsabilidade

### 6.1 Regra Geral

A glosa deve respeitar: obrigação contratual, nexo causal, evidência, impacto, matriz RACI e possibilidade real de atuação do prestador.

### 6.1.1 Escala de ocorrências reincidentes (mesma natureza, 90 dias)

Falhas de **mesma natureza** — **mesma** classificação de causa / tipo de não conformidade (código ou categoria no ITSM, a fixar no ANS), no **mesmo** item de configuração ou serviço digital, com **nexo** no **mesmo** contrato (C1, C2 ou C3) —, contabilizam-se em **janela móvel de 90 dias**:

| Ocorrência | Efeito |
|------------|--------|
| **1ª** | **Alerta automático** — a própria **prestação de contas e medição** (IMR, relatórios, instrumento) funciona como **alerta**; pode-se exigir registro no ITSM **sem** efeito financeiro adicional, conforme ANS. |
| **2ª** | **Advertência** formal, com prazo e registro documental (canal a definir no ANS / TR). |
| **3ª e seguintes (na janela)** | **Glosa por item** sobre a **unidade remunerável** afetada, com **escalonamento progressivo** segundo **5.1**, **5.1.1 a 5.1.2** (criticidade e persistência) e tabela de nexo **6.3**, a ratificar no ANS. |

A sequência **alerta → advertência → glosa** busca **compatibilizar** sanções e remuneração com tratamento **graduado** (a validar com a assessoria jurídica do órgão e normas aplicáveis), **sem** dispensa de obrigações contratuais.

**Relação com a trava trilateral (6.2.1):** enquanto o ativo for **governável** (não houver requisito estruturante ausente conforme **5.2**), falhas reincidentes de mesma natureza **não** justificam, **por si sós**, a **suspensão de faturamento nos três contratos**; aplica-se primeiro a escala acima. A trava **6.2.1** permanece reservada ao **não governável** / **fora do padrão mínimo** amarrado no ANS e à **falta estruturante**, **ou** a casos de impacto excecional **expressamente** previstos no ANS (ex.: incidente de gravidade excepcional, **sem** confundir reincidência corrigível com colapso de governança). **Não** se duplica a punição prevista no **5.1**, **5.1.1–5.1.2**, **6.3 e 6.4** pelo mesmo fato (vedação de efeito punitivo duplo).

### 6.2 Regra de Pagamento Zero Coletivo

Pode ser aplicada quando o ativo ou serviço estiver **não governável** por ausência de requisito estruturante (ativo fora da CMDB, sem identificação, crítico sem monitoramento, serviço fora do catálogo, ausência de dono operacional ou de evidência verificável).

### 6.2.1 Trava trilateral de faturamento (mesmo CI, três contratos)

Para **pressão cruzada** entre fornecedores e redução de “conforto” com pagamento parcial sobre ativo mal governado, o ANS pode prever **suspensão de faturamento** vinculada ao **mesmo** CI ou serviço digital na base remunerável do período:

- **Gatilho:** item **não governável** (conforme 5.2) **ou** **fora do padrão mínimo** pactado (checklist objetivo por unidade de remuneração), **sem** enquadramento em **ARRC** (seção 7).
- **Efeito:** enquanto o gatilho perdurar, **não haverá** remuneração por resultado **atribuível àquele CI ou serviço** nos **Contratos 1, 2 e 3** no **mesmo** período de medição; **Outros** (seção 8) vinculados àquele objeto ficam igualmente **sem pagamento** no período.
- **Relação com 6.1.1:** a **reincidência** de mesma natureza (90 dias) **não** substitui este gatilho quando estiver configurado **não governável** ou **falta estruturante**; quando o ativo **permanecer governável**, prevalece a **escala de ocorrências** (**6.1.1**) face à suspensão nos três contratos, salvo cláusula de exceção no ANS (incidente de impacto excecional).
- **Precedência:** a suspensão **prevalece** sobre percentuais de não conformidade leve/média/grave quando o ANS assim vincular o “fora do padrão mínimo” ao regime de suspensão; a **glosa transitória por visibilidade** (6.4) **não** se cumula com a mesma causa de suspensão — **vedado efeito punitivo duplo** pelo mesmo fato.
- **Decisão:** dúvidas de enquadramento (suspensão vs. ARRC vs. glosa específica) competem à **Administração**, com registro no ITSM.

Redação consolidada e tabela de evidências mínimas: [IMR-sintese-executiva.md](./IMR-sintese-executiva.md).

### 6.3 Regra de Glosa Específica

Quando o ativo for governável, mas houver falha específica, a glosa deve atingir prioritariamente o contrato responsável:

| Falha | Principal responsável |
|-------|----------------------|
| Servidor offline por falha operacional | Contrato 2 |
| Patch atrasado | Contrato 2 |
| Backup inválido | Contrato 3 |
| EDR inativo | Contrato 3 |
| Falha de monitoramento | Contrato 1 |
| CMDB desatualizada | Contrato 1 (salvo falta de dado do Contrato 2) |
| Vulnerabilidade sem revalidação | Contrato 3 |
| Chamado encerrado indevidamente | Contrato 2 |
| SLA medido incorretamente | Contrato 1 |
| Consumo de nuvem sem alerta | Contrato 1 |
| Consumo de nuvem sem ajuste técnico após acionamento | Contrato 2 |
| Evidência obrigatória do Contrato 2 ou 3 não visível ao Contrato 1 no canal pactado, **sem** nexo de impedimento no Contrato 1 | Contrato 2 ou Contrato 3 (conforme origem da evidência) — detalhe na **6.4** |
| Impedimento à visibilidade das evidências do Contrato 2 ou 3 **atribuível ao Contrato 1** | Contrato 1 — detalhe na **6.4** |

Para a mecânica de **glosa transitória por visibilidade** (percentuais, não cumulatividade e escalação), aplicar a **seção 6.4**.

### 6.4 Glosa transitória por visibilidade de evidências ao Contrato 1

**Finalidade:** simetrizar o controle quando o Contrato 1 audita evidências dos Contratos 2 e 3, mas a **consultabilidade** dessas evidências no canal oficial de fiscalização falha ou gera disputa de nexo. Esta subseção **não substitui** a escala de pagamento por estado do ativo (seção 5); trata de **glosa contratual sobre a parcela remunerável da unidade afetada** no contrato do prestador, com percentuais a ratificar no ANS.

**Distinção em relação à seção 5:** os percentuais abaixo incidem sobre o **valor faturado da unidade remunerável afetada** naquele período, pelo **contrato** responsável pelo nexo (C2, C3 ou C1). A convivência com as faixas de estado do ativo (ex.: não conformidade grave a 20%) deve ser disciplinada no ANS (**vedado efeito punitivo duplo** pelo mesmo fato).

**Evidência visível ao Contrato 1:** considera-se atendido quando a evidência estiver **registrada e consultável** no ITSM ou no(s) painel(is) de governança pactuados, com vínculo a ativo ou serviço identificável (CMDB ou catálogo), **sem** que o aceite manual do Contrato 1 seja condição para a **existência** do registro, e dentro do **prazo máximo de publicação ou ingestão** fixado no ANS.

**Contrato 2 e Contrato 3 — glosa transitória de 10%:** enquanto a evidência exigida pelo modelo ou pelo ANS para a unidade remunerável afetada **não estiver visível** ao Contrato 1 no canal oficial, aplica-se **glosa de 10%** sobre o **valor dessa unidade** no período de faturamento. A glosa **cessa automaticamente** no período seguinte à regularização. Aplica-se **somente** quando não estiver caracterizado impedimento com **nexo no Contrato 1** sobre a mesma pendência (vide item seguinte).

**Contrato 1 — glosa de 20%:** quando houver **impedimento atribuível ao Contrato 1** à visibilidade das evidências do Contrato 2 ou 3 — incluindo indisponibilidade da ferramenta ITSM sob gestão do C1; regra ou fluxo de gestão de mudanças, incidentes ou catálogo que impeça registro ou consulta **sem culpa** do C2 ou C3; ou falhas já enquadradas na tabela da seção 6.3 como falha de monitoramento, CMDB desatualizada **por responsabilidade exclusiva do C1**, SLA medido incorretamente — **e** o Contrato 2 ou 3 tiver cumprido o dever de publicar no canal pactuado **com comprovação documentada**, aplica-se **glosa de 20%** sobre o **valor da mesma unidade remunerável afetada** no período, até cessar o impedimento.

**Não cumulatividade:** não se aplicam **simultaneamente**, sobre o mesmo item e o mesmo período de faturamento, a glosa transitória de 10% (C2 ou C3) e a de 20% (C1). Havendo divergência sobre o nexo causal, a **Administração** decide, com registro formal no ITSM.

**Arbitragem e conflito de papéis:** nas divergências sobre nexo entre **falta de visibilidade** (esta subseção) e **impedimento atribuível ao Contrato 1**, o Contrato 1 **não** atua como árbitro único da própria causa; aplica-se a **exceção** descrita na seção 11 (arbitragem), preservando a **decisão final da Administração**.

**Prazos e escalação (recomendações para o ANS):** definir prazo máximo de permanência da situação sem tratativa; após limiar (ex.: 15 dias corridos, se assim pactuado), escalonamento para deliberação da Administração; vedada a perpetuação indefinida sem plano de saneamento.

**Relação com a seção 7 (ARRC):** quando a indisponibilidade de evidência ou de consulta decorrer de **restrição comprovada do contratante** (e não de omissão do C2/C3 nem de falha do C1), prevalece o regime de tolerância da seção 7; **não** se aplica a presente subseção como penalidade ao Contrato 2 ou 3.

---

## 7. Limitação Causada pelo Contratante

### 7.1 Situações Previstas

Pode haver casos em que o ativo não esteja conforme por limitação do próprio órgão contratante, tais como: equipamento ainda não entregue formalmente, impossibilidade de acesso físico, ausência de autorização administrativa, dependência de fornecedor externo, falta de licença adquirida pela Administração, pendência de aceite de risco, decisão institucional de não aplicar atualização, janela de manutenção negada, credencial não fornecida, bloqueio por política interna, indisponibilidade de link contratado diretamente pelo órgão, ou ativo legado sem compatibilidade técnica imediata.

Quando a impossibilidade de o Contrato 1 **consultar** evidências no canal oficial resultar de **restrição imputável ao contratante** (por exemplo, acesso não concedido à ferramenta de governança, pendência institucional), prevalece o regime **ARRC** desta seção; **não** incide a glosa transitória por visibilidade da **seção 6.4** contra o Contrato 2 ou o Contrato 3.

### 7.2 Regra

> **Não se deve penalizar o prestador por falha que ele não causou, mas também não se deve pagar integralmente por serviço não prestado.**

### 7.3 Estado de Tolerância: ARRC

> **Ativo em Regularização Assistida por Restrição do Contratante — ARRC**

### 7.4 Efeito Financeiro

| Situação | Efeito |
|----------|--------|
| Restrição comprovadamente causada pelo contratante | Sem penalidade ao prestador |
| Serviço parcialmente prestado | Pagamento proporcional |
| Serviço não prestado por impossibilidade real | Suspensão parcial do pagamento daquela parcela |
| Prestador omisso em registrar ou escalar a restrição | Glosa aplicável ao prestador |
| Restrição não documentada | Não se aplica tolerância |

### 7.5 Percentual de Tolerância Sugerido

| Condição | Pagamento sugerido |
|----------|:-----------------:|
| Prestador executou tudo que era possível e documentou impedimento | 50% a 80% da unidade |
| Prestador apenas aguardou sem plano de ação | 0% a 20% |
| Prestador registrou, escalou, propôs solução e depende do contratante | 70% a 80% |
| Serviço não pode ser tecnicamente prestado de nenhuma forma | Suspensão do item até saneamento |
| Restrição superada, mas prestador não regularizou no prazo | Glosa normal |

### 7.6 Prazo de Tolerância

1. Até 30 dias: tolerância ordinária
2. De 31 a 60 dias: exige plano de regularização
3. Acima de 60 dias: decisão formal da Administração
4. Acima de 90 dias: revisão do escopo, aceite de risco ou exclusão temporária da base remunerável

> A tolerância não pode virar pagamento permanente por ativo irregular. Ela deve ser transitória, documentada e vinculada a plano de saneamento.

---

## 8. Serviços sob Demanda e Situações Sazonais

### 8.1 Premissa

Além da remuneração por ativo conforme, o contrato deve prever **serviços sob demanda** para eventos sazonais, expansões, projetos pontuais ou necessidades extraordinárias.

### 8.2 Principais Serviços sob Demanda

| Área | Exemplos |
|------|---------|
| **Endpoints** | Instalação massiva, substituição de parque, migração de usuários, inventário físico assistido |
| **Rede e Wi-Fi** | Implantação de nova rede sem fio, expansão de APs, rede temporária para evento, site survey |
| **Nuvem** | Criação de ambiente, migração de workload, redimensionamento sazonal, nova landing zone |
| **Segurança** | Operação reforçada sob ataque, hunt específico, investigação forense, varredura extraordinária |
| **Continuidade** | Restore extraordinário, teste adicional de DR, simulado institucional, migração de política de backup |

### 8.3 Forma de Remuneração sob Demanda

Usar **ordem de serviço específica**, contendo: descrição do serviço, unidade de medida, quantidade estimada, critério de aceite, prazo, valor unitário, evidência exigida, responsável pelo aceite e relação com ativo/serviço na CMDB.

### 8.4 Exemplos de Unidades sob Demanda

| Serviço | Unidade sugerida |
|---------|-----------------|
| Instalação de computador | Equipamento instalado e aceito |
| Substituição de computador | Equipamento substituído e antigo recolhido |
| Implantação de access point | AP instalado, configurado e monitorado |
| Site survey Wi-Fi | Relatório técnico aceito |
| Criação de ambiente cloud | Ambiente criado e validado |
| Migração de workload | Workload migrado e validado |
| Restore extraordinário | Restore executado e aceito |
| Investigação de incidente | Relatório técnico aceito |
| Simulado de DR | Exercício executado e relatório aprovado |
| Regra WAF emergencial | Regra implantada, testada e registrada |

> Serviço sob demanda não deve ser usado para remunerar rotina ordinária. Ele deve cobrir eventos excepcionais, sazonais ou projetos delimitados.

### 8.5 Teto financeiro para “Outros” (sétima unidade)

A unidade residual **Outros** (serviços sob demanda remunerados por catálogo + OS, conforme 8.1 a 8.4) deve observar **limite global** pactado no ANS:

- **Teto:** a soma dos valores **pagos** na linha “Outros” em cada contrato, no **período de faturamento** (ex.: mês civil), **não ultrapassa 10%** do **valor total** daquele contrato, salvo reajuste formal de plano e autorização da Administração.
- **Controle:** saldo disponível = teto menos valores já pagos no período (ou no critério acumulado definido no ANS); OS que exceder o saldo **não gera direito** até regularização.
- **Vedação:** não utilizar “Outros” para remunerar obrigação ordinária, retrabalho por falha da contratada, correção de descumprimento, substituição de glosa ou **burlar** a trava trilateral da **seção 6.2.1**.

Detalhamento: [IMR-sintese-executiva.md](./IMR-sintese-executiva.md), seção 4.

---

## 9. Condição "Sob Ataque"

### 9.1 Definição

Considera-se condição "sob ataque" quando houver evidência ou forte indício de evento malicioso que afete confidencialidade, integridade, disponibilidade, identidade, infraestrutura, aplicações ou dados (DDoS, ransomware, malware disseminado, comprometimento de credencial, exploração ativa de vulnerabilidade, exfiltração suspeita, desfiguração de portal, uso indevido de conta privilegiada etc.).

### 9.2 Responsabilidades em Crise

| Ação | Responsável |
|------|-------------|
| Detecção inicial de segurança | Contrato 3 |
| Detecção de indisponibilidade | Contrato 1 |
| Coordenação de crise | Contrato 1 + Administração |
| Contenção de ameaça | Contrato 3 |
| Execução de bloqueios técnicos em infraestrutura | Contrato 2 (sob orientação do 3) |
| Regras WAF/DDoS/Cloudflare de segurança | Contrato 3 |
| Ajustes de rede, DNS, balanceamento ou servidores | Contrato 2 |
| Comunicação operacional | Contrato 1 |
| Comunicação institucional externa | Administração |
| Preservação de evidências | Contrato 3 |
| Linha do tempo do incidente | Contrato 1 (com insumos do 2 e 3) |
| Restauração de serviços | Contrato 2 e/ou 3 conforme natureza |
| Restore | Contrato 3 (com apoio do 2) |
| Relatório pós-incidente | Contrato 1 + Contrato 3 |
| Plano de correção | Contrato responsável pela causa |

### 9.3 Regra de Prioridade

1. Conter o ataque
2. Preservar evidências
3. Manter ou restaurar serviços críticos
4. Reduzir superfície de exposição
5. Comunicar adequadamente
6. Registrar decisões
7. Corrigir causa raiz
8. Revisar controles

> O Contrato 3 orienta a resposta de segurança, mas **não deve assumir operação ordinária** de servidores, redes, banco ou aplicações. A execução técnica sobre esses componentes continua com o Contrato 2.

---

## 10. Modelo de RACI Obrigatório

### 10.1 Regra

Cada serviço deve ter matriz RACI com um responsável pela execução, um responsável final pelo resultado, consultados e informados, sem duplicidade de responsável final.

### 10.2 Modelo Simplificado

| Atividade | Contrato 1 | Contrato 2 | Contrato 3 | Administração |
|-----------|:----------:|:----------:|:----------:|:-------------:|
| Monitorar disponibilidade | R | C | C | I |
| Operar infraestrutura | I | R/A | C | I |
| Operar segurança | I | C | R/A | I |
| Executar backup | I | C | R/A | I |
| Corrigir servidor | I | R/A | C | I |
| Corrigir vulnerabilidade em servidor | I | R/A | C/R na validação | I |
| Validar correção de vulnerabilidade | I | C | R/A | I |
| Aprovar mudança crítica | R/C | C | C | A |
| Executar mudança | I | R/A | C | I |
| Coordenar crise | R | C | C | A |
| Comunicar usuários | R | C | C | A |
| Aplicar glosa | C | I | I | A |
| Decidir nexo em disputa de visibilidade de evidências (seção 6.4) | C | C | C | A |

**Legenda:** R = Responsável pela execução | A = Accountable (responsável final) | C = Consultado | I = Informado

Na linha **Decidir nexo em disputa de visibilidade**, os três contratos figuram como **consultados** por fornecerem subsídios técnicos; a **Administração** é a **accountable** pela decisão final, evitando que o Contrato 1 arbitre sozinho quando for parte interessada.

---

## 11. Regras para Evitar Jogo de Empurra

1. **Dono operacional único:** cada serviço terá um único dono operacional.
2. **Repasse com evidência:** nenhum chamado poderá ser devolvido ou repassado sem evidência técnica.
3. **Responsabilidade até aceite:** o chamado permanece com o contrato acionado até que o repasse seja aceito no ITSM ou decidido pelo Contrato 1/Administração.
4. **Penalidade por repasse indevido:** repasse indevido, tardio ou sem evidência pode gerar glosa.
5. **Obrigação de apoio:** mesmo quando não for responsável principal, a contratada deve apoiar a solução dentro de sua competência.
6. **Arbitragem operacional:** divergência entre contratos será arbitrada operacionalmente pelo Contrato 1, com decisão final da Administração. **Exceção:** em disputa sobre **nexo causal** relativo à **glosa transitória por visibilidade de evidências** (seção 6.4) — ou seja, se a ausência de visibilidade deve-se ao Contrato 2 ou 3, ao Contrato 1 ou a fatores externos —, o Contrato 1 **não** decide sozinho quando for parte interessada; a **Administração** promove a deliberação final com subsídios técnicos dos contratos, com registro no ITSM.

---

## 12. Pontos de Observação Críticos

| Tema | Distribuição | Observação |
|------|-------------|------------|
| **Nuvem** | Contrato 2 opera · Contrato 1 controla consumo · Contrato 3 valida segurança | Sem limites, alertas e responsáveis claros, nuvem pode gerar risco financeiro relevante |
| **Cloudflare** | Contrato 2 publica · Contrato 3 protege · Contrato 1 monitora | Regras de WAF e DDoS não devem ser alteradas sem registro e evidência |
| **Backup** | Contrato 3 faz backup e restore · Contrato 2 apoia infraestrutura · Contrato 1 valida evidências | Backup só tem valor contratual se for recuperável |
| **CMDB** | Requisito estruturante | Ativo fora da CMDB tende a ser ativo não governável, salvo período formal de transição |
| **Serviços sob demanda** | Devem existir para sazonalidade | Não devem substituir serviço ordinário nem remunerar retrabalho por falha da contratada; teto **10%** do contrato (**seção 8.5** e [IMR-sintese-executiva.md](./IMR-sintese-executiva.md)) |
| **Trava trilateral** | C1 + C2 + C3 | CI fora do padrão mínimo ou não governável **sem ARRC** pode **zerar** faturamento vinculado naquele período nos **três** contratos (**6.2.1**) |
| **Ativo conforme** | Principal unidade de remuneração | O modelo depende de evidência automática confiável. Sem automação, o custo de fiscalização aumenta |
| **Limitação do contratante** | Tolerância prevista (ARRC) | Tolerância não significa pagamento integral — ausência de penalidade indevida com pagamento proporcional ao que foi possível prestar |
| **Visibilidade de evidências ao C1** | C2/C3 publicam no canal pactado · C1 opera ITSM/painéis · Admin decide nexo em disputa | Glosa transitória **10%** (C2/C3) ou **20%** (C1 causador), **não cumulativa** — seção **6.4**; restrição do contratante enquadra **ARRC** (seção 7), não a 6.4 contra C2/C3 |

---

## 13. Cláusulas Conceituais Sugeridas

### 13.1 Cláusula de Remuneração por Ativo Conforme

> A remuneração dos serviços será baseada em unidades de ativos ou serviços conformes, observados critérios objetivos de governança, operação, segurança, continuidade, monitoramento, documentação e evidência. A simples existência física ou lógica do ativo não gera direito ao pagamento integral, sendo necessário que o item esteja registrado, monitorado, protegido, documentado e operacional conforme os requisitos aplicáveis.

### 13.2 Cláusula sobre Limitação Causada pelo Contratante

> Quando a não conformidade decorrer de fato atribuível exclusivamente à Administração, de restrição institucional, de ausência de autorização, de indisponibilidade de acesso, de pendência de licenciamento, de decisão formal de risco ou de dependência externa não gerida pela contratada, não será aplicada penalidade ao prestador, desde que a restrição esteja registrada tempestivamente no ITSM, acompanhada de evidências e de plano de regularização. Nesses casos, o pagamento será proporcional aos serviços efetivamente prestados, vedado o pagamento integral por serviço não executado ou ativo não governável.

### 13.3 Cláusula sobre Serviços sob Demanda

> Além das unidades ordinárias de ativos e serviços conformes, poderão ser executados serviços sob demanda mediante ordem de serviço específica, com unidade de medida, quantidade, prazo, valor, critério de aceite, evidência obrigatória e vínculo com ativo, serviço ou projeto registrado na ferramenta ITSM e, quando aplicável, na CMDB. A soma dos pagamentos realizados nessa modalidade, por contrato e por período de faturamento, ficará **limitada a 10%** do valor total do respectivo contrato, vedada sua utilização para remunerar rotina ordinária, retrabalho ou serviços já contemplados nas unidades ordinárias.

---

## 14. Fechamento do Modelo

O modelo final organiza-se da seguinte forma:

| # | Elemento | Descrição |
|---|----------|-----------|
| 1 | **Contrato 1** | Governa, mede, monitora, evidencia e coordena |
| 2 | **Contrato 2** | Opera infraestrutura, suporte, redes, nuvem, banco, endpoints e aplicações |
| 3 | **Contrato 3** | Protege, detecta, responde, controla identidade, faz backup e garante recuperação |
| 4 | **Remuneração** | Ocorre por ativo ou serviço conforme (**6 unidades ordinárias** + **Outros** com teto 10% — **8.5** e [IMR-sintese-executiva.md](./IMR-sintese-executiva.md)) |
| 5 | **Não governável / fora do padrão mínimo** | Pode gerar pagamento zero; com **6.2.1**, suspensão de faturamento vinculado ao CI nos **três** contratos no período, salvo ARRC |
| 6 | **Glosa** | Específica por falha (6.3); por visibilidade de evidências ao C1 (6.4) — transitória 10% (C2/C3) ou 20% (C1 causador), não cumulativa; Admin decide nexo em disputa; **sem** duplicar punição com **6.2.1** |
| 7 | **Tolerância ARRC** | Restrição do contratante → sem penalidade, com pagamento proporcional |
| 8 | **Sob demanda (“Outros”)** | OS + catálogo; **teto 10%** do valor do contrato por período de faturamento (**8.5**) |
| 9 | **Administração** | Mantém decisão final, fiscalização e aplicação de consequências contratuais |

---

*Documento elaborado com base no modelo de referência de contratação de Operações de TI — versão final consolidada.*