SDR — Trilateralidade C1-GOV ↔ C2-OPR ↔ C3-SEC: cobrança mútua

Página estática gerada a partir do Markdown do repositório — o texto abaixo já vem no HTML (adequado a importação por URL em ferramentas que não executam o ver-md.html). Arquivo: sdr-0011c-c1-trilateralidade-cobranca-mutua.md

Baixar o .md — Abrir no visualizador Markdown — Catálogo de SDRs — Início do site

Fonte: SDRs/sdr-0011c-c1-trilateralidade-cobranca-mutua.md

SDR — Trilateralidade C1-GOV ↔ C2-OPR ↔ C3-SEC: cobrança mútua

Eixo: Ambos (Modelo de Serviços | Arquitetura Contratual | Ambos)

Campo Valor
Pai sdr-0011-governanca-c1-medicao.md
SSoT Sim — dono do texto canônico da cobrança mútua entre os três contratos no âmbito SDR; consumidor narrativo: arquitetura-contratual/site/governanca.html#trilateralidade (com remissão de seguranca.html)
Status Em validação

1. Finalidade

Fixar, como sub-SDR de sdr-0011 e em harmonia com sdr-0001, a lógica de cobrança mútua que sustenta a maturidade do serviço: três contratos independentes que se cobram entre si, sem subordinação operacional, com a Administração como árbitro e decisora. Texto canônico da matriz de cobranças (anteriormente espalhado em seguranca.html#trilateralidade) passa a viver aqui.

2. Princípios

  • Sem subordinação operacional entre fornecedores. Os três contratos são pares; respondem aos mesmos parâmetros do ANS, mas com cláusulas distintas.
  • Vedação de duplo papel — quem opera não fiscaliza; quem mede não opera disfarçado; quem protege não esconde achados de quem mede.
  • Cobrança com nexo e evidência — sem retórica; toda cobrança remete a obrigação contratual, evidência observável e impacto.
  • Administração arbitra — em disputa de nexo, ARRC, exceção e trava trilateral, a decisão é da Administração; o C1-GOV instrui.
  • Mesma falha não gera dupla punição financeira entre contratos.
  • Trava trilateral corta faturamento dos três contratos no mesmo período se o item for não governável e não houver ARRC.

3. Matriz de cobranças mútuas (canônica)

Evento ou exigência Quem dispara Quem executa Quem mede e atesta
Patch crítico em servidor de produção C3-SEC (priorização por risco) C2-OPR (janela e mudança) C1-GOV (cumprimento do SLA, evidência no ITSM)
Endurecimento (hardening) de baseline C3-SEC (define padrão) C2-OPR (aplica e mantém) C3-SEC valida; C1-GOV mede aderência
Incidente de segurança detectado pelo SOC C3-SEC (detecção) C2-OPR (bloqueio, isolamento, restauração técnica) C3-SEC conduz IR e RPI; C1-GOV mede tempos e linha do tempo
Falha operacional com sintoma de segurança C2-OPR (alarme do NOC) Handover ao SOC C3-SEC e tratamento conjunto C1-GOV fiscaliza linha do tempo e custódia
Ciclo joiner/mover/leaver (IAM) Administração / C1-GOV C3-SEC (governança IAM) com C2-OPR (provisionamento) C1-GOV audita evidência
Restauração de backup (teste de DR) C3-SEC (calendário e cenário) C2-OPR (execução) C1-GOV valida resultado contra RTO/RPO
Mudança em produção que afeta postura C2-OPR (RFC) com revisão obrigatória do C3-SEC C2-OPR (executa após aprovação) C1-GOV (registro, ateste); C3-SEC acompanha pós-mudança
Fechamento mensal do IMR C1-GOV (calendário) C2-OPR e C3-SEC (entrega de evidência) C1-GOV consolida; Administração decide ateste/glosa
Trava trilateral (item não governável) C1-GOV (constatação) Administração (enquadramento) C1-GOV registra; corte nos três contratos no período

4. Incidente ativo: restauração antes da imputação contratual

  • Prioridade técnica: enquanto houver incidente degradante ou prioridade crítica pactuada (ex.: P1), contenção, workaround e restauração do serviço — com registro mínimo de linha do tempo no ITSM — precedem a discussão de culpa contratual entre C2-OPR e C3-SEC e não podem ser suspensas por disputa de nexo em curso.
  • Imputação financeira diferida: glosa, nexo para SLA e decisão sobre responsabilidade contratual seguem o rito do ciclo (sdr-0011b), contraditório ou comitê em janela pactuada no ANS/TR — salvo hipótese de fraude ou dolo com procedimento escrito no instrumento (não confundir com registro factual mínimo durante o incidente).
  • Duas salas: a sala de incidente (resposta operacional — NOC C2-OPR, SOC/ETIR C3-SEC, handover técnico) não é substituída pela sala de crise contratual (sdr-0011b §4); esta última trata de disputa de nexo, ARRC, trava e coordenação com a Administração, sem bloquear a execução técnica urgente.
  • Coerência com glosa: medidas transitórias de visibilidade ou nexo já previstas no ANS (sdr-0005, sdr-0010) não autorizam paralisar contenção ou restauração; quando houver tensão entre texto de glosa e restauração, prevalece restauração até decisão explícita da Administração escrita no instrumento ou aditivo.

5. RACI mínimo nas fronteiras (exemplos; detalhe no TR)

A matriz abaixo fixa princípio para reduzir zonas cinzentas; o detalhe (nomes, ferramentas, exceções) vive no TR e em anexo RACI do certame, sem repetir aqui como texto canônico paralelo.

Fronteira típica C1-GOV C2-OPR C3-SEC Administração
Patch crítico em ativo de segurança (ex.: firewall, WAF) em produção Mede SLA e evidência; I na janela R/A execução e mudança C validação de postura; A interno C3 sobre playbook A janela ou exceção institucional
Mudança em produção que altera postura de segurança R registro e pauta de medição; mede após R/A RFC e execução após aprovação C obrigatório pré-produção; validação pós-mudança A mudanças críticas institucionais
Teste de backup/restore (execução operacional) R/A ateste vs RTO/RPO pactuados R/A execução técnica C cenário e calendário de DR A aceite de risco quando aplicável
Provisionamento IAM (joiner/mover/leaver) Audita evidência; I no fluxo R/A execução na plataforma R/A política e governança IAM A política e perfis institucionais

Legenda resumida: R responsável (executa), A autoridade (decide no polo), C consultado, I informado — conforme uso no site; refinamento por papel está no TR.

6. O que C1-GOV cobra de C2-OPR e de C3-SEC

  • Evidência consultável de tudo que entra no IMR: ITSM, SIEM, ferramentas de mudança, relatório de teste de backup, base CMDB congelada no período.
  • Aderência ao PPSI/LGPD (sdr-0014) e à matriz de riscos (sdr-0012); recortes do C1-GOV em sdr-0011d.
  • Coerência entre catálogo e execução — o que está prometido acontece, com trilha auditável.
  • Qualidade do dado e integridade do log: relógios sincronizados (NTP), formatos pactuados, sem lacuna silenciosa.
  • Tempestividade — SLA por classe respeitado; sem reabertura silenciosa, sem reclassificação fora de procedimento.
  • Trava trilateral e glosa conforme sdr-0005: nenhum dos três cobra o que não comprova.

7. O que C3-SEC cobra de C2-OPR

  • Aplicação de patches e baselines no prazo definido por classe de risco; sem postergar sem aceite formal.
  • Hardening efetivo (SO, banco, rede, aplicação) e ausência de configuration drift em produção.
  • Segregação e gestão de acessos privilegiados (PAM) coerentes com o desenho do C3-SEC, sem contas compartilhadas ou bypass.
  • Backup testado com evidência de restore dentro do RTO/RPO; sem “backup que ninguém testou”.
  • Logs íntegros e enviados ao SIEM no formato e no relógio acordados; sem lacuna silenciosa.
  • Mudança comunicada ao C3-SEC antes de afetar produção; janela respeitada; rollback documentado.

8. O que C2-OPR cobra de C3-SEC

  • SLA do SOC — tempo de primeiro reconhecimento, qualidade de triagem, redução de falso positivo que sobrecarrega filas operacionais.
  • Playbook usável — instruções claras para o C2-OPR executar bloqueio sem improviso e sem risco de quebrar produção legítima.
  • Liberação de regras (WAF, EDR, firewall) quando o impacto operacional for desproporcional ao risco residual.
  • Devolução de credencial PAM e break-glass em tempo hábil.
  • RPI no prazo, com causa raiz e ações que o C2-OPR consiga implementar.
  • Calendário de DR e exercícios compatível com janelas operacionais.

9. O que C2-OPR e C3-SEC cobram de C1-GOV

  • Tempo de decisão da Administração sobre exceções, risco aceito, bloqueios e janelas críticas — o C1-GOV é responsável por levar a pauta no ritmo necessário e medir o atraso.
  • Congelamento da base CMDB no período de medição e regra clara de inclusão e exclusão de CI.
  • Integridade do ITSM e da numeração de incidente.
  • Proteção contra dupla cobrança — o mesmo CI não pesa em denominadores incompatíveis entre C2-OPR e C3-SEC.
  • Critério de evidência mínima publicado por unidade IMR.
  • Relatório transparente de qualidade do dado, com pontos cegos declarados e plano de saneamento.

10. Vedação de duplo papel (resumo)

O fornecedor que opera C1-GOV não pode também operar C2-OPR ou C3-SEC do mesmo serviço — quem mede não opera; quem opera não atesta a si próprio. O desenho lógico admite acesso de leitura cruzada (consolidar evidência exige ler logs e registros de C2-OPR/C3-SEC), mas quem decide ateste, glosa ou aceitação de risco não é o avaliado. Norma matriz: sdr-0001. Controle operacional: C1-GOV em conjunto com a Administração.

11. ARRC e trava trilateral

  • ARRC (ato/restrição de responsabilidade do contratante) — força maior, óbice imputável à Administração; suspende a cobrança de SLA enquanto durar e for documentado, sem mover a base remunerável de modo silencioso.
  • Trava trilateral — quando o item está não governável e não há ARRC, corta faturamento nos três contratos no mesmo período. A decisão de enquadramento é da Administração. Texto canônico: sdr-0005.

12. Regras para agentes

  • Em cobrança mútua, indicar quem dispara, quem executa, quem mede e atesta (formato da matriz §3); para RACI em fronteira típica, remeter ao quadro §5 sem copiar o TR.
  • Não criar duplicidade desta tabela em outros sdr-*.md; remeter a este sub-SDR.
  • Em material novo, manter o tom “sem retórica, com nexo e evidência”.

13. Consumidores

  • sdr-0011 (hub),
  • arquitetura-contratual/site/governanca.html#trilateralidade (texto canônico no site),
  • arquitetura-contratual/site/seguranca.html#trilateralidade (remissão; mantém apenas trecho específico do C3 — “C3 cobra de C2-OPR” e “C2-OPR cobra de C3-SEC” — com link a este sub-SDR para a matriz central).

14. Ligações

Agentes de conformidade (Cursor)

Agente Regra Cursor Norma em SDRs/governance/rules/
Verificador de conformidade SDR sdr-conformity-checker.mdc sdr-conformity-checker.md
Detector de implementação sem vínculo SDR implementation-without-sdr-detector.mdc implementation-without-sdr-detector.md
Anti-vibecoding sem SDR no-vibecoding-without-sdr.mdc no-vibecoding-without-sdr.md

Processo: governance/README.md · Rastreabilidade código: traceability.md · Checagem: python scripts/check_sdr_conformity.py (na raiz do repositório).