Domínio 4
Proteção desde a concepção
Incorporação de requisitos de segurança, privacidade e proteção infantojuvenil desde as primeiras etapas de concepção de produtos, serviços e processos.
Por que este domínio é necessário?
- Reduz o risco de correções tardias, caras e parciais depois do lançamento.
- Sustenta os direitos à privacidade, à segurança e ao desenvolvimento saudável.
- Sem requisitos desde o início, a proteção vira remendo sobre decisões já tomadas.
- Aumenta a previsibilidade do desenvolvimento e reduz retrabalho.
Direitos relacionados
- Privacidade
- Segurança
- Melhor interesse
- Desenvolvimento saudável
Objetivos
- Definir requisitos protetivos obrigatórios no ciclo de desenvolvimento.
- Adotar configurações protetivas por padrão.
- Testar e validar a proteção antes do lançamento.
Capacidades
Capacidades interdependentes que compõem este domínio.
Requisitos protetivos de produto
Em validaçãoRequisitos funcionais e não funcionais que asseguram proteção infantojuvenil em novas soluções.
Abrir capacidadeConfigurações protetivas por padrão
Em validaçãoDefinições iniciais mais protetivas aplicadas automaticamente a contas de crianças e adolescentes.
Abrir capacidadeTestes e validação
Em validaçãoVerificação prática de que os controles protetivos funcionam como esperado.
Abrir capacidadeRevisão de mudanças
Em validaçãoAnálise do impacto protetivo de alterações em produtos, algoritmos e processos já existentes.
Abrir capacidade
Práticas esperadas
- Catálogo de requisitos protetivos por tipo de funcionalidade.
- Critérios de aceitação verificáveis.
- Inclusão dos requisitos no fluxo de desenvolvimento.
- Definição de padrões protetivos por faixa etária.
- Restrição de visibilidade, contato e coleta de dados por padrão.
- Registro das decisões de padrão adotadas.
- Casos de teste específicos para cenários de risco infantojuvenil.
- Registro dos resultados e das correções.
- Bloqueio de lançamento em caso de falha crítica.
- Critérios para identificar mudanças que exigem revisão.
- Registro da análise realizada.
- Reversão prevista em caso de impacto negativo.
Evidências
- Checklist de requisitos protetivos no processo de desenvolvimento
- Registro de revisão de design
- Resultados de testes de proteção
- Documentação de configurações padrão
As evidências apresentadas são exemplos orientativos. A pertinência e a suficiência devem ser avaliadas considerando porte, setor, risco e contexto da organização.
Indicadores
| Indicador | Objetivo | Cálculo | Periodicidade |
|---|---|---|---|
| Cobertura de requisitos protetivos | Verificar quantos lançamentos passaram pela checagem de requisitos protetivos. | Lançamentos com checklist concluído dividido pelo total de lançamentos elegíveis. | Trimestral |
Indicadores sugeridos. As metas devem ser definidas pela organização conforme porte, setor e risco.
Perguntas orientadoras
- Existe uma prática formal documentada?Ver no Assessment
- Há responsável definido?Ver no Assessment
- A prática é aplicada de maneira consistente?Ver no Assessment
- Existem evidências disponíveis?Ver no Assessment
- Os resultados são monitorados?Ver no Assessment
- Há revisão periódica?Ver no Assessment
- Crianças, adolescentes ou seus representantes são considerados?Ver no Assessment
- A alta liderança recebe informações sobre o tema?Ver no Assessment
- Fornecedores e terceiros estão incluídos?Ver no Assessment
- Incidentes geram aprendizado e ajustes?Ver no Assessment
Relação com os níveis de maturidade
Nível 1 · Reativo
Proteção considerada apenas após reclamações ou incidentes.
Nível 2 · Estruturado
Requisitos existem, mas são aplicados de forma inconsistente.
Nível 3 · Preventivo
Requisitos integrados ao ciclo de desenvolvimento, com validação.
Nível 4 · Proativo e sistêmico
Proteção desde a concepção é premissa de arquitetura, com testes e métricas próprias.
Recursos e referências
- IEEE 2089-2021
- Comentário Geral nº 25
- Privacy by design
- Safety by design