Governação de projetos de TIC com segurança desde a conceção em 2026
O projeto estava dentro do prazo, até a auditoria fazer uma pergunta
O CISO de uma empresa de tecnologia de pagamentos em rápido crescimento tinha boas notícias para o conselho de administração. A nova plataforma de integração de clientes estava pronta para lançamento. A equipa de produto tinha entregue a experiência móvel, a engenharia tinha integrado a verificação de identidade, o departamento jurídico tinha validado os fornecedores de serviços de nuvem e de API, e as operações tinham ensaiado o plano de entrada em produção.
Depois, o auditor interno fez uma pergunta simples:
“Mostrem-me onde a segurança e a privacidade foram consideradas em cada fase do projeto.”
A sala do projeto ficou em silêncio.
Havia um relatório de testes de intrusão, mas tinha sido realizado tarde. Havia um diagrama de arquitetura de nuvem, mas não havia evidência de que os fluxos de dados tivessem sido revistos à luz dos princípios do RGPD da UE. Havia um questionário de diligência prévia de fornecedores, mas não estava associado ao Registo de Riscos. Havia um pedido de alteração para a implementação em produção, mas a aprovação não mencionava o impacto em serviços críticos, notificação de incidentes, testes de resiliência, notificação de clientes ou escalonamento de violações de dados pessoais. Havia notas de sprint, mas os requisitos de segurança estavam dispersos por histórias de utilizador e mensagens instantâneas.
Nada era manifestamente negligente. Tudo parecia um projeto de TIC moderno e atarefado. Mas, para uma entidade financeira sujeita à DORA, um prestador SaaS potencialmente abrangido pela NIS2 e um responsável pelo tratamento ou subcontratante ao abrigo do RGPD da UE, a questão já não era apenas saber se existia segurança. A questão era saber se a segurança desde a conceção podia ser demonstrada.
Esse é o problema de 2026. Os projetos de TIC já não são avaliados apenas pela rapidez de entrega, controlo de custos e qualidade técnica. São avaliados pela evidência de governação: avaliações de risco, decisões de conceção, diligência prévia de fornecedores, registos de desenvolvimento seguro, aprovações de alterações, decisões de privacidade, resultados de testes e supervisão pela gestão.
A ISO/IEC 27001:2022 fornece às organizações uma estrutura prática de sistema de gestão para resolver este problema. Ajuda CISO, gestores de conformidade, patrocinadores de projetos, Encarregados da Proteção de Dados (DPO), arquitetos, equipas de compras e auditores a transformar projetos de TIC significativos em evidência defensável de segurança desde a conceção.
Porque é que a governação de projetos de TIC é agora um problema de evidência regulamentar
Uma migração para a nuvem, um portal de clientes, uma plataforma de pagamentos, uma implementação de CRM, uma alteração de fornecedor de identidade, uma pipeline de análise, uma integração de API, um fluxo de trabalho SaaS, uma aplicação low-code ou uma transição de serviço gerido podem alterar o perfil de risco da organização. Em 2026, essas alterações ocorrem sob obrigações sobrepostas.
A NIS2 aplica-se amplamente a entidades essenciais e importantes nos setores do Anexo I e do Anexo II, incluindo infraestrutura digital, prestadores de serviços geridos, prestadores de serviços de segurança geridos e prestadores digitais. O NIS2 Article 20 torna os órgãos de administração responsáveis por aprovar medidas de gestão de riscos de cibersegurança e supervisionar a sua implementação. O NIS2 Article 21 exige medidas técnicas, operacionais e organizacionais adequadas e proporcionadas para gestão de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, aquisição segura, desenvolvimento seguro, tratamento de vulnerabilidades, avaliação de eficácia, higiene de cibersegurança, criptografia, controlo de acesso, gestão de ativos e comunicações seguras.
A DORA aplica-se a entidades financeiras e centra-se na resiliência operacional digital. O DORA Article 5 atribui ao órgão de administração a responsabilidade pela gestão do risco das TIC. O DORA Article 6 exige um quadro de gestão do risco das TIC sólido, abrangente e bem documentado. A DORA também abrange a notificação de incidentes relacionados com as TIC, testes de resiliência operacional, continuidade de negócio das TIC, resposta e recuperação, partilha de informações sobre ciberameaças, gestão do risco de terceiros de TIC, acordos contratuais e supervisão de prestadores terceiros críticos de TIC.
O RGPD da UE acrescenta a camada de responsabilização para os dados pessoais. O GDPR Article 25 exige proteção de dados desde a conceção e por defeito. Os responsáveis pelo tratamento devem conseguir demonstrar conformidade com princípios como licitude, lealdade, transparência, limitação das finalidades, minimização de dados, limitação da conservação, integridade, confidencialidade e responsabilização. Quando o tratamento for suscetível de resultar em risco elevado, também pode ser exigida uma Avaliação de Impacto sobre a Proteção de Dados (AIPD) ao abrigo do GDPR Article 35.
O fio condutor é a evidência. Reguladores e auditores não perguntam apenas se uma plataforma foi cifrada, corrigida, analisada ou testada. Perguntam se a organização consegue demonstrar que segurança, privacidade, risco de fornecedores e resiliência fizeram parte da tomada de decisão desde o início.
É por isso que a governação de projetos segundo a ISO/IEC 27001:2022 é tão poderosa. Permite à organização gerir NIS2, DORA, RGPD da UE, NIST CSF 2.0, obrigações contratuais e pedidos de garantia de clientes através de um processo de SGSI repetível, em vez de múltiplas listas de verificação desconectadas.
A espinha dorsal ISO 27001 para a governação de projetos
A ISO/IEC 27001:2022 é frequentemente mal interpretada como um exercício de certificação. Para projetos de TIC, o seu valor operacional é mais amplo. Fornece uma espinha dorsal de governação para a mudança no negócio.
As cláusulas 4.1 a 4.4 exigem que as organizações compreendam questões internas e externas, partes interessadas, requisitos legais, regulamentares e contratuais, âmbito do SGSI, interfaces e dependências. Em termos de projeto, isto significa que o termo de abertura do projeto deve identificar serviços afetados, clientes, fornecedores, regulamentos, processos de negócio, dados pessoais, operações críticas e serviços externalizados.
As cláusulas 5.1 a 5.3 exigem compromisso da liderança, alinhamento com políticas, recursos, integração nos processos de negócio e responsabilidades atribuídas. Isto é relevante porque tanto a NIS2 como a DORA colocam a cibersegurança e o risco das TIC sob responsabilidade do órgão de administração. Um projeto que altera uma plataforma crítica de clientes não pode depender de um comentário informal de segurança numa conversa de chat. Precisa de responsabilização clara.
As cláusulas 6.1.1 a 6.1.3 exigem um processo repetível de avaliação e tratamento de riscos, critérios de risco, proprietários do risco, avaliação de confidencialidade, integridade e disponibilidade, planos de tratamento de riscos, Declaração de Aplicabilidade e aprovação do risco residual. É aqui que o risco do projeto se transforma em evidência de auditoria.
As cláusulas 7.1 a 7.5 exigem recursos, competência, sensibilização, comunicação e controlo da informação documentada. É assim que os registos do projeto se tornam evidência fiável, em vez de artefactos dispersos.
A cláusula 8.1 exige planeamento e controlo operacional, informação documentada que demonstre que os processos foram executados conforme planeado, controlo de alterações planeadas, revisão de alterações não intencionais, mitigação de efeitos adversos e controlo de processos, produtos ou serviços fornecidos externamente que sejam relevantes para o SGSI. As cláusulas 8.2 e 8.3 exigem avaliações de risco de segurança da informação e tratamento em intervalos planeados ou quando ocorram alterações significativas.
O Anexo A liga depois este ciclo de gestão a controlos práticos. Para a segurança desde a conceção em projetos de TIC, três controlos do Anexo A da ISO/IEC 27001:2022 são centrais:
| Controlo ISO/IEC 27001:2022 | Nome do controlo | Porque é relevante para projetos de TIC |
|---|---|---|
| A.5.8 | Segurança da informação na gestão de projetos | Integra a segurança em todas as fases do projeto e cria evidência de governação antes de ser criada exposição |
| A.8.25 | Ciclo de vida de desenvolvimento seguro | Incorpora requisitos de segurança, conceção segura, programação segura, testes e disciplina de implementação |
| A.8.32 | Gestão de alterações | Garante que as alterações em produção são planeadas, sujeitas a avaliação de risco, testadas, aprovadas, monitorizadas e passíveis de revisão |
O Zenith Blueprint: roteiro de 30 passos para auditores da Clarysec trata a segurança da informação na gestão de projetos como uma preocupação de governação em todos os tipos de projeto, não apenas no desenvolvimento de software:
“Qualquer projeto — uma migração de sistema de marketing, uma mudança de instalações, uma reformulação de processo de negócio, uma plataforma de integração de Recursos Humanos, até uma fusão ou aquisição — pode afetar a confidencialidade, integridade ou disponibilidade da informação. E, quando isso acontece, a segurança tem de ter lugar à mesa.”
A mesma secção capta a lição essencial de implementação:
“O objetivo deste controlo não é sobrecarregar os projetos com burocracia. É garantir que a segurança é tratada como um input de conceção, não como uma fase de testes.”
Esta distinção separa o teatro de conformidade da segurança desde a conceção defensável.
Como é a segurança desde a conceção dentro de um projeto de TIC
A segurança desde a conceção começa antes do primeiro sprint, pedido de aquisição, diagrama de arquitetura ou manual de execução de migração. Coloca uma pergunta simples: o que pode este projeto alterar no risco?
Um modelo prático de governação de projetos usa sete pontos de controlo de evidência.
| Ponto de controlo do projeto | Evidência de segurança desde a conceção | Proprietário típico | Valor para conformidade transversal |
|---|---|---|---|
| Iniciação | Classificação de segurança do projeto, serviços afetados, aplicabilidade regulamentar, categorias de dados, criticidade | Patrocinador do projeto e CISO | Suporta o âmbito ISO, medidas de risco NIS2, análise de funções críticas DORA e responsabilização no RGPD da UE |
| Requisitos | Requisitos de segurança, requisitos de privacidade, requisitos de resiliência, requisitos de fornecedores | Proprietário do produto, responsável de segurança, DPO, compras | Suporta aquisição segura, privacidade desde a conceção e cláusulas de terceiros |
| Conceção | Revisão da arquitetura, modelação de ameaças, mapa de fluxo de dados, limites de confiança, decisões de criptografia | Equipas de arquitetura e segurança | Suporta desenvolvimento seguro, proteção de dados no RGPD da UE e controlos de risco das TIC da DORA |
| Construção ou configuração | Registos de programação segura, inventário de componentes, risco de dependência, configurações de referência | Equipa de engenharia ou de plataforma | Suporta tratamento de vulnerabilidades e segurança da cadeia de fornecimento de software |
| Teste | Resultados de testes de segurança, casos de abuso, análises de vulnerabilidades, testes de cópia de segurança e recuperação quando relevantes | Garantia da qualidade, segurança, operações | Suporta testes DORA, avaliação de eficácia NIS2 e evidência ISO |
| Aprovação de alteração | Aceitação do risco, plano de reversão, plano de monitorização, atualizações de escalonamento de incidentes | CAB ou aprovadores delegados | Suporta controlo de alterações ISO, reporte de governação DORA e resiliência operacional |
| Pós-implementação | Lições aprendidas, revisão de risco residual, monitorização de fornecedores, revisão da eficácia dos controlos | Proprietário do serviço e gestor do SGSI | Suporta melhoria contínua e preparação para auditoria |
O objetivo não é burocracia. O objetivo é tornar a segurança visível onde as decisões do projeto realmente acontecem.
A Política de Segurança da Informação Clarysec Enterprise exprime isto diretamente:
“A governação da segurança deve ser integrada com a governação empresarial, a gestão de projetos, a aquisição e as funções de supervisão jurídica, para garantir que a segurança da informação não fica isolada, mas incorporada em toda a tomada de decisão do negócio.”
Da secção “Requisitos de governação”, cláusula 5.5 da política.
Também torna os ciclos de vida dos projetos uma preocupação de implementação:
“Ciclos de vida de projetos (por exemplo, desenvolvimento seguro, modelação de ameaças)”
Da secção “Requisitos de implementação da política”, cláusula 6.3.1.1 da política.
E estabelece o princípio de auditoria que muitas organizações descobrem demasiado tarde:
“Todos os controlos implementados devem ser auditáveis, suportados por procedimentos documentados e por evidência retida da sua operação.”
Da secção “Requisitos de implementação da política”, cláusula 6.6.1 da política.
Por outras palavras, trabalho de segurança que não seja governado, retido e mapeado falhará muitas vezes em auditoria, mesmo que as equipas técnicas tenham tomado decisões razoáveis.
Da modelação de ameaças à evidência: um exemplo prático de fintech
Considere um projeto para lançar um novo portal de integração de clientes da UE para uma fintech. O portal recolhe documentos de identidade, realiza verificação biométrica através de um terceiro, armazena o estado da integração, integra-se com o CRM, aciona notificações aos clientes e alimenta a pontuação de risco.
Uma abordagem de segurança desde a conceção construiria a evidência à medida que o projeto avança.
Primeiro, abra um registo de classificação de segurança do projeto. Identifique se o projeto afeta funções críticas ou importantes, dados pessoais, categorias especiais de dados pessoais, autenticação, disponibilidade orientada para o cliente, serviços de TIC externalizados, processos de reporte regulados ou comunicações com clientes. Ao abrigo do RGPD da UE, dados biométricos usados para identificação única constituem uma categoria especial de dados pessoais, salvo se se aplicar uma exceção específica. Isto eleva imediatamente o nível exigido de análise jurídica e salvaguardas.
Segundo, crie uma avaliação de riscos do projeto. A Política de Gestão de Riscos Clarysec SME torna a gestão de riscos parte do planeamento, não um exercício trimestral em folha de cálculo:
“1.2 Garante que a gestão de riscos é uma componente ativa do planeamento, da execução de projetos, da seleção de fornecedores e da resposta a incidentes, em alinhamento com ISO 27001, ISO 31000 e os requisitos regulamentares aplicáveis.”
Da secção “Finalidade”, cláusula 1.2 da política.
Para ambientes empresariais, a Política de Gestão de Riscos Clarysec Enterprise define o âmbito nos níveis de projeto e técnicos:
“Abrange os riscos de segurança da informação nos níveis estratégico, operacional, de projeto e técnico, e é obrigatória para todo o pessoal, contratados e prestadores de serviços envolvidos em atividades do Sistema de Gestão de Segurança da Informação (SGSI).”
Da secção “Âmbito”, cláusula 2.3 da política.
Terceiro, execute uma modelação de ameaças antes do início do desenvolvimento. A Política de Desenvolvimento Seguro Enterprise é explícita:
“Todas as novas aplicações e alterações de maior impacto devem ser sujeitas a revisão da arquitetura segura e modelação de ameaças antes do início do desenvolvimento.”
Da secção “Requisitos de implementação da política”, cláusula 6.1.1 da política.
Para o portal de integração, a modelação de ameaças deve cobrir interfaces expostas, fluxos de identidade, limites de privilégios, casos de abuso de API, falsificação de webhooks, ataques de repetição, credenciais comprometidas, caminhos de exfiltração de dados, risco de dependência, requisitos de logging, pressupostos de cópia de segurança, requisitos de recuperação e modos de falha do prestador.
Quarto, atualize a evidência de privacidade. A Política de proteção de dados e privacidade SME define a linha de base:
“5.3.1. A privacidade desde a conceção e por defeito deve ser aplicada em todos os novos sistemas e serviços”
Da secção “Requisitos de governação”, cláusula 5.3.1 da política.
O registo do projeto deve incluir finalidade, fundamento de licitude, papel de responsável pelo tratamento ou subcontratante, decisões de minimização de dados, regras de retenção, funções de acesso, escolhas de cifragem, considerações sobre impacto nos titulares dos dados, requisitos de transparência, termos do subcontratante e vias de notificação de violações de dados pessoais.
Quinto, registe a evidência de desenvolvimento seguro. A Política de Desenvolvimento Seguro SME fornece uma lista concisa de evidência que funciona para equipas pequenas e médias:
“5.3 O Diretor-Geral (GM) deve manter registos de: 5.3.1 Todos os projetos ativos de desenvolvimento de software e os programadores ou fornecedores responsáveis 5.3.2 Listas de verificação de segurança utilizadas em cada projeto 5.3.3 Revisões de código realizadas e as pessoas que as realizaram 5.3.4 Resultados dos testes antes da implementação 5.3.5 Componentes de terceiros e respetivo estado de licenciamento ou de risco”
Da secção “Requisitos de governação”, cláusula 5.3 da política.
Sexto, controle a implementação como uma alteração. A Política de gestão de alterações SME estabelece:
“1.1 Esta política garante que todas as alterações a sistemas de TI, configurações, aplicações empresariais ou serviços na nuvem são planeadas, sujeitas a avaliação de risco, testadas e aprovadas antes da implementação.”
Da secção “Finalidade”, cláusula 1.1 da política.
Para o portal de integração, o pedido de alteração deve incluir serviços afetados, avaliação de riscos, resultados dos testes, plano de reversão, plano de monitorização, aprovações de segurança, aprovação formal de privacidade, preparação dos fornecedores, atualizações de escalonamento de incidentes e critérios de acionamento de comunicações com clientes.
Por fim, mapeie as obrigações. A Política de Cumprimento Legal e Regulamentar SME fornece a regra operacional:
“5.2.2 Quando um regulamento se aplicar a várias áreas (por exemplo, o RGPD da UE aplica-se à retenção, segurança e privacidade), tal deve ser claramente mapeado no Registo de Conformidade e nos materiais de formação.”
Da secção “Requisitos de governação”, cláusula 5.2.2 da política.
Esse Registo de Conformidade torna-se a ponte entre os controlos ISO/IEC 27001:2022, as medidas do NIS2 Article 21, as obrigações de risco das TIC da DORA, a responsabilização do RGPD da UE e os compromissos contratuais com clientes.
Mapear um único pacote de evidência de projeto para NIS2, DORA, RGPD da UE e NIST CSF 2.0
A estratégia de conformidade mais eficiente não é duplicar trabalho. É mapear um conjunto robusto de evidência para múltiplas obrigações.
O Zenith Blueprint, na fase de Gestão de Riscos, Passo 14, recomenda este tipo de trabalho de referência cruzada:
“Para cada regulamento, se aplicável, pode criar uma tabela simples de mapeamento (por exemplo, como apêndice num relatório) que liste os principais requisitos de segurança do regulamento e os controlos/políticas correspondentes no seu SGSI.”
Acrescenta que isto é útil porque mostra a auditores e avaliadores “que não está a gerir a segurança no vazio, mas com consciência do contexto jurídico.”
O Zenith Controls: guia de conformidade transversal da Clarysec suporta a mesma abordagem integrada ao mapear os controlos ISO/IEC 27001:2022 para outros referenciais, expectativas de auditoria e necessidades de conformidade. Para a governação de projetos de TIC, enquadra A.5.8, A.8.25 e A.8.32 como controlos preventivos que protegem a confidencialidade, integridade e disponibilidade em preocupações de governação, segurança das aplicações, ecossistema, proteção e segurança de sistemas e redes.
| Artefacto de evidência | Finalidade ISO/IEC 27001:2022 | Valor para NIS2 | Valor para DORA | Valor para o RGPD da UE |
|---|---|---|---|---|
| Classificação de segurança do projeto | Define âmbito, partes interessadas, dependências e controlo operacional | Demonstra identificação baseada no risco de sistemas e serviços afetados | Identifica impacto em funções críticas ou importantes | Identifica dados pessoais, papéis e contexto de tratamento |
| Modelação de ameaças | Suporta avaliação de riscos e controlos de desenvolvimento seguro | Suporta aquisição segura, desenvolvimento e tratamento de vulnerabilidades | Suporta o quadro de risco das TIC e a estratégia de resiliência | Suporta privacidade desde a conceção e salvaguardas adequadas |
| Diligência prévia de fornecedores e revisão contratual | Suporta controlos de fornecedores e da cadeia de fornecimento de TIC | Suporta segurança da cadeia de fornecimento e avaliação direta de fornecedores | Suporta risco de terceiros de TIC, direitos de auditoria e planeamento de saída | Suporta salvaguardas do subcontratante e instruções de tratamento |
| Registos de desenvolvimento seguro e testes | Suporta SDLC seguro, gestão de vulnerabilidades e preparação para alterações | Suporta desenvolvimento seguro e avaliação de eficácia | Suporta testes de resiliência e remediação | Suporta segurança do tratamento e redução do risco de violação |
| Registo de aprovação de alteração | Suporta alterações planeadas, revisão e mitigação de efeitos adversos | Suporta implementação gerida com base no risco | Suporta reporte de governação e resiliência operacional | Suporta responsabilização por alterações de sistema que afetam dados pessoais |
| Atualização de incidentes e monitorização | Suporta logging, monitorização, planeamento de incidentes e recolha de evidência | Suporta tratamento de incidentes e preparação para reporte | Suporta classificação e escalonamento de incidentes graves de TIC | Suporta deteção e resposta a violações de dados pessoais |
| Mapeamento no Registo de Conformidade | Suporta requisitos legais e regulamentares e informação documentada | Demonstra alinhamento com o Article 21 | Demonstra integração no quadro DORA | Demonstra responsabilização em todos os princípios |
Esta tabela não substitui a análise jurídica. É um acelerador de governação. Garante que CISO, DPO, patrocinador do projeto, responsável de compras, proprietário do sistema e auditor interno analisam a mesma evidência.
O NIST CSF 2.0 também se encaixa naturalmente neste modelo. A sua função GOVERN ajuda as organizações a estabelecer políticas, papéis, apetite ao risco, supervisão e consciência legal ou contratual. As suas funções IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER ajudam as equipas a discutir ativos, serviços de fornecedores, controlo de acesso, segurança de dados, segurança de plataformas, desenvolvimento seguro de software, monitorização, resposta a incidentes e recuperação numa linguagem operacional comum.
| Requisito regulamentar ou de referencial | Como a governação de projetos ISO 27001 fornece evidência |
|---|---|
| DORA Article 5, Governação e organização | Demonstra supervisão pela gestão, responsabilidades definidas, vias de escalonamento e aprovação de decisões de risco das TIC |
| DORA Article 6, quadro de gestão do risco das TIC | Produz avaliações de risco das TIC ao nível do projeto, registos de tratamento, requisitos de resiliência e evidência de controlos |
| DORA Article 28, risco de terceiros de TIC | Documenta diligência prévia de fornecedores, salvaguardas contratuais, direitos de auditoria, planeamento de saída e monitorização contínua |
| NIS2 Article 20, Governação | Demonstra aprovação e supervisão pela gestão das medidas de gestão de riscos de cibersegurança |
| NIS2 Article 21(2)(d), Segurança da cadeia de fornecimento | Regista avaliação de fornecedores, critérios de aquisição, riscos de prestadores de serviços e requisitos contratuais de segurança |
| NIS2 Article 21(2)(e), Aquisição, desenvolvimento e manutenção seguros | Capta requisitos seguros, revisão da arquitetura, tratamento de vulnerabilidades, testes e evidência de remediação |
| GDPR Article 25, Proteção de Dados desde a Conceção e por Defeito | Demonstra requisitos de privacidade, minimização, retenção, controlo de acesso, salvaguardas do subcontratante e resultados de AIPD quando exigidos |
| NIST CSF 2.0 GV.PO-01 e GV.PO-02 | Demonstra que as políticas de cibersegurança são estabelecidas, comunicadas, aplicadas, revistas e atualizadas através da execução do projeto |
Um único processo alinhado com ISO 27001 e centrado no Anexo A.5.8 pode gerar evidência defensável para todas estas expectativas.
O desenvolvimento seguro é mais amplo do que escrever código
Muitas falhas em projetos de TIC acontecem porque a organização trata o desenvolvimento seguro como algo que apenas os programadores fazem. Em 2026, o desenvolvimento seguro também inclui configuração SaaS, automatização de fluxos de trabalho, infraestrutura como código, integrações de API, regras de identidade, zonas de aterragem na nuvem, pipelines de análise, automatização robótica de processos e aplicações empresariais low-code.
O Zenith Blueprint, na fase Controlos em Ação, Passo 20, aborda o controlo 8.25 Ciclo de Vida de Desenvolvimento Seguro da ISO/IEC 27002:2022:
“Este controlo aplica-se quer esteja a escrever as suas próprias aplicações, a configurar plataformas como sistemas ERP ou CRM, a personalizar fluxos de trabalho SaaS ou a gerir ambientes de infraestrutura como código.”
Também explica que os requisitos de segurança devem estar ao lado dos requisitos funcionais e que a modelação de ameaças ajuda a identificar partes expostas do sistema, funções de utilizador de risco e fluxos de dados que exigem proteção reforçada.
Para um projeto moderno, a evidência de desenvolvimento seguro pode incluir:
- Requisitos de segurança ligados aos requisitos de negócio
- Modelação de ameaças ou revisão da arquitetura segura
- Lista de verificação de programação segura ou de configuração segura
- Registos de revisão de código ou revisão por pares
- Inventário de componentes e estado do risco de dependência
- Decisões de gestão de segredos
- Desenho de controlo de acesso e princípio do menor privilégio
- Requisitos de logging e monitorização
- Resultados de análises de vulnerabilidades e registos de remediação
- Testes de segurança em pré-produção
- Testes de cópia de segurança, recuperação e resiliência quando relevantes
- Evidência de aprovação de implementação e reversão
O objetivo não é obrigar todos os projetos a passar pelo mesmo processo pesado. O objetivo é a proporcionalidade. Uma pequena alteração interna de fluxo de trabalho não exige a mesma evidência que uma migração de uma plataforma core de pagamentos. Mas todos os projetos devem ser classificados, sujeitos a avaliação de risco e governados de acordo com o impacto.
A gestão de alterações protege o projeto de si próprio
O momento mais arriscado em muitos projetos não é a conceção nem a programação. É a implementação.
Uma equipa pode realizar modelação de ameaças, revisão de código, avaliação de fornecedores e revisão de privacidade, e ainda assim criar uma indisponibilidade ou violação através de uma alteração apressada em produção. Uma flag de depuração permanece ativa. Uma regra de firewall é mais ampla do que o aprovado. Um script de migração copia dados pessoais para um ambiente de não produção. Um endpoint de webhook de terceiro é implementado sem autenticação. Uma alteração de logging regista números de documentos de identidade. Uma tarefa de cópia de segurança falha silenciosamente após a transição.
O Zenith Blueprint, na fase Controlos em Ação, Passo 21, descreve o controlo 8.32 Gestão de Alterações da ISO/IEC 27002:2022 em termos diretos:
“A mudança é inevitável, mas em cibersegurança a mudança não controlada é perigosa.”
E continua:
“No seu núcleo, a gestão de alterações eficaz é um fluxo de trabalho repetível. Começa com uma proposta clara, que descreve o que muda, porquê, quando e quais são os potenciais riscos.”
Um registo robusto de alteração de TIC deve responder a:
- Que sistema, serviço, fluxo de dados, fornecedor ou configuração está a mudar?
- Que riscos foram identificados e quem é o seu proprietário?
- A alteração afeta dados pessoais, serviços críticos, autenticação, logging, cópias de segurança ou resposta a incidentes?
- Que verificações de segurança, privacidade, resiliência e fornecedores foram realizadas?
- Que testes foram concluídos antes da implementação?
- Que monitorização confirmará o comportamento esperado?
- Que plano de reversão ou recuperação existe?
- Quem aprovou o risco residual?
- Que evidência será retida?
Para a DORA, isto suporta gestão do risco das TIC documentada, resiliência, continuidade, classificação de incidentes e lições aprendidas. Para a NIS2, suporta medidas de gestão de riscos, desenvolvimento seguro, prevenção de incidentes e continuidade. Para o RGPD da UE, ajuda a demonstrar que as alterações que afetam dados pessoais foram revistas à luz dos princípios de finalidade, minimização, retenção, acesso e segurança.
As decisões sobre fornecedores e nuvem devem fazer parte da conceção do projeto
Em projetos de TIC modernos, a decisão de conceção de maior risco é frequentemente “comprar” em vez de “construir”. Serviços na nuvem, fornecedores de API, plataformas de verificação de identidade, processadores de pagamentos, fornecedores de análise, prestadores de serviços geridos e prestadores de segurança geridos tornam-se parte da superfície de risco.
A NIS2 inclui explicitamente segurança da cadeia de fornecimento, vulnerabilidades diretas de fornecedores e prestadores de serviços, práticas de cibersegurança de fornecedores, procedimentos de desenvolvimento seguro e resultados de avaliações coordenadas de risco da cadeia de fornecimento. A DORA é mais aprofundada para entidades financeiras. Exige gestão do risco de terceiros de TIC como parte do quadro de gestão do risco das TIC, responsabilidade contínua mesmo quando os serviços de TIC são externalizados, registos de informação, avaliações pré-contratuais, análise de risco de concentração, controlos contratuais, direitos de auditoria e inspeção, critérios de cessação e estratégias de saída testadas para funções críticas ou importantes.
Para o portal de integração, o prestador de verificação biométrica não pode ser aprovado apenas porque a equipa de compras aprecia o preço e a documentação da API é boa. O projeto precisa de evidência de diligência prévia de segurança, papel no tratamento, localização dos dados, subcontratantes, compromissos de disponibilidade, apoio a incidentes, direitos de auditoria, assistência à cessação, viabilidade de saída e obrigações de monitorização.
Num modelo de evidência maduro, as decisões sobre fornecedores e nuvem ficam dentro do pacote de evidência do projeto, não numa pasta de fornecedores desconectada. Quando o auditor pergunta por que razão um terceiro foi aceite, a resposta deve incluir necessidade de negócio, avaliação de riscos, salvaguardas contratuais, revisão de proteção de dados, impacto na resiliência e monitorização contínua.
Como os auditores irão rever a evidência de segurança desde a conceção
Auditores diferentes abordam o mesmo projeto de TIC por ângulos diferentes. Um auditor de certificação, auditor interno, revisor DORA, autoridade competente NIS2, auditor de privacidade, avaliador orientado por NIST ou auditor de estilo COBIT pode pedir evidência semelhante, mas interpretá-la de forma diferente.
| Perspetiva de auditoria | O que o auditor irá perguntar | Evidência que normalmente satisfaz a pergunta |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | A segurança da informação foi integrada na gestão de projetos e no planeamento operacional, e as decisões de tratamento de riscos estão documentadas? | Termo de abertura do projeto, avaliação de riscos, mapeamento da SoA, plano de tratamento, aprovações por fases, controlos de informação documentada |
| Avaliador NIST CSF 2.0 | Os resultados de governação, risco, fornecedores, proteção, deteção, resposta e recuperação refletem-se nas decisões do projeto? | Perfil atual e perfil-alvo, plano de lacunas, inventário de fornecedores, desenho de acesso, plano de monitorização, procedimentos de incidente e recuperação |
| Auditor de estilo COBIT ou ISACA | Os objetivos, a propriedade, os controlos de processo, os direitos de decisão e a monitorização de desempenho estão claros? | RACI, atas de governação, propriedade dos controlos, relatórios de KPI e KRI, aprovações de alterações, constatações de auditoria interna |
| Revisor DORA | O projeto afeta funções críticas ou importantes, dependências de terceiros de TIC, testes de resiliência ou notificação de incidentes? | Avaliação de criticidade, registo de risco das TIC, registo centralizado de fornecedores, cláusulas contratuais, resultados dos testes, atualizações de classificação de incidentes |
| Auditor de RGPD da UE ou privacidade | O projeto aplicou privacidade desde a conceção, fundamento de licitude, minimização, retenção, segurança e responsabilização? | Mapa de fluxo de dados, registo de fundamento de licitude, AIPD quando aplicável, matriz de acessos, regras de retenção, termos do subcontratante, atualizações do playbook de violação |
Os auditores não querem uma apresentação bonita do projeto. Querem rastreabilidade. Querem ver que os requisitos deram origem a riscos, os riscos deram origem a controlos, os controlos deram origem a evidência de implementação e a implementação deu origem a revisão.
É por isso que o Zenith Controls é útil na preparação para auditoria. Ajuda as equipas a explicar por que motivo o Anexo A.5.8, A.8.25 e A.8.32 são controlos preventivos que protegem a confidencialidade, integridade e disponibilidade antes de falhas previsíveis chegarem à produção.
O pacote mínimo de evidência de projeto da Clarysec
Um pacote robusto de evidência de segurança desde a conceção não precisa de ser enorme. Precisa de ser consistente, proporcional e mapeado.
Para um projeto de TIC de risco médio, a Clarysec recomenda normalmente o seguinte pacote mínimo:
- Registo de classificação de segurança do projeto
- Nota de aplicabilidade regulamentar que cubra NIS2, DORA quando relevante, RGPD da UE e obrigações contratuais
- Mapa de fluxos de dados e de impacto em ativos
- Avaliação de riscos do projeto e plano de tratamento
- Modelação de ameaças ou revisão da arquitetura segura
- Avaliação de fornecedores e serviços na nuvem quando aplicável
- Lista de verificação de desenvolvimento seguro ou de configuração
- Resultados de testes de segurança e evidência de remediação
- Aprovação de alteração com plano de reversão e monitorização
- Registo de privacidade desde a conceção, incluindo fundamento de licitude e retenção quando estejam envolvidos dados pessoais
- Atualizações de resposta a incidentes e monitorização
- Revisão pós-implementação e lições aprendidas
- Mapeamento do Registo de Conformidade para controlos e obrigações
O Zenith Blueprint fornece a lógica do roteiro. O Passo 22 leva a segurança da informação a todas as fases do projeto. O Passo 20 incorpora o desenvolvimento seguro no planeamento, conceção, código, testes e implementação. O Passo 21 torna a gestão de alterações estruturada, rastreável e passível de revisão. O Passo 14 recomenda referências cruzadas entre RGPD da UE, NIS2, DORA e outras obrigações, para que os requisitos de conformidade não caiam por entre as falhas.
As políticas fornecem regras operacionais. A Política de Segurança da Informação integra a segurança com a gestão de projetos, compras e supervisão jurídica. A Política de Gestão de Riscos torna os riscos de projeto parte da atividade do SGSI. A Política de Desenvolvimento Seguro exige modelação de ameaças. A Política de Gestão de Alterações exige alterações planeadas, sujeitas a avaliação de risco, testadas e aprovadas. A Política de proteção de dados e privacidade exige privacidade desde a conceção e por defeito. A Política de Cumprimento Legal e Regulamentar exige que regulamentos com aplicação em várias áreas sejam mapeados no Registo de Conformidade.
Em conjunto, estas ferramentas transformam a segurança desde a conceção de uma aspiração num modelo operacional auditável.
Padrões comuns de falha em projetos de TIC
As falhas são geralmente previsíveis.
A primeira é o envolvimento tardio da segurança. As revisões de segurança acontecem depois de a arquitetura estar fixada, os contratos assinados e as datas de entrega publicadas. Nesse momento, a segurança torna-se um bloqueador em vez de um input de conceção.
A segunda é a evidência fragmentada. O projeto tem resultados de testes numa ferramenta, revisão de fornecedores noutra, comentários de privacidade por correio eletrónico, aceitação do risco numa gravação de reunião e aprovação de alteração num pedido. Não há um fio único que prove a governação.
A terceira são pontos cegos de fornecedores. O projeto depende de um serviço na nuvem ou de um fornecedor de API, mas ninguém verifica subcontratantes, localização dos dados, direitos de auditoria, apoio a incidentes, planos de saída ou risco de concentração.
A quarta é o desvio de privacidade. Um sistema construído para uma finalidade começa a suportar análise, experimentação com IA, exportações de marketing ou monitorização operacional sem revisitar fundamento de licitude, transparência, minimização ou retenção.
A quinta é alteração não revista. Uma implementação em produção é aprovada pela funcionalidade, mas não é avaliada quanto a acesso, logging, cifragem, cópias de segurança, resiliência, dados pessoais ou impacto no reporte.
A sexta é supervisão de gestão fraca. Riscos de projeto de alto impacto são aceites a um nível demasiado baixo, sem evidência de que o proprietário do risco responsável compreendeu as consequências regulamentares.
Estes problemas não se resolvem comprando mais uma ferramenta de análise. Resolvem-se integrando a governação da segurança na forma como os projetos são propostos, concebidos, adquiridos, construídos, testados, alterados e revistos.
A mensagem para o CISO em 2026
A segurança desde a conceção em projetos de TIC é agora uma questão de conselho de administração, auditoria e regulação. A NIS2 torna a gestão de riscos de cibersegurança uma responsabilidade do órgão de administração. A DORA torna o risco das TIC, os testes de resiliência, a gestão de incidentes e a supervisão de terceiros uma obrigação estruturada do setor financeiro. O RGPD da UE exige responsabilização pelo tratamento de dados pessoais e segurança adequada. A ISO/IEC 27001:2022 fornece a estrutura de sistema de gestão para operacionalizar estas obrigações.
Para os CISO, a oportunidade é deixar de confrontar as equipas de projeto no fim da entrega. Coloque a segurança na iniciação, requisitos, conceção, seleção de fornecedores, construção, testes, aprovação de alterações e revisão pós-implementação.
Para os gestores de conformidade, a oportunidade é substituir evidência dispersa por um único pacote de evidência de projeto mapeado.
Para os auditores, a oportunidade é testar o ciclo de vida do projeto, não apenas o sistema final.
Para os proprietários do negócio, a oportunidade é uma entrega mais rápida e mais segura. A segurança desde a conceção reduz retrabalho, evita surpresas de conformidade, melhora decisões sobre fornecedores e dá à liderança uma narrativa de risco defensável.
Se os seus projetos de TIC estão a avançar mais depressa do que o seu modelo de evidência, comece por um projeto-piloto. Use o Zenith Blueprint da Clarysec para definir pontos de controlo de segurança do projeto, aplique as políticas Clarysec para gestão de riscos, desenvolvimento seguro, gestão de alterações e privacidade, e use o Zenith Controls para mapear a governação de projetos ISO/IEC 27001:2022 para NIS2, DORA, RGPD da UE e NIST CSF 2.0.
A Clarysec pode ajudá-lo a criar um pacote reutilizável de evidência de projeto de segurança desde a conceção, alinhá-lo com o seu SGSI e prepará-lo para auditoria interna, auditoria de certificação, preparação para DORA, governação NIS2 e responsabilização no RGPD da UE.
Comece pelo seu próximo projeto de TIC significativo. Se altera sistemas, fornecedores, dados, acessos, resiliência ou confiança dos clientes, merece segurança desde a conceção desde o primeiro dia.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
