Pejotização de desenvolvedores e o controle A.8.30 da ISO 27001: é ou não desenvolvimento terceirizado?

A pejotização, contratação de desenvolvedores como pessoa jurídica ao invés do regime CLT, virou prática recorrente no mercado brasileiro de tecnologia. No entanto, em auditorias de SGSI - Sistema de Gestão de Segurança da Informação baseadas na ISO/IEC 27001:2022, esse modelo tem provocado o debate sobre se o trabalho desses profissionais deve ou não ser tratado sob o controle A.8.30 — desenvolvimento terceirizado.

A resposta não é trivial. Há auditores que enquadram desenvolvedores PJ como terceirização de desenvolvimento e exigem o A.8.30. Outros entendem que o desenvolvedor PJ, integrado aos processos internos da contratante, é colaborador para todos os efeitos de segurança da informação, e o A.8.30 não se aplica. Este artigo propõe um caminho técnico para essa decisão, com base no texto da norma e na natureza dos controles envolvidos.

O que diz, literalmente, o A.8.30 da ISO 27001?

O controle A.8.30 do Anexo A da ISO/IEC 27001:2022 tem o seguinte enunciado: “A organização deve dirigir, monitorar e analisar criticamente as atividades relacionadas à terceirização de desenvolvimento de sistemas.” ABNT NBR ISO/IEC 27001:2022, Anexo A, controle 8.30.

O guia de implementação correspondente na ISO/IEC 27002:2022, esclarece que o controle se destina a situações em que parte ou todo o desenvolvimento é confiado a partes externas, exigindo, entre outros pontos, contratos com requisitos de segurança, propriedade intelectual definida, evidências de testes, gestão de vulnerabilidades pelo fornecedor e direito de auditoria.

O elemento decisivo, portanto, não é o tipo contratual do desenvolvedor, mas a quem pertence o processo de desenvolvimento. O A.8.30 se aplica quando o desenvolvimento é conduzido por uma parte externa, com seu próprio ciclo de vida, sua própria equipe e seus próprios controles, e a organização exerce supervisão contratual sobre essa entrega.

O que caracteriza uma terceirização de desenvolvimento?

Em uma terceirização de desenvolvimento o fornecedor é quem detém o processo. Confira as características típicas:

• A contratante define o resultado esperado (produto, módulo, sustentação) e o fornecedor decide como alocar pessoas, ferramentas e metodologia.
• A seleção dos profissionais é responsabilidade do fornecedor; a contratante avalia a empresa, não os indivíduos.
• O SDLC, o controle de versão, o pipeline e a gestão de vulnerabilidades pertencem ao fornecedor, ou são contratualmente espelhados nos padrões da contratante.
• Os profissionais não passam pelo onboarding pleno do SGSI da contratante; sua adesão é mediada por contrato e pelo SGSI do fornecedor.
• A relação contratual é entre duas pessoas jurídicas, e qualquer substituição de pessoa física pelo fornecedor não exige nova seleção pela contratante.

É nesse cenário que o A.8.30 ganha sentido: a contratante não controla diretamente o desenvolvimento e, por isso, precisa direcionar, monitorar e revisar.

Pejotização: o PJ como modalidade contratual, não como terceirização

No modelo de pejotização tipicamente praticado no Brasil, o desenvolvedor PJ entra pela mesma porta do colaborador CLT. O processo seletivo é o do RH e da liderança técnica da contratante; a integração inclui treinamento de segurança, assinatura de NDA, ciência das políticas internas e provisionamento de acessos pelo IAM corporativo; o backlog é definido pelo product manager e pelo tech lead da contratante; o código entra no repositório corporativo, passa pelo code review do time e pelo pipeline da contratante; e a substituição do PJ exige novo processo seletivo na contratante.

O que muda, em essência, é o vínculo jurídico-tributário. Não há um fornecedor que detenha o desenvolvimento, não há SDLC externo, não há equipe terceira gerenciada por terceiros. Há um colaborador cuja remuneração é faturada por CNPJ.

Do ponto de vista de segurança da informação, que é a perspectiva da ISO 27001, esse profissional é tratado pelos mesmos controles que se aplicam a um CLT: A.6.1 a A.6.6 (recursos humanos), A.5.10 (uso aceitável), A.5.15 a A.5.18 (controle de acesso), A.8.25 a A.8.28 (desenvolvimento seguro), A.8.32 (gestão de mudanças).

Tabela comparativa: CLT, PJ e Terceirizado

A tabela a seguir resume as diferenças que importam para a auditoria de um SGSI. O critério prático é simples: onde está o controle do processo de desenvolvimento?

Posicionamento técnico sobre a Pejotização de desenvolvedores e o controle A.8.30 da ISO 27001 

Portanto, fica claro que o colaborador PJ não configura desenvolvimento terceirizado para fins do controle A.8.30 quando: (i) é selecionado e integrado pelos processos internos da contratante; (ii) opera sob a supervisão técnica direta da contratante; (iii) utiliza o SDLC, os repositórios, o pipeline e as ferramentas da contratante; e (iv) está submetido ao SGSI da contratante em pé de igualdade com colaboradores CLT. Nessas condições, o desenvolvimento é interno; o vínculo contratual é apenas a forma de remuneração. 

O A.8.30 deve ser aplicado quando existe, de fato, um fornecedor que conduz o desenvolvimento, com sua equipe, seu processo e seus controles, entregando software ou sustentação à contratante. Cabem aqui direcionamento, monitoramento e revisão, com cláusulas de segurança, direito de auditoria, requisitos de SDLC, gestão de vulnerabilidades e propriedade intelectual. 

Ao tratar todo PJ como terceirização gera um risco que desloca o foco do controle real (a integração desse profissional ao SGSI) para um controle inadequado (a supervisão contratual de um fornecedor que não existe). O efeito prático é uma evidência artificial: contratos de “terceirização” que descrevem uma relação que, no plano operacional, é de colaboração direta, sem qualquer ganho de segurança. 

Recomenda-se que o SGSI documente explicitamente, em sua declaração de aplicabilidade ou em procedimento de RH/desenvolvimento, o tratamento dado a colaboradores PJ, com os critérios objetivos. Essa documentação evita a discussão recorrente em cada auditoria e oferece ao auditor um caminho claro para verificar se o controle aplicado é o correto. 

Como você tem tratado a pejotização no seu SGSI? 

A norma não fala de CLT, PJ ou MEI. Fala de quem detém o processo de desenvolvimento. Quando o desenvolvimento é interno, independentemente do contrato individual de cada desenvolvedor, os controles aplicáveis são os de pessoal, acesso e desenvolvimento seguro. Quando o desenvolvimento é confiado a um terceiro, com sua própria operação, entra em cena o A.8.30. 

Esse é o entendimento que melhor preserva a intenção da norma e a realidade do mercado brasileiro. Mas é, reconhecidamente, uma leitura, e auditores experientes podem chegar a conclusões diferentes diante de cenários híbridos (squads externos com lideranças mistas, body shop com seleção do cliente, fábricas com pessoas alocadas in loco). 

Como você tem tratado a pejotização no seu SGSI? Quais critérios sua organização adota para distinguir colaborador PJ de desenvolvimento terceirizado em auditorias da ISO 27001? Deixe sua experiência nos comentários e caso tenha dúvidas, entre em contato com nossos consultores.