Vale remediar ou reconstruir um SaaS feito por IA para SOC 2?

Um prazo de SOC 2 não transforma código fraco em um projeto de reconstrução. Ele transforma a incerteza no problema que você precisa eliminar. Se você consegue desenhar os limites do sistema, provar quem pode acessar os dados dos clientes e mostrar que os controles funcionam de modo consistente, uma remediação bem delimitada costuma ser mais rápida e segura. Se ninguém consegue explicar identidade, separação entre clientes ou movimentação de dados sem ler componentes aleatórios em produção, aplicar correções talvez apenas torne a incerteza mais difícil de enxergar.

A escolha não é entre «código antigo e código limpo». A pergunta é se o sistema atual consegue sustentar controles compreensíveis, testáveis e estáveis durante o período da auditoria. Já vi equipes substituírem um serviço feio, mas conhecido, poucas semanas antes da coleta de evidências e depois descobrirem que o novo serviço não tinha histórico operacional. Também vi fundadores preservarem um protótipo porque ele parecia funcionar, enquanto cada rota da API implementava autorização de uma forma diferente. As duas equipes otimizaram a variável errada.

Uma decisão sensata usa quatro testes: estabilidade da arquitetura, evidências dos controles, tratamento dos dados e prazo. Faça esses testes antes de prometer uma data de auditoria ou contratar uma reescrita. Seu auditor deve confirmar o escopo e as expectativas sobre evidências, mas a decisão de engenharia pertence às pessoas que precisarão operar o sistema depois da emissão do relatório.

Uma auditoria SOC 2 não avalia a limpeza do código

Um exame SOC 2 trata do sistema de uma organização prestadora de serviços e dos controles relevantes para os Critérios de Serviços de Confiança selecionados. A AICPA descreve o SOC 2 em termos de segurança, disponibilidade, integridade do processamento, confidencialidade e privacidade. Esse enquadramento importa porque um auditor não dá pontos por uma arquitetura da moda, um framework novo ou um repositório arrumado. Ele avalia se a descrição do sistema feita pela administração é correta e se os controles dentro do escopo atendem aos requisitos do trabalho.

Os tipos 1 e 2 também criam pressões diferentes para a engenharia. Um relatório de tipo 1 aborda o desenho dos controles em uma data específica. Um relatório de tipo 2 acrescenta a eficácia operacional durante um período. Pergunte à firma de CPA responsável pelo exame qual período e quais amostras ela espera; a duração e a abordagem de amostragem são decisões do trabalho, não valores que a engenharia deva adivinhar a partir de um artigo.

Essa diferença derruba um discurso de vendas comum: «Reconstrua para passar no SOC 2». Nenhum aplicativo passa no SOC 2 sozinho. A organização define um sistema, opera controles ao redor dele, retém evidências e faz afirmações que o auditor do serviço examina. O comportamento do aplicativo pode apoiar ou prejudicar esses controles, mas um repositório reescrito não substitui revisões de acesso, aprovações de mudanças, resposta a incidentes, gestão de fornecedores nem documentação verdadeira.

Código confuso pode permanecer em um sistema defensável quando a equipe conhece seus limites, testa o comportamento importante e faz mudanças por um processo controlado. Código bonito pode estar dentro de um sistema indefensável quando o acesso à produção é compartilhado, os logs omitem a identidade do agente, segredos ficam no controle de versão ou os deploys ignoram a revisão. Trate a qualidade do código como um sinal de possível falha de controle, não como o critério da auditoria.

Comece definindo o escopo. Liste os serviços de produção, armazenamentos de dados, filas, provedores de identidade, caminhos de deploy, ferramentas administrativas e pessoas que entregam o serviço usado pelos clientes. Marque os componentes excluídos e justifique cada exclusão. Se a equipe não consegue concordar com esse inventário, nenhuma estimativa de remediação ou reconstrução é confiável.

Estabilidade arquitetural significa mudança previsível

Uma arquitetura é estável o bastante para remediação quando os engenheiros conseguem prever o efeito de uma mudança e verificar essa previsão antes da publicação. Ela não precisa de microsserviços, modelagem formal de domínio ou uma nuvem específica. Precisa de responsabilidades claras por identidade, autorização, acesso a dados, configuração e deploy.

Teste a estabilidade com um exercício de impacto da mudança. Escolha um requisito comum, como desativar o acesso administrativo de um funcionário que saiu. Peça à equipe que identifique cada ponto de aplicação, a fonte oficial, o deploy necessário, o teste que comprova a negação, o registro criado e o caminho de reversão. Repita o exercício para excluir os dados de um cliente e trocar um segredo de produção. Se as respostas convergirem para um pequeno conjunto de componentes conhecidos, a remediação tem uma base sólida. Se cada pessoa encontrar mais um caminho oculto, a arquitetura ainda está sendo descoberta.

Aplicativos gerados por IA costumam falhar nesse teste de maneiras reconhecíveis. Um componente do navegador acessa o banco diretamente em um fluxo, enquanto outro usa uma API. Várias rotas confiam em um ID de usuário fornecido pelo cliente. A autorização vive na visibilidade da página, no middleware, nas regras do banco e em verificações de rota escritas à mão, todas com premissas diferentes. Variáveis de ambiente misturam configuração pública e credenciais. Nenhum desses defeitos, sozinho, exige uma reconstrução. A distribuição deles pode exigir.

Conte caminhos de controle, não arquivos. Dez rotas vulneráveis atrás de uma política central podem ser corrigidas e testadas como uma unidade. Três rotas com três modelos de identidade sem relação talvez exijam a troca do limite de identidade. Um repositório grande com uma camada modular de serviços pode ser mais seguro para remediar do que um protótipo pequeno cujas regras de negócio vivem em callbacks da interface e gatilhos do banco.

Uso três descobertas arquiteturais como sinais de reconstrução. Primeiro, o sistema não possui um identificador oficial de cliente ou conta, então o isolamento depende de filtros improvisados. Segundo, ações privilegiadas não têm um único limite de aplicação. Terceiro, o modelo de dados persistente contradiz as verdadeiras regras de propriedade do produto e força cada consulta a reconstruir quem é dono do quê. Quando os três aparecem juntos, correções locais tendem a preservar a mesma ambiguidade sob mais código.

Não confunda código desconhecido com código instável. Uma equipe competente consegue mapear código desconhecido com rastros, testes e observação em execução. A instabilidade aparece quando a mesma entrada chega a decisões de segurança materialmente diferentes por caminhos que ninguém consegue enumerar. Essa é uma propriedade que pode ser investigada, não uma sensação sobre quem escreveu o protótipo.

A estabilidade da arquitetura também inclui responsabilidade operacional. Pergunte quem recebe um alerta quando as falhas de autorização aumentam, quem sabe distinguir um ataque de uma versão quebrada, quem pode desativar o caminho afetado e quem confirma a recuperação. Provoque uma falha controlada em um período tranquilo e acompanhe a resposta desde o sinal até o ticket, a decisão, a correção e o encerramento. Se o aplicativo tem alertas, mas nenhum responsável nomeado, ou se o responsável não possui uma ação segura de contenção, o desenho não é estável em operação. Ainda é possível remediá-lo, mas o escopo deve incluir o manual de resposta, as permissões, a telemetria e o teste de recuperação. Reconstruir o código sem atribuir essas responsabilidades repete a mesma fraqueza em uma tecnologia mais nova.

Evidências sobrevivem ao reparo, não a um recomeço improvisado

A continuidade das evidências de controle é o argumento prático mais forte para a remediação perto de um período de observação de tipo 2. Um reparo pode preservar o histórico de deploys, registros de tickets, revisões de acesso, histórico de alertas, testes de backup e logs de produção. Uma reconstrução costuma mudar ao mesmo tempo o limite do sistema, as ferramentas, os repositórios, os papéis e as pessoas que executam os controles. O novo desenho pode ser melhor, mas seus controles ainda precisam funcionar e deixar evidências.

Evidência não é uma captura de tela recolhida na noite anterior ao trabalho de campo. Uma boa evidência identifica o controle, o responsável pela ação, o momento, a população, o resultado e o tratamento das exceções. Uma aprovação de pull request sem prova de que todas as mudanças de produção passam por aquele repositório é fraca. Uma lista dos administradores atuais sem a decisão do revisor e o acompanhamento das remoções está incompleta. A configuração de um alerta sem um teste ou registro de incidente diz pouco sobre sua operação.

Monte uma tabela de continuidade de evidências antes de tocar na arquitetura. Para cada controle, registre a fonte atual de evidência, a fonte proposta após a mudança, a data da migração, o responsável e como você provará a integridade durante a transição. Dê atenção especial aos controles cuja população muda, como deploys que passam para outro pipeline ou usuários que migram para outro provedor de identidade. O auditor pode precisar das duas populações e de uma reconciliação entre elas.

Um pequeno registro pode revelar se o histórico de mudanças é coletável. Exija um registro como este para cada versão em produção e depois verifique se os identificadores indicados existem nos sistemas que os produziram:

{
  "release_id": "prod-2026-06-18-07",
  "commit": "8c91f14",
  "pull_request": 184,
  "approved_by": "[email protected]",
  "deployed_by": "pipeline",
  "deployed_at": "2026-06-18T14:22:31Z",
  "test_run": "security-4421",
  "exception": null
}

O registro conecta fontes de evidência, mas não basta sozinho. O commit deve levar à mudança revisada, o pull request deve mostrar um aprovador qualificado, a execução dos testes deve corresponder àquele commit e o sistema de deploy deve mostrar o mesmo artefato chegando à produção. Colha amostras da população completa de versões e explique bots, mudanças emergenciais, reversões e mudanças aprovadas que nunca foram publicadas. Procure também registros ausentes; uma amostra perfeita tirada de uma lista incompleta prova muito pouco. Se você não consegue estabelecer essa cadeia para o aplicativo atual, reconstruí-lo não corrigirá o controle de gestão de mudanças. Só iniciará um histórico novo que exigirá a mesma reconciliação.

Preserve evidências antigas de forma imutável ao migrar. Exporte logs com limites de tempo documentados, retenha metadados do repositório e do pipeline de acordo com sua política de retenção e registre quem verificou a exportação. Não mantenha um ambiente de produção antigo como museu se isso cria risco de acesso ou de correções. Preserve os registros, documente o descarte e desligue o ambiente por meio do mesmo processo aprovado que você afirma operar.

O tratamento dos dados define quanto código precisa mudar

Mapeie os dados antes de estimar qualquer uma das opções. Fundadores costumam começar por telas e funcionalidades porque são visíveis. O escopo do SOC 2 e o risco do aplicativo dependem de dados de clientes, credenciais, tokens, logs, backups, exportações de suporte e dos serviços que os processam. Um plano de reconstrução que redesenha as telas enquanto copia o mesmo banco de dados confuso é trabalho cosmético.

Crie um inventário do fluxo de dados no nível de grupos de campos, não apenas «o aplicativo usa um banco de dados». Registre o que entra, onde é validado, onde é armazenado, qual cliente é o dono, quais papéis podem ler, para onde sai, por quanto tempo permanece e como a exclusão se propaga. Inclua tarefas em segundo plano, analytics, monitoramento de erros, e-mail, armazenamento de objetos, cópias de teste e fluxos manuais do suporte. Registre a incerteza como uma descoberta; não preencha lacunas com suposições.

A descoberta dos dados muda a decisão nas duas direções. Você pode descobrir que o protótipo possui um armazenamento relacional bem estruturado e que todo comportamento perigoso vive em uma camada fina de API. Isso favorece a remediação, pois substituir o limite é menor do que migrar os dados. Você também pode encontrar registros duplicados de clientes, chaves de objetos sem escopo, credenciais armazenadas ao lado de perfis e tarefas que copiam linhas de produção para tabelas de teste não administradas. Isso favorece um novo modelo de dados e uma migração controlada.

O risco da migração merece uma estimativa própria. Um esquema limpo não garante uma transição limpa. Você precisa de regras de mapeamento, totais de validação, tratamento de registros rejeitados, critérios para voltar atrás, comportamento da exclusão e um plano para as gravações que ocorrerem durante a migração. Hashes podem confirmar a igualdade dos bytes em objetos inalterados; contagens de registros e invariantes do negócio podem validar tabelas transformadas. Nunca declare uma migração concluída apenas porque o processo terminou sem erro.

Logs exigem moderação. Equipes que se preparam para uma auditoria às vezes aumentam o registro em todos os pontos e acabam capturando tokens de sessão, corpos de requisição, dados pessoais ou erros do banco com segredos. Registre o agente, a ação, o alvo, o resultado, o horário e o identificador de correlação necessários para responsabilização. Exclua credenciais e cargas desnecessárias. Restrinja o acesso aos logs e teste a ocultação usando falhas realistas.

A distinção mais clara é entre correção e controle dos dados. A correção pergunta se o aplicativo armazenou o valor pretendido. O controle pergunta se somente agentes autorizados puderam causá-lo, vê-lo, alterá-lo, exportá-lo ou excluí-lo e se a organização consegue provar esses fatos. Uma reescrita focada na correção pode reproduzir a mesma falha de controle com tipos mais organizados.

Identidade e limites entre clientes são condições decisivas

Identidade quebrada e isolamento ruim entre clientes podem forçar uma reconstrução mesmo quando o resto do produto funciona. A autenticação prova ou estabelece quem é o agente. A autorização decide o que ele pode fazer. O isolamento garante que a autoridade e os dados de um cliente não vazem para o espaço de outro. Protótipos gerados por IA misturam essas três funções com frequência, e consertar a página de login resolve apenas a primeira.

Acompanhe uma requisição desde a borda da rede até o armazenamento. Identifique onde a sessão ou o token é validado, onde o servidor obtém o agente, de onde vem o contexto do cliente, onde a permissão é verificada e como a consulta é limitada. Identificadores de usuário, papel ou cliente fornecidos pelo navegador não devem ganhar autoridade só porque a interface costuma enviar valores honestos. Decisões do servidor precisam de uma fonte oficial.

O OWASP ASVS ajuda porque trata a segurança de aplicativos como requisitos verificáveis, não como uma lista genérica de vulnerabilidades. A OWASP afirma que o ASVS fornece uma base para testar controles técnicos de segurança e uma lista de requisitos para desenvolvimento seguro. Use a versão atual combinada com seus avaliadores e registre identificadores de requisitos com a versão nas evidências dos testes, porque a OWASP alerta que esses identificadores podem mudar. Eu não afirmaria que um sistema «está em conformidade com o ASVS» após executar um scanner; relacione os requisitos relevantes aos testes e às descobertas.

Escolha a remediação quando puder estabelecer um caminho de identidade confiável, centralizar a autorização em um limite estreito e impor o escopo do cliente em todo acesso aos dados. Substitua um subsistema quando somente esse limite não for seguro. Reconstrua o serviço quando a autoridade depender do estado do navegador em todo o aplicativo ou quando o modelo de dados não conseguir expressar a propriedade do cliente sem inferências.

Descobertas de segredos e injeção exigem contenção imediata, independentemente da escolha de longo prazo. Revogue as credenciais expostas, remova o acesso não autorizado, preserve evidências do incidente e examine o uso. Depois, parametrize as consultas, valide as entradas nos limites de confiança e restrinja os privilégios do banco. Uma futura reconstrução não é desculpa para deixar o sistema atual exposto durante o projeto e a migração.

Não opere dois sistemas de identidade por mais tempo do que o necessário. Gravações duplicadas, tradução de tokens e administração dividida aumentam a superfície de controle e complicam as evidências. Se uma migração por etapas precisar dos dois, defina qual sistema é a fonte oficial para cada população, adicione critérios de expiração, teste a revogação através da ponte e marque uma data para a remoção.

A remediação vence quando o limite é conhecível

Escolha uma remediação delimitada quando o modelo de propriedade do produto for coerente, o comportamento arriscado estiver concentrado atrás de limites substituíveis e a equipe conseguir provar as mudanças com testes automatizados e registros operacionais. Isso continua verdadeiro mesmo que o código gerado seja repetitivo ou fora de moda. A preparação para auditoria recompensa mais o comportamento controlado do que a pureza estética.

Um bom escopo de remediação define resultados, não uma limpeza vaga. Substitua a autorização que confia no navegador por verificações no servidor. Mova segredos para um repositório aprovado e faça a rotação deles. Consolide deploys de produção em um único pipeline revisado. Acrescente restrições de cliente ao acesso aos dados. Oculte campos sensíveis dos logs. Adicione testes que tentem acessar outro cliente e executar ações privilegiadas como um usuário sem privilégios. Relacione cada mudança a um controle, risco, fonte de evidência e teste de aceitação.

A refatoração fora desses resultados pode esperar. Renomear arquivos, trocar bibliotecas de estado ou converter cada componente para um padrão preferido cria volume de revisão sem reduzir um risco declarado. Grandes alterações cosméticas também escondem regressões de segurança. Mantenha as mudanças de segurança pequenas o bastante para um revisor entendê-las e separe refatorações mecânicas de mudanças no comportamento.

Defina critérios de saída que uma pessoa cética possa testar. «Autenticação corrigida» não é um critério. «Toda rota protegida da API rejeita um token expirado, obtém o agente no servidor, verifica a permissão exigida, limita o acesso ao cliente desse agente e emite um evento de auditoria sem dados sensíveis» é testável. Anexe o inventário das rotas e os resultados, incluindo falhas.

A remediação vira falsa economia quando toda correção exige mais uma exceção. Procure camadas de política que rotas antigas conseguem contornar, indicadores de compatibilidade que nunca expiram e testes que simulam a verdadeira camada de autorização até fazê-la desaparecer. Se a lista de exceções crescer durante a primeira etapa do reparo, pare e reavalie o limite. Esforço já gasto não torna a arquitetura mais estável.

Uma correção limitada também pode comprar tempo para uma reconstrução posterior, mas chame isso de contenção. Defina qual risco ela reduz, qual dívida permanece e quando a decisão de substituição voltará a ser analisada. Não descreva um controle compensatório temporário como desenho permanente só porque o calendário da auditoria está apertado.

Reconstrua somente com uma migração controlada

Escolha reconstruir quando o sistema não conseguir expressar ou aplicar seus limites de confiança sem exceções espalhadas, quando o modelo de dados conflitar com as regras de propriedade ou quando o comportamento essencial não puder ser caracterizado o bastante para uma mudança segura. Reconstruir porque o código causa vergonha é desperdício. Reconstruir porque não existe um limite de controle testável é uma decisão de engenharia que pode ser defendida.

A reconstrução deve começar com um inventário de comportamentos, não com um editor vazio. Registre papéis dos usuários, regras dos clientes, fluxos privilegiados, ciclo de vida dos dados, integrações, comportamento em falhas e tarefas operacionais. Marque o comportamento acidental que não deve sobreviver. Logs de produção e registros do suporte podem revelar caminhos que a interface visível não mostra, mas examine esses dados sem copiá-los para ferramentas não administradas.

O NIST SP 800-218 afirma que práticas de desenvolvimento seguro normalmente precisam ser adicionadas a cada modelo de ciclo de desenvolvimento. Seu Secure Software Development Framework agrupa o trabalho em preparar a organização, proteger o software, produzir software bem protegido e responder a vulnerabilidades. A lição útil é que um repositório novo não chega com um processo seguro. Coloque requisitos, revisão, procedência, testes, proteção da publicação e resposta a vulnerabilidades no plano desde o primeiro commit.

Inclua a geração de evidências no caminho de entrega. Exija mudanças revisadas, conecte compilações a commits imutáveis, registre quem aprovou versões em produção, retenha os resultados dos testes e garanta que mudanças emergenciais entrem no mesmo registro depois da contenção. Teste backups restaurando-os, não conferindo o status da tarefa. Teste alertas criando sinais controlados. Registre as revisões de acesso de modo que fique claro que o revisor avaliou cada conta.

Evite uma transição completa de uma só vez quando for difícil reverter dados ou fluxos de clientes. Mova uma funcionalidade delimitada ou um grupo de clientes, observe, reconcilie os resultados e preserve a possibilidade de voltar atrás. Os serviços antigo e novo precisam de responsáveis explícitos enquanto coexistirem. Controles duplicados são aceitáveis em uma migração curta; controles ambíguos não são.

Uma reconstrução termina quando os antigos caminhos de autoridade forem removidos, a reconciliação dos dados passar, os critérios de reversão forem encerrados, as credenciais antigas forem revogadas, a infraestrutura herdada for descartada e a descrição do sistema corresponder à produção. Publicar a nova interface é um evento intermediário. Se o antigo usuário do banco ainda tiver acesso amplo ou uma tarefa herdada continuar gravando dados de clientes, o limite não mudou.

O calendário da auditoria pode vencer o desenho mais limpo

O calendário da auditoria muda qual opção tecnicamente válida é responsável. Antes do período de observação, você tem espaço para redesenhar controles, operá-los, corrigir falhas e coletar evidências. Durante um período de tipo 2, uma migração importante pode alterar a população dos controles e a descrição do sistema. Perto do trabalho de campo, ela pode criar tarefas de reconciliação justamente quando a equipe precisa de registros estáveis e responsáveis disponíveis.

Coloque quatro datas em uma página: a data pretendida do tipo 1 ou o período do tipo 2, a última data segura para uma mudança arquitetural relevante, a janela da transição e as datas de congelamento ou entrega de evidências combinadas com o auditor. Acrescente compromissos com clientes e períodos de negócio de alto risco. Se ninguém consegue fornecer as datas da auditoria, pause a promessa técnica em vez de inventar uma folga.

Depois, classifique as mudanças pelo impacto nos controles. Uma atualização de biblioteca protegida por testes existentes pode deixar o desenho do controle inalterado. Mover os deploys para outro provedor muda as fontes de evidência e talvez os papéis de acesso. Substituir a autenticação muda populações de usuários, evidências de acesso, logs, procedimentos do suporte e a descrição do sistema. A quantidade de código alterado é um indicador ruim do impacto na auditoria.

Use um registro curto de decisão com quatro dimensões pontuadas:

1. Clareza dos limites: a equipe consegue enumerar os caminhos de identidade, clientes, dados e deploy?
2. Concentração dos reparos: poucos componentes podem conter a maioria das descobertas materiais?
3. Continuidade das evidências: os registros dos controles conseguem permanecer completos durante a mudança?
4. Reversibilidade da migração: a equipe consegue detectar uma transição ruim e restaurar um serviço seguro?

Dê notas com evidências, não com otimismo. Um diagrama apoiado por rastros é evidência. «O framework cuida disso» não é. Entregue o registro ao responsável técnico, ao responsável pela segurança, ao dono do controle e ao auditor para que o questionem. O auditor deve orientar sobre as implicações para o exame, enquanto a administração mantém a responsabilidade pelo sistema e pelos controles.

Se a remediação vencer, congele refatorações não relacionadas até que as falhas de controle sejam encerradas e a coleta de evidências se estabilize. Se a reconstrução vencer, mantenha o serviço atual contido enquanto o substituto cria seu histórico operacional. A FixMyMess pode diagnosticar uma base de código gerada por IA, corrigir segurança e lógica, refatorá-la ou preparar uma reconstrução para o deploy; use esse tipo de revisão especializada para questionar o escopo, não para terceirizar as decisões de controle da administração.

Não prometa que nenhum dos caminhos garante um relatório limpo. Auditores testam o que realmente funcionou, e exceções podem surgir de pessoas, processos, fornecedores ou evidências, mesmo quando os controles do aplicativo funcionam. Um plano honesto inclui tempo para encontrar controles que falharam, corrigi-los e mostrar como a correção operou.

O registro da decisão deve mostrar a incerteza

Escreva a decisão antes do início da implementação. Um registro útil nomeia o sistema no escopo, os Critérios de Serviços de Confiança selecionados, as descobertas conhecidas de arquitetura e dados, as falhas atuais dos controles, o escopo da remediação, o escopo da reconstrução, os riscos de migração, os efeitos sobre evidências, as datas, os responsáveis, as premissas e a condição que mudaria a escolha. Anexe o material de origem para que outro revisor consiga reproduzir o raciocínio depois.

Não deixe uma pontuação única esconder uma condição decisiva. Uma reconstrução pode ter nota ruim no prazo e ainda ser necessária porque o isolamento entre clientes não pode ser consertado. Uma remediação pode ter nota boa na velocidade e ainda ser insegura porque ninguém consegue delimitar o acesso privilegiado. Declare primeiro as condições decisivas e depois compare custo e prazo entre as opções viáveis.

Faça perguntas precisas ao auditor do serviço. A transição proposta mudará a descrição do sistema ou a população do controle? Quais evidências sustentarão a operação antes e depois da migração? Como a administração deve descrever um controle que mudou durante o período? Quais limites e organizações subcontratadas pertencem ao escopo? A firma de CPA deve responder para aquele trabalho; um painel de conformidade não pode fazer esses julgamentos.

Faça também perguntas de engenharia que os auditores não conseguem responder. Conseguimos enumerar todo caminho de gravação em produção? Conseguimos revogar um usuário em todos os pontos dentro do processo declarado? Conseguimos provar que um cliente não busca o objeto de outro mudando um identificador? Conseguimos restaurar dados e reconciliá-los com um ponto conhecido? Um commit aprovado pode ser rastreado até o artefato em execução? Essas respostas determinam se as afirmações sobre os controles são verdadeiras.

A opção padrão deve ser a menor mudança que crie um limite estável e testável e preserve evidências confiáveis. Abandone essa preferência quando o sistema existente não conseguir expressar quem é dono dos dados ou quem pode agir sobre eles. Um prazo de SOC 2 é um péssimo motivo para manter um sistema impossível de conhecer e um motivo igualmente ruim para apagar um sistema conhecido.