“Quem será o responsável por debugar a mariposa enterrada no relê!”
Disaster Recovery Planning, Política de continuidade de negócio, planejamento de riscos, plano de contingência, plano de recuperação de desastres… Passamos hoje a entender este “monstro” da gestão em TI e quais os fatores jurídicos que fizeram com que as principais normas internacionais em TI contemplassem esta medida.
Muito tem a dizer uma passagem do livro do ilustre jurista Daniel Ustarróz (in Responsabilidade Contratual, Editora RT, 2a. Edição), que assim dispõe: “afinal o homem diligente é aquele que mais simula hipóteses abstratas (como a desvalorização cambial, terrorismo, hiperinflação etc.), mas no jogo das probabilidades as têm por remotas”
Moral da história é que previsíveis todas as situações de fato podem ser, agora, o difícil é contemplar no “jogo das probabilidades” quais incidentes realmente são “possíveis”, afastando situações remotas. E este é o desafio da Governança contemporânea: Contemplar um plano de contingência que o assegure de eventual inadimplência contratual com seu cliente, em nível de Service Level Agreement, e que ao mesmo tempo não seja um “tratado” contendo situações mais que improváveis.
Diz a lenda (porque eu não estava lá para ver), que o primeiro Bug foi originado por uma inseto (bug) que andava a passear no circuito de um computador, daí o termo. O termo é geralmente (mas erroneamente) creditado a Grace Hopper. Em 1946, ela trabalhava no Laboratório de Computação da Faculdade de Harvard, onde rastreou um erro no Harvard Mark II até chegar a uma mariposa enredada em um relé. Este inseto (bug, em inglês) foi cuidadosamente removido e colocado no livro de registros
Agora indago: Pode acontecer de uma mariposa obstar o funcionamento de um sistema computacional? Pode! Mas, e a probabilidade de isto acontecer?
Todo este exercício foi cuidadosamente conduzido para que pudéssemos transmitir a vocês como os Tribunais estão se manifestando quando o assunto é rescisão contratual por inadimplemento em contratos de TI. Evidentemente que muitos tomadores de serviços em TI tem se valido de cláusulas de SLA e Contingência para efetivamente criar meios para resoluções de contrato em quaisquer casos! O Analista Sênior escorregou no sabonete? Bem, como vocês tratam esta situação? 4 horas é suficiente para resolver! Paranóia!
Pode parecer hilário, mas o assunto é sério. Tenho casos de clientes que foram compelidos a consignarem em seus PCNs até mesmo situações como “Chuva”, “Ventania”, “Estado de espírito de colaboradores”, dentre outros! Ou seja, a empresa tem efetivamente que “Parar a chuva” em 2 horas! Querem que ela seja Deus?
Descontração à parte, falo do aspecto jurídico! São obrigações desproporcionais segundo a Lei Brasileira, e que se levadas à apreciação do Judiciário, certamente serão consideradas disposições nulas. Temos feito a revisão IT Compliance em Planos de Contingência em empresas e verificado que em verdade tinha um amontoado de páginas sem adequação legal alguma!
Não estamos pregando o fim do Plano de Contingência, mas que sejam elaborados com base nas normas técnicas, e lhes garanto, é mais fácil que se imagina e não há necessidade de modelos. Contingenciar é pensar antecipadamente, é prever situações em um estágio onde se pode pensar com a “cabeça fria”. A contingência deve existir em todas as áreas da atividade humana e vem crescendo sua preocupação quando o assunto são contratos de tecnologia. Desmistificando os “mitos”, os passos são simples, e segundo John Watkins (http://www.drj.com/new2dr/w2_011.htm):
“This analysis should serve the following purposes:
- identify the potential risks,
- estimate the effects of a disaster on the organization, and
- determine the requirements for a recovery strategy.”
No que diz respeito a exigências legais que fundamentam a elaboração de um plano de contingência, encontramos as seguintes legislações:
- Código Civil Brasileiro – Lei 10.404/2002
- Código de Defesa do Consumidor – Lei 8078/1990
- Resolução 3.380 do Conselho Monetário Nacional
Igualmente, nas principias normatizações nacionais e internacionais sobre segurança da informação e governança, encontramos a necessidade da manutenção do Plano de Contingência:
- NBR ISO IEC 27001:2006: Prevê que o Plano de Contingência seja documentação testada e integrante do Chamado SGSI ( Sistema de Gestão de Segurança da Informação), que é o resultado da aplicação planejada de objetivos, diretrizes, políticas, procedimentos, modelos e outras medidas administrativas que, conjuntamente, definem como são reduzidos os riscos para segurança da informação. (A.14) Também prevê a implantação no modelo PDCA (Plan-Do-Check-Act ou Planejar-Executar-Verificar-Agir) onde não basta possuir documentação, é preciso demonstrar que tudo foi absolutamente testado.
- NBR ISO/IEC 17799: Prevê a “Gestão da Continuidade do Negócio” onde demonstra imperativo que empresas detenham um Plano de Contingência testado e atualizado.
- Serbanes-Oxley (2002): Prevê em sua seção 404 (Management Assessment of Internals Controls), (103) (Auditing, Quality Control, And Independence Standards and Rules) e 409 (Real Time Disclosure), a necessidade de um plano de gerenciamento de Riscos em frameworks nacionais e internacionais como CobIT e ITIL.
Como se verifica, mais do que um “luxo” ou condição para grandes contratações, o Plano de Contingência é requisito indispensável de todas as normas envolvendo Tecnologia. Deve-se ter em mente que só documentação basta apenas para as chamadas “pré-auditorias”, sendo que auditorias “on-the-fly” ocorrerão, para se verificar na prática o disposto nas documentações. Por outro lado, deve-se revisar com o Jurídico tais disposições, para que suas cláusulas não constituam abusividades ou nulidades, eis que nos termos do Código Civil de 2002, em seu artigo 393: “O devedor não responde pelos prejuízos resultantes de caso fortuito ou força maior, se expressamente não se houver por eles responsabilizado”. Muita atenção às empresas de TI que se comprometem por contrato a condições não muito factíveis, eis que “O Contrato faz lei entre as partes”.
No próximo artigo falaremos sobre a Contingência na Forense Computacional e dos Tópicos necessários para a concepção deste Documento.







