ISO 27001 para Empresas de Software │ Caixa Mágica

A ISO 27001 para empresas de software é diferente da versão que a maioria das pessoas imagina. A imagem habitual são políticas, dossiês e uma sala de servidores fechada à chave. Numa empresa cujo produto é código, a maior parte da norma vive dentro do processo de entrega, em decisões que os engenheiros tomam todas as semanas.

Isto importa em duas direções. Se está a comprar software, diz-lhe que perguntas testam de facto se o certificado de um fornecedor significa alguma coisa. Se é uma empresa de software a ponderar a certificação, diz-lhe quanto do trabalho é engenharia e não documentação.

O que se segue são as seis áreas onde a norma morde com mais força numa organização de desenvolvimento, e para cada uma a prova que um cliente pode razoavelmente pedir.

Um certificado prova que um auditor examinou o sistema. A declaração de âmbito diz-lhe se examinou a parte que vai construir o seu software.

O que a ISO 27001 para empresas de software exige de facto

A norma certifica um Sistema de Gestão da Segurança da Informação, o que soa administrativo até olhar para onde os controlos têm de operar. Numa consultora, a resposta são escritórios e portáteis. Numa empresa de software são repositórios, pipelines de build, ambientes e as pessoas que têm credenciais para os três.

Assim, o mesmo certificado significa algo bastante diferente consoante o que a organização faz. A ISO 27001 para empresas de software concentra-se, por isso, em zonas que um resumo de auditoria genérico nunca menciona. As duas colunas abaixo mostram onde fica o peso numa equipa de desenvolvimento.

O que se espera

Políticas e papelada

Um conjunto documentado de políticas, um registo de ativos, registos de formação e uma revisão pela gestão. Requisitos reais, e a parte que a maioria das consultoras vende.

O que significa na prática

O processo de entrega

Revisão de código, gestão de dependências, separação de ambientes, acessos a repositórios, avaliação de subcontratados e resposta a incidentes, evidenciados e não descritos.

Ambos são auditados. Só o segundo lhe diz alguma coisa sobre o software que está prestes a encomendar.

Esta distinção explica um padrão que os clientes notam assim que sabem procurá-lo. Uma consultora e uma casa de desenvolvimento podem ter certificados que se leem quase da mesma forma na primeira página, enquanto as auditorias subjacentes examinaram coisas completamente diferentes. Uma olhou para portáteis, registos de formação e um registo de riscos. A outra olhou para tudo isso mais o pipeline que leva código para produção.

Seis áreas onde a ISO 27001 para empresas de software toca a entrega

Nenhuma destas é exótica. Muitas equipas já trabalham assim, porque as práticas são anteriores à norma e existem por razões de engenharia e não de conformidade. O que a ISO 27001 para empresas de software acrescenta não é a prática em si, mas um auditor externo que a verifica e volta todos os anos.

Revisão de código antes do merge. As alterações chegam ao ramo principal através de revisão e não por fora dela. Prova: regras de proteção de ramo e histórico de revisões, difíceis de forjar retroativamente.

Gestão de dependências. Um registo do que está no build, e um processo para reagir quando um componente se revela vulnerável. Prova: um inventário de componentes a pedido, e a rapidez com que chega.

Separação de ambientes. Desenvolvimento, staging e produção mantidos à parte, com promoção controlada entre eles e sem dados de produção na base local de um programador. Prova: documentação do processo de deployment e fronteiras de acesso.

Acessos a repositórios e infraestrutura. Concedidos com menor privilégio e aprovação documentada, depois revistos periodicamente em vez de concedidos uma vez e esquecidos. Prova: registos de revisão de acessos e o procedimento de offboarding.

Avaliação de subcontratados. Todos os terceiros avaliados antes de tocarem num projeto, incluindo freelancers e agências parceiras. Prova: o processo de avaliação de fornecedores e uma lista atualizada de subcontratados.

Resposta a incidentes com prazos. Deteção, classificação, notificação e revisão pós-incidente, escritas e testadas em vez de improvisadas. Prova: o procedimento e um registo de ter sido exercitado.

O offboarding merece atenção particular, já que é onde organizações certificadas e não certificadas divergem de forma mais visível. Conceder acessos é fácil de fazer bem porque há alguém à espera. Remover acessos na semana em que um programador sai do projeto não tem ninguém a pressionar, e é exatamente por isso que um auditor pergunta.

A gestão de dependências tornou-se o outro separador fiável, em boa parte pela forma como o software é construído hoje. Uma aplicação moderna carrega centenas de componentes de terceiros, e cada um é uma via de entrada para os seus sistemas se ninguém os acompanhar. Uma equipa que consegue produzir um inventário rigoroso a pedido é uma equipa que já sabe o que entrega.

Peça a um fornecedor um inventário de componentes atualizado. O tempo de resposta diz-lhe mais do que o documento.

A avaliar um fornecedor de software e quer testar estas seis áreas com um fornecedor a sério?

Fale com a nossa equipa

Que prova pedir a um fornecedor de software certificado

A certificação diz-lhe que um auditor ficou satisfeito. Não lhe diz o que ele examinou, e é por isso que três pedidos concretos valem mais do que um questionário de vinte páginas.

Três pedidos que testam o certificado

A declaração de âmbito

Nomeia desenvolvimento, entrega e suporte de software, ou apenas uma sede?

→

A revisão de acessos

Quem tem acesso a repositórios e produção, quando foi revisto pela última vez, e o que o offboarding remove.

→

O último incidente

O que aconteceu, quem foi notificado, e o que mudou depois. Uma resposta real é específica.

Um fornecedor com os processos implementados responde aos três em dias. A vaguidade no terceiro é o sinal mais forte, porque um procedimento testado produz uma história e um não testado produz uma descrição.

Porque é que a declaração de âmbito decide tudo

Dois certificados podem ter a mesma norma, a mesma entidade acreditada e o mesmo logótipo, cobrindo atividades inteiramente diferentes. Um diz "gestão da segurança da informação para a sede corporativa". Outro diz "conceção, desenvolvimento, entrega, manutenção e suporte de software e soluções de tecnologias de informação".

Só o segundo lhe diz que os engenheiros que escrevem o seu código trabalham dentro do sistema certificado. Ler esse parágrafo demora trinta segundos e esclarece mais sobre a ISO 27001 para empresas de software do que qualquer questionário, e mesmo assim é a parte que quase ninguém abre.

O âmbito também lhe diz se pessoas externas estão cobertas. Se um fornecedor coloca engenheiros dentro da sua organização, ou trabalha através de agências parceiras, o certificado só é útil quando esses acordos ficam dentro do sistema certificado. Um âmbito que pára nos colaboradores permanentes deixa de fora precisamente o acordo que está a comprar.

A Caixa Mágica Software detém o certificado 26ISMS-1252 ao abrigo da ISO/IEC 27001:2022, com um âmbito que cobre conceção, desenvolvimento, entrega, manutenção e suporte de software e soluções de TI, incluindo serviços nearshore e de reforço de equipas. Pode ler o que a nossa certificação abrange ou verificá-la diretamente na base de dados IAF CertSearch.

Quando vale a pena procurar a ISO 27001 para empresas de software

Para uma empresa de software a ponderar a certificação, o cálculo honesto é comercial e não técnico. Se os seus clientes são entidades essenciais ou importantes ao abrigo da NIS2, entidades financeiras ao abrigo do DORA, ou administração pública, o requisito já está a chegar através dos contratos e questionários deles. Certificar uma vez custa menos do que responder às mesmas perguntas vinte vezes por ano.

Se nenhum dos seus clientes é regulado, o argumento para a ISO 27001 para empresas de software é mais fraco e o trabalho é real. Conte com um esforço de documentação menor do que teme e com uma disciplina de processo maior, sobretudo em revisões de acessos e retenção de evidência.

Uma coisa a decidir antes de começar: quão largo será o âmbito. Um âmbito estreito é mais barato de alcançar e consideravelmente menos útil, porque os clientes que sabem ler um certificado vão reparar. Cobrir a cadeia de entrega de ponta a ponta custa mais na preparação e responde a muito mais perguntas depois.

Perguntas frequentes

Cinco perguntas surgem sempre que certificação e entrega de software se cruzam, por isso as respostas estão reunidas aqui.

O que exige a ISO 27001 a uma empresa de software?

Para lá do sistema de gestão documentado, os controlos chegam ao processo de entrega: revisão de código antes do merge, gestão de dependências com registo do que está no build, separação entre desenvolvimento, staging e produção, acessos a repositórios e infraestrutura com menor privilégio e revisão periódica, avaliação de subcontratados, e um procedimento de resposta a incidentes testado e com prazos definidos.

A ISO 27001 certifica o software que uma empresa constrói?

Não. A norma certifica o sistema de gestão da organização, não produtos, plataformas ou aplicações individuais. Um fornecedor que afirme que um produto específico é certificado ISO 27001 leu mal a norma. O que o certificado cobre é todos os projetos entregues dentro do âmbito declarado.

Quanto tempo demora a certificação ISO 27001 numa empresa de software?

Depende muito mais da prática existente do que da dimensão da empresa. Equipas que já fazem revisão de código, controlo de acessos e gestão de dependências estão sobretudo a documentar e evidenciar o que fazem. Equipas a começar do zero estão a mudar a forma como trabalham, o que demora consideravelmente mais. O certificado depois tem validade de três anos, com auditorias de acompanhamento anuais.

Que prova pode um cliente pedir a um fornecedor certificado?

A declaração de âmbito, um inventário de componentes atualizado, registos de revisão de acessos, o procedimento de offboarding, o procedimento de resposta a incidentes e um registo de ter sido exercitado, e a lista de subcontratados. O tempo de resposta é muitas vezes mais informativo do que os documentos, porque um fornecedor com processos a funcionar produz tudo isto em dias.

A ISO 27001 chega para cumprir a NIS2 ou o DORA?

Responde a grande parte da questão da cadeia de fornecimento, embora não a toda. Prazos de notificação de incidentes, um contacto de segurança nomeado e a localização dos dados são específicos dos seus próprios deveres de reporte e continuam a ter de ser acordados por contrato. A certificação cobre o sistema de gestão subjacente, não os termos do seu acordo em concreto.

Equipa Caixa Mágica

A Caixa Mágica Software é uma empresa portuguesa de software com mais de 20 anos de experiência a fornecer software à medida, soluções de IA e equipas de desenvolvimento *nearshore* para empresas europeias.

Desenvolvimento de Software · Caixa Mágica Software

Peça-nos os três

A declaração de âmbito, a revisão de acessos, o último incidente. O nosso certificado cobre toda a cadeia de entrega incluindo equipas nearshore, e é verificável na base de dados do IAF sem nos perguntar nada.

Iniciar uma conversa Ver o que a nossa certificação abrange