Como a MyCena atende aos seus requisitos de conformidade

Selecione uma estrutura abaixo. Cada mapeamento mostra quais controles específicos a MyCena aborda, como ela os aborda e quais evidências de auditoria a plataforma gera automaticamente. Use isso em conversas com auditores e revisões de conformidade com clientes.
Estruturas dos EUA e da UE Evidências geradas automaticamente Exportações prontas para auditoria
Framework →
SOC 2 Type II — Critérios de Serviços de Confiança
Segurança, Disponibilidade e Confidencialidade
O SOC 2 avalia controles relevantes para segurança, disponibilidade, integridade de processamento, confidencialidade e privacidade. Os critérios mais diretamente abordados pela MyCena estão sob a série de Critérios Comuns (CC) — especialmente controles de acesso, segurança lógica e gestão de mudanças. Os mapeamentos abaixo referenciam os critérios AICPA TSC 2017.
Requisito de controleComo a MyCena atende
CC6.1Software de segurança de acesso lógico, infraestrutura e arquiteturas
A MyCena gera e controla todas as credenciais de forma centralizada. Os usuários nunca possuem credenciais — eliminando o vetor mais comum de acesso lógico não autorizado. A organização mantém controle criptográfico sobre cada credencial no escopo.
Logs de geração de credenciais, trilha de auditoria de eventos de acesso, registros de gestão de chaves de criptografia
CC6.2Registro e autorização de novos usuários antes da emissão de credenciais do sistema
A emissão de credenciais na MyCena requer autorização explícita do administrador. Nenhum usuário pode autoprovisionár acesso. Cada evento de emissão de credencial é registrado com a identidade do administrador autorizador, carimbo de data/hora e escopo do sistema.
Log de provisionamento de usuários com identidade do aprovador, carimbo de data/hora e escopo do sistema por evento de emissão
CC6.3Acesso baseado em função e remoção de acesso quando não mais necessário
A MyCena permite a revogação instantânea de todas as credenciais de qualquer usuário em todos os sistemas conectados com um único comando. A revogação é registrada com carimbo de data/hora, identidade do administrador e escopo. O acesso não pode persistir após a revogação — a credencial deixa de funcionar imediatamente.
Log de evento de revogação com carimbo de data/hora e confirmação, demonstrando janela zero de acesso pós-revogação
CC6.6Medidas de segurança de acesso lógico para proteção contra ameaças externas ao sistema
Como os usuários nunca conhecem ou possuem credenciais, ataques de phishing e engenharia social não conseguem extrair credenciais utilizáveis. Não há credencial que um agente de ameaça externo possa roubar de um usuário. A injeção de credenciais ocorre no ponto de autenticação — nunca na memória ou no armazenamento acessível ao usuário.
Documentação de arquitetura, logs de bloqueio de credenciais no navegador, zero extrações bem-sucedidas de credenciais por phishing
CC6.7Transmissão e movimentação de informações
As credenciais são transmitidas criptografadas de ponta a ponta. Elas nunca estão em texto claro em trânsito. O navegador é ativamente impedido de salvar ou armazenar em cache os valores das credenciais. Os logs de auditoria capturam todos os eventos de transmissão.
Logs de criptografia em trânsito, confirmação de bloqueio no navegador, registros de auditoria de transmissão de credenciais
CC7.2Monitoramento de anomalias e eventos de segurança
A MyCena gera uma trilha de auditoria em tempo real de cada evento de acesso — quem acessou qual sistema, quando, de qual dispositivo e IP. Padrões de acesso anômalos são exibidos no painel e exportáveis para integração com SIEM.
Log de eventos de acesso em tempo real, registros de sinalização de anomalias, exportação compatível com SIEM
CC9.2Gestão de acesso de fornecedores e terceiros
Todas as credenciais de terceiros e fornecedores são geradas, controladas e revogáveis pela organização — não pelo fornecedor. O acesso do fornecedor é limitado por sistema, registrado por evento e revogável instantaneamente quando o contrato termina. Nenhum offboarding manual é necessário.
Log de acesso de terceiros, registros de revogação de credenciais de fornecedores, documentação de limitação de escopo

Evidências de auditoria geradas automaticamente pela MyCena

Log de eventos de acesso
Cada evento de login: usuário, sistema, carimbo de data/hora, dispositivo, IP. Exportável. À prova de adulteração.
Log de provisionamento
Cada emissão de credencial: aprovador, usuário, sistema, carimbo de data/hora. Cadeia completa de autorização.
Log de revogação
Cada evento de revogação com carimbo de data/hora e confirmação. Prova de janela zero disponível.
Relatório de acesso de fornecedores
Todas as credenciais de terceiros no escopo, último acesso, status de revogação, escopo por sistema.

Como usar isso em uma conversa de auditoria

Quando o auditor de SOC 2 perguntar sobre evidências de controle de acesso, abra o painel da MyCena e exporte o log de eventos de acesso para o período em revisão. Cada critério de controle de acesso CC6 e CC7 pode ser evidenciado a partir de uma única exportação. Os logs de provisionamento e revogação juntos demonstram o ciclo de vida completo do usuário — desde a emissão autorizada até o encerramento confirmado — sem lacunas.

Regra de Segurança HIPAA — 45 CFR Parte 164
Salvaguardas Administrativas, Físicas e Técnicas
A Regra de Segurança HIPAA exige que entidades cobertas e associados comerciais implementem salvaguardas para proteger informações de saúde eletrônicas protegidas (ePHI). A MyCena atende a vários requisitos de Salvaguardas Técnicas e Administrativas — especialmente aqueles relacionados a controle de acesso, controles de auditoria e controles de força de trabalho. As referências são à 45 CFR Parte 164 Subparte C.
Salvaguarda / padrãoComo a MyCena atende
§164.312(a)(1)Controle de acesso — identificação única de usuário
A MyCena atribui e gerencia credenciais únicas por usuário por sistema. Contas ou credenciais compartilhadas não são possíveis — cada credencial é gerada exclusivamente para um usuário e um sistema. O login compartilhado é estruturalmente eliminado.
Log de emissão de credenciais por usuário, confirmando credencial única por par usuário-sistema
§164.312(a)(2)(i)Controle de acesso — logoff automático
Os controles de sessão da MyCena podem aplicar expiração de credenciais e requisitos de reautenticação. As janelas de validade das credenciais são configuráveis por sistema. Credenciais expiradas não podem ser usadas sem reautorização da plataforma MyCena.
Registros de configuração de validade de credenciais, logs de expiração de sessão
§164.312(a)(2)(ii)Controle de acesso — procedimento de acesso de emergência
Os administradores da MyCena podem provisionar credenciais de acesso de emergência rapidamente para cenários de break-glass. A emissão de emergência é registrada com motivo, aprovador e escopo com limite de tempo. As credenciais de emergência são revogadas automaticamente no vencimento ou manualmente por qualquer administrador.
Log de emissão e revogação de credenciais de emergência com código de motivo e aprovador
§164.312(b)Controles de auditoria — mecanismos de hardware, software e procedimentos
A MyCena gera uma trilha de auditoria abrangente e à prova de adulteração de cada evento de acesso a cada sistema conectado. Os logs incluem identidade do usuário, sistema acessado, carimbo de data/hora, identificador do dispositivo e endereço IP. Os logs são exportáveis para integração com SIEM e sistemas de gestão de auditoria.
Trilha de auditoria de acesso completa exportável em formatos padrão. Cobrindo 100% dos eventos de acesso mediados pela MyCena.
§164.312(c)(1)Integridade — proteger ePHI contra alteração ou destruição imprópria
Ao controlar todas as credenciais de forma centralizada, a MyCena reduz o risco de acesso não autorizado que poderia levar à alteração ou destruição imprópria de ePHI. Nenhum usuário que foi desligado retém qualquer credencial que possa permitir acesso continuado.
Logs de completude de revogação demonstrando validade zero de credenciais pós-desligamento
§164.312(d)Autenticação de pessoa ou entidade
A MyCena garante que somente o usuário especificamente autorizado possa acessar um sistema por meio de sua credencial gerenciada pela MyCena. As credenciais são vinculadas ao dispositivo e são somente por injeção — não podem ser extraídas e usadas de um dispositivo ou contexto diferente.
Logs de vinculação de dispositivo, documentação de arquitetura somente por injeção, registros de eventos de acesso
§164.308(a)(3)Segurança da força de trabalho — autorização e supervisão
Cada emissão de credencial requer autorização do administrador. Os membros da força de trabalho não podem autoprovisionár acesso a nenhum sistema. O encerramento aciona a revogação imediata de credenciais em todos os sistemas — nenhuma lista de verificação de offboarding manual é necessária.
Trilha de auditoria de provisionamento e revogação da força de trabalho, demonstrando cadeia de autorização para cada concessão de acesso

Evidências de auditoria geradas automaticamente pela MyCena

Log de acesso único por usuário
Confirma ausência de credenciais compartilhadas. Cada evento de acesso vinculado a um único usuário nomeado.
Log do ciclo de vida da força de trabalho
Eventos de provisionamento e revogação para cada membro da força de trabalho. Tempo de encerramento até revogação registrado.
Trilha de auditoria de acesso completa
100% do acesso a sistemas ePHI mediado pela MyCena. Formato de log de auditoria compatível com HIPAA disponível.
Log de acesso de emergência
Eventos de break-glass com motivo, aprovador, escopo, duração e confirmação de revogação.

Como usar isso em uma revisão HIPAA

Os auditores HIPAA se concentram em três coisas nas revisões de controle de acesso: você pode provar quem acessou o quê e quando, pode provar que funcionários desligados perderam o acesso prontamente, e pode provar que não existem credenciais compartilhadas. As exportações de auditoria da MyCena respondem às três diretamente — sem coleta manual de evidências. Exporte o log de acesso, o log do ciclo de vida da força de trabalho e o relatório de confirmação de revogação para o período de auditoria.

Framework de Cibersegurança NIST 2.0
Governar, Identificar, Proteger, Detectar, Responder, Recuperar
O NIST CSF 2.0 (lançado em fevereiro de 2024) expandiu o framework para seis funções, adicionando Governar como a função abrangente. A MyCena aborda controles principalmente dentro de Governar, Proteger e Detectar, com contribuições significativas para as subcategorias de Gestão de Identidade e Controle de Acesso. As referências usam o formato de identificador do CSF 2.0.
Função / categoriaComo a MyCena atende
GV.OC-01Governar — contexto organizacional: funções e responsabilidades
A MyCena aplica uma separação clara: a organização controla todas as credenciais, não os usuários individuais. Essa atribuição de controle estrutural é em si um controle de governança — a política da organização é aplicada pela arquitetura, não por treinamento ou procedimento.
Registros de configuração do administrador, documentação de política de acesso baseado em função
PR.AA-01Proteger — identidades e credenciais gerenciadas para usuários autorizados
A MyCena gera e gerencia todas as credenciais de forma centralizada. Cada identidade tem uma credencial única. Nenhuma credencial é gerada ou mantida pelo usuário. O ciclo de vida das credenciais — emissão, rotação, revogação — está sob controle organizacional em todos os momentos.
Log do ciclo de vida das credenciais: emissão, eventos de rotação, confirmações de revogação por identidade
PR.AA-02Proteger — identidades verificadas e vinculadas a credenciais
As credenciais são vinculadas a identidades de usuário específicas e dispositivos específicos na emissão. A credencial não pode ser extraída e usada de uma identidade ou contexto de dispositivo diferente. A vinculação identidade-credencial é registrada e verificável.
Registros de vinculação identidade-credencial, logs de vinculação de dispositivo por evento de emissão
PR.AA-05Proteger — permissões de acesso gerenciadas com privilégio mínimo
As credenciais são limitadas por sistema na emissão — um usuário recebe acesso a sistemas específicos, não a classes amplas de sistema. O movimento lateral usando uma única credencial comprometida é estruturalmente restringido.
Registros de escopo de acesso por sistema, log de auditoria de alteração de escopo, mapa de acesso ao sistema por usuário
PR.AA-06Proteger — acesso físico controlado
A injeção de credenciais é vinculada ao dispositivo. Uma credencial não pode ser usada em um dispositivo não registrado — mesmo que um usuário seja coagido ou um dispositivo seja roubado. A perda de dispositivo físico não compromete automaticamente as credenciais de acesso.
Log de registro de dispositivo, registros de tentativas de acesso de dispositivos não registrados (eventos bloqueados)
DE.AE-02Detectar — anomalias e eventos analisados
O log de eventos de acesso em tempo real da MyCena permite a detecção de padrões anômalos — horários de acesso incomuns, IPs de origem incomuns, combinações incomuns de sistemas, frequência de acesso incomumente alta. Os logs são exportáveis para SIEM para detecção automatizada de anomalias.
Fluxo de eventos de acesso em tempo real, exportação de detecção de anomalias, registros de integração com SIEM
RS.MA-01Responder — incidentes gerenciados
Quando um incidente é detectado, a MyCena permite a revogação imediata de credenciais em todos os sistemas para o usuário afetado — contido em segundos, não horas. A revogação é registrada com carimbo de data/hora, confirmando a ação de contenção e seu tempo exato relativo à detecção do incidente.
Log de revogação de resposta a incidentes: tempo de detecção até revogação, escopo, confirmação
PR.PS-01Proteger — software gerenciado para reduzir a superfície de ataque
Ao remover credenciais da posse do usuário completamente, a MyCena elimina a maior superfície de ataque única na maioria dos ambientes — credenciais mantidas pelo usuário. Esta é uma redução estrutural da superfície de ataque, não um controle compensatório.
Documentação de arquitetura. Sem credenciais em memória acessível ao usuário, armazenamento do navegador ou gerenciadores de senha.

Evidências de auditoria geradas automaticamente pela MyCena

Log do ciclo de vida de identidade
Ciclo de vida completo de credenciais por identidade: emissão, rotação, alterações de escopo, revogação.
Mapa de escopo de acesso
Escopo de acesso por usuário e por sistema em qualquer momento. Exportável para revisão de privilégio mínimo.
Exportação de detecção de anomalias
Eventos de acesso sinalizados por padrões anômalos. Formato compatível com SIEM.
Log de resposta a incidentes
Tempo de detecção até revogação por incidente. Confirma velocidade e escopo de contenção.

Como usar isso em uma avaliação NIST CSF

As avaliações do NIST CSF pontuam a maturidade em cada subcategoria. A MyCena move várias subcategorias PR.AA de maturidade “parcial” ou “informada por risco” para “adaptativa” — porque os controles são arquitetônicos, não procedurais. Ao apresentar a um avaliador, lidere com o argumento estrutural: a MyCena não adiciona uma política em torno de gestão de credenciais, ela remove credenciais da posse do usuário completamente. Essa distinção move o ponteiro de maturidade mais do que qualquer controle compensatório.

Regulamento Geral sobre a Proteção de Dados — UE 2016/679
Proteção de Dados por Design, Segurança do Processamento, Notificação de Violação
O RGPD exige que as organizações implementem medidas técnicas e organizacionais adequadas para proteger os dados pessoais. A MyCena aborda várias das lacunas de conformidade mais frequentemente citadas — especialmente os Artigos 25, 32 e 33, que juntos cobrem proteção de dados por design, controles de segurança e obrigações de divulgação de violações.
Artigo / requisitoComo a MyCena atende
Article 25(1)Proteção de dados por design — medidas técnicas na fase de design
A MyCena implementa o controle de credenciais no nível arquitetônico — antes que um usuário toque em um sistema. Ao remover credenciais da posse do usuário completamente, a organização estruturalmente impede o mecanismo mais comum pelo qual os dados pessoais são expostos.
Documentação de arquitetura confirmando o modelo de injeção de credenciais. Sem credenciais armazenadas em forma acessível ao usuário.
Article 25(2)Proteção de dados por padrão — apenas dados necessários processados
A MyCena aplica o acesso de privilégio mínimo por design. As credenciais são limitadas por usuário por sistema na emissão — nenhum usuário recebe acesso mais amplo do que sua função específica exige. O acesso além do que é necessário é estruturalmente impedido.
Registros de escopo de acesso por usuário. Nenhum usuário tem acesso de credencial a sistemas além do seu escopo definido.
Article 32(1)(a)Segurança do processamento — pseudonimização e criptografia
Todas as credenciais gerenciadas pela MyCena são distribuídas de forma criptografada e injetadas sem expor texto claro ao usuário, à área de transferência do dispositivo ou ao armazenamento do navegador. As credenciais nunca são armazenadas em texto claro em nenhum ponto do ciclo de vida do usuário.
Documentação de arquitetura confirmando criptografia em trânsito e distribuição somente por injeção. Confirmação de bloqueio no navegador.
Article 32(1)(b)Segurança do processamento — confidencialidade e integridade contínuas
A confidencialidade contínua é mantida garantindo que nenhum usuário, contratado ou terceiro retenha acesso às credenciais após o término de sua autorização. O mecanismo de revogação da MyCena garante que o acesso seja encerrado em todos os sistemas simultaneamente e confirmado no log de auditoria.
Log de completude de revogação. Confirmação de acesso bloqueado pós-revogação. Zero janelas de acesso abertas após o encerramento.
Article 32(1)(d)Segurança do processamento — testes e avaliação regulares das medidas
O log de eventos de acesso da plataforma MyCena permite monitoramento contínuo e revisão regular de quem acessou quais sistemas. Revisões de acesso regulares podem ser realizadas diretamente na plataforma sem coleta manual de dados.
Exportação de revisão de acesso. Relatórios periódicos de auditoria de escopo de acesso. Registros de testes de revogação.
Article 33Notificação de violação à autoridade supervisora — janela de 72 horas
O log de auditoria em tempo real da MyCena fornece as evidências necessárias para uma notificação completa e precisa — quais sistemas foram acessados, por quem, quando e de onde. Organizações com a MyCena implantada podem produzir uma cronologia de acesso completa imediatamente, sem a reconstrução manual de logs que tipicamente atrasa as notificações.
Log de eventos de acesso em tempo real. Exportação de cronologia de incidentes. Cobre 100% do acesso mediado pela MyCena a sistemas de dados pessoais.
Article 28Obrigações do operador — medidas técnicas e organizacionais
Onde a organização que implanta a MyCena atua como operadora, a MyCena fornece os controles técnicos que sustentam as obrigações de segurança do operador. O operador gera e controla cada credencial e pode demonstrar isso com um log de auditoria.
Documentação de controles de segurança do operador. Log de acesso de terceiros mostrando credenciais controladas pela organização para todos os funcionários do operador.
Recital 83 / Art. 32(2)Avaliação de riscos — riscos de destruição acidental ou ilegal, alteração, divulgação não autorizada
O acesso não autorizado baseado em credenciais — phishing, uso indevido interno, acesso obsoleto — é o risco de maior frequência na maioria dos ambientes. A MyCena remove esses riscos estruturalmente em vez de mitigá-los proceduralmente, reduzindo materialmente o risco residual que uma avaliação de risco do RGPD deve quantificar.
Atualização do registro de riscos confirmando eliminação estrutural de phishing, compartilhamento de credenciais e vetores de acesso obsoleto.

Evidências de auditoria geradas automaticamente pela MyCena

Log de eventos de acesso
Cada acesso a sistemas de dados pessoais: usuário, sistema, carimbo de data/hora, dispositivo, IP. Suporta notificação de violação em 72 horas com cronologia completa do incidente.
Registros de escopo de acesso
Escopo de acesso ao sistema por usuário confirmando aplicação de privilégio mínimo. Suporta evidências de minimização de dados do Artigo 25(2).
Log de completude de revogação
Revogação pós-encerramento com carimbo de data/hora. Confirma zero janelas de acesso ativo após o término do vínculo empregatício ou contratual.
Documentação de controle do operador
Evidências de controle técnico para obrigações de segurança do operador do Artigo 28. Suporta questionários de due diligence de controladores de dados.

Como usar isso em uma revisão RGPD ou negociação DPA

Os Encarregados de Proteção de Dados e as autoridades supervisoras se concentram em três perguntas nas revisões de controle de acesso: você sabe quem teve acesso aos dados pessoais e quando, pode demonstrar que o acesso terminou quando deveria ter terminado, e o que você seria capaz de informar a um regulador dentro de 72 horas após uma violação? A MyCena responde às três a partir da mesma exportação de auditoria.

Lei de Resiliência Operacional Digital — UE 2022/2554
Gestão de Riscos de TIC, Controles de Acesso e Governança de Terceiros
A DORA tornou-se aplicável em 17 de janeiro de 2025 para entidades financeiras na UE — bancos, seguradoras, empresas de investimento, instituições de pagamento e seus provedores críticos de serviços de TIC de terceiros. A MyCena aborda diretamente os requisitos de gestão de acesso de TIC da DORA nos Artigos 9 e 10, e os requisitos de governança de riscos de terceiros no Artigo 28.
Artigo / requisitoComo a MyCena atende
Article 9(2)Segurança de TIC — gestão de direitos de acesso e autenticação
A DORA exige que as entidades financeiras implementem controles de autenticação fortes e gerenciem os direitos de acesso de TIC com base na necessidade de saber. A MyCena remove completamente as credenciais da posse do usuário — os direitos de acesso são gerenciados centralmente pela organização. Cada credencial é gerada com um escopo definido, registrada na emissão e revogável instantaneamente.
Log de emissão de credenciais confirmando acesso por escopo por usuário por sistema. Sem credenciais geradas ou mantidas pelo usuário.
Article 9(4)(c)Segurança de TIC — políticas para contas privilegiadas e acesso remoto
A DORA exige especificamente controles para contas privilegiadas e canais de acesso remoto. A MyCena governa todos os tipos de contas sob o mesmo modelo de controle central — contas privilegiadas recebem a mesma disciplina de gestão de credenciais que contas padrão, com restrições de escopo configuráveis, controles de sessão e registro de auditoria.
Log de gestão de credenciais de contas privilegiadas. Registros de sessão de acesso remoto. Documentação de configuração de escopo.
Article 9(4)(d)Segurança de TIC — autenticação forte para sistemas críticos
A DORA exige autenticação multifator ou forte para sistemas críticos de TIC. A MyCena aplica a qualidade das credenciais na fonte — as credenciais são geradas criptograficamente, únicas por usuário por sistema e vinculadas ao dispositivo. O modelo de injeção significa que a credencial não pode ser extraída e reproduzida.
Registros de geração de credenciais confirmando qualidade criptográfica. Logs de vinculação de dispositivo. Documentação de arquitetura.
Article 10(1)Testes de segurança de TIC — testes regulares de controles de acesso
A DORA exige testes regulares dos controles de segurança de TIC. O teste de revogação da MyCena — incorporado ao processo de implantação padrão — fornece uma demonstração repetível e registrada de que os controles de acesso funcionam conforme especificado. Cada teste de revogação produz um registro com carimbo de data/hora mostrando o tempo exato desde o comando de revogação até a confirmação de acesso zero.
Registros de teste de revogação: carimbo de data/hora do comando, carimbo de data/hora de confirmação, sistemas cobertos, confirmação de acesso zero.
Article 28(2)Risco de TIC de terceiros — acordos contratuais para acesso e segurança
A DORA exige que as entidades financeiras gerenciem a segurança do acesso de TIC de terceiros. A MyCena governa todas as credenciais de terceiros e fornecedores sob o mesmo modelo de controle central que o pessoal interno. As credenciais dos fornecedores são limitadas, registradas e revogáveis pela entidade financeira — não pelo fornecedor.
Log de acesso de terceiros. Registros de revogação de credenciais de fornecedores. Documentação de limitação de escopo por contrato com fornecedor.
Article 28(4)(e)Risco de TIC de terceiros — estratégia de saída e cessação de acesso a dados
A DORA exige que as entidades tenham estratégias de saída para acordos de TIC com terceiros, incluindo confirmação de que o acesso a sistemas e dados cessa no final do contrato. A MyCena fornece essa confirmação estruturalmente — o offboarding do fornecedor é um único comando de revogação que encerra todas as credenciais simultaneamente.
Log de revogação de offboarding do fornecedor. Confirmação de acesso bloqueado pós-revogação. Suporta documentação de estratégia de saída da DORA.
Article 19(1)Relatório de incidentes relacionados a TIC — notificação inicial de 4 horas
A DORA exige notificação inicial de incidentes graves de TIC dentro de 4 horas após a classificação. O log de acesso em tempo real da MyCena permite a avaliação rápida de quais sistemas foram acessados e por quem durante uma janela de incidente — permitindo classificação mais rápida do incidente e notificações iniciais mais precisas.
Log de eventos de acesso em tempo real. Exportação de cronologia de incidentes para notificação regulatória. Cobre todo o acesso ao sistema mediado pela MyCena.

Evidências de auditoria geradas automaticamente pela MyCena

Log de gestão de acesso de TIC
Todos os eventos de emissão de credenciais, alterações de escopo e revogação. Suporta requisitos de evidência de gestão de direitos de acesso do Artigo 9 da DORA.
Relatório de acesso de terceiros
Todas as credenciais de fornecedores e terceiros: escopo, data de emissão, último acesso, status de revogação. Suporta diretamente a governança de terceiros do Artigo 28 da DORA.
Registros de testes de revogação
Resultados de testes de revogação cronometrados com confirmação de acesso zero. Suporta requisitos de testes de segurança do Artigo 10 da DORA.
Cronologia de acesso em incidente
Log de acesso em tempo real exportável para classificação de incidentes e notificação regulatória dentro da janela de 4 horas da DORA.

Como usar isso em uma revisão DORA

Os supervisores da DORA e as funções de auditoria interna se concentram em duas coisas nas revisões de controle de acesso: a entidade pode demonstrar que os direitos de acesso de TIC são gerenciados sistematicamente, e a entidade pode demonstrar que o acesso de terceiros termina quando os contratos terminam. Lidere com o relatório de acesso de terceiros — ele mostra cada credencial ativa de fornecedor, seu escopo e seu status de revogação, que é exatamente a evidência que as revisões do Artigo 28 da DORA estão buscando.

ISO/IEC 27001:2022 — Gestão de Segurança da Informação
Controle de Acesso, Autenticação e Ciclo de Vida de Identidade
A ISO 27001:2022 reestruturou os controles do Anexo A de 114 para 93, reorganizados em quatro temas. A MyCena aborda controles principalmente dentro do Tema 5 (Controles organizacionais) e Tema 8 (Controles tecnológicos), especialmente o cluster de gestão de acesso A.5.15–A.5.18 e os controles de autenticação e acesso privilegiado A.8.2 e A.8.5.
Controle do Anexo AComo a MyCena atende
A.5.15Controle de acesso — política e regras
A ISO 27001 exige uma política documentada de controle de acesso e regras que regem quem recebe acesso e em quais condições. A MyCena aplica a política de controle de acesso arquitetonicamente — cada concessão de acesso é registrada com o administrador aprovador, o usuário, o sistema e o escopo. Desvios da política são estruturalmente impedidos em vez de detectados após o fato.
Log de provisionamento confirmando que cada concessão de acesso foi autorizada pelo administrador. Registros de configuração de escopo demonstrando aplicação da política.
A.5.16Gestão de identidade — ciclo de vida
A ISO 27001 exige a gestão do ciclo de vida de identidade — desde o provisionamento do novo colaborador pela mudança de função até a revogação do colaborador que sai. A MyCena fornece uma trilha de auditoria completa do ciclo de vida de identidade: cada evento de provisionamento, cada alteração de escopo e cada revogação, com carimbos de data/hora e administrador aprovador.
Log completo do ciclo de vida de identidade por usuário. Provisionamento de entrada, mudança de função, revogação de saída — todos com carimbo de data/hora e atribuídos ao administrador.
A.5.17Gestão de informações de autenticação
A ISO 27001 A.5.17 exige especificamente que as informações de autenticação — senhas e credenciais — sejam gerenciadas com segurança. A MyCena remove completamente as credenciais da posse do usuário: nenhum usuário cria, mantém, armazena ou transmite uma credencial. As informações de autenticação são geradas centralmente, distribuídas criptografadas e injetadas no ponto de autenticação.
Documentação de arquitetura. Sem credenciais armazenadas na memória do usuário, navegador ou gerenciador de senhas. Distribuição somente por injeção confirmada.
A.5.18Direitos de acesso — revisão, modificação e remoção
A ISO 27001 exige revisão periódica dos direitos de acesso, modificação rápida quando as funções mudam e remoção do acesso quando o vínculo empregatício termina. A MyCena permite as três a partir da mesma plataforma. A revogação do colaborador que sai é simultânea e imediata em todos os sistemas, com confirmação registrada — medida em segundos, não dias.
Relatórios periódicos de revisão de direitos de acesso. Log de modificação por mudança de função. Confirmação de revogação do colaborador que sai com carimbo de data/hora.
A.8.2Direitos de acesso privilegiado — gestão e monitoramento
A ISO 27001 A.8.2 exige especificamente que os direitos de acesso privilegiado sejam gerenciados, alocados com base na necessidade de uso e monitorados. A MyCena aplica o mesmo modelo de controle central a contas privilegiadas que a contas padrão — credenciais privilegiadas são geradas centralmente, limitadas a sistemas específicos e sujeitas ao mesmo registro de auditoria.
Log de eventos de acesso privilegiado. Registros de escopo de credenciais privilegiadas. Sem credenciais privilegiadas autoprovisionadas.
A.8.5Autenticação segura — procedimentos
A ISO 27001 A.8.5 exige procedimentos de autenticação seguros, incluindo autenticação forte para sistemas de alto risco e não transmissão de senhas em texto claro. O modelo de injeção da MyCena significa que as senhas nunca são transmitidas pelo usuário — elas são injetadas pela plataforma no ponto de autenticação sem que o usuário as veja.
Documentação de arquitetura confirmando modelo somente por injeção, sem transmissão de texto claro ao usuário, vinculação de dispositivo.
A.8.3Restrição de acesso à informação
A ISO 27001 exige que o acesso à informação seja restrito a usuários autorizados de acordo com a política de controle de acesso. A MyCena aplica essa restrição no nível da credencial — um usuário que não tem uma credencial para um sistema simplesmente não pode acessá-lo. A restrição de acesso é aplicada arquitetonicamente, não pelo comportamento do usuário.
Registros de escopo de acesso por usuário. Nenhuma credencial existe para combinações sistema-usuário não autorizadas.

Evidências de auditoria geradas automaticamente pela MyCena

Log do ciclo de vida de identidade
Evidência completa de A.5.16: provisionamento de entrada, mudanças de função, revogação de saída — todos com carimbo de data/hora e atribuídos ao administrador.
Relatório de revisão de direitos de acesso
Escopo de acesso por usuário e por sistema em qualquer momento. Suporta revisões periódicas de direitos de acesso A.5.18.
Log de acesso privilegiado
Todos os eventos de acesso de contas privilegiadas com atribuição completa. Suporta monitoramento de acesso privilegiado A.8.2.
Documentação de arquitetura de autenticação
Documentação técnica confirmando conformidade com A.5.17 e A.8.5 — modelo somente por injeção, sem credenciais mantidas pelo usuário.

Como usar isso em uma auditoria de certificação ISO 27001

Os auditores de certificação ISO 27001 revisam tanto a documentação quanto as evidências de implementação. Para controles de controle de acesso — A.5.15 a A.5.18 — a constatação mais comum é a lacuna entre a política documentada e a prática demonstrada. A MyCena fecha essa lacuna: a política é aplicada pelo fluxo de trabalho de provisionamento da plataforma, e o log de auditoria demonstra que foi aplicada para cada evento de acesso no período de auditoria.

PCI DSS v4.0 — Padrão de Segurança de Dados da Indústria de Cartões de Pagamento
Restringir o Acesso a Componentes do Sistema e Dados do Titular do Cartão
O PCI DSS v4.0 (obrigatório a partir de março de 2025) fortaleceu significativamente os Requisitos 7 e 8 — controle de acesso e autenticação. A MyCena aborda diretamente as constatações mais citadas do PCI DSS: credenciais compartilhadas, autenticação fraca, falta de identificação única de usuário e falha em revogar prontamente o acesso de pessoal desligado.
RequisitoComo a MyCena atende
Req 7.2.1Modelo de controle de acesso — privilégio mínimo e necessidade de saber
O PCI DSS exige que o acesso a componentes do sistema seja limitado ao mínimo necessário. A MyCena aplica o privilégio mínimo no nível da credencial — as credenciais são limitadas por usuário por sistema na emissão. Um usuário não pode acessar um sistema de ambiente de dados do titular do cartão a menos que explicitamente provisionado para aquele sistema específico.
Registros de escopo de credenciais por usuário por sistema. Nenhum usuário tem acesso de credencial a sistemas CDE além do seu escopo provisionado.
Req 8.2.1IDs de usuário — ID único para cada usuário
O Requisito 8.2.1 do PCI DSS exige explicitamente que todos os usuários recebam um ID único. A MyCena aplica isso estruturalmente — as credenciais são geradas por usuário por sistema. Credenciais compartilhadas são arquitetonicamente impossíveis: dois usuários não compartilham uma credencial em um ambiente gerenciado pela MyCena.
Registros de emissão de credenciais confirmando credencial única por par usuário-sistema. Log de acesso mostrando atribuição de usuário único para cada evento.
Req 8.3.1Fatores de autenticação — autenticação forte para acesso não console
O PCI DSS v4.0 exige autenticação multifator para todo acesso não console ao CDE. A MyCena complementa as implementações de MFA governando a camada de credencial que o MFA verifica. A credencial subjacente é criptograficamente forte, única por sistema e não pode ser extraída do conhecimento do usuário.
Documentação de arquitetura confirmando governança da MyCena sobre a camada de credencial. Registros de integração de MFA onde aplicável.
Req 8.2.4Contas de usuário — gestão de contas inativas
O PCI DSS exige que contas inativas sejam bloqueadas ou removidas prontamente. Com a MyCena, quando um usuário é desligado ou uma conta é desativada, sua credencial é revogada instantaneamente em todos os sistemas CDE. Não há período durante o qual a credencial permanece válida na posse do usuário.
Log de revogação de conta com carimbo de data/hora. Confirmação de acesso bloqueado pós-revogação. Zero credenciais ativas para contas desativadas.
Req 8.6.1Contas de sistema e aplicativos — gerenciadas e monitoradas
O PCI DSS v4.0 expandiu significativamente os requisitos para gestão de contas de sistema e aplicativos. A MyCena aplica a mesma governança central de credenciais a contas de sistema que a usuários humanos — cada credencial de conta de serviço é gerada centralmente, limitada e revogável. As credenciais de contas de sistema não são codificadas — elas são injetadas em tempo de execução.
Registros de gestão de credenciais de contas de sistema. Sem credenciais codificadas em configuração. Logs de injeção em tempo de execução para processos automatizados.
Req 10.2.1Log de auditoria — todo acesso individual aos dados do titular do cartão
O PCI DSS exige logs de auditoria capturando todo acesso individual de usuário a dados do titular do cartão e sistemas CDE. A MyCena gera um log de acesso abrangente e à prova de adulteração para cada evento de acesso mediado pela MyCena — identidade do usuário, sistema, carimbo de data/hora, dispositivo e IP de origem. Exportável em formatos padrão.
Log de auditoria de acesso CDE completo: usuário, sistema, carimbo de data/hora, dispositivo, IP. Exportável em formatos compatíveis com QSA.
Req 7.3.1Sistema de controle de acesso — gestão de acesso a todos os componentes do sistema
O PCI DSS v4.0 exige um sistema de controle de acesso que gerencie e aplique o acesso a todos os componentes do sistema. A MyCena fornece isso na camada de credencial — cada componente do sistema conectado à MyCena tem seu acesso governado centralmente, sem credenciais mantidas pelo usuário que contornem o controle.
Inventário de sistemas conectados. Registros de governança de credenciais para todos os componentes do sistema CDE. Sem caminhos de desvio documentados.

Evidências de auditoria geradas automaticamente pela MyCena

Log de acesso único por usuário
Evidência do Req 8.2.1: cada evento de acesso CDE atribuído a um único usuário nomeado. Credenciais compartilhadas são impossíveis.
Log de revogação de conta
Evidência do Req 8.2.4: revogação de conta encerrada com carimbo de data/hora e confirmação de acesso bloqueado pós-revogação.
Log de auditoria de acesso CDE
Evidência do Req 10.2.1: log completo de acesso a sistemas de dados do titular do cartão em formato de exportação compatível com QSA.
Registros de contas de sistema
Evidência do Req 8.6.1: gestão de credenciais de contas de serviço e aplicativos, sem credenciais codificadas, logs de injeção em tempo de execução.

Como usar isso em uma avaliação PCI DSS QSA

Os QSAs do PCI DSS avaliam tanto o design quanto a eficácia operacional dos controles. As constatações mais comuns nas revisões dos Requisitos 7 e 8 são contas compartilhadas, offboarding atrasado e a incapacidade de demonstrar que usuários desligados perderam o acesso prontamente. A MyCena fornece evidências estruturais para os três: o log de acesso único por usuário demonstra ausência de compartilhamento, o log de revogação com carimbos de data/hora demonstra encerramento imediato, e o log de auditoria de acesso CDE suporta a coleta de evidências do Requisito 10.

CMMC 2.0 — Certificação do Modelo de Maturidade de Cibersegurança
Domínio de Controle de Acesso — Proteção de Informações Não Classificadas Controladas
O CMMC 2.0 é obrigatório para contratados do Departamento de Defesa dos EUA que lidam com Informações Não Classificadas Controladas (CUI) ou Informações de Contrato Federal (FCI). O Nível 2 — o requisito mais comum — é baseado no NIST SP 800-171 Rev 2. A MyCena aborda diretamente o domínio de Controle de Acesso (AC), que é o domínio mais frequentemente avaliado e com mais deficiências nas avaliações do CMMC.
Prática / controleComo a MyCena atende
AC.L1-3.1.1Acesso autorizado — limitar a usuários e processos autorizados
O CMMC exige que o acesso a sistemas contendo FCI/CUI seja limitado a usuários autorizados. A MyCena aplica isso no nível da credencial — nenhum usuário pode acessar um sistema CUI a menos que explicitamente provisionado por um administrador. Não há credenciais criadas pelo usuário e nenhuma credencial que pudesse ser compartilhada com um usuário não autorizado, uma vez que as credenciais nunca estão na posse do usuário.
Log de provisionamento de credenciais confirmando que cada acesso ao sistema CUI é autorizado pelo administrador. Sem credenciais autoprovisionadas ou compartilhadas.
AC.L1-3.1.2Controle de transações e funções — limitar a transações autorizadas
O CMMC exige limitar o acesso ao sistema aos tipos de transações e funções que os usuários autorizados estão autorizados a executar. O escopo de credenciais por sistema da MyCena aplica isso — a credencial de um usuário concede acesso a um sistema específico com um escopo definido. O movimento lateral usando uma credencial comprometida é restringido porque cada sistema requer sua própria credencial provisionada separadamente.
Registros de escopo de credenciais por sistema. Log de eventos de acesso mostrando atribuição de acesso específico por sistema.
AC.L2-3.1.5Privilégio mínimo — contas não privilegiadas para atividades não privilegiadas
O CMMC Nível 2 exige o princípio do privilégio mínimo. A MyCena aplica o privilégio mínimo limitando cada credencial a sistemas específicos na emissão. Os usuários não podem escalar seu próprio acesso — a escalada de privilégios requer provisionamento pelo administrador de uma nova credencial com escopo.
Diferenciação de privilégios nos registros de escopo de credenciais. Sem eventos de acesso escalado pelo usuário no log de acesso.
AC.L2-3.1.6Privilégio mínimo — uso de contas privilegiadas apenas para funções privilegiadas
O CMMC exige que contas privilegiadas sejam usadas apenas para funções privilegiadas. O modelo de credencial da MyCena aplica isso por design: uma credencial privilegiada é limitada a funções e sistemas privilegiados específicos. Ela não pode ser usada para acesso geral porque não é uma credencial geral. Os eventos de acesso privilegiado são registrados separadamente e auditáveis de forma independente.
Log de uso de credencial privilegiada. Eventos de acesso privilegiado no log de auditoria separados dos eventos de acesso padrão.
AC.L2-3.1.7Privilégio mínimo — impedir que usuários não privilegiados executem funções privilegiadas
O CMMC exige a prevenção de usuários não privilegiados de executar funções privilegiadas. A MyCena impede que usuários não privilegiados acessem sistemas privilegiados ao não provisioná-los com credenciais para esses sistemas. Um usuário sem credencial MyCena para um sistema privilegiado simplesmente não pode autenticar-se nele — a prevenção é arquitetônica, não comportamental.
Registros de escopo de credenciais confirmando que nenhum usuário padrão possui credenciais para sistemas privilegiados. Logs de tentativas de acesso bloqueadas onde aplicável.
IA.L2-3.5.3Autenticação multifator — para acesso local e em rede a sistemas CUI
O CMMC Nível 2 exige MFA para todo acesso local e em rede a sistemas contendo CUI. A MyCena complementa as implementações de MFA governando a credencial que o MFA verifica. A combinação fornece duas camadas distintas: o MFA verifica a identidade do usuário, e a MyCena garante que a credencial é gerada pela organização, não exposta e não phishável.
Documentação de integração de MFA. Registros de governança de credenciais da MyCena demonstrando a camada de credencial abaixo do MFA.
AU.L2-3.3.1Log de auditoria — criar e reter logs para monitoramento e investigação
O CMMC exige que os logs de auditoria sejam criados e retidos por tempo suficiente para suportar monitoramento, análise e investigação. O log de eventos de acesso da MyCena fornece um registro completo e à prova de adulteração de todos os acessos a sistemas gerenciados pela MyCena — usuário, sistema, carimbo de data/hora, dispositivo, IP. Os logs são retidos e exportáveis em formatos adequados para integração com SIEM e revisão de avaliação CMMC.
Log de auditoria de acesso completo com registros de retenção. Capacidade de exportação para SIEM. Cobre 100% do acesso ao sistema CUI mediado pela MyCena.

Evidências de auditoria geradas automaticamente pela MyCena

Log de acesso autorizado
Evidência AC.L1: cada acesso ao sistema CUI é provisionado pelo administrador e registrado. Sem credenciais autoprovisionadas ou compartilhadas.
Registros de acesso privilegiado
Evidência AC.L2-3.1.5–3.1.7: credenciais privilegiadas com escopo separado, eventos de acesso privilegiado registrados de forma independente.
Log de auditoria completo
Evidência AU.L2-3.3.1: log completo de eventos de acesso com retenção, exportável para avaliação CMMC e integração com SIEM.
Registros de escopo de credenciais
Escopo de acesso por usuário e por sistema. Suporta demonstração de privilégio mínimo em todas as práticas do domínio AC.

Como usar isso em uma avaliação CMMC

Os avaliadores do CMMC avaliam tanto a existência quanto a operação das práticas em todos os 14 domínios. O domínio de Controle de Acesso — 22 práticas no Nível 2 — é o mais comumente deficiente em autoavaliações e avaliações de terceiros. A MyCena aborda as práticas do domínio AC mais frequentemente citadas como deficientes: compartilhamento de credenciais, falta de aplicação de privilégio mínimo, falha em revogar acesso prontamente e ausência de uma trilha de auditoria completa. Ao preparar um Plano de Segurança do Sistema (SSP) e Plano de Ação e Marcos (POA&M), o log de acesso da MyCena e os registros de escopo de credenciais fornecem os artefatos que um avaliador precisa. Lidere com estes em seu pacote de evidências.

Diretiva (UE) 2022/2555 · Em vigor desde outubro de 2024 · Entidades essenciais e importantes
A NIS2 é a expansão mais significativa da legislação europeia de cibersegurança desde a Diretiva NIS original. Aplica-se a entidades essenciais e importantes em 18 setores, introduz responsabilidade pessoal para a alta direção e passa de orientações voluntárias para obrigações técnicas obrigatórias. Ataques baseados em credenciais estão implicados em praticamente todos os requisitos substantivos da NIS2. A MyCena os aborda estruturalmente — não por meio de políticas ou treinamento.
O argumento de responsabilidade pessoal: O Artigo 20 torna os gestores seniores nomeados pessoalmente responsáveis por aprovar e supervisionar as medidas de cibersegurança. Os diretores podem ser temporariamente proibidos de exercer funções de gestão por não conformidade. Um documento de política não é uma defesa. A MyCena é um controle estrutural — o tipo de evidência que um regulador aceita.
Artigo / obrigaçãoComo a MyCena atende
Governança · Responsabilidade da Alta Direção
Art. 20Responsabilidade da alta direção
O módulo de governança da MyCena produz um log de auditoria contínuo e em tempo real de cada evento de acesso. Quando um regulador solicita evidências de que os controles de acesso estavam em vigor e funcionando, a resposta é uma exportação — não uma reconstrução manual. Os gestores seniores podem demonstrar um controle estrutural, não uma política.
Log de governança de acesso em tempo real; carimbos de data/hora de revogação; pacote de evidências para a diretoria exportável sob demanda
Medidas de Gestão de Riscos · Artigo 21
Art. 21(2)(a)Análise de riscos e políticas de segurança de sistemas de informação
A MyCena é um controle estrutural de risco, não uma política. A resposta da análise de riscos para vetores de ataque baseados em credenciais — phishing, engenharia social, roubo interno, movimento lateral — muda de “temos uma política” para “a credencial não existe em mãos humanas.”
Documentação de arquitetura; registros de geração e distribuição de credenciais; sem credenciais mantidas pelo usuário em nenhum sistema
Art. 21(2)(b)Tratamento de incidentes
Quando um incidente envolve uma credencial comprometida, a MyCena permite a revogação instantânea em todos os sistemas simultaneamente. O tempo de contenção cai de dias para segundos. O log de governança fornece a trilha forense completa desde a emissão da credencial até a revogação.
Log de resposta a incidentes: tempo de detecção até revogação, escopo, confirmação; trilha contínua de eventos de acesso para investigação forense
Art. 21(2)(c)Continuidade dos negócios
O ransomware — a principal ameaça à continuidade dos negócios — entra via credencial e se propaga via movimento lateral. A segmentação de credenciais por sistema da MyCena significa que uma credencial comprometida abre uma porta, não toda a rede. O movimento lateral, que transforma um único comprometimento em um evento de continuidade, é estruturalmente bloqueado.
Registros de segmentação de credenciais por sistema; sem reutilização de credenciais entre sistemas; movimento lateral estruturalmente restringido
Art. 21(2)(d)Segurança da cadeia de fornecimento
A MyCena governa cada credencial de terceiros e fornecedor centralmente — gerada pela organização, limitada a sistemas específicos e revogada instantaneamente no final do contrato. A segurança da cadeia de fornecimento não depende das próprias práticas de segurança do fornecedor. Um único comando fecha todos os caminhos de acesso do fornecedor simultaneamente.
Log de governança de credenciais de terceiros; carimbos de data/hora de provisionamento e revogação por fornecedor; confirmação de revogação instantânea
Art. 21(2)(e)Segurança de redes e sistemas de informação
A MyCena governa credenciais em aplicativos web, APIs, SSH, RDP e sistemas de banco de dados — a superfície completa de credenciais de um ambiente de TI moderno. Cada evento de acesso é registrado na camada de credencial, fornecendo visibilidade em todo o patrimônio de rede e sistemas de informação.
Log de eventos de acesso de cobertura total em todos os sistemas governados; registros de governança de credenciais SSH, RDP, HTTPS e API
Art. 21(2)(f)Avaliação de eficácia
O módulo de governança GRC registra cada evento de acesso continuamente. A avaliação de eficácia é automatizada, não periódica — as evidências existem em todos os momentos e podem ser consultadas para qualquer período de tempo, sistema ou usuário sem preparação manual.
Log contínuo de eventos de acesso; relatórios de frequência de acesso por sistema; exportação de detecção de anomalias; formato compatível com SIEM
Art. 21(2)(i)Autenticação multifator
A MyCena opera como a camada antes do MFA, governando a credencial que o MFA foi projetado para proteger. O espelhamento de 2FA da MyCena distribui tokens de MFA para usuários autorizados simultaneamente, fechando o vetor de personificação de helpdesk usado pelo Scattered Spider para contornar completamente o MFA. MyCena + MFA é estruturalmente mais forte do que apenas MFA.
Registros de integração de MFA; logs de distribuição de 2FA; tentativas de personificação de helpdesk bloqueadas na camada de credencial
Art. 21(2)(j)Comunicações de voz, vídeo e texto seguras
Ataques de voz deepfake e chamadas de vishing direcionadas a helpdesks são o vetor de ataque primário atual. A MyCena fecha isso estruturalmente: quando uma chamada solicita uma credencial, não há nada a fornecer. O funcionário não a conhece. O ataque falha independentemente do canal de comunicação usado.
Documentação de arquitetura: nenhuma credencial existe na memória do usuário ou armazenamento acessível; vishing e phishing estruturalmente neutralizados
Notificação de Incidentes · Artigo 23
Art. 23Obrigações de notificação
Incidentes significativos devem ser notificados dentro de 24 horas (alerta precoce) e 72 horas (notificação). O log de governança fornece a base forense para ambas as janelas de notificação — quem acessou o quê, quando, de onde e exatamente quando a credencial foi revogada. Os relatórios referenciam evidências precisas com carimbo de data/hora em vez de reconstruções estimadas.
Notificação de 72 horas suportada por exportação de log de acesso em tempo real; carimbo de data/hora de revogação como evidência de contenção; trilha forense completa disponível desde o primeiro dia do incidente
Medidas de Supervisão · Artigos 32/33
Art. 32/33Evidências de supervisão sob demanda
O log de governança da MyCena está sempre atualizado. As evidências para cada obrigação de controle de acesso são produzidas continuamente e automaticamente. Quando um supervisor chega, a resposta já está lá — não reunida ao longo de dias. As evidências são exportáveis em segundos em formato pronto para auditores.
Exportação de log de auditoria sob demanda; pacote completo de evidências de governança de acesso; sem preparação manual necessária

Os três argumentos NIS2 que encerram a conversa

1
Responsabilidade pessoal (Art. 20)
Os diretores precisam de um controle estrutural para apontar. Uma política não é uma defesa. A MyCena é a evidência que um supervisor do Artigo 20 aceita.
2
Cadeia de fornecimento (Art. 21(2)(d))
O requisito NIS2 mais difícil de cumprir porque exige governança técnica, não garantia contratual. A MyCena governa cada credencial de terceiros do lado da organização.
3
Contenção de incidentes (Art. 21(2)(b) + Art. 23)
O prazo de notificação de 72 horas e o requisito de demonstrar contenção dependem da revogação instantânea e de um log em tempo real. A MyCena fornece ambos desde o primeiro dia.

A NIS2 define o patamar mínimo. A MyCena o supera — não porque foi projetada em torno da diretiva, mas porque remover credenciais da posse humana é a resposta estrutural à ameaça que a NIS2 foi escrita para abordar.

Briefing de conformidade
Um briefing de 45 minutos sobre como a MyCena gera evidências de auditoria para o seu framework específico — sob demanda, automaticamente.
Agendar um briefing →
MyCena
Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.