Compliance and regulations

O Regulamento Geral sobre a Proteção de Dados (RGPD), a lei da UE em matéria de proteção de dados, exige um mecanismo lícito de transferência para o envio de dados pessoais para fora do Espaço Económico Europeu (EEE, a UE mais a Islândia, o Listenstaine e a Noruega) e medidas de segurança adequadas ao risco. Para uma gestão de palavras-passe em conformidade com o RGPD, é necessário conhecer todos os locais onde existem dados de credenciais e dispor de prova para cada um deles.

As credenciais podem estar armazenadas num centro de dados em Frankfurt e, ainda assim, ficar sujeitas a uma ordem judicial estrangeira, se o fornecedor estiver sujeito a uma jurisdição fora da UE. Uma etiqueta «alojado na UE» também nada diz sobre a localização das cópias de segurança. Este artigo apresenta o mapa de seis zonas dos dados de credenciais: os locais onde um gestor de palavras-passe empresarial guarda dados, o artigo do RGPD que cada local ativa e as evidências que é necessário conservar. Termina com um dossiê de evidências de 8 pontos, que pode ser verificado antes de uma auditoria.

O que exige a gestão de palavras-passe em conformidade com o RGPD

O RGPD exige que os dados pessoais sejam tratados de forma segura, com proteção de dados desde a conceção e protegidos por medidas adequadas ao risco. 

A gestão de palavras-passe em conformidade com o RGPD implica poder demonstrar que os dados de credenciais são cifrados, acessíveis apenas a quem deles necessita, registados e abrangidos pelos contratos e registos adequados, onde quer que estejam armazenados.

A lei define o resultado a alcançar (artigos 5.º, n.º 1, alínea f), 25.º e 32.º). Cabe à organização escolher os controlos e provar que funcionam (artigo 5.º, n.º 2). Na prática, isto traduz-se em cinco requisitos:

• Cifrar as credenciais armazenadas. O artigo 32.º, n.º 1, alínea a), refere «a pseudonimização e a cifragem dos dados pessoais» como medida adequada.
• Limitar o acesso por função (RBAC). Cada pessoa inicia sessão com a sua própria conta e vê apenas o que a sua função exige, mesmo quando a credencial aberta é partilhada. Trata-se da proteção de dados desde a conceção (artigo 25.º) aplicada ao acesso.
• Manter o serviço disponível e testado. O artigo 32.º, n.º 1, alíneas b) a d), abrange a resiliência, o restabelecimento do acesso após um incidente e os testes regulares das medidas.
• Registar quem abriu o quê. Um registo de acessos mostra que credenciais foram acedidas e quando. É a evidência necessária para avaliar se uma violação afetou dados pessoais (artigo 33.º).
• Documentar todos os locais onde os dados se encontram. Isto implica um registo das atividades de tratamento, um contrato com cada entidade externa que trate os dados e um mecanismo lícito para qualquer transferência para fora do EEE.

Estes deveres abrangem as palavras-passe por duas razões. Um registo de credencial identifica normalmente um colaborador ou remete para um, o que o torna um dado pessoal (artigo 4.º, n.º 1: qualquer informação relativa a uma pessoa identificável). As credenciais abrem também outros sistemas, como RH, CRM e bases de dados de clientes, onde se armazenam dados pessoais. O artigo 32.º, n.º 2, exige a avaliação do risco de acesso não autorizado a dados pessoais, pelo que uma violação do gestor de palavras-passe constitui uma via de violação para todos os sistemas que ele desbloqueia. A cifragem reduz o risco sem retirar o registo do âmbito de aplicação. 

A organização é o responsável pelo tratamento do cofre, a entidade que decide por que razão e de que forma os dados de credenciais são utilizados. Um fornecedor ou prestador de alojamento que o explora ou apoia segundo as instruções da organização é um subcontratante, e o artigo 28.º exige um contrato com este. O artigo 30.º exige que se mantenha um registo das atividades de tratamento (RoPA) que enumere os destinatários, os locais e as transferências deste tratamento. Identificar esses locais é a primeira tarefa.

Residência, soberania e jurisdição são três conceitos distintos

Residência dos dados é o local onde os dados estão fisicamente armazenados. Soberania dos dados significa que os dados estão sujeitos às leis e ao controlo jurídico de um país escolhido. Jurisdição indica que tribunais e autoridades podem emitir ordens à empresa do fornecedor. Um fornecedor sujeito à lei dos EUA pode armazenar o cofre na Alemanha e, ainda assim, receber exigências legais dos EUA.

O CLOUD Act permite às autoridades dos EUA exigir aos fornecedores de serviços de comunicações eletrónicas ou de computação remota sob jurisdição dos EUA que entreguem os dados que se encontrem na sua posse, custódia ou controlo, mesmo quando estão armazenados no estrangeiro. Um fornecedor que seja uma empresa norte-americana ou tenha uma empresa-mãe nos EUA pode, por isso, receber tais exigências mesmo que o cofre esteja numa região da UE. Determinar se um dado fornecedor está abrangido pela lei é uma questão para a equipa jurídica.

O RGPD não contém qualquer regra geral de localização de dados. Regula as transferências para países terceiros no capítulo V (artigos 44.º a 50.º), e o acesso remoto a partir de fora do EEE, como o suporte do fornecedor, pode contar como transferência. Algumas regras nacionais e setoriais acrescentam exigências próprias de localização, pelo que convém verificar as que se aplicam à organização.

Transferências para fora do EEE: que mecanismos se aplicam

O capítulo V do RGPD exige um mecanismo lícito de transferência e garantias que se mantenham no país de destino. O acesso remoto de suporte a partir de fora do EEE a um cofre de palavras-passe alojado no seu interior conta como transferência, pelo que a região de alojamento, por si só, não resolve a questão. Existem três vias, e cada uma aplica-se a uma situação diferente.

• Decisão de adequação (artigo 45.º). A Comissão Europeia declarou que a proteção do país de destino é equivalente. A decisão de 10 de julho de 2023 relativa ao Quadro de Proteção de Dados UE-EUA abrange apenas as empresas dos EUA que se autocertificaram, pelo que convém verificar a entrada do fornecedor na lista do quadro. Os quadros UE-EUA anteriores foram anulados em tribunal e o atual foi contestado, pelo que as cláusulas contratuais-tipo devem permanecer como solução de recurso no DPA.
• Garantias adequadas (artigo 46.º). Normalmente, cláusulas contratuais-tipo (CCT), modelos de cláusulas contratuais aprovados pela Comissão, acompanhadas de uma avaliação de impacto da transferência (TIA). A TIA verifica se a legislação do país de destino permite às autoridades aceder aos dados. Decorre do acórdão Schrems II e das Recomendações 01/2020 do Comité Europeu para a Proteção de Dados (EDPB).
• Derrogações (artigo 49.º). Exceções restritas, como o consentimento explícito depois de a pessoa ser informada dos riscos. Adequam-se a transferências ocasionais e não servem de base ao tratamento rotineiro por fornecedores.

Uma região de alojamento na UE reduz o risco sem o eliminar. O pessoal de suporte fora do EEE, os metadados tratados noutro local e uma empresa-mãe fora do EEE com acesso podem, cada um, originar uma transferência. O poder de uma autoridade estrangeira para ordenar a uma empresa-mãe a divulgação de dados constitui um risco de jurisdição distinto (ver a secção sobre residência acima). A região deve ser considerada um dos elementos da TIA, e não a sua conclusão.

O mapa de seis zonas dos dados de credenciais

O mapa de seis zonas dos dados de credenciais divide um gestor de palavras-passe empresarial em seis locais onde existem dados de credenciais. Cada zona pode situar-se num país diferente e tem o seu próprio dever ao abrigo do RGPD, pelo que verificar apenas «o servidor» deixa de fora cópias pelas quais a organização é responsável.

Um gestor de palavras-passe é um sistema de cópias. Algumas ficam com a organização, outras com o fornecedor e as restantes com os fornecedores deste. As cópias que ficam com a organização dependem do modelo de implementação. Numa implementação em alojamento próprio, a organização é o operador de todas as zonas, pelo que cada pergunta abaixo se aplica às equipas e aos prestadores de alojamento da própria organização, em vez de a um fornecedor.

Cada zona desencadeia também um dever diferente. As cópias de segurança originam deveres de eliminação no termo do contrato (artigo 28.º, n.º 3, alínea g)) e os fornecedores originam deveres que têm de ser transmitidos ao longo da cadeia (artigo 28.º, n.º 4). As seis subsecções seguintes abordam cada zona e o que solicitar.

Zona 1: Credenciais armazenadas

As credenciais armazenadas são o conteúdo que os utilizadores guardam: inícios de sessão, notas, anexos e os segredos subjacentes aos códigos de utilização única. Com a cifragem do lado do cliente, esse conteúdo chega ao servidor como texto cifrado, dados ilegíveis sem a chave. Uma cópia roubada da base de dados expõe, assim, apenas segredos ilegíveis, desde que a chave que desbloqueia a chave privada cifrada permaneça no dispositivo do utilizador (ver Zona 2).

As credenciais cifradas continuam a ser dados pessoais quando se relacionam com uma pessoa identificável, pelo que a Zona 1 permanece no âmbito. O artigo 32.º, n.º 1, alínea a), indica a cifragem como exemplo de medida adequada, e esta reduz o risco. Na entrada do RoPA relativa ao gestor de palavras-passe, deve registar-se a localização desta zona e o método de cifragem.

Os nomes dos registos, a estrutura de pastas e os metadados de auditoria são armazenados separadamente e pertencem à Zona 3. Devem ter uma linha própria no RoPA, com a mesma localização e os mesmos detalhes de acesso.

Zona 2: Material de chaves

O material de chaves é o conjunto de chaves criptográficas que desbloqueiam as credenciais armazenadas. Quem detiver as chaves pode ler os dados, onde quer que esteja o texto cifrado, pelo que a localização das chaves e os seus detentores importam tanto como a localização do servidor. O artigo 32.º, n.º 1, alínea a), só torna a cifragem adequada se as chaves forem controladas com o mesmo cuidado que os dados. 

A cadeia segue esta ordem: palavra-passe mestra, chave mestra, chave privada, chaves de cofre, chaves de registo. A palavra-passe mestra do utilizador gera a chave mestra através de uma função como a PBKDF2, que torna lenta a tentativa de adivinhar palavras-passe. Essa chave decifra uma chave privada, que decifra as chaves de cofre, as quais, por sua vez, desbloqueiam as chaves de cada registo.

O servidor armazena a chave privada e as chaves de cofre de forma cifrada. A chave que as decifra permanece no dispositivo do utilizador, pelo que uma cópia da base de dados, por si só, não dá acesso.

A recuperação é o único percurso de chaves que merece ser mapeado em separado. Alguns modelos incluem uma conta de recuperação ou uma chave de escrow, para que uma organização possa restabelecer o acesso após a perda da palavra-passe mestra. Quem detiver essa chave também pode aceder ao texto simples, pelo que deve ser tratada como qualquer outra chave: quem a detém, onde está armazenada e que tribunais podem obrigar o seu detentor. O guia sobre o que a cifragem zero-knowledge protege e não protege explica o funcionamento.

Zona 3: Dados de serviço

Os dados de serviço são tudo o que o sistema regista sobre a utilização, e não sobre o conteúdo. A cifragem do lado do cliente não os abrange, pelo que o operador normalmente os consegue ler. Isso torna-os dados pessoais por direito próprio e a parte do sistema a que uma exigência legal pode chegar sem tocar na cifragem. Inclui, normalmente:

• Identidades de contas, endereços de e-mail e registos de faturação
• Endereços IP de início de sessão, identificadores de dispositivos e registos de data e hora dos acessos
• Registos de auditoria, bem como nomes de registos e estrutura de pastas, se o produto não os cifrar

Aplicam-se três deveres. Os registos são a evidência para avaliar uma violação (artigos 32.º e 33.º). A conservação deve limitar-se ao necessário (artigo 5.º, n.º 1, alínea e)). Os colaboradores podem solicitar os seus próprios dados (artigo 15.º). Numa implementação em alojamento próprio, esta zona fica a cargo da própria organização.

Zona 4: Cópias de segurança, réplicas e recuperação de desastres

As cópias de segurança, as réplicas e os locais de recuperação de desastres (DR) são as cópias dos dados de credenciais que existem fora do servidor principal. Cada cópia pode situar-se num país diferente e sob um operador diferente, pelo que cada uma requer uma resposta própria sobre localização, cifragem e eliminação.

Cópias de segurança são cópias armazenadas para restaurar dados. Réplicas são cópias ativas noutros servidores. Os locais de recuperação de desastres (DR) são localizações de reserva. Apoiam a disponibilidade e a recuperação (artigo 32.º, n.º 1, alíneas b) e c)), mas cada cópia adicional alarga a superfície de ataque e o conjunto de jurisdições aplicáveis. Há três perguntas a colocar:

• Onde está armazenada cada cópia de segurança e réplica, e alguma cópia sai da UE ou do EEE? Uma cópia num país terceiro pode contar como transferência ao abrigo do capítulo V.
• As cópias de segurança são cifradas e as chaves são mantidas separadas dos dados?
• Depois de terminado o contrato, em quantos dias desaparece a última cópia e como se verifica?

O artigo 28.º, n.º 3, alínea g), exige que o subcontratante, à escolha da organização, elimine ou devolva todos os dados pessoais quando os serviços terminam e elimine as cópias existentes, salvo se a lei exigir a sua conservação. As cópias de segurança estão abrangidas por esse dever. Na prática, expiram frequentemente num ciclo de rotação, pelo que o prazo de conservação é o valor que convém obter por escrito.

Zona 5: Caches de cliente e armazenamento offline

Alguns dados saem do servidor por conceção. As aplicações para computador e móveis podem manter cópias offline, as extensões de navegador podem guardar uma chave de sessão ou de desbloqueio, e os utilizadores podem exportar ficheiros de cofre. Cada uma é uma cópia fora dos controlos centrais e acompanha o dispositivo do colaborador para onde quer que vá.

Esta é a zona em que a política da própria organização mais importa. É necessário decidir se o modo offline é permitido, exigir a cifragem de disco através da gestão de dispositivos móveis (MDM) e restringir quem pode exportar. As exportações merecem o maior cuidado, uma vez que um ficheiro CSV pode ser lido por quem o abrir. Deve perguntar-se ao fornecedor se os administradores podem limitar o modo offline por função, se os dados em cache se apagam após um período definido e se a utilização offline e as exportações são registadas.

Um dispositivo perdido com uma cópia do cofre constitui um risco nos termos do artigo 32.º, n.º 2, que refere a perda e a divulgação não autorizada, e pode desencadear os deveres de notificação de violações previstos nos artigos 33.º e 34.º. Os terminais e os locais de exportação aprovados devem ser listados no RoPA.

Zona 6: Subcontratantes ulteriores e acesso de suporte

Os subcontratantes ulteriores são os fornecedores que um fornecedor utiliza para prestar o serviço, como alojamento, envio de e-mail, monitorização e ferramentas de suporte. Ao abrigo do artigo 28.º, n.os 2 e 4, o subcontratante necessita da autorização da organização para os contratar e tem de transmitir os mesmos deveres de proteção de dados ao longo da cadeia.

Terceiros estiveram envolvidos em 48 % das violações no DBIR de 2026 da Verizon, um aumento de 60 % face ao ano anterior. O relatório agrupa estes casos em três arquétipos: um fornecedor na cadeia de fornecimento de software, um fornecedor que aloja os dados no seu ambiente e um fornecedor com ligação ao ambiente da organização. Um gestor de palavras-passe alojado é do segundo tipo, e uma ligação de suporte ou de integração aos sistemas da organização pode torná-lo do terceiro. Os fornecedores do fornecedor devem ser verificados tão rigorosamente como o seu produto.

Há quatro elementos a solicitar:

• Uma lista atual de subcontratantes ulteriores e do país em que cada um opera
• Aviso prévio de alterações, com direito de oposição
• Quem, na equipa de suporte do fornecedor, pode ver os dados de serviço (Zona 3) e mediante que aprovação
• Se algum subcontratante ulterior ou via de suporte pode aceder ao material de chaves (Zona 2)

Mapa de zonas e artigos: A obrigação e a evidência

O mapa de zonas e artigos associa cada uma das seis zonas de credenciais à disposição do RGPD que ativa, ao documento que comprova a conformidade e à parte responsável por essa obrigação. Serve de base para a entrada do RoPA relativa ao gestor de palavras-passe, e a coluna de evidências deve ser preenchida antes de um auditor perguntar. O dossiê de evidências no final lista os mesmos documentos como lista de verificação.

A repartição determina quem notifica. Nos termos do artigo 33.º, o responsável pelo tratamento notifica a autoridade de controlo no prazo de 72 horas após ter tomado conhecimento de uma violação, sempre que possível. O subcontratante tem de informar a organização «sem demora injustificada», o que não fixa qualquer prazo, pelo que se deve inscrever no DPA um prazo de notificação. Em alojamento próprio, a organização é simultaneamente responsável pelo tratamento e operador, e a coluna Responsável reduz-se às suas próprias equipas.

O DPA a obter de um fornecedor de gestores de palavras-passe

Um acordo de tratamento de dados (DPA) é o contrato que o artigo 28.º, n.º 3, exige entre um responsável pelo tratamento e um subcontratante. No caso de um fornecedor de gestores de palavras-passe, deve indicar o objeto, a duração, a natureza, a finalidade, os tipos de dados e as categorias de titulares dos dados, além de oito obrigações nas alíneas a) a h). As Diretrizes 07/2020 do EDPB sobre responsáveis pelo tratamento e subcontratantes explicam cada uma delas.

A linha das auditorias exige a leitura mais atenta. O artigo 28.º, n.º 3, alínea h), exige que o contrato faculte as informações que comprovam a conformidade e permita auditorias, incluindo inspeções. Se o fornecedor não abrir a sua infraestrutura a inspeções presenciais, o contrato deve indicar o que as substitui.

As evidências a analisar incluem, assim, a lista de subcontratantes ulteriores, uma avaliação de transferências e os relatórios de auditoria a que o contrato dá direito. Devem juntar-se os registos próprios do cofre, exportados para um SIEM (um sistema que recolhe e analisa registos de segurança).

Modelos de implementação da gestão de palavras-passe em conformidade com o RGPD

O modelo de implementação determina quais das seis zonas a equipa controla. Uma cloud de fornecedor deixa a maioria das zonas com o fornecedor, uma cloud numa região da UE reduz os locais onde se situam e o alojamento próprio transfere-as para a infraestrutura e para a lista de deveres da organização. As configurações air-gapped vão mais longe e acrescentam o tratamento offline de atualizações e registos.

Um serviço gerido pelo fornecedor oferece menos controlo sobre os formatos de exportação e o momento da saída. Antes de assinar, convém verificar como se poderia sair: que formatos se podem exportar e qual o prazo para eliminar as cópias de segurança nos termos do artigo 28.º, n.º 3, alínea g).

Alojamento próprio e RGPD: Que deveres se assumem

O alojamento próprio transfere os deveres do RGPD de um contrato com um fornecedor para os procedimentos operacionais da própria organização. A organização controla onde se situa cada zona e quem a opera, o que pode eliminar a relação de subcontratação para o próprio cofre. Passa também a ser o operador, pelo que assegura as evidências por si. A página sobre o gestor de palavras-passe on-premise descreve esta opção de implementação.

O que se ganha:

• Controlo sobre o local onde se situa cada zona, incluindo as cópias de segurança
• Nenhuma transferência para um fornecedor e nenhuma cadeia de subcontratantes ulteriores para o próprio cofre

O que passa a ser devido:

• Localizações das cópias de segurança e das réplicas, restauros testados e um calendário de conservação
• Procedimentos de recuperação de chaves, aplicação de patches e alta disponibilidade
• Um registo atualizado das atividades de tratamento (artigo 30.º)
• Um processo próprio de deteção e notificação de violações (artigo 33.º)

Exemplo hipotético: uma equipa restaura um cofre após uma falha de servidor e descobre que a tarefa de cópia de segurança noturna estava a gravar num armazenamento num segundo país, configurado anos antes por alguém que entretanto saiu. O cofre estava on-premises, mas uma cópia nunca esteve. Essa cópia é uma questão de transferência nos termos do capítulo V. Uma verificação zona a zona encontra-a antes de um incidente.

O risco interno permanece com a organização. A cifragem do lado do cliente impede os administradores de ler o conteúdo do cofre, mas estes continuam a poder eliminar dados, copiar texto cifrado e cópias de segurança, alterar a configuração ou editar registos. Convém segregar funções e registar as ações dos administradores.

As implementações air-gapped acrescentam outro dever. Sem ligação à internet, as atualizações são aplicadas e os registos movidos manualmente. O isolamento não elimina vulnerabilidades, e os suportes de dados transportados para dentro tornam-se o meio pelo qual uma atualização chega ao sistema.

O artigo 32.º, n.º 1, exige medidas adequadas ao risco. Deve documentar-se quem aprova um pacote de atualização, como se verifica a sua integridade antes da importação, com que frequência os registos saem da rede e quem trata dos suportes de dados. O procedimento de restauro também deve ser testado, uma vez que as alíneas c) e d) do n.º 1 do artigo 32.º abrangem o restabelecimento da disponibilidade e o teste regular das medidas.

Como o Passwork gere a localização e o acesso aos dados

O Passwork Self-hosted funciona numa infraestrutura sob o controlo da organização: servidores on-premises, uma cloud privada ou uma rede air-gapped. O cofre, as chaves e as cópias de segurança ficam onde a organização os colocar, pelo que é a equipa que decide onde se situa cada zona. As respostas abaixo seguem as seis zonas e as perguntas formuladas acima.

O Passwork instala-se com Docker em Linux (a via recomendada), com um script PowerShell em Windows Server ou manualmente, e existem pacotes offline para redes air-gapped. Os guias técnicos do Passwork abordam cada via.

Conteúdo do cofre e chaves (zonas 1 e 2). Os dados são cifrados no cliente com AES-256, pelo que o servidor armazena apenas texto cifrado e material de chaves cifrado. A chave mestra é derivada com PBKDF2 e nunca sai do dispositivo do utilizador em texto simples. Uma segunda camada AES-256, independente, protege a base de dados no servidor.

A arquitetura zero-knowledge determina quem pode ler os dados: apenas os utilizadores que detêm as chaves, pelo que nem os próprios administradores da organização conseguem ler o conteúdo do cofre. A recuperação faz-se através de uma conta de recuperação previamente criada, cuja palavra-passe mestra é guardada offline, e é a organização que decide quem a detém.

Dados de serviço (zona 3). O «Activity Log» (registo de atividade) regista as ações de utilizadores, administradores e do sistema, e os seus registos de auditoria estão preparados para integração com SIEM. Os nomes de registos e de pastas, a estrutura de acessos e os metadados de auditoria ficam no servidor, pelo que devem constar do RoPA. A política de conservação é definida pela organização, que mantém os registos no seu próprio armazenamento.

Cópias de segurança e réplicas (zona 4). Os replica sets do MongoDB com três ou mais membros votantes, em conjunto com servidores de aplicação escalados horizontalmente, conferem ao serviço tolerância a falhas para mais de 10 000 utilizadores. Tarefas agendadas em segundo plano criam e fazem a rotação dos ficheiros de cópia de segurança, e é a organização que escolhe onde são armazenados.

Caches de cliente e armazenamento offline (zona 5). O modo offline é só de leitura e requer ativação expressa em dois níveis: o utilizador marca um registo e depois ativa o modo offline num dispositivo específico. Os administradores controlam as funções que o podem utilizar, o número máximo de registos por dispositivo e o tempo máximo sem sincronização antes de um apagamento automático. Os descarregamentos e as visualizações offline são sincronizados com o «Activity Log» e com o «Security Dashboard» (painel de segurança) quando o dispositivo volta a ligar-se. 

Subcontratantes ulteriores (zona 6). Uma implementação em alojamento próprio não tem subcontratantes ulteriores alojados por um fornecedor. A lista de fornecedores limita-se aos prestadores de alojamento e de cópias de segurança da própria organização, e as mesmas perguntas acima aplicam-se-lhes. Um prestador de cloud privada que opere o cofre para a organização é o seu subcontratante e necessita de um DPA próprio.

O acesso segue o princípio do menor privilégio. O controlo de acesso baseado em funções (RBAC) define os níveis de acesso a cofres e pastas, a sincronização de grupos LDAP e Active Directory transpõe as alterações do diretório para o Passwork e o SAML SSO trata do início de sessão. O Passwork está certificado ISO 27001, é testado através da HackerOne e o seu código-fonte está disponível para auditoria independente.

Dossiê de evidências do RGPD para a gestão de palavras-passe

O dossiê de evidências de 8 pontos é o conjunto de documentos que se deve possuir antes de uma auditoria ao gestor de palavras-passe ao abrigo do RGPD. Abrange registos de tratamento, condições do fornecedor, avaliações de transferências, localização das cópias de segurança, revisões de acessos e procedimentos de violação. Os pontos 1 a 6 correspondem a zonas individuais, enquanto os pontos 7 e 8 abrangem o acesso e a gestão de violações em todas elas.

• Entrada do registo das atividades de tratamento para o gestor de palavras-passe, com as seis zonas (artigo 30.º)
• DPA assinado que abranja as condições do artigo 28.º, n.º 3, se um fornecedor ou prestador de alojamento tratar qualquer zona
• Lista atual de subcontratantes ulteriores e cláusula de aviso de alterações, na mesma condição
• Avaliação de impacto da transferência, se alguma zona envolver um país terceiro (capítulo V)
• Avaliação de impacto sobre a proteção de dados, se a análise de risco o exigir (artigo 35.º)
• Mapa de cópias de segurança e réplicas, com localizações e condições de eliminação
• Revisão das permissões do cofre, realizada a partir de exportações do registo de auditoria
• Procedimento de violação em 72 horas que indique quem decide e quem notifica (artigo 33.º)

O RGPD não fixa qualquer intervalo para as revisões de acessos. A cadência trimestral é comum, pelo que convém definir uma adequada ao risco e documentá-la.

O registo de auditoria é a evidência que sustenta os pontos 7 e 8. Mostra quem acedeu a que credencial e quando, o que ajuda a delimitar uma violação e a avaliar se os dados pessoais podem ter sido afetados. Deve ser exportado para um SIEM, para sobreviver ao cofre e alimentar o registo de violações exigido pelo artigo 33.º, n.º 5.

Por onde começar na gestão de palavras-passe em conformidade com o RGPD

A gestão de palavras-passe em conformidade com o RGPD começa por adequar a implementação aos dados que não podem sair da jurisdição da organização. Depois, é necessário dispor de um contrato ou registo para cada zona que um fornecedor trata: onde se situam o conteúdo, as chaves, os dados de serviço, as cópias de segurança, as caches e os subcontratantes ulteriores, e o que abrange cada um.

Comece por uma única página. Desenhe as seis zonas do gestor de palavras-passe atual e assinale aquelas a que não consegue responder. Essas são as primeiras perguntas a colocar ao fornecedor ou, em alojamento próprio, as primeiras tarefas internas. Depois de completo o mapa, o guia de segurança de palavras-passe segundo o RGPD aborda o nível seguinte: regras de palavras-passe e práticas do pessoal.

Perguntas frequentes

Soberania dos dados e gestão de palavras-passe: Manter as credenciais onde pertencem

A soberania dos dados para credenciais exige três controlos (localização, cifragem, acesso), e não apenas a conformidade com o RGPD. Compara os modelos on-premise, air-gapped e cloud na UE e mostra onde uma arquitetura zero-knowledge como a do Passwork fecha, na realidade, a lacuna de soberania.

PassworkPasswork Team

O que é a cifragem zero-knowledge? Como funciona em 5 minutos

A cifragem zero-knowledge significa que o servidor nunca detém as chaves de decifragem, apenas texto cifrado. Explica como funciona a cadeia de chaves, contra que ameaças protege, o que não protege e como verificar a afirmação de um fornecedor.

PassworkPasswork Team

Modelos de implementação de gestores de palavras-passe: Comparação entre cloud, alojamento próprio e híbrido

Escolher onde executar o gestor de palavras-passe importa tanto como escolher qual utilizar. Este guia analisa a implementação em cloud, em alojamento próprio e híbrida, com uma matriz de conformidade para RGPD, HIPAA e NIS2 e uma visão clara das contrapartidas de cada modelo.

PassworkAlex Muntyan

Die Datenschutz-Grundverordnung (DSGVO), das Datenschutzgesetz der EU, verlangt für die Übermittlung personenbezogener Daten außerhalb des Europäischen Wirtschaftsraums (EWR, die EU plus Island, Liechtenstein und Norwegen) eine Rechtsgrundlage für die Übermittlung sowie Sicherheitsmaßnahmen, die dem Risiko angemessen sind. Kennen Sie für DSGVO-konformes Passwortmanagement jeden Ort, an dem Ihre Zugangsdaten vorliegen, und halten Sie für jeden einen Nachweis bereit.

Ihre Zugangsdaten können in einem Rechenzentrum in Frankfurt gespeichert sein und trotzdem einer ausländischen Gerichtsanordnung unterliegen, wenn der Anbieter einer Jurisdiktion außerhalb der EU unterliegt. Ein Label „EU-gehostet" sagt zudem nichts darüber aus, wo die Backups liegen. Dieser Artikel stellt die Sechs-Zonen-Karte der Zugangsdaten vor: die Orte, an denen ein Passwortmanager für Unternehmen Daten speichert, den DSGVO-Artikel, den jeder Ort auslöst, und die Nachweise, die Sie bereithalten müssen. Er schließt mit einem 8-Punkte-Evidenzpaket, das Sie vor einem Audit prüfen können.

Was DSGVO-konformes Passwortmanagement erfordert

Die DSGVO verlangt, dass personenbezogene Daten sicher verarbeitet werden, dass der Datenschutz von Anfang an mitgedacht wird und dass Maßnahmen greifen, die dem Risiko angemessen sind. 

DSGVO-konformes Passwortmanagement bedeutet, dass Sie nachweisen können, dass Zugangsdaten verschlüsselt sind, nur für Personen erreichbar sind, die sie benötigen, protokolliert werden und überall, wo sie gespeichert sind, durch die richtigen Verträge und Aufzeichnungen abgedeckt sind.

Das Gesetz legt das Ergebnis fest (Artikel 5(1)(f), 25 und 32). Sie wählen die Maßnahmen und weisen nach, dass sie funktionieren (Artikel 5(2)). In der Praxis ergeben sich daraus fünf Anforderungen:

• Gespeicherte Zugangsdaten verschlüsseln. Artikel 32(1)(a) nennt „die Pseudonymisierung und Verschlüsselung personenbezogener Daten" als geeignete Maßnahme.
• Zugriff über Rollen begrenzen (rollenbasierte Zugriffskontrolle, RBAC). Jede Person meldet sich unter ihrem eigenen Konto an und sieht nur, was ihre Aufgabe erfordert, selbst wenn die geöffneten Zugangsdaten gemeinsam genutzt werden. Das ist Datenschutz durch Technikgestaltung (Artikel 25), angewendet auf den Zugriff.
• Den Dienst verfügbar halten und testen. Artikel 32(1)(b) bis (d) umfasst Belastbarkeit, die Wiederherstellung des Zugriffs nach einem Vorfall und die regelmäßige Überprüfung der Maßnahmen.
• Aufzeichnen, wer was geöffnet hat. Ein Zugriffsprotokoll zeigt, auf welche Zugangsdaten wann zugegriffen wurde. Das ist der Nachweis, den Sie brauchen, um zu beurteilen, ob eine Datenschutzverletzung personenbezogene Daten betroffen hat (Artikel 33).
• Jeden Ort dokumentieren, an dem die Daten liegen. Das bedeutet ein Verzeichnis von Verarbeitungstätigkeiten, einen Vertrag mit jeder externen Partei, die die Daten verarbeitet, und eine Rechtsgrundlage für jede Übermittlung außerhalb des EWR.

Diese Pflichten erfassen Passwörter aus zwei Gründen. Ein Zugangsdatensatz nennt normalerweise einen Mitarbeiter oder verweist auf einen, was ihn zu personenbezogenen Daten macht (Artikel 4(1): jede Information, die sich auf eine identifizierbare Person bezieht). Die Zugangsdaten öffnen außerdem andere Systeme, etwa HR-, CRM- und Kundendatenbanken, in denen personenbezogene Daten gespeichert sind. Artikel 32(2) verlangt, dass Sie das Risiko eines unbefugten Zugriffs auf personenbezogene Daten bewerten – eine Datenschutzverletzung beim Passwortmanager ist damit ein Einstiegspunkt in jedes System, das er entsperrt. Verschlüsselung senkt das Risiko, nimmt den Datensatz aber nicht aus dem Anwendungsbereich. 

Ihre Organisation ist der Verantwortliche für den Tresor, also die Stelle, die entscheidet, warum und wie die Zugangsdaten verwendet werden. Ein Anbieter oder Hosting-Anbieter, der ihn auf Ihre Anweisung betreibt oder unterstützt, ist Auftragsverarbeiter, und Artikel 28 verlangt dafür einen Vertrag. Artikel 30 verlangt, dass Sie ein Verzeichnis von Verarbeitungstätigkeiten (VVT) führen, das die Empfänger, Standorte und Übermittlungen dieser Verarbeitung auflistet. Diese Standorte zu finden, ist die erste Aufgabe.

Residenz, Souveränität und Jurisdiktion sind drei verschiedene Dinge

Datenresidenz bezeichnet, wo Ihre Daten physisch gespeichert sind. Datensouveränität bedeutet, dass die Daten den Gesetzen und der Rechtskontrolle eines bestimmten Landes unterliegen. Jurisdiktion ist, welche Gerichte und Behörden dem Unternehmen des Anbieters Anordnungen erteilen können. Ein Anbieter, der US-Recht unterliegt, kann Ihren Tresor in Deutschland speichern und trotzdem US-Rechtsforderungen erhalten.

Der CLOUD Act erlaubt es US-Behörden, Anbieter elektronischer Kommunikations- oder Remote-Computing-Dienste, die der US-Jurisdiktion unterliegen, zur Herausgabe von Daten zu verpflichten, die sich in ihrem Besitz, ihrer Verwahrung oder ihrer Kontrolle befinden – auch wenn diese im Ausland gespeichert sind. Ein Anbieter, der ein US-Unternehmen ist oder eine US-Muttergesellschaft hat, kann daher solchen Forderungen ausgesetzt sein, während Ihr Tresor in einer EU-Region liegt. Ob ein bestimmter Anbieter unter das Gesetz fällt, ist eine Frage für Ihr Rechtsteam.

Die DSGVO enthält keine allgemeine Pflicht zur Datenlokalisierung. Sie regelt Übermittlungen in Drittländer in Kapitel V (Artikel 44 bis 50), und Fernzugriff von außerhalb des EWR, etwa durch den Support eines Anbieters, kann als Übermittlung gelten. Einige nationale und branchenspezifische Vorschriften fügen eigene Lokalisierungspflichten hinzu, prüfen Sie also die für Sie geltenden Regeln.

Übermittlungen außerhalb des EWR: Welche Mechanismen gelten

Kapitel V der DSGVO verlangt eine Rechtsgrundlage für die Übermittlung und Garantien, die im Zielland Bestand haben. Fernzugriff durch den Support von außerhalb des EWR auf einen innerhalb des EWR gehosteten Passwort-Tresor zählt als Übermittlung, eine Hosting-Region allein beantwortet die Frage also nicht. Es gibt drei Wege, und jeder gilt in einer anderen Situation.

• Angemessenheitsbeschluss (Artikel 45). Die Europäische Kommission hat festgestellt, dass das Schutzniveau im Zielland gleichwertig ist. Der EU-US Data Privacy Framework-Beschluss vom 10. Juli 2023 deckt nur selbstzertifizierte US-Unternehmen ab, prüfen Sie also den Eintrag des Anbieters in der Framework-Liste. Frühere EU-US-Rahmenwerke wurden gerichtlich gekippt, und das aktuelle wird angefochten, halten Sie Standardvertragsklauseln also als Rückfalloption im AVV bereit.
• Geeignete Garantien (Artikel 46). Meist Standardvertragsklauseln (SCC), von der Kommission genehmigte Musterklauseln, zusammen mit einer Transferfolgenabschätzung (TIA). Die TIA prüft, ob das Recht des Ziellands Behörden den Zugriff auf die Daten erlaubt. Sie folgt aus dem Schrems-II-Urteil und den Empfehlungen 01/2020 des EDPB.
• Ausnahmeregelungen (Artikel 49). Eng gefasste Ausnahmen, etwa die ausdrückliche Einwilligung, nachdem die betroffene Person über die Risiken informiert wurde. Sie eignen sich für gelegentliche Übermittlungen, nicht für die routinemäßige Verarbeitung durch einen Anbieter.

Eine EU-Hosting-Region senkt das Risiko, beseitigt es aber nicht. Support-Personal außerhalb des EWR, anderswo verarbeitete Metadaten und eine Muttergesellschaft außerhalb des EWR mit Zugriff können jeweils eine Übermittlung auslösen. Die Befugnis einer ausländischen Behörde, eine Muttergesellschaft zur Offenlegung von Daten zu verpflichten, ist ein eigenständiges Jurisdiktionsrisiko (siehe den Abschnitt zur Residenz oben). Behandeln Sie die Region als einen Faktor Ihrer TIA, nicht als deren Ergebnis.

Die Sechs-Zonen-Karte der Zugangsdaten

Die Sechs-Zonen-Karte der Zugangsdaten teilt einen Passwortmanager für Unternehmen in sechs Orte auf, an denen Zugangsdaten existieren. Jede Zone kann in einem anderen Land liegen und bringt ihre eigene DSGVO-Pflicht mit sich. Wer nur „den Server" prüft, übersieht Kopien, für die er verantwortlich ist.

Ein Passwortmanager ist ein System von Kopien. Einige davon halten Sie selbst, andere der Anbieter, und wieder andere die Lieferanten des Anbieters. Welche Kopien bei Ihnen liegen, hängt vom Bereitstellungsmodell ab. Bei einem selbst gehosteten Modell sind Sie der Betreiber jeder Zone, sodass sich jede Frage unten auf Ihre eigenen Teams und Hosting-Anbieter bezieht statt auf einen Anbieter.

Jede Zone löst außerdem eine andere Pflicht aus. Backups werfen Löschpflichten bei Vertragsende auf (Artikel 28(3)(g)), und Lieferanten werfen Pflichten auf, die entlang der Kette weitergegeben werden müssen (Artikel 28(4)). Die nächsten sechs Unterabschnitte behandeln jede Zone und was Sie dazu erfragen sollten.

Zone 1: Gespeicherte Zugangsdaten

Gespeicherte Zugangsdaten sind die Inhalte, die Nutzer ablegen: Logins, Notizen, Anhänge und die Geheimnisse hinter Einmalcodes. Mit clientseitiger Verschlüsselung erreicht sie der Server als Chiffretext – Daten, die ohne den Schlüssel unlesbar sind. Eine gestohlene Kopie der Datenbank legt dann nur unlesbare Geheimnisse offen, vorausgesetzt der Schlüssel, der den verschlüsselten privaten Schlüssel entschlüsselt, bleibt auf dem Gerät des Nutzers (siehe Zone 2).

Verschlüsselte Zugangsdaten bleiben personenbezogene Daten, wenn sie sich auf eine identifizierbare Person beziehen, Zone 1 bleibt also im Anwendungsbereich. Artikel 32(1)(a) nennt Verschlüsselung als Beispiel einer geeigneten Maßnahme, und sie senkt das Risiko. Erfassen Sie in Ihrem VVT-Eintrag für den Passwortmanager den Standort und die Verschlüsselungsmethode dieser Zone.

Datensatznamen, Ordnerstruktur und Audit-Metadaten werden getrennt gespeichert und gehören zu Zone 3. Führen Sie dafür eine eigene VVT-Zeile mit denselben Angaben zu Standort und Zugriff.

Zone 2: Schlüsselmaterial

Schlüsselmaterial ist die Gesamtheit der kryptografischen Schlüssel, die gespeicherte Zugangsdaten entsperren. Wer die Schlüssel besitzt, kann die Daten lesen, unabhängig davon, wo der Chiffretext liegt – Schlüsselstandort und Schlüsselinhaber sind daher ebenso wichtig wie der Serverstandort. Artikel 32(1)(a) macht Verschlüsselung nur dann zu einer geeigneten Maßnahme, wenn die Schlüssel ebenso sorgfältig kontrolliert werden wie die Daten. 

Die Kette verläuft über Masterpasswort, Hauptschlüssel, privaten Schlüssel, Tresorschlüssel, Datensatzschlüssel. Aus dem Masterpasswort des Nutzers wird der Hauptschlüssel über eine Funktion wie PBKDF2 abgeleitet, die das Erraten von Passwörtern verlangsamt. Dieser Schlüssel entschlüsselt einen privaten Schlüssel, der Tresorschlüssel entschlüsselt, die wiederum die Schlüssel einzelner Datensätze entsperren.

Der Server speichert den privaten Schlüssel und die Tresorschlüssel in verschlüsselter Form. Der Schlüssel, der sie entschlüsselt, bleibt auf dem Gerät des Nutzers, sodass eine Kopie der Datenbank allein keinen Zugriff ermöglicht.

Die Wiederherstellung ist der eine Schlüsselpfad, den es sich lohnt, gesondert zu betrachten. Manche Designs enthalten ein Wiederherstellungskonto oder einen Hinterlegungsschlüssel, damit eine Organisation den Zugriff nach einem verlorenen Masterpasswort wiederherstellen kann. Wer diesen Schlüssel besitzt, kann ebenfalls auf Klartext zugreifen – behandeln Sie ihn also wie jeden anderen Schlüssel: wer ihn besitzt, wo er gespeichert ist und welche Gerichte seinen Inhaber zur Herausgabe verpflichten können. Unser Leitfaden zu dem, was Zero-Knowledge-Verschlüsselung schützt und was nicht, erklärt die Mechanik.

Zone 3: Servicedaten

Servicedaten sind alles, was das System über die Nutzung aufzeichnet, statt über den Inhalt. Clientseitige Verschlüsselung deckt sie nicht ab, sodass der Betreiber sie meist lesen kann. Das macht sie selbst zu personenbezogenen Daten und zu dem Teil des Systems, den eine behördliche Anordnung erreichen kann, ohne die Verschlüsselung anzutasten. Dazu gehören typischerweise:

• Kontoidentitäten, E-Mail-Adressen und Rechnungsdaten
• Anmelde-IP-Adressen, Geräte-Kennungen und Zugriffszeitstempel
• Audit-Protokolle sowie Datensatznamen und Ordnerstruktur, falls das Produkt sie nicht verschlüsselt

Drei Pflichten gelten hier. Protokolle sind Ihr Nachweis zur Beurteilung einer Datenschutzverletzung (Artikel 32 und 33). Die Speicherdauer muss auf das Nötige begrenzt sein (Artikel 5(1)(e)). Mitarbeiter können ihre eigenen Daten anfordern (Artikel 15). Bei einem selbst gehosteten Modell halten Sie diese Zone selbst.

Zone 4: Backups, Replikate und Disaster Recovery

Backups, Replikate und Disaster-Recovery-Standorte (DR) sind die Kopien von Zugangsdaten, die außerhalb des primären Servers liegen. Jede Kopie kann in einem anderen Land und unter einem anderen Betreiber liegen, sodass für jede eine eigene Antwort zu Standort, Verschlüsselung und Löschung nötig ist.

Backups sind gespeicherte Kopien zur Wiederherstellung von Daten. Replikate sind laufende Kopien auf anderen Servern. Disaster-Recovery-Standorte (DR) sind Standby-Standorte. Sie unterstützen Verfügbarkeit und Wiederherstellung (Artikel 32(1)(b) und (c)), aber jede zusätzliche Kopie vergrößert die Angriffsfläche und die Zahl der geltenden Jurisdiktionen. Fragen Sie drei Dinge ab:

• Wo wird jedes Backup und Replikat gespeichert, und verlässt eine Kopie die EU oder den EWR? Eine Kopie in einem Drittland kann nach Kapitel V als Übermittlung zählen.
• Sind die Backups verschlüsselt, und werden die Schlüssel getrennt von den Daten aufbewahrt?
• Wie viele Tage dauert es nach Vertragsende, bis die letzte Kopie gelöscht ist, und wie überprüfen Sie das?

Artikel 28(3)(g) verpflichtet den Auftragsverarbeiter, nach Ihrer Wahl alle personenbezogenen Daten bei Beendigung der Dienste zu löschen oder zurückzugeben und vorhandene Kopien zu löschen, sofern das Recht keine Speicherung verlangt. Backups fallen unter diese Pflicht. In der Praxis laufen sie oft über einen Rotationszyklus aus, die Aufbewahrungsdauer ist also die Zahl, die Sie sich schriftlich geben lassen sollten.

Zone 5: Client-Caches und Offline-Speicher

Manche Daten verlassen den Server konstruktionsbedingt. Desktop- und Mobil-Apps können Offline-Kopien vorhalten, Browser-Erweiterungen können eine Sitzung oder einen Entsperrschlüssel vorhalten, und Nutzer können Tresordateien exportieren. Jede davon ist eine Kopie außerhalb Ihrer zentralen Kontrolle und reist dorthin, wohin das Gerät des Mitarbeiters reist.

Das ist die Zone, in der Ihre eigene Richtlinie am meisten zählt. Legen Sie fest, ob der Offline-Modus erlaubt ist, verlangen Sie Festplattenverschlüsselung über Mobile Device Management (MDM), und schränken Sie ein, wer exportieren darf. Behandeln Sie Exporte mit der größten Sorgfalt, da eine CSV-Datei für jeden lesbar ist, der sie öffnet. Fragen Sie den Anbieter, ob Administratoren den Offline-Modus nach Rolle einschränken können, ob zwischengespeicherte Daten sich nach einer festgelegten Zeit selbst löschen und ob Offline-Nutzung und Exporte protokolliert werden.

Ein verlorenes Gerät mit einer Tresorkopie ist ein Risiko nach Artikel 32(2), der Verlust und unbefugte Offenlegung nennt, und kann die Meldepflichten bei Datenschutzverletzungen nach Artikel 33 und 34 auslösen. Listen Sie Endgeräte und zugelassene Exportorte in Ihrem VVT auf.

Zone 6: Unterauftragsverarbeiter und Support-Zugriff

Unterauftragsverarbeiter sind die Lieferanten, die ein Anbieter zur Erbringung des Dienstes einsetzt, etwa für Hosting, E-Mail-Zustellung, Monitoring und Support-Tools. Nach Artikel 28(2) und 28(4) braucht der Auftragsverarbeiter Ihre Genehmigung, um sie einzubinden, und muss dieselben Datenschutzpflichten entlang der Kette weitergeben.

Dritte waren laut Verizons DBIR 2026 an 48 % der Datenschutzverletzungen beteiligt – ein Anstieg von 60 % gegenüber dem Vorjahr. Der Bericht ordnet diese Fälle drei Archetypen zu: einem Anbieter in Ihrer Software-Lieferkette, einem Anbieter, der Ihre Daten in seiner Umgebung hostet, und einem Anbieter mit einer Verbindung in Ihre Umgebung. Ein gehosteter Passwortmanager ist der zweite Typ, und eine Support- oder Integrationsverbindung in Ihre Systeme kann ihn zum dritten machen. Prüfen Sie die Lieferanten des Anbieters so genau wie dessen Produkt.

Fordern Sie vier Dinge an:

• Eine aktuelle Liste der Unterauftragsverarbeiter und des Landes, in dem jeder tätig ist
• Vorabbenachrichtigung über Änderungen, mit einem Widerspruchsrecht
• Wer im Support-Team des Anbieters Servicedaten einsehen kann (Zone 3) und unter welcher Genehmigung
• Ob ein Unterauftragsverarbeiter oder Support-Zugang auf Schlüsselmaterial zugreifen kann (Zone 2)

Zone-zu-Artikel-Karte: Die Pflicht und der Nachweis

Die Zone-zu-Artikel-Karte ordnet jeder der sechs Zugangsdaten-Zonen die DSGVO-Vorschrift zu, die sie auslöst, das Dokument, das die Einhaltung belegt, und die Partei, die dafür verantwortlich ist. Nutzen Sie sie als Grundgerüst für Ihren VVT-Eintrag zum Passwortmanager, und füllen Sie die Nachweis-Spalte aus, bevor ein Auditor fragt. Das Evidenzpaket am Ende listet dieselben Dokumente als Checkliste.

Diese Aufteilung entscheidet, wer meldet. Nach Artikel 33 meldet der Verantwortliche die Datenschutzverletzung der Aufsichtsbehörde innerhalb von 72 Stunden, nachdem er davon Kenntnis erlangt hat, soweit möglich. Der Auftragsverarbeiter muss Sie „unverzüglich" informieren, was keine Zahl festlegt – schreiben Sie also eine Meldefrist in den AVV. Beim Self-Hosting sind Sie zugleich Verantwortlicher und Betreiber, und die Spalte „Verantwortlich" fällt auf Ihre eigenen Teams zusammen.

Der AVV, den Sie von einem Passwortmanager-Anbieter brauchen

Ein Auftragsverarbeitungsvertrag (AVV) ist der Vertrag, den Artikel 28(3) zwischen einem Verantwortlichen und einem Auftragsverarbeiter vorschreibt. Für einen Passwortmanager-Anbieter muss er Gegenstand, Dauer, Art, Zweck, Datenarten und Kategorien betroffener Personen festlegen, zuzüglich acht Pflichten in den Punkten (a) bis (h). Die EDPB Guidelines 07/2020 zu Verantwortlichen und Auftragsverarbeitern erläutern jede davon.

Die Zeile zu Audits verdient die genaueste Lektüre. Artikel 28(3)(h) verlangt, dass Ihnen der Vertrag die Informationen gibt, die die Einhaltung belegen, und Audits einschließlich Inspektionen erlaubt. Öffnet der Anbieter seine Infrastruktur nicht für eine Inspektion vor Ort, sollte der Vertrag festlegen, was stattdessen gilt.

Die Nachweise, die Sie dann prüfen, umfassen die Liste der Unterauftragsverarbeiter, eine Transferfolgenabschätzung und die Audit-Berichte, auf die Ihnen der Vertrag Anspruch gibt. Ergänzen Sie Ihre eigenen Tresor-Protokolle, exportiert in ein SIEM (ein System, das Sicherheitsprotokolle sammelt und auswertet).

Bereitstellungsmodelle für DSGVO-konformes Passwortmanagement

Ihr Bereitstellungsmodell entscheidet, welche der sechs Zonen Ihr Team kontrolliert. Eine Anbieter-Cloud belässt die meisten Zonen beim Anbieter, eine EU-Region-Cloud schränkt ein, wo sie liegen, und Self-Hosting verlagert sie auf Ihre Infrastruktur und Ihre Pflichtenliste. Air-gapped-Umgebungen gehen am weitesten und ergänzen den Umgang mit Offline-Updates und Protokollen.

Ein vom Anbieter verwalteter Dienst gibt Ihnen weniger Kontrolle über Exportformate und den Zeitpunkt eines Ausstiegs. Prüfen Sie vor der Unterschrift, wie Sie den Dienst verlassen würden: welche Formate Sie exportieren können und welche Frist für die Löschung von Backups nach Artikel 28(3)(g) gilt.

Self-Hosting und DSGVO: Welche Pflichten Sie übernehmen

Self-Hosting verlagert DSGVO-Pflichten von einem Anbietervertrag in Ihre eigenen Betriebsabläufe. Sie kontrollieren, wo jede Zone liegt und wer sie betreibt, wodurch das Auftragsverarbeiterverhältnis für den Tresor selbst entfallen kann. Sie werden außerdem selbst zum Betreiber und tragen die Nachweise damit selbst. Unsere Seite zum On-Premises-Passwortmanager behandelt diese Bereitstellungsoption.

Was Sie gewinnen:

• Kontrolle darüber, wo jede Zone liegt, einschließlich Backups
• Keine Übermittlung an einen Anbieter und keine Kette von Unterauftragsverarbeitern für den Tresor selbst

Was Sie nun schulden:

• Standorte von Backups und Replikaten, getestete Wiederherstellungen und einen Aufbewahrungsplan
• Verfahren zur Schlüsselwiederherstellung, Patching und Hochverfügbarkeit
• Ein aktuelles Verzeichnis von Verarbeitungstätigkeiten (Artikel 30)
• Ihren eigenen Prozess zur Erkennung und Meldung von Datenschutzverletzungen (Artikel 33)

Hypothetisches Beispiel: Ein Team stellt einen Tresor nach einem Server-Absturz wieder her und stellt fest, dass der nächtliche Backup-Job seit Jahren in einen Speicher in einem zweiten Land schreibt, eingerichtet von jemandem, der das Unternehmen inzwischen verlassen hat. Der Tresor lag on-premises, eine Kopie jedoch nie. Diese Kopie ist eine Übermittlungsfrage nach Kapitel V. Eine Prüfung Zone für Zone findet das, bevor es ein Vorfall tut.

Das Insider-Risiko bleibt bei Ihnen. Clientseitige Verschlüsselung bedeutet, dass Administratoren Tresorinhalte nicht lesen können, aber sie können weiterhin Daten löschen, Chiffretext und Backups kopieren, die Konfiguration ändern oder Protokolle bearbeiten. Trennen Sie Zuständigkeiten, und protokollieren Sie Administratorhandlungen.

Air-gapped-Bereitstellungen bringen eine weitere Pflicht mit sich. Ohne Internetverbindung spielen Sie Updates manuell ein und bewegen Protokolle manuell. Isolation entfernt keine Schwachstellen, und der Datenträger, den Sie hineintragen, wird zum Weg, auf dem ein Update das System erreicht.

Artikel 32(1) verlangt dem Risiko angemessene Maßnahmen. Dokumentieren Sie, wer ein Update-Paket genehmigt, wie Sie seine Integrität vor dem Import prüfen, wie oft Protokolle das Netzwerk verlassen und wer die Datenträger handhabt. Testen Sie auch das Wiederherstellungsverfahren, denn 32(1)(c) und (d) decken die Wiederherstellung der Verfügbarkeit und die regelmäßige Überprüfung Ihrer Maßnahmen ab.

Wie Passwork Datenstandort und Zugriff handhabt

Passwork Self-hosted läuft auf Infrastruktur, die Sie kontrollieren: On-Premises-Server, eine Private Cloud oder ein air-gapped Netzwerk. Der Tresor, die Schlüssel und die Backups liegen dort, wo Sie sie platzieren, Ihr Team entscheidet also, wo jede Zone liegt. Die Antworten unten folgen den sechs Zonen und den oben gestellten Fragen.

Passwork wird mit Docker auf Linux installiert (der empfohlene Weg), mit einem PowerShell-Skript auf Windows Server oder manuell, und Offline-Pakete decken air-gapped Netzwerke ab. Die technischen Leitfäden von Passwork behandeln jeden Weg.

Tresorinhalt und Schlüssel (Zonen 1 und 2). Daten werden clientseitig mit AES-256 verschlüsselt, der Server speichert also nur Chiffretext und verschlüsseltes Schlüsselmaterial. Der Hauptschlüssel wird mit PBKDF2 abgeleitet und verlässt das Gerät des Nutzers nie im Klartext. Eine zweite, unabhängige AES-256-Schicht schützt die Datenbank auf dem Server.

Zero-Knowledge-Architektur entscheidet, wer die Daten lesen kann: nur die Nutzer, die die Schlüssel besitzen, sodass auch Ihre eigenen Administratoren die Tresorinhalte nicht lesen können. Die Wiederherstellung läuft über ein vorab eingerichtetes Wiederherstellungskonto, dessen Masterpasswort Sie offline speichern, und Sie entscheiden, wer es besitzt.

Servicedaten (Zone 3). Das Aktivitätsprotokoll erfasst Nutzer-, Admin- und Systemaktionen, und seine Audit-Trails sind bereit für die SIEM-Integration. Datensatz- und Ordnernamen, Zugriffsstruktur und Audit-Metadaten liegen auf dem Server, listen Sie sie also in Ihrem VVT auf. Sie legen die Aufbewahrungsrichtlinie fest und bewahren die Protokolle auf Ihrem eigenen Speicher auf.

Backups und Replikate (Zone 4). MongoDB-Replikatsets mit drei oder mehr stimmberechtigten Mitgliedern geben dem Dienst zusammen mit horizontal skalierten Anwendungsservern Fehlertoleranz für über 10.000 Nutzer. Geplante Hintergrundaufgaben erstellen und rotieren Backup-Archive, und Sie wählen, wo sie gespeichert werden.

Client-Caches und Offline-Speicher (Zone 5). Der Offline-Modus ist nur lesend und auf zwei Ebenen opt-in: Der Nutzer markiert einen Datensatz und aktiviert dann Offline auf einem bestimmten Gerät. Administratoren legen fest, welche Rollen ihn nutzen dürfen, die maximale Anzahl an Datensätzen pro Gerät und die maximale nicht synchronisierte Zeit vor einer automatischen Löschung. Offline-Downloads und -Ansichten werden mit dem Aktivitätsprotokoll und dem Sicherheits-Dashboard synchronisiert, sobald das Gerät wieder verbunden ist. 

Unterauftragsverarbeiter (Zone 6). Eine selbst gehostete Bereitstellung hat keinen vom Anbieter gehosteten Unterauftragsverarbeiter. Ihre Lieferantenliste beschränkt sich auf Ihre eigenen Hosting- und Backup-Anbieter, und dieselben Fragen von oben gelten für sie. Ein Private-Cloud-Host, der den Tresor für Sie betreibt, ist Ihr Auftragsverarbeiter und braucht seinen eigenen AVV.

Der Zugriff folgt dem Prinzip der geringsten Privilegien. Rollenbasierte Zugriffskontrolle (RBAC) legt Zugriffslevel für Tresore und Ordner fest, LDAP- und Active-Directory-Gruppensynchronisierung überträgt Verzeichnisänderungen nach Passwork, und SAML SSO übernimmt die Anmeldung. Passwork ist ISO-27001-zertifiziert, über HackerOne getestet, und der Quellcode steht für eine unabhängige Prüfung zur Verfügung.

DSGVO-Evidenzpaket für Passwortmanagement

Das 8-Punkte-Evidenzpaket ist die Zusammenstellung der Dokumente, die Sie vor einem DSGVO-Audit Ihres Passwortmanagers bereithalten sollten. Es umfasst Verarbeitungsaufzeichnungen, Anbieterbedingungen, Transferfolgenabschätzungen, Backup-Standorte, Zugriffsüberprüfungen und Verfahren bei Datenschutzverletzungen. Punkte 1 bis 6 sind einzelnen Zonen zugeordnet, während Punkte 7 und 8 Zugriff und den Umgang mit Datenschutzverletzungen über alle Zonen hinweg abdecken.

• Eintrag im Verzeichnis von Verarbeitungstätigkeiten für den Passwortmanager, der alle sechs Zonen aufführt (Artikel 30)
• Unterschriebener AVV, der die Bedingungen nach Artikel 28(3) abdeckt, falls ein Anbieter oder Hosting-Anbieter eine Zone verarbeitet
• Aktuelle Liste der Unterauftragsverarbeiter und die Klausel zur Änderungsmitteilung, unter derselben Bedingung
• Transferfolgenabschätzung, falls eine Zone ein Drittland berührt (Kapitel V)
• Datenschutz-Folgenabschätzung, falls Ihre Risikobewertung eine erfordert (Artikel 35)
• Backup- und Replikat-Karte mit Standorten und Löschfristen
• Zugriffsüberprüfung der Tresor-Berechtigungen, durchgeführt anhand von Audit-Protokoll-Exporten
• Ein 72-Stunden-Verfahren bei Datenschutzverletzungen, das benennt, wer entscheidet und wer meldet (Artikel 33)

Die DSGVO legt kein festes Intervall für Zugriffsüberprüfungen fest. Vierteljährlich ist ein gängiger Rhythmus, legen Sie also einen fest, der zu Ihrem Risiko passt, und dokumentieren Sie ihn.

Das Audit-Protokoll ist der Nachweis hinter Punkt 7 und 8. Es zeigt, wer wann auf welche Zugangsdaten zugegriffen hat, was Ihnen hilft, das Ausmaß einer Datenschutzverletzung einzuschätzen und zu beurteilen, ob personenbezogene Daten betroffen sein könnten. Exportieren Sie es in Ihr SIEM, damit es den Tresor überlebt und das von Artikel 33(5) vorgeschriebene Verzeichnis der Datenschutzverletzungen speist.

Wo Sie mit DSGVO-konformem Passwortmanagement anfangen

DSGVO-konformes Passwortmanagement beginnt damit, die Bereitstellung an die Daten anzupassen, die Ihre Jurisdiktion nicht verlassen dürfen. Halten Sie dann für jede Zone, die ein Anbieter verarbeitet, einen Vertrag oder Nachweis bereit: wo Inhalt, Schlüssel, Servicedaten, Backups, Caches und Unterauftragsverarbeiter liegen und was jeweils greift.

Beginnen Sie mit einer einzigen Seite. Zeichnen Sie die sechs Zonen für Ihren aktuellen Passwortmanager auf, und markieren Sie die, die Sie nicht beantworten können. Das sind Ihre ersten Fragen an den Anbieter oder Ihre ersten internen Aufgaben, wenn Sie selbst hosten. Sobald die Karte vollständig ist, behandelt der DSGVO-Leitfaden zur Passwortsicherheit die nächste Ebene: Passwortregeln und die Praxis der Mitarbeiter.

Häufig gestellte Fragen

Datensouveränität und Passwortmanagement: Zugangsdaten dort behalten, wo sie hingehören

Datensouveränität für Zugangsdaten erfordert drei Kontrollen (Standort, Verschlüsselung, Zugriff) – nicht nur DSGVO-Konformität. Vergleicht On-Premise-, air-gapped- und EU-Cloud-Modelle und zeigt, wo eine Zero-Knowledge-Architektur wie die von Passwork die Souveränitätslücke tatsächlich schließt.

PassworkPasswork Team

Was ist Zero-Knowledge-Verschlüsselung? So funktioniert sie in 5 Minuten

Zero-Knowledge-Verschlüsselung bedeutet, dass der Server nie Ihre Entschlüsselungs-Schlüssel besitzt, nur Chiffretext. Erfahren Sie, wie die Schlüsselkette funktioniert, wogegen sie schützt, wogegen nicht, und wie Sie die Behauptung eines Anbieters überprüfen.

PassworkPasswork Team

Bereitstellungsmodelle für Passwortmanager: Cloud, Self-hosted und Hybrid im Vergleich

Wo Sie Ihren Passwortmanager betreiben, ist genauso wichtig wie welchen Sie wählen. Dieser Leitfaden schlüsselt Cloud-, Self-hosted- und Hybrid-Bereitstellung auf – mit einer Compliance-Matrix für DSGVO, HIPAA und NIS2 und einem klaren Blick auf die Kompromisse jedes Modells.

PassworkAlex Muntyan

El Reglamento General de Protección de Datos (RGPD), la ley de protección de datos de la UE, exige un mecanismo de transferencia lícito para enviar datos personales fuera del Espacio Económico Europeo (EEE, la UE más Islandia, Liechtenstein y Noruega), y medidas de seguridad adecuadas al riesgo. Para una gestión de contraseñas conforme al RGPD, es necesario saber en qué lugares existen los datos de las credenciales y disponer de pruebas para cada uno de ellos.

Sus credenciales pueden almacenarse en un centro de datos de Fráncfort y, aun así, quedar sujetas a una orden judicial extranjera si el proveedor está sometido a una jurisdicción ajena a la UE. Una etiqueta «alojado en la UE» tampoco dice nada sobre dónde están las copias de seguridad. Este artículo presenta el mapa de seis zonas de datos de credenciales: los lugares donde un gestor de contraseñas empresarial guarda datos, el artículo del RGPD que activa cada uno y las pruebas que debe conservar. Termina con un paquete de evidencias de 8 puntos que puede comprobar antes de una auditoría.

Qué exige la gestión de contraseñas conforme al RGPD

El RGPD exige que los datos personales se procesen de forma segura, que la protección de datos se integre desde el diseño y que se apliquen medidas proporcionales al riesgo. 

Una gestión de contraseñas conforme al RGPD significa poder demostrar que los datos de las credenciales están cifrados, que solo pueden acceder a ellos las personas que los necesitan, que quedan registrados y que están cubiertos por los contratos y registros adecuados, sea donde sea que se almacenen.

La ley fija el resultado (artículos 5(1)(f), 25 y 32). Usted elige los controles y demuestra que funcionan (artículo 5(2)). En la práctica, esto se traduce en cinco requisitos:

• Cifre las credenciales almacenadas. El artículo 32(1)(a) cita «la seudonimización y el cifrado de datos personales» como una medida adecuada.
• Limite el acceso por rol (RBAC). Cada persona inicia sesión con su propia cuenta y solo ve lo que su trabajo requiere, incluso cuando la credencial que abre es compartida. Esto es protección de datos desde el diseño (artículo 25) aplicada al acceso.
• Mantenga el servicio disponible y probado. El artículo 32(1)(b) a (d) cubre la resiliencia, la restauración del acceso tras un incidente y las pruebas periódicas de sus medidas.
• Registre quién abrió qué. Un registro de accesos muestra qué credenciales se consultaron y cuándo. Es la evidencia que necesita para valorar si una vulneración afectó a datos personales (artículo 33).
• Documente cada lugar donde residen los datos. Esto implica un registro de tratamiento, un contrato con cada tercero que trate los datos y un mecanismo lícito para cualquier transferencia fuera del EEE.

Estas obligaciones alcanzan a las contraseñas por dos motivos. Un registro de credenciales suele identificar a un empleado o estar vinculado a uno, lo que lo convierte en un dato personal (artículo 4(1): cualquier información relativa a una persona identificable). Las credenciales también dan acceso a otros sistemas, como RR. HH., CRM y bases de datos de clientes, donde se almacenan datos personales. El artículo 32(2) exige evaluar el riesgo de acceso no autorizado a datos personales, por lo que una vulneración del gestor de contraseñas es una vía de entrada a todos los sistemas que desbloquea. El cifrado reduce el riesgo, pero no excluye el registro del ámbito de aplicación. 

Su organización es el responsable del tratamiento de la bóveda, la parte que decide por qué y cómo se usan los datos de las credenciales. Un proveedor o proveedor de alojamiento que lo opera o lo respalda siguiendo sus instrucciones es un encargado del tratamiento, y el artículo 28 exige un contrato con él. El artículo 30 exige mantener un registro de actividades de tratamiento (RoPA) que recoja los destinatarios, las ubicaciones y las transferencias de este tratamiento. Encontrar esas ubicaciones es la primera tarea.

Residencia, soberanía y jurisdicción son tres cosas distintas

La residencia de los datos es el lugar donde se almacenan físicamente. La soberanía de los datos significa que los datos están sujetos a las leyes y al control legal de un país determinado. La jurisdicción es qué tribunales y autoridades pueden emitir órdenes contra la empresa del proveedor. Un proveedor sujeto a la legislación de EE. UU. puede almacenar su bóveda en Alemania y, aun así, recibir requerimientos legales estadounidenses.

La CLOUD Act permite a las autoridades estadounidenses exigir a los proveedores de servicios de comunicación electrónica o de computación remota sujetos a la jurisdicción de EE. UU. que entreguen los datos que posean, custodien o controlen, incluso cuando estén almacenados en el extranjero. Por tanto, un proveedor que sea una empresa estadounidense o que tenga una matriz estadounidense puede enfrentarse a este tipo de requerimientos aunque su bóveda esté en una región de la UE. Si un proveedor concreto queda sujeto a esta ley es una cuestión para su equipo legal.

El RGPD no contiene una regla general de localización de datos. Regula las transferencias a terceros países en el capítulo V (artículos 44 a 50), y el acceso remoto desde fuera del EEE, como el soporte del proveedor, puede considerarse una transferencia. Algunas normas nacionales o sectoriales añaden requisitos de localización propios, así que compruebe las que se aplican en su caso.

Transferencias fuera del EEE: Qué mecanismos se aplican

El capítulo V del RGPD exige un mecanismo de transferencia lícito y garantías que se mantengan en el país de destino. El acceso remoto de soporte desde fuera del EEE a una bóveda de contraseñas alojada dentro de él cuenta como una transferencia, por lo que la región de alojamiento por sí sola no resuelve la cuestión. Existen tres vías, y cada una se aplica a una situación distinta.

• Decisión de adecuación (artículo 45). La Comisión Europea ha determinado que la protección del país de destino es equivalente. La decisión del Marco de Privacidad de Datos UE-EE. UU. del 10 de julio de 2023 solo cubre a las empresas estadounidenses autocertificadas, así que compruebe si el proveedor figura en la lista del marco. Marcos anteriores entre la UE y EE. UU. fueron anulados por los tribunales, y el actual también ha sido impugnado, por lo que conviene mantener las cláusulas contractuales tipo como respaldo en el DPA.
• Garantías adecuadas (artículo 46). Normalmente, cláusulas contractuales tipo (SCC), modelos de contrato aprobados por la Comisión, junto con una evaluación de impacto de la transferencia (TIA). La TIA comprueba si la legislación del país de destino permite a las autoridades acceder a los datos. Se deriva de la sentencia Schrems II y de las Recomendaciones 01/2020 del Comité Europeo de Protección de Datos (CEPD).
• Excepciones (artículo 49). Excepciones limitadas, como el consentimiento explícito tras informar al interesado de los riesgos. Son adecuadas para transferencias puntuales y no amparan el tratamiento habitual por parte de un proveedor.

Alojar los datos en una región de la UE reduce el riesgo, pero no lo elimina. El personal de soporte fuera del EEE, los metadatos tratados en otro lugar y una matriz fuera del EEE con acceso pueden, cada uno, generar una transferencia. La capacidad de una autoridad extranjera para ordenar a una matriz que divulgue datos es un riesgo de jurisdicción distinto (véase el apartado de residencia anterior). Trate la región como un factor más en su TIA, no como su conclusión.

El mapa de seis zonas de datos de credenciales

El mapa de seis zonas de datos de credenciales divide un gestor de contraseñas empresarial en seis lugares donde existen datos de credenciales. Cada zona puede estar en un país distinto y conlleva su propia obligación bajo el RGPD, por lo que comprobar solo «el servidor» deja fuera copias de las que usted es responsable.

Un gestor de contraseñas es un sistema de copias. Usted conserva algunas, el proveedor conserva otras, y los proveedores del proveedor conservan el resto. Qué copias quedan en sus manos depende del modelo de despliegue. En un despliegue autoalojado, usted es el operador de todas las zonas, por lo que cada pregunta siguiente se aplica a sus propios equipos y proveedores de alojamiento en lugar de a un proveedor externo.

Cada zona también activa una obligación distinta. Las copias de seguridad generan obligaciones de eliminación al finalizar el contrato (artículo 28(3)(g)), y los proveedores generan obligaciones que deben trasladarse a lo largo de la cadena (artículo 28(4)). Los seis apartados siguientes tratan cada zona y qué pedir.

Zona 1: Credenciales almacenadas

Las credenciales almacenadas son el contenido que guardan los usuarios: inicios de sesión, notas, archivos adjuntos y los secretos que hay detrás de los códigos de un solo uso. Con el cifrado del lado del cliente, llegan al servidor como texto cifrado, datos ilegibles sin la clave. Una copia robada de la base de datos solo expone entonces secretos ilegibles, siempre que la clave que desbloquea la clave privada cifrada permanezca en el dispositivo del usuario (véase la zona 2).

Las credenciales cifradas siguen siendo datos personales cuando se refieren a una persona identificable, por lo que la zona 1 sigue dentro del ámbito de aplicación. El artículo 32(1)(a) cita el cifrado como ejemplo de medida adecuada, y reduce el riesgo. En la entrada de su RoPA para el gestor de contraseñas, anote la ubicación de esta zona y el método de cifrado.

Los nombres de los registros, la estructura de carpetas y los metadatos de auditoría se almacenan por separado y pertenecen a la zona 3. Asígneles su propia línea en el RoPA con la misma ubicación y los mismos detalles de acceso.

Zona 2: Material de claves

El material de claves es el conjunto de claves criptográficas que desbloquean las credenciales almacenadas. Quien posea las claves puede leer los datos, estén donde estén el texto cifrado, por lo que la ubicación de las claves y quién las posee importan tanto como la ubicación del servidor. El artículo 32(1)(a) solo considera el cifrado una medida adecuada cuando las claves se controlan con el mismo cuidado que los datos. 

La cadena recorre la contraseña maestra, la clave maestra, la clave privada, las claves de bóveda y las claves de registro. La contraseña maestra del usuario deriva la clave maestra mediante una función como PBKDF2, que ralentiza los intentos de adivinar la contraseña. Esa clave descifra una clave privada, que descifra las claves de bóveda, las cuales a su vez desbloquean las claves de cada registro.

El servidor almacena la clave privada y las claves de bóveda en forma cifrada. La clave que las descifra permanece en el dispositivo del usuario, por lo que una copia de la base de datos por sí sola no concede acceso.

La recuperación es la única vía de claves que merece un mapeo aparte. Algunos diseños incluyen una cuenta de recuperación o una clave en depósito para que una organización pueda restaurar el acceso tras perder la contraseña maestra. Quien posea esa clave también puede acceder al texto en claro, así que trátela como cualquier otra clave: quién la posee, dónde se almacena y qué tribunales pueden obligar a revelarla a quien la posee. Nuestra guía sobre qué protege y qué no protege el cifrado de conocimiento cero explica el mecanismo.

Zona 3: Datos de servicio

Los datos de servicio son todo lo que el sistema registra sobre el uso, no sobre el contenido. El cifrado del lado del cliente no los cubre, por lo que el operador normalmente puede leerlos. Esto los convierte en datos personales por derecho propio y en la parte del sistema a la que puede llegar un requerimiento legal sin tocar el cifrado. Suele incluir:

• Identidades de cuenta, direcciones de correo electrónico y registros de facturación
• Direcciones IP de inicio de sesión, identificadores de dispositivo y marcas de tiempo de acceso
• Registros de auditoría, además de los nombres de los registros y la estructura de carpetas si el producto no los cifra

Se aplican tres obligaciones. Los registros son su evidencia para valorar una vulneración (artículos 32 y 33). La conservación debe limitarse a lo que necesite (artículo 5(1)(e)). Los empleados pueden solicitar sus propios datos (artículo 15). En un despliegue autoalojado, usted mismo gestiona esta zona.

Zona 4: Copias de seguridad, réplicas y recuperación ante desastres

Las copias de seguridad, las réplicas y los sitios de recuperación ante desastres (DR) son las copias de datos de credenciales que existen fuera del servidor principal. Cada copia puede estar en un país distinto y bajo un operador distinto, por lo que cada una necesita su propia respuesta sobre ubicación, cifrado y eliminación.

Las copias de seguridad son copias almacenadas para restaurar datos. Las réplicas son copias activas en otros servidores. Los sitios de recuperación ante desastres (DR) son ubicaciones en espera. Respaldan la disponibilidad y la recuperación (artículo 32(1)(b) y (c)), pero cada copia adicional amplía la superficie de ataque y el conjunto de jurisdicciones aplicables. Pregunte tres cosas:

• ¿Dónde se almacena cada copia de seguridad y cada réplica, y sale alguna copia de la UE o del EEE? Una copia en un tercer país puede contar como una transferencia conforme al capítulo V.
• ¿Las copias de seguridad están cifradas, y las claves se mantienen separadas de los datos?
• Una vez finalizado el contrato, ¿cuántos días tardan en desaparecer todas las copias, y cómo lo verifica?

El artículo 28(3)(g) exige que el encargado del tratamiento, a elección del responsable, elimine o devuelva todos los datos personales cuando finalicen los servicios, y que elimine las copias existentes salvo que la ley exija su conservación. Las copias de seguridad quedan sujetas a esta obligación. En la práctica, suelen caducar en un ciclo de rotación, por lo que el plazo de conservación es el dato que conviene obtener por escrito.

Zona 5: Cachés de los clientes y almacenes sin conexión

Algunos datos salen del servidor por diseño. Las aplicaciones de escritorio y móviles pueden conservar copias sin conexión, las extensiones del navegador pueden conservar una sesión o una clave de desbloqueo, y los usuarios pueden exportar archivos de la bóveda. Cada una es una copia fuera de sus controles centrales que viaja allí donde va el dispositivo del empleado.

Esta es la zona donde más importa su propia política. Decida si se permite el modo sin conexión, exija el cifrado de disco mediante la gestión de dispositivos móviles (MDM), y restrinja quién puede exportar. Trate las exportaciones con el máximo cuidado, ya que un archivo CSV es legible por cualquiera que lo abra. Pregunte al proveedor si los administradores pueden limitar el modo sin conexión por rol, si los datos en caché se borran automáticamente tras un periodo determinado, y si el uso sin conexión y las exportaciones quedan registrados.

Un dispositivo perdido con una copia de la bóveda es un riesgo conforme al artículo 32(2), que menciona la pérdida y la divulgación no autorizada, y puede activar las obligaciones de notificación de vulneraciones de los artículos 33 y 34. Enumere los endpoints y las ubicaciones de exportación aprobadas en su RoPA.

Zona 6: Subencargados y acceso de soporte

Los subencargados son los proveedores que utiliza un proveedor para prestar el servicio, como el alojamiento, el envío de correo electrónico, la monitorización y las herramientas de soporte. Conforme a los artículos 28(2) y 28(4), el encargado del tratamiento necesita su autorización para contratarlos y debe trasladar las mismas obligaciones de protección de datos a lo largo de la cadena.

Los terceros estuvieron implicados en el 48 % de las vulneraciones registradas en el DBIR 2026 de Verizon, un aumento del 60 % respecto al año anterior. El informe agrupa estos casos en tres arquetipos: un proveedor en su cadena de suministro de software, un proveedor que aloja sus datos en su propio entorno y un proveedor con una conexión a su entorno. Un gestor de contraseñas alojado es del segundo tipo, y un enlace de soporte o integración con sus sistemas puede convertirlo en el tercero. Revise a los proveedores del proveedor con la misma atención que su producto.

Pida cuatro cosas:

• Una lista actualizada de subencargados y el país en el que opera cada uno
• Aviso previo de los cambios, con derecho a oponerse
• Quién del equipo de soporte del proveedor puede ver datos de servicio (zona 3), y bajo qué autorización
• Si algún subencargado o canal de soporte puede acceder al material de claves (zona 2)

Mapa de zonas a artículos: La obligación y la evidencia

El mapa de zonas a artículos vincula cada una de las seis zonas de credenciales con la disposición del RGPD que activa, el documento que demuestra el cumplimiento y la parte responsable de aportarlo. Utilícelo como esqueleto para la entrada de su RoPA sobre el gestor de contraseñas, y complete la columna de evidencias antes de que un auditor la solicite. El paquete de evidencias del final enumera los mismos documentos como lista de verificación.

Este reparto decide quién notifica. Conforme al artículo 33, el responsable notifica a la autoridad de control en un plazo de 72 horas desde que tiene conocimiento de la vulneración, siempre que sea posible. El encargado debe informarle «sin dilación indebida», una expresión que no fija un número, así que conviene recoger un plazo de notificación en el DPA. Cuando aloja el sistema usted mismo, es a la vez responsable y operador, y la columna de responsable se reduce a sus propios equipos.

El DPA que necesita de un proveedor de gestores de contraseñas

Un acuerdo de tratamiento de datos (DPA) es el contrato que exige el artículo 28(3) entre un responsable y un encargado del tratamiento. En el caso de un proveedor de gestores de contraseñas, debe especificar el objeto, la duración, la naturaleza, la finalidad, los tipos de datos y las categorías de interesados, además de ocho obligaciones recogidas en los puntos (a) a (h). Las Directrices 07/2020 del CEPD sobre responsables y encargados explican cada una.

La fila de auditorías es la que exige una lectura más atenta. El artículo 28(3)(h) exige que el contrato le facilite la información que demuestre el cumplimiento y permita auditorías, incluidas inspecciones. Si el proveedor no abre su infraestructura a una inspección in situ, el contrato debería indicar qué la sustituye.

La evidencia que revisa entonces incluye la lista de subencargados, una evaluación de transferencia y los informes de auditoría a los que el contrato le da derecho. Añada sus propios registros de la bóveda, exportados a un SIEM (sistema de gestión de eventos e información de seguridad).

Modelos de despliegue para una gestión de contraseñas conforme al RGPD

Su modelo de despliegue decide cuáles de las seis zonas controla su equipo. Una nube del proveedor deja la mayoría de las zonas en manos del proveedor, una nube en región de la UE reduce dónde se ubican, y el autoalojamiento las traslada a su infraestructura y a su lista de obligaciones. Los entornos aislados (air-gapped) van más allá y añaden la gestión de actualizaciones y registros sin conexión.

Un servicio gestionado por el proveedor le da menos control sobre los formatos de exportación y los plazos de salida. Antes de firmar, compruebe cómo saldría: qué formatos puede exportar y el plazo para eliminar las copias de seguridad conforme al artículo 28(3)(g).

Autoalojamiento y RGPD: Qué obligaciones asume

El autoalojamiento traslada las obligaciones del RGPD de un contrato con un proveedor a sus propios procedimientos operativos. Usted controla dónde se ubica cada zona y quién la opera, lo que puede eliminar la relación de encargado del tratamiento para la propia bóveda. Usted también se convierte en el operador, por lo que es usted quien aporta la evidencia. Nuestra página sobre el gestor de contraseñas on-premise trata esta opción de despliegue.

Lo que gana:

• Control sobre dónde se ubica cada zona, incluidas las copias de seguridad
• Ninguna transferencia a un proveedor ni cadena de subencargados para la propia bóveda

Lo que ahora debe:

• Ubicaciones de las copias de seguridad y réplicas, restauraciones probadas y un calendario de conservación
• Procedimientos de recuperación de claves, aplicación de parches y alta disponibilidad
• Un registro actualizado de actividades de tratamiento (artículo 30)
• Su propio proceso de detección y notificación de vulneraciones (artículo 33)

Ejemplo hipotético: un equipo restaura una bóveda tras una caída del servidor y descubre que la tarea de copia de seguridad nocturna llevaba tiempo escribiendo en un almacenamiento situado en un segundo país, configurado años antes por alguien que ya no está en la empresa. La bóveda estaba on-premises, pero una copia nunca lo estuvo. Esa copia plantea una cuestión de transferencia conforme al capítulo V. Una revisión zona por zona la detecta antes de que lo haga un incidente.

El riesgo interno sigue siendo suyo. El cifrado del lado del cliente significa que los administradores no pueden leer el contenido de la bóveda, pero sí pueden eliminar datos, copiar texto cifrado y copias de seguridad, cambiar la configuración o modificar registros. Separe funciones y registre las acciones de los administradores.

Los despliegues aislados (air-gapped) añaden otra obligación. Sin conexión a internet, usted aplica las actualizaciones y traslada los registros manualmente. El aislamiento no elimina las vulnerabilidades, y el soporte físico que introduce se convierte en la vía por la que una actualización llega al sistema.

El artículo 32(1) exige medidas proporcionales al riesgo. Documente quién aprueba un paquete de actualización, cómo verifica su integridad antes de importarlo, con qué frecuencia salen los registros de la red y quién gestiona el soporte físico. Pruebe también el procedimiento de restauración, ya que el 32(1)(c) y (d) cubren la restauración de la disponibilidad y las pruebas periódicas de sus medidas.

Cómo gestiona Passwork la ubicación de los datos y el acceso

Passwork Self-hosted funciona sobre infraestructura que usted controla: servidores on-premises, una nube privada o una red aislada. La bóveda, las claves y las copias de seguridad se ubican donde usted las ponga, de modo que su equipo decide dónde vive cada zona. Las respuestas siguientes siguen las seis zonas y las preguntas planteadas más arriba.

Passwork se instala con Docker en Linux (la vía recomendada), con un script de PowerShell en Windows Server, o manualmente, y los paquetes sin conexión cubren las redes aisladas. Las guías técnicas de Passwork explican cada vía.

Contenido de la bóveda y claves (zonas 1 y 2). Los datos se cifran en el cliente con AES-256, por lo que el servidor solo almacena texto cifrado y material de claves cifrado. La clave maestra se deriva con PBKDF2 y nunca sale del dispositivo del usuario en texto claro. Una segunda capa independiente de AES-256 protege la base de datos en el servidor.

La arquitectura de conocimiento cero decide quién puede leer los datos: solo los usuarios que poseen las claves, de modo que tampoco sus propios administradores pueden leer el contenido de la bóveda. La recuperación se realiza mediante una cuenta de recuperación preconfigurada cuya contraseña maestra usted almacena fuera de línea, y usted decide quién la posee.

Datos de servicio (zona 3). El registro de actividad recoge las acciones de usuarios, administradores y del sistema, y sus pistas de auditoría están listas para integrarse con un SIEM. Los nombres de registros y carpetas, la estructura de acceso y los metadatos de auditoría residen en el servidor, así que incorpórelos a su RoPA. Usted define la política de conservación y mantiene los registros en su propio almacenamiento.

Copias de seguridad y réplicas (zona 4). Los conjuntos de réplicas de MongoDB con tres o más miembros votantes, junto con servidores de aplicación escalados horizontalmente, dan al servicio tolerancia a fallos para más de 10 000 usuarios. Tareas programadas en segundo plano crean y rotan los archivos de copia de seguridad, y usted elige dónde se almacenan.

Cachés de los clientes y almacenes sin conexión (zona 5). El modo sin conexión es de solo lectura y debe activarse voluntariamente en dos niveles: el usuario marca un registro y, después, activa el modo sin conexión en un dispositivo concreto. Los administradores controlan qué roles pueden usarlo, el número máximo de registros por dispositivo y el tiempo máximo sin sincronizar antes de un borrado automático. Las descargas y visualizaciones sin conexión se sincronizan con el registro de actividad y el panel de seguridad cuando el dispositivo vuelve a conectarse. 

Subencargados (zona 6). Un despliegue autoalojado no tiene ningún subencargado alojado por un proveedor. Su lista de proveedores se limita a sus propios proveedores de alojamiento y de copias de seguridad, y se les aplican las mismas preguntas anteriores. Un proveedor de nube privada que opere la bóveda por usted es su encargado del tratamiento y necesita su propio DPA.

El acceso sigue el principio de mínimo privilegio. El control de acceso basado en roles (RBAC) define los niveles de acceso para bóvedas y carpetas, la sincronización de grupos de LDAP y Active Directory traslada los cambios del directorio a Passwork, y el SSO mediante SAML gestiona el inicio de sesión. Passwork está certificado según ISO 27001, se somete a pruebas a través de HackerOne, y su código fuente está disponible para auditoría independiente.

Paquete de evidencias del RGPD para la gestión de contraseñas

El paquete de evidencias de 8 puntos es el conjunto de documentos que debería tener antes de una auditoría del RGPD de su gestor de contraseñas. Cubre los registros de tratamiento, las condiciones del proveedor, las evaluaciones de transferencia, las ubicaciones de las copias de seguridad, las revisiones de acceso y los procedimientos ante vulneraciones. Los puntos 1 a 6 corresponden a zonas individuales, mientras que los puntos 7 y 8 cubren el acceso y la gestión de vulneraciones en todas ellas.

• Entrada del registro de actividades de tratamiento del gestor de contraseñas, con las seis zonas (artículo 30)
• DPA firmado que cubra las condiciones del artículo 28(3), si un proveedor o proveedor de alojamiento trata alguna zona
• Lista actualizada de subencargados y la cláusula de aviso de cambios, en la misma condición
• Evaluación de impacto de la transferencia, si alguna zona afecta a un tercer país (capítulo V)
• Evaluación de impacto relativa a la protección de datos, si su revisión de riesgos la exige (artículo 35)
• Mapa de copias de seguridad y réplicas con ubicaciones y condiciones de eliminación
• Revisión de accesos de los permisos de la bóveda, realizada a partir de exportaciones del registro de auditoría
• Un procedimiento de vulneraciones de 72 horas que indique quién decide y quién notifica (artículo 33)

El RGPD no fija un intervalo concreto para las revisiones de acceso. Una cadencia trimestral es habitual, así que establezca una que se ajuste a su riesgo y documéntela.

El registro de auditoría es la evidencia que respalda los puntos 7 y 8. Muestra quién accedió a cada credencial y cuándo, lo que ayuda a delimitar el alcance de una vulneración y a valorar si pueden verse afectados datos personales. Expórtelo a su SIEM para que sobreviva a la bóveda y alimente el registro de vulneraciones que exige el artículo 33(5).

Por dónde empezar con la gestión de contraseñas conforme al RGPD

Una gestión de contraseñas conforme al RGPD empieza por hacer coincidir el despliegue con los datos que no puede permitir que salgan de su jurisdicción. Después, mantenga un contrato o un registro para cada zona que gestione un proveedor: dónde se ubican el contenido, las claves, los datos de servicio, las copias de seguridad, las cachés y los subencargados, y qué lo cubre a cada uno.

Empiece con una sola página. Dibuje las seis zonas de su gestor de contraseñas actual y marque las que no puede responder. Esas son sus primeras preguntas para el proveedor, o sus primeras tareas internas si se autoaloja. Una vez completo el mapa, la guía de seguridad de contraseñas del RGPD cubre la siguiente capa: normas de contraseñas y prácticas del personal.

Preguntas frecuentes

Soberanía de los datos y gestión de contraseñas: Mantener las credenciales donde deben estar

La soberanía de los datos de las credenciales exige tres controles (ubicación, cifrado, acceso), no solo el cumplimiento del RGPD. Compara los modelos on-premise, air-gapped y de nube en la UE, mostrando dónde una arquitectura de conocimiento cero como la de Passwork cierra realmente la brecha de soberanía.

PassworkPasswork Team

¿Qué es el cifrado de conocimiento cero? Cómo funciona en 5 minutos

El cifrado de conocimiento cero significa que el servidor nunca posee sus claves de descifrado, solo el texto cifrado. Descubra cómo funciona la cadena de claves, contra qué protege, qué no protege y cómo verificar la afirmación de un proveedor.

PassworkPasswork Team

Modelos de despliegue de gestores de contraseñas: Nube, autoalojado e híbrido comparados

Elegir dónde ejecutar su gestor de contraseñas importa tanto como elegir cuál usar. Esta guía analiza el despliegue en la nube, autoalojado e híbrido, con una matriz de cumplimiento para RGPD, HIPAA y NIS2, y una mirada clara a las ventajas y desventajas de cada modelo.

PassworkAlex Muntyan

The General Data Protection Regulation (GDPR), the EU's data protection law, requires a lawful transfer mechanism for sending personal data outside the European Economic Area (EEA, the EU plus Iceland, Liechtenstein and Norway), and security measures that fit the risk. For GDPR-compliant password management, know every place your credential data exists and hold proof for each one.

Your credentials can be stored in a Frankfurt data centre and still fall under a foreign court order if the provider is subject to a non-EU jurisdiction. An "EU hosted" label also says nothing about where the backups are. This article introduces the six-zone credential data map: the places where an enterprise password manager keeps data, the GDPR article each place triggers, and the evidence you need to hold. It ends with an 8-point evidence pack you can check before an audit.

What GDPR-compliant password management requires

GDPR requires personal data to be processed securely, built with data protection from the start, and protected by measures that fit the risk. 

GDPR-compliant password management means you can show that credential data is encrypted, reachable only by people who need it, logged, and covered by the right contracts and records wherever it is stored.

The law sets the outcome (Articles 5(1)(f), 25 and 32). You choose the controls and prove they work (Article 5(2)). In practice, that breaks down into five requirements:

• Encrypt stored credentials. Article 32(1)(a) names "the pseudonymisation and encryption of personal data" as an appropriate measure.
• Limit access by role (RBAC). Each person signs in under their own account and sees only what their job needs, even when the credential they open is shared. This is data protection by design (Article 25) applied to access.
• Keep the service available and tested. Article 32(1)(b) to (d) covers resilience, restoring access after an incident and regular testing of your measures.
• Record who opened what. An access log shows which credentials were reached and when. It is the evidence you need to judge whether a breach affected personal data (Article 33).
• Document every place the data lives. That means a record of processing, a contract with each outside party that handles the data, and a lawful mechanism for any transfer outside the EEA.

These duties reach passwords for two reasons. A credential record normally names an employee or links to one, which makes it personal data (Article 4(1): any information relating to an identifiable person). The credentials also open other systems, such as HR, CRM and customer databases, where personal data is stored. Article 32(2) requires you to assess the risk of unauthorised access to personal data, so a breach of the password manager is a breach path into every system it unlocks. Encryption lowers the risk without taking the record out of scope. 

Your organisation is the controller for the vault, the party that decides why and how the credential data is used. A vendor or hosting provider that runs or supports it on your instructions is a processor, and Article 28 requires a contract with it. Article 30 requires you to keep a record of processing activities (RoPA) that lists the recipients, locations and transfers for this processing. Finding those locations is the first job.

Residency, sovereignty and jurisdiction are three different things

Data residency is where your data is physically stored. Data sovereignty means the data is subject to the laws and legal control of a chosen country. Jurisdiction is which courts and authorities can issue orders to the vendor's company. A vendor subject to US law can store your vault in Germany and still receive US legal demands.

The CLOUD Act lets US authorities require providers of electronic communication or remote computing services under US jurisdiction to hand over data in their possession, custody or control, even when it is stored abroad. A vendor that is a US company or has a US parent may therefore face such demands while your vault sits in an EU region. Whether a given vendor falls within the statute is a question for your legal team.

GDPR contains no general data-localisation rule. It regulates transfers to third countries in Chapter V (Articles 44 to 50), and remote access from outside the EEA, such as vendor support, can count as a transfer. Some national and sector rules add localisation requirements of their own, so check the ones that apply to you.

Transfers outside the EEA: Which mechanisms apply

Chapter V of GDPR requires a lawful transfer mechanism and safeguards that hold in the destination country. Remote support access from outside the EEA to a password vault hosted inside it counts as a transfer, so a hosting region alone does not settle the question. Three routes exist, and each applies in a different situation.

• Adequacy decision (Article 45). The European Commission has ruled that the destination country's protection is equivalent. The EU-US Data Privacy Framework decision of 10 July 2023 covers only US companies that have self-certified, so check the vendor's entry on the framework list. Earlier EU-US frameworks were struck down in court, and the current one has been challenged, so keep standard contractual clauses as a fallback in the DPA.
• Appropriate safeguards (Article 46). Usually standard contractual clauses (SCCs), model contract terms approved by the Commission, plus a transfer impact assessment (TIA). The TIA checks whether the destination country's law lets authorities access the data. It follows from the Schrems II ruling and the EDPB's Recommendations 01/2020.
• Derogations (Article 49). Narrow exceptions, such as explicit consent after the individual is told of the risks. They suit occasional transfers and do not support routine vendor processing.

An EU hosting region lowers risk without removing it. Support staff outside the EEA, metadata handled elsewhere and a non-EEA parent company with access can each create a transfer. A foreign authority's power to order a parent to disclose data is a separate jurisdiction risk (see the residency section above). Treat the region as one input to your TIA, not as its conclusion.

The six-zone credential data map

The six-zone credential data map splits an enterprise password manager into six places where credential data exists. Each zone can sit in a different country and carries its own GDPR duty, so checking only "the server" misses copies you are responsible for.

A password manager is a system of copies. You hold some of them, the vendor holds others, and the vendor's suppliers hold the rest. Which copies sit with you depends on the deployment model. In a self-hosted deployment you are the operator of every zone, so each question below applies to your own teams and hosting providers instead of a vendor.

Each zone also triggers a different duty. Backups raise deletion duties at contract end (Article 28(3)(g)), and suppliers raise duties that must pass down the chain (Article 28(4)). The next six subsections cover each zone and what to ask for.

Zone 1: Stored credentials

Stored credentials are the content users store: logins, notes, attachments and the secrets behind one-time codes. With client-side encryption, it reaches the server as ciphertext, data that is unreadable without the key. A stolen copy of the database then exposes only unreadable secrets, provided the key that unwraps the encrypted private key stays on the user's device (see Zone 2).

Encrypted credentials are still personal data when they relate to an identifiable person, so Zone 1 stays in scope. Article 32(1)(a) lists encryption as an example of an appropriate measure, and it lowers the risk. In your RoPA entry for the password manager, record this zone's location and encryption method.

Record names, folder structure and audit metadata are stored separately and belong to Zone 3. Give them their own RoPA line with the same location and access details.

Zone 2: Key material

Key material is the set of cryptographic keys that unlock stored credentials. Whoever holds the keys can read the data, wherever the ciphertext sits, so key location and key holders matter as much as server location. Article 32(1)(a) makes encryption appropriate only when the keys are controlled as carefully as the data. 

The chain runs master password, master key, private key, vault keys, record keys. The user's master password derives the master key through a function such as PBKDF2, which makes password guessing slow. That key decrypts a private key, which decrypts vault keys, which in turn unlock the keys of individual records.

The server stores the private key and vault keys in encrypted form. The key that decrypts them stays on the user's device, so a copy of the database alone does not give access.

Recovery is the one key path worth mapping separately. Some designs include a recovery account or escrow key so an organisation can restore access after a lost master password. Whoever holds that key can also reach plaintext, so treat it like any other key: who holds it, where it is stored, and which courts can compel its holder. Our guide to what zero-knowledge encryption does and does not protect explains the mechanics.

Zone 3: Service data

Service data is everything the system records about use rather than content. Client-side encryption does not cover it, so the operator can usually read it. That makes it personal data in its own right and the part of the system a legal demand can reach without touching the encryption. It typically includes:

• Account identities, email addresses and billing records
• Sign-in IP addresses, device identifiers and access timestamps
• Audit logs, plus record names and folder structure if the product does not encrypt them

Three duties apply. Logs are your evidence for judging a breach (Articles 32 and 33). Retention must be limited to what you need (Article 5(1)(e)). Employees can request their own data (Article 15). In a self-hosted deployment, you hold this zone yourself.

Zone 4: Backups, replicas and disaster recovery

Backups, replicas and disaster recovery (DR) sites are the copies of credential data that live outside the primary server. Each copy can sit in a different country and under a different operator, so each needs its own answer on location, encryption and deletion.

Backups are stored copies for restoring data. Replicas are live copies on other servers. Disaster recovery (DR) sites are standby locations. They support availability and recovery (Article 32(1)(b) and (c)), but every extra copy widens the attack surface and the set of jurisdictions that apply. Ask three things:

• Where is each backup and replica stored, and does any copy leave the EU or EEA? A copy in a third country can count as a transfer under Chapter V.
• Are backups encrypted, and are the keys kept apart from the data?
• After the contract ends, how many days until the last copy is gone, and how do you verify it?

Article 28(3)(g) requires the processor, at your choice, to delete or return all personal data when the services end, and to delete existing copies unless the law requires storage. Backups fall under that duty. In practice they often expire on a rotation cycle, so the retention window is the figure to get in writing.

Zone 5: Client caches and offline stores

Some data leaves the server by design. Desktop and mobile apps may keep offline copies, browser extensions may keep a session or unlock key, and users can export vault files. Each is a copy outside your central controls and travels wherever the employee's device does.

This is the zone where your own policy matters most. Decide whether offline mode is allowed, require disk encryption through mobile device management (MDM), and restrict who can export. Treat exports with the most care, since a CSV file is readable by anyone who opens it. Ask the vendor whether administrators can limit offline mode by role, whether cached data wipes itself after a set period, and whether offline use and exports are logged.

A lost device with a vault copy is a risk under Article 32(2), which names loss and unauthorised disclosure, and may trigger the breach-notification duties in Articles 33 and 34. List endpoints and approved export locations in your RoPA.

Zone 6: Sub-processor and support access

Sub-processors are the suppliers a vendor uses to deliver the service, such as hosting, email delivery, monitoring and support tooling. Under Article 28(2) and 28(4), the processor needs your authorisation to engage them and must pass the same data protection duties down the chain.

Third parties were involved in 48% of breaches in Verizon's 2026 DBIR, a 60% rise on the previous year. The report groups these cases into three archetypes: a vendor in your software supply chain, a vendor hosting your data in its environment, and a vendor with a connection to your environment. A hosted password manager is the second kind, and a support or integration link into your systems can make it the third. Check the vendor's suppliers as closely as its product.

Ask for four things:

• A current list of sub-processors and the country each operates in
• Advance notice of changes, with a right to object
• Who on the vendor's support team can see service data (Zone 3), and under what approval
• Whether any sub-processor or support route can touch key material (Zone 2)

Zone-to-article map: The obligation and the evidence

The zone-to-article map pairs each of the six credential zones with the GDPR provision it triggers, the document that proves compliance, and the party who owns it. Use it as the skeleton for your RoPA entry on the password manager, and fill the evidence column before an auditor asks. The evidence pack at the end lists the same documents as a checklist.

The split decides who notifies. Under Article 33, the controller notifies the supervisory authority within 72 hours of becoming aware of a breach, where feasible. The processor must tell you "without undue delay", which sets no number, so write a notification window into the DPA. When you self-host, you are both controller and operator, and the Owner column collapses to your own teams.

The DPA you need from a password manager vendor

A data processing agreement (DPA) is the contract that Article 28(3) requires between a controller and a processor. For a password manager vendor, it must state the subject matter, duration, nature, purpose, data types and data subject categories, plus eight obligations in points (a) to (h). The EDPB Guidelines 07/2020 on controllers and processors explain each one.

The audit row needs the closest reading. Article 28(3)(h) requires the contract to give you the information that proves compliance and to allow audits, including inspections. If the vendor won't open its infrastructure to on-site inspection, the contract should state what replaces it.

The evidence you review then includes the sub-processor list, a transfer assessment and the audit reports the contract entitles you to. Add your own vault logs, exported to a SIEM (a system that collects and analyses security logs).

Deployment models for GDPR-compliant password management

Your deployment model decides which of the six zones your team controls. A vendor cloud leaves most zones with the vendor, an EU-region cloud narrows where they sit, and self-hosting moves them onto your infrastructure and your duties list. Air-gapped setups go furthest and add offline update and log handling.

A vendor-managed service gives you less control over export formats and exit timing. Before you sign, check how you would leave: which formats you can export, and the deadline for deleting backups under Article 28(3)(g).

Self-hosting and GDPR: Which duties you take on

Self-hosting moves GDPR duties from a vendor contract into your own operating procedures. You control where every zone sits and who operates it, which can remove the processor relationship for the vault itself. You also become the operator, so you carry the evidence yourself. Our on-premise password manager page covers the deployment option.

What you gain:

• Control over where every zone sits, including backups
• No transfer to a vendor and no sub-processor chain for the vault itself

What you now owe:

• Backup and replica locations, tested restores and a retention schedule
• Key recovery procedures, patching and high availability
• An updated record of processing activities (Article 30)
• Your own breach detection and notification process (Article 33)

Hypothetical example: a team restores a vault after a server crash and finds that the nightly backup job has been writing to storage in a second country, set up years earlier by someone who has since left. The vault was on-premises, but one copy never was. That copy is a transfer question under Chapter V. A zone-by-zone check finds it before an incident does.

Insider risk stays with you. Client-side encryption means administrators can't read vault contents, but they can still delete data, copy ciphertext and backups, change configuration or edit logs. Separate duties and log administrator actions.

Air-gapped deployments add another duty. With no internet connection, you apply updates and move logs manually. Isolation doesn't remove vulnerabilities, and the media you carry in becomes the way an update reaches the system.

Article 32(1) requires measures appropriate to the risk. Document who approves an update package, how you verify its integrity before import, how often logs leave the network and who handles the media. Test the restore procedure too, since 32(1)(c) and (d) cover restoring availability and regularly testing your measures.

How Passwork handles data location and access

Passwork self-hosted runs on infrastructure you control: on-premises servers, a private cloud or an air-gapped network. The vault, the keys and the backups sit where you put them, so your team decides where each zone lives. The answers below follow the six zones and the questions asked above.

Passwork installs with Docker on Linux (the recommended path), with a PowerShell script on Windows Server, or manually, and offline packages cover air-gapped networks. The Passwork tech guides cover each route.

Vault payload and keys (zones 1 and 2). Data is encrypted on the client with AES-256, so the server stores only ciphertext and encrypted key material. The master key is derived with PBKDF2 and never leaves the user's device in plaintext. A second, independent AES-256 layer protects the database on the server.

Zero-knowledge architecture decides who can read the data: only the users who hold the keys, so your own administrators can't read vault contents either. Recovery runs through a pre-provisioned recovery account whose master password you store offline, and you decide who holds it.

Service data (zone 3). The Activity Log records user, admin and system actions, and its audit trails are ready for SIEM integration. Record and folder names, access structure and audit metadata sit on the server, so list them in your RoPA. You set the retention policy and keep the logs on your own storage.

Backups and replicas (zone 4). MongoDB replica sets with three or more voting members, together with horizontally scaled application servers, give the service fault tolerance for 10,000+ users. Scheduled background tasks create and rotate backup archives, and you choose where they are stored.

Client caches and offline stores (zone 5). Offline mode is read-only and opt-in at two levels: the user marks a record, then enables offline on a specific device. Administrators control which roles may use it, the maximum records per device and the maximum unsynced time before an automatic wipe. Offline downloads and views sync to the Activity Log and the Security Dashboard when the device reconnects. 

Sub-processors (zone 6). A self-hosted deployment has no vendor-hosted sub-processor. Your supplier list is limited to your own hosting and backup providers, and the same questions above apply to them. A private-cloud host that runs the vault for you is your processor and needs its own DPA.

Access follows least privilege. Role-based access control (RBAC) sets access levels for vaults and folders, LDAP and Active Directory group sync carries directory changes into Passwork, and SAML SSO handles sign-in. Passwork is ISO 27001 certified, tested through HackerOne, and its source code is available for independent audit.

GDPR evidence pack for password management

The 8-point evidence pack is the set of documents you should hold before a GDPR audit of your password manager. It covers processing records, vendor terms, transfer assessments, backup locations, access reviews and breach procedures. Items 1 to 6 map to individual zones, while items 7 and 8 cover access and breach handling across all of them.

• Record of processing activities entry for the password manager, listing all six zones (Article 30)
• Signed DPA covering the Article 28(3) terms, if a vendor or hosting provider processes any zone
• Current sub-processor list and the change-notice clause, under the same condition
• Transfer impact assessment, if any zone touches a third country (Chapter V)
• Data protection impact assessment, if your risk review requires one (Article 35)
• Backup and replica map with locations and deletion terms
• Access review of vault permissions, run from audit log exports
• A 72-hour breach procedure that names who decides and who notifies (Article 33)

GDPR sets no fixed interval for access reviews. Quarterly is a common cadence, so set one that matches your risk and document it.

The audit log is the evidence behind items 7 and 8. It shows who accessed which credential and when, which helps you scope a breach and judge whether personal data may be affected. Export it to your SIEM so it outlives the vault and feeds the breach record required by Article 33(5).

Where to start with GDPR-compliant password management

GDPR-compliant password management starts with matching the deployment to the data you cannot let leave your jurisdiction. Then hold a contract or record for every zone a vendor handles: where the payload, keys, service data, backups, caches and sub-processors sit, and what covers each.

Start with a single page. Draw the six zones for your current password manager and mark the ones you cannot answer. Those are your first vendor questions, or your first internal tasks if you self-host. Once the map is complete, the GDPR password security guide covers the next layer: password rules and staff practice.

Frequently asked questions

Data sovereignty and password management: Keeping credentials where they belong

Data sovereignty for credentials requires three controls (location, encryption, access) not just GDPR compliance. Compares on-premise, air-gapped, and EU cloud models, showing where zero-knowledge architecture like Passwork’s actually closes the sovereignty gap.

PassworkPasswork Team

What is zero-knowledge encryption? How it works in 5 minutes

Zero-knowledge encryption means the server never holds your decryption keys, only ciphertext. Learn how the key chain works, what it protects against, what it doesn’t, and how to verify a vendor’s claim.

PassworkPasswork Team

Password manager deployment models: Cloud, self-hosted, and hybrid compared

Choosing where to run your password manager matters as much as choosing which one. This guide breaks down cloud, self-hosted, and hybrid deployment — with a compliance matrix for GDPR, HIPAA, and NIS2, and a clear look at the trade-offs each model carries.

PassworkAlex Muntyan

Escolher um gestor de credenciais para uma empresa europeia em 2026 é tanto uma decisão de conformidade como uma decisão de produto. 

O abuso de credenciais continua a ser uma das vias de entrada mais comuns nos ambientes empresariais. O Data Breach Investigations Report de 2026 da Verizon confirma que 50 % das vítimas de ransomware registaram um evento de credenciais ou de infostealer nos 95 dias anteriores ao ataque. 

Ao mesmo tempo, a aplicação do RGPD tem consequências reais. Em abril de 2026, o Garante italiano multou a empresa de consultoria Ambrosetti em 85 000 euros por armazenar palavras-passe como texto em claro e recorrer a hashing MD5, invocando expressamente o artigo 32.º do RGPD como fundamento. A NIS2 deixou de ser um projeto: 23 dos 27 Estados-Membros da UE já a transpuseram para o direito nacional, segundo o rastreador de transposição da ECSO. 

Ao avaliar soluções como o Passwork e o 1Password, os fatores que vão além das funcionalidades começam a ter peso. Este artigo compara ambos os produtos nessa perspetiva: jurisdição, soberania de dados, flexibilidade de implementação, preparação para auditorias, conformidade a longo prazo com o RGPD e a NIS2, bem como custo total de propriedade.

Pontos principais

• Ambas as plataformas oferecem gestão de palavras-passe empresarial, mas seguem abordagens arquitetónicas diferentes. O 1Password é um serviço baseado na cloud, assente no seu modelo de segurança Secret Key, enquanto o Passwork oferece implementação autoalojada com cifragem AES-256 do lado do cliente.
• O modelo de implementação determina quem controla a infraestrutura e quem é responsável por ela. Numa implementação autoalojada, a organização gere o ambiente. Num serviço SaaS, o fornecedor opera a infraestrutura e permanece sujeito às leis da sua própria jurisdição.
• A residência de dados e a soberania de dados abordam aspetos diferentes da governação de dados. Escolher um centro de dados na UE determina onde os dados são armazenados. Por si só, isso não determina a legislação de que país pode aplicar-se ao fornecedor do serviço.
• O RGPD e a NIS2 centram-se na forma como as organizações protegem e gerem o acesso às credenciais. As organizações devem ser capazes de demonstrar controlos técnicos adequados, gestão de acessos, registo de eventos e provas de auditoria.
• Com 100 utilizadores, a licença padrão do Passwork custa 3600 €/ano, contra cerca de 9588 USD/ano do 1Password Business. O Passwork custa 3 €/utilizador/mês (licença padrão) ou 4,5 €/utilizador/mês (licença avançada). O 1Password Business custa 7,99 USD/utilizador/mês. Os escalões Enterprise têm preço sob consulta em ambos os casos.
• Escolher o 1Password se a equipa privilegia a conveniência operacional e uma experiência cloud cuidada em detrimento de uma soberania de dados estrita. Escolher o Passwork se a organização está sujeita ao RGPD, à NIS2 ou ao DORA e precisa de demonstrar que os dados de credenciais nunca saem da sua própria infraestrutura.

O campo de batalha da conformidade: Residência de dados vs. soberania de dados

As organizações europeias que avaliam gestores de palavras-passe têm de distinguir entre residência de dados e soberania de dados. A residência de dados define onde os dados são armazenados. A soberania de dados define o sistema jurídico que os rege. Uma solução baseada na cloud pode oferecer residência de dados na UE e, ainda assim, estar sujeita a uma jurisdição fora da UE. As soluções autoalojadas eliminam essa lacuna ao manter os dados de credenciais inteiramente dentro da infraestrutura da própria organização, sob um único quadro jurídico previsível.

1Password oferece residência de dados na UE: os clientes podem selecionar uma região de alojamento europeia e os dados dos cofres ficam em servidores na UE. No entanto, por si só, isso não resolve todas as preocupações jurisdicionais das organizações com requisitos rigorosos de soberania.

O que significa o acesso transfronteiriço a dados para os fornecedores de cloud

Quando um gestor de credenciais baseado na cloud é operado por uma empresa fora da UE, a questão de conformidade essencial não é onde se localizam os servidores, mas que sistema jurídico pode obrigar essa empresa a divulgar dados.

Qualquer fornecedor fora da UE pode receber pedidos legais das autoridades da sua jurisdição de origem. A lei aplicável depende do local onde o fornecedor está constituído, e não do local onde os dados são armazenados.

O U.S. CLOUD Act (2018) é o exemplo mais conhecido. Permite que as autoridades policiais dos EUA exijam que os fornecedores constituídos nos EUA forneçam dados armazenados em qualquer parte do mundo.

1Password não é uma empresa dos EUA. A AgileBits Inc. está constituída no Canadá, pelo que o CLOUD Act não se aplica da mesma forma que aos fornecedores norte-americanos. No entanto, o Canadá participa em quadros internacionais de cooperação entre autoridades policiais, como o Five Eyes, o que significa que os pedidos legais transfronteiriços continuam a ser um fator a ter em conta.

Artigo 48.º do RGPD estabelece que uma decisão judicial estrangeira, por si só, não constitui base jurídica válida para a transferência de dados pessoais a partir da UE. Essa restrição aplica-se sobretudo à organização enquanto responsável pelo tratamento de dados.

Tal como qualquer gestor de credenciais baseado na cloud operado por uma entidade fora da UE, o 1Password introduz uma camada de complexidade jurisdicional que uma implementação autoalojada não tem.

Como a implementação on-premise elimina esta lacuna

Passwork baseia-se num modelo autoalojado: nenhum terceiro detém os dados de credenciais da organização. Quando implementado na infraestrutura própria, dentro da jurisdição da UE, o conteúdo dos cofres nunca sai do ambiente da organização. Nenhuma empresa externa pode receber uma ordem de um governo estrangeiro relativa a dados a que não tem acesso. As leis que regem os dados são as da jurisdição onde se encontram os servidores.

O Passwork está disponível como solução autoalojada e numa cloud soberana na UE, o que dá à organização controlo total sobre os dados e a infraestrutura. Conhecer as opções de implementação: passwork.pro

Comparação de funcionalidades: Passwork vs 1Password

Passwork e o 1Password no escalão Business partilham uma base comum: cifragem AES-256, controlo de acesso baseado em funções (RBAC), SSO e ferramentas para programadores. As diferenças surgem ao nível da arquitetura. A implementação autoalojada do Passwork dá à organização controlo direto sobre as chaves de cifragem, os registos de auditoria e o perímetro de administração, sem dependência da infraestrutura do fornecedor nem de ligação de saída a serviços externos.

Arquitetura de segurança

A arquitetura Secret Key do 1Password exige uma chave de 128 bits codificada como uma cadeia de 34 carateres, gerada na configuração do dispositivo, que é combinada com a palavra-passe mestra para derivar a chave de cifragem. Mesmo que os servidores do 1Password fossem comprometidos, seria computacionalmente inviável decifrar os cofres cifrados sem a Secret Key. É um modelo de segurança cloud bem concebido.

O Passwork utiliza cifragem zero-knowledge do lado do cliente numa instância autoalojada. A cifragem e a decifragem ocorrem no cliente (dispositivo do utilizador). O servidor armazena apenas texto cifrado. Como a plataforma é alojada pela própria organização, esta mantém controlo total sobre o servidor de aplicação, as chaves de cifragem e os registos de auditoria. Esta implementação garante um ambiente isolado, sem infraestrutura partilhada, riscos de ambientes multi-tenant nem dependência da gestão de chaves do fornecedor.

Administração empresarial: RBAC, AD/LDAP e SSO

Ambas as plataformas cobrem as funcionalidades de administração empresarial que as equipas de TI esperam.

O 1Password Business inclui aprovisionamento SCIM, integração SSO através do Okta e do Azure AD e uma consola de administração madura. O produto Extended Access Management (disponível como módulo adicional com licença separada) alarga o controlo de confiança no dispositivo e de acesso a aplicações para além do próprio cofre de palavras-passe.

O Passwork oferece RBAC granular, integração nativa com Active Directory e LDAP para aprovisionamento de utilizadores e sincronização de grupos, e SSO SAML. Para simplificar a gestão em grande escala, o Passwork separa o acesso aos dados dos privilégios administrativos através de dois mecanismos distintos:

• Os grupos de utilizadores controlam o acesso aos dados: os administradores atribuem permissões a cofres e pastas ao nível do grupo. Quando os utilizadores são adicionados a um grupo, herdam automaticamente o acesso às palavras-passe e credenciais correspondentes. 
• As funções definem os privilégios do sistema: as funções predefinidas e personalizadas gerem o acesso às definições do sistema, aos diretórios de utilizadores e aos registos de auditoria. Assim, os utilizadores comuns interagem apenas com os cofres que lhes foram atribuídos, enquanto os administradores gerem a infraestrutura sem acesso às palavras-passe propriamente ditas, graças ao modelo Zero-Knowledge.

Para as organizações que utilizam infraestrutura de identidade baseada em AD (a maioria das empresas europeias), a ligação ao LDAP faz com que a integração e a saída de colaboradores sigam os fluxos de trabalho do diretório já existentes. Os grupos de segurança sincronizam-se automaticamente, o que garante que as permissões dos cofres e as funções administrativas permanecem alinhadas com o diretório central da organização.

Uma diferença prática que merece destaque: como o Passwork é autoalojado, a consola de administração, os registos de auditoria e o diretório de utilizadores situam-se todos dentro do perímetro da rede da própria organização. As operações administrativas não dependem do SLA de disponibilidade de um fornecedor.

DevOps e gestão de segredos

O 1Password investiu fortemente em ferramentas para programadores. A sua CLI (op), o Secrets Automation e as integrações nativas com GitHub Actions, Kubernetes e pipelines de CI/CD fazem dele um gestor de segredos competente para equipas cloud-native. A experiência do programador é cuidada.

O Passwork disponibiliza uma REST API completa e ferramentas CLI para fluxos de trabalho DevOps: injeção de segredos em pipelines, rotação programática de credenciais, gestão de chaves de API e de credenciais de bases de dados juntamente com as palavras-passe de utilizadores humanos, num cofre unificado.

Para equipas que operam em ambientes com isolamento físico (air gap) ou em ambientes com perímetro estritamente controlado, a diferença de arquitetura é relevante. O 1Password oferece, de facto, um Connect Server autoalojado que mantém os segredos em cache local e reduz a dependência da API do 1Password, mas a configuração inicial e a sincronização periódica continuam a exigir ligação de saída à infraestrutura cloud do 1Password. 

O Passwork não exige tal dependência em nenhuma fase: todo o conjunto de componentes funciona dentro do perímetro da própria empresa desde o primeiro dia, sem chamadas a serviços externos. Para as organizações em que o tráfego de saída para a cloud de um fornecedor não é permitido por política ou por arquitetura, essa distinção é um requisito obrigatório.

Preparar o futuro: A NIS2 e o mandato pós-quântico de 2027

A NIS2 introduziu uma cláusula que os fornecedores preferiam que passasse despercebida

Artigo 21.º da NIS2 inclui a segurança dos fornecedores de serviços de TIC no registo de riscos da organização. Um gestor de palavras-passe baseado na cloud é um fornecedor de serviços de TIC. Ao abrigo da NIS2, a organização é responsável por avaliar se a postura de segurança desse fornecedor (incluindo a sua jurisdição legal e as obrigações de resposta a incidentes) cumpre o limiar de risco definido.

Se uma violação no fornecedor do gestor de palavras-passe expuser as credenciais da organização, podem ser acionadas do seu lado as obrigações de notificação de incidentes da NIS2: notificação inicial no prazo de 24 horas e relatório detalhado no prazo de 72 horas.

A implementação de uma solução autoalojada altera esse perfil de risco. A superfície de ataque é a infraestrutura da própria organização, regida pelos seus controlos de segurança e auditada pela sua equipa. As avaliações de risco da cadeia de abastecimento exigidas pela NIS2 tornam-se substancialmente mais simples quando a «cadeia de abastecimento» do armazenamento de credenciais é interna.

O mandato da ANSSI para 2027: Resistência à computação quântica

A agência nacional de cibersegurança de França, a ANSSI, anunciou que deixará de certificar produtos de segurança (incluindo gestores de palavras-passe) sem cifragem resistente à computação quântica a partir de 2027. Até 2030, a ANSSI prevê que todas as aquisições empresariais exijam criptografia resistente à computação quântica. Para as organizações em França e em toda a UE, isto cria um prazo de certificação inadiável nos próximos 12–18 meses.

A questão relevante para as equipas de aquisição não é apenas se um fornecedor é compatível com a criptografia pós-quântica (PQC), mas se a organização controla quando e como essa transição ocorre.

Num gestor de palavras-passe baseado na cloud, a migração da camada de cifragem dos cofres ocorre segundo o calendário do fornecedor, numa infraestrutura partilhada. Numa implementação autoalojada, a organização aplica as atualizações criptográficas (incluindo os algoritmos PQC normalizados pelo NIST) ao seu próprio ritmo, sem depender do ciclo de lançamentos de um fornecedor.

Preços e custo total de propriedade

Preços de referência

O 1Password Business custa 7,99 USD por utilizador por mês (com faturação anual). O plano Teams custa 4,99 USD/utilizador/mês. O preço do plano Enterprise é fornecido mediante orçamento personalizado.

Os preços do Passwork estão estruturados para os compradores europeus:

Com 100 utilizadores, a licença padrão do Passwork custa 3600 €/ano, contra cerca de 9588 USD/ano do 1Password Business. A diferença aumenta com a escala.

TCO para além do preço da licença

A implementação on-premise (nas instalações da organização) exige infraestrutura de servidores, manutenção e esforço operacional interno. Para as organizações que já operam infraestrutura própria (a maioria das empresas europeias em setores regulados), o custo marginal de acrescentar uma instância autoalojada do Passwork é baixo. Para as organizações sem presença on-premise, o esforço de infraestrutura é uma consideração real e deve ser dimensionado com realismo antes de se assinar o contrato.

O cálculo do custo total de propriedade (TCO) tem também de incluir uma linha para o risco de conformidade. Uma violação que envolva um repositório de credenciais baseado na cloud pode desencadear as coimas previstas no artigo 83.º do RGPD de até 10 milhões de euros ou 2 % do volume de negócios anual mundial em caso de violação dos requisitos de segurança previstos no artigo 32.º. As coimas do RGPD já ultrapassaram, em termos acumulados, 6,31 mil milhões de euros até 2026. O caso Ambrosetti (85 000 euros por palavras-passe protegidas com hash MD5) ilustra que as autoridades de proteção de dados já auditam diretamente a implementação criptográfica, e não apenas os prazos de notificação de violações.

Veredicto: Que gestor de palavras-passe se adequa a uma organização sediada na UE

A escolha de um gestor de palavras-passe para uso empresarial resume-se a uma pergunta: onde termina o perímetro de conformidade da organização? As equipas cloud-native com ambientes de identidade modernos encontrarão um ajuste natural nas integrações profundas com o ecossistema e numa experiência de utilização multiplataforma. As organizações sujeitas ao RGPD, à NIS2 ou ao DORA têm um requisito adicional e inegociável: o controlo jurisdicional sobre o local onde as credenciais são armazenadas e tratadas. 

Escolher o 1Password Business se:

• A equipa está distribuída globalmente e é cloud-native
• A equipa dá prioridade à experiência do programador e à experiência de utilização multiplataforma em detrimento da arquitetura de conformidade
• O ambiente regulamentar não exige uma soberania de dados estrita
• A organização precisa do Extended Access Management ou de uma integração profunda com um ambiente moderno de identidade na cloud

Escolher o Passwork se:

• A organização está sujeita ao RGPD, à NIS2 ou ao DORA e precisa de demonstrar soberania de dados
• A organização opera em infraestruturas críticas, serviços financeiros, saúde ou setor público
• A organização precisa de integração nativa com AD/LDAP num ambiente de identidade on-premise existente
• A organização prepara-se para a certificação ANSSI ou para a contratação pública na UE
• A equipa de segurança precisa de controlo total sobre a camada de cifragem, os registos de auditoria e a gestão de chaves

Para as empresas europeias em setores regulados, a arquitetura que responde «sim» a todos os cinco critérios é autoalojada, on-premise e livre de conflitos jurisdicionais. 

O Passwork oferece às equipas de TI europeias um cofre de credenciais autoalojado, preparado para o RGPD, com registo de auditoria completo, integração AD/LDAP e cifragem zero-knowledge, tudo dentro da infraestrutura própria. Solicitar uma demonstração ou consultar o guia de implementação autoalojada: passwork.pro

Perguntas frequentes

Die Wahl eines Credential-Managers für ein europäisches Unternehmen im Jahr 2026 ist ebenso eine Compliance-Entscheidung wie eine Produktentscheidung. 

Der Missbrauch von Anmeldedaten bleibt einer der häufigsten Wege in Unternehmensumgebungen. Der Data Breach Investigations Report 2026 von Verizon bestätigt, dass 50 % der Ransomware-Opfer innerhalb von 95 Tagen vor dem Angriff ein Credential- oder Infostealer-Ereignis hatten. 

Gleichzeitig hat die DSGVO-Durchsetzung echte Durchschlagskraft. Im April 2026 verhängte die italienische Garante gegen das Beratungsunternehmen Ambrosetti ein Bußgeld von 85.000 € für die Speicherung von Passwörtern im Klartext und die Verwendung von MD5-Hashing, wobei ausdrücklich auf DSGVO-Artikel 32 als Grundlage verwiesen wurde. NIS2 ist kein Entwurf mehr: 23 von 27 EU-Mitgliedstaaten haben es laut dem ECSO-Transpositions-Tracker in nationales Recht umgesetzt. 

Bei der Bewertung von Lösungen wie Passwork und 1Password spielen Faktoren jenseits der Funktionen eine Rolle. Dieser Artikel vergleicht beide Produkte aus dieser Perspektive: Jurisdiktion, Datensouveränität, Bereitstellungsflexibilität, Audit-Bereitschaft, langfristige Compliance mit DSGVO und NIS2 sowie Gesamtbetriebskosten.

Die wichtigsten Erkenntnisse

• Beide Plattformen bieten Enterprise-Passwortverwaltung, verwenden jedoch unterschiedliche architektonische Ansätze. 1Password ist ein cloudbasierter Dienst, der auf seinem Secret-Key-Sicherheitsmodell aufbaut, während Passwork eine selbstgehostete Bereitstellung mit clientseitiger AES-256-Verschlüsselung bietet.
• Das Bereitstellungsmodell bestimmt, wer die Infrastruktur kontrolliert und wer dafür verantwortlich ist. Bei einer selbstgehosteten Bereitstellung verwaltet Ihre Organisation die Umgebung. Bei einem SaaS-Dienst betreibt der Anbieter die Infrastruktur und unterliegt den Gesetzen seiner eigenen Jurisdiktion.
• Datenresidenz und Datensouveränität adressieren unterschiedliche Aspekte der Daten-Governance. Die Wahl eines EU-Rechenzentrums bestimmt, wo Ihre Daten gespeichert werden. Es bestimmt jedoch nicht allein, welche Landesgesetze auf den Dienstanbieter Anwendung finden können.
• DSGVO und NIS2 konzentrieren sich darauf, wie Organisationen den Zugriff auf Anmeldedaten schützen und verwalten. Organisationen sollten in der Lage sein, angemessene technische Kontrollen, Zugangsverwaltung, Protokollierung und Audit-Nachweise nachzuweisen.
• Bei 100 Benutzern kostet Passwork Standardlizenz 3.600 €/Jahr gegenüber ca. 9.588 $/Jahr für 1Password Business. Passwork wird mit 3 €/Benutzer/Monat (Standardlizenz) oder 4,5 €/Benutzer/Monat (Erweiterte Lizenz) berechnet. 1Password Business kostet 7,99 $/Benutzer/Monat. Enterprise-Stufen werden bei beiden Anbietern individuell angeboten.
• Wählen Sie 1Password, wenn Ihr Team operativen Komfort und eine ausgefeilte Cloud-Erfahrung gegenüber strikter Datensouveränität priorisiert. Wählen Sie Passwork, wenn Ihre Organisation der DSGVO, NIS2 oder DORA unterliegt und nachweisen muss, dass Anmeldedaten niemals Ihre eigene Infrastruktur verlassen.

Das Compliance-Schlachtfeld: Datenresidenz vs. Datensouveränität

Europäische Organisationen, die Passwort-Manager evaluieren, müssen zwischen Datenresidenz und Datensouveränität unterscheiden. Datenresidenz definiert, wo Daten gespeichert werden. Datensouveränität definiert, welches Rechtssystem sie regiert. Eine cloudbasierte Lösung kann EU-Datenresidenz bieten, während sie dennoch einer nicht-europäischen Jurisdiktion unterliegt. Selbstgehostete Lösungen schließen diese Lücke, indem Anmeldedaten vollständig innerhalb der eigenen Infrastruktur der Organisation verbleiben — unter einem einzigen, vorhersehbaren Rechtsrahmen.

1Password bietet EU-Datenresidenz: Kunden können eine europäische Hosting-Region auswählen, und Tresor-Daten befinden sich auf Servern innerhalb der EU. Dies allein löst jedoch nicht alle Jurisdiktionsbedenken für Organisationen mit strengen Souveränitätsanforderungen.

Was grenzüberschreitender Datenzugriff für Cloud-Anbieter bedeutet

Wenn ein cloudbasierter Credential-Manager von einem Unternehmen außerhalb der EU betrieben wird, ist die zentrale Compliance-Frage nicht, wo sich die Server befinden, sondern welches Rechtssystem dieses Unternehmen zur Datenoffenlegung zwingen kann.

Jeder nicht-europäische Anbieter kann rechtmäßige Anfragen von Behörden in seiner Heimatjurisdiktion erhalten. Das anwendbare Recht hängt davon ab, wo der Anbieter eingetragen ist, nicht wo die Daten gespeichert werden.

Der U.S. CLOUD Act (2018) ist das bekannteste Beispiel. Er ermöglicht es US-amerikanischen Strafverfolgungsbehörden, von in den USA eingetragenen Anbietern die Herausgabe von weltweit gespeicherten Daten zu verlangen.

1Password ist kein US-Unternehmen. AgileBits Inc. ist in Kanada eingetragen, sodass der CLOUD Act nicht in gleicher Weise gilt wie für US-Anbieter. Kanada nimmt jedoch an internationalen Rahmenwerken für die Zusammenarbeit der Strafverfolgungsbehörden wie Five Eyes teil, was bedeutet, dass grenzüberschreitende rechtliche Anfragen weiterhin zu berücksichtigen sind.

DSGVO-Artikel 48 besagt, dass eine ausländische Gerichtsentscheidung allein keine gültige Rechtsgrundlage für die Übermittlung personenbezogener Daten aus der EU darstellt. Diese Einschränkung gilt in erster Linie für Ihre Organisation als Verantwortlicher.

Wie jeder cloudbasierte Credential-Manager, der von einer nicht-europäischen Einheit betrieben wird, führt 1Password eine Ebene jurisdiktioneller Komplexität ein, die eine selbstgehostete Bereitstellung nicht hat.

Wie eine On-Premise-Bereitstellung die Lücke schließt

Das selbstgehostete Modell von Passwork bedeutet, dass kein Dritter Ihre Anmeldedaten besitzt. Bereitgestellt auf Ihrer eigenen Infrastruktur innerhalb der EU-Jurisdiktion verlassen Tresorinhalte niemals Ihre Umgebung. Kein externes Unternehmen kann eine ausländische Regierungsanordnung für Daten erhalten, auf die es keinen Zugriff hat. Die Gesetze, die Ihre Daten regieren, sind die Gesetze der Jurisdiktion, in der sich Ihre Server befinden.

Passwork ist als selbstgehostete Lösung und in einer souveränen EU-Cloud verfügbar und gibt Ihnen die volle Kontrolle über Ihre Daten und Infrastruktur. Erkunden Sie die Bereitstellungsoptionen — passwork.pro

Funktionsvergleich: Passwork vs. 1Password

Passwork und 1Password auf der Business-Stufe teilen eine gemeinsame Basis: AES-256-Verschlüsselung, RBAC, SSO und Entwicklertools. Die Unterschiede zeigen sich auf architektonischer Ebene. Die selbstgehostete Bereitstellung von Passwork gibt der Organisation direkte Kontrolle über Verschlüsselungsschlüssel, Audit-Logs und den Admin-Perimeter — ohne Abhängigkeit von Anbieter-Infrastruktur oder ausgehender Konnektivität zu externen Diensten.

Sicherheitsarchitektur

Die Secret-Key-Architektur von 1Password erfordert einen 128-Bit-Schlüssel, der als 34-Zeichen-String codiert ist und bei der Geräteeinrichtung generiert wird. Dieser wird mit dem Masterpasswort kombiniert, um den Verschlüsselungsschlüssel abzuleiten. Selbst wenn die Server von 1Password kompromittiert würden, wäre es rechnerisch nicht machbar, verschlüsselte Tresore ohne den Secret Key zu entschlüsseln. Es ist ein gut konzipiertes Cloud-Sicherheitsmodell.

Passwork verwendet clientseitige Zero-Knowledge-Verschlüsselung auf einer selbstgehosteten Instanz. Ver- und Entschlüsselung erfolgen auf dem Client (Benutzergerät). Der Server speichert nur Chiffretext. Da Sie die Plattform hosten, behalten Sie die vollständige Kontrolle über den Anwendungsserver, Verschlüsselungsschlüssel und Audit-Logs. Diese Bereitstellung garantiert eine isolierte Umgebung, frei von gemeinsam genutzter Infrastruktur, Multi-Tenant-Risiken oder Abhängigkeit von Anbieter-Schlüsselverwaltung.

Enterprise-Administration: RBAC, AD/LDAP und SSO

Beide Plattformen decken die Enterprise-Administrationsfunktionen ab, die IT-Teams erwarten.

1Password Business umfasst SCIM-Provisioning, SSO-Integration über Okta und Azure AD sowie eine ausgereifte Admin-Konsole. Sein Extended Access Management-Produkt (verfügbar als separat lizenziertes Add-on) erweitert Gerätevertrauen und Anwendungszugriffskontrollen über den Passwort-Tresor hinaus.

Passwork bietet granulare rollenbasierte Zugriffskontrolle (RBAC), native Active Directory- und LDAP-Integration für Benutzer-Provisioning und Gruppensynchronisation sowie SAML SSO. Um die Verwaltung im großen Maßstab zu vereinfachen, trennt Passwork den Datenzugriff von administrativen Berechtigungen durch zwei unterschiedliche Mechanismen:

• Benutzergruppen steuern den Datenzugriff — Administratoren weisen Berechtigungen für Tresore und Ordner auf Gruppenebene zu. Wenn Benutzer einer Gruppe hinzugefügt werden, erben sie automatisch den Zugriff auf die entsprechenden Passwörter und Anmeldedaten. 
• Rollen definieren Systemrechte — Vordefinierte und benutzerdefinierte Rollen verwalten den Zugriff auf Systemeinstellungen, Benutzerverzeichnisse und Audit-Logs. Dies stellt sicher, dass Standardbenutzer nur mit ihren zugewiesenen Tresoren interagieren, während Administratoren die Infrastruktur verwalten, ohne unter dem Zero-Knowledge-Modell Zugriff auf tatsächliche Passwörter zu haben.

Für Organisationen, die AD-basierte Identitätsinfrastruktur betreiben (die Mehrheit der europäischen Unternehmen), bedeutet die LDAP-Integration, dass Onboarding und Offboarding über bestehende Verzeichnis-Workflows laufen. Sicherheitsgruppen werden automatisch synchronisiert, sodass Tresor-Berechtigungen und administrative Rollen mit Ihrem zentralen Verzeichnis abgestimmt bleiben.

Ein praktischer Unterschied, der erwähnt werden sollte: Da Passwork selbstgehostet ist, befinden sich Admin-Konsole, Audit-Logs und Benutzerverzeichnis alle innerhalb Ihres eigenen Netzwerkperimeters. Administrative Operationen haben keine Abhängigkeit von einem Verfügbarkeits-SLA des Anbieters.

DevOps und Secrets Management

1Password hat stark in Entwicklertools investiert. Seine CLI (op), Secrets Automation und native Integrationen mit GitHub Actions, Kubernetes und CI/CD-Pipelines machen es zu einem leistungsfähigen Secrets Manager für cloud-native Teams. Die Entwicklererfahrung ist ausgereift.

Passwork bietet eine vollständige REST API und CLI-Tools für DevOps-Workflows: Einspeisung von Secrets in Pipelines, programmatische Rotation von Anmeldedaten, Verwaltung von API-Schlüsseln und Datenbank-Anmeldedaten zusammen mit menschlichen Passwörtern in einem einheitlichen Tresor.

Für Teams, die in air-gapped oder strikt perimeter-kontrollierten Umgebungen arbeiten, ist der architektonische Unterschied relevant. 1Password bietet zwar einen selbstgehosteten Connect Server, der Secrets lokal zwischenspeichert und die Abhängigkeit von der 1Password-API reduziert, aber die Ersteinrichtung und periodische Synchronisation erfordern weiterhin ausgehende Konnektivität zur Cloud-Infrastruktur von 1Password. 

Passwork erfordert zu keinem Zeitpunkt eine solche Abhängigkeit: Der gesamte Stack läuft vom ersten Tag an innerhalb des eigenen Unternehmensperimeters, ohne Aufrufe zu externen Diensten. Für Organisationen, bei denen ausgehender Datenverkehr zur Cloud eines Anbieters durch Richtlinien oder Architektur nicht erlaubt ist, ist dieser Unterschied eine harte Anforderung.

Zukunftssicherheit: NIS2 und das Post-Quantum-Mandat 2027

NIS2 fügte eine Klausel hinzu, die Anbieter lieber übersehen würden

NIS2-Artikel 21 setzt die Sicherheit Ihrer IKT-Dienstleister auf Ihr Risikoregister. Nicht auf deren — auf Ihres. Ein cloudbasierter Passwort-Manager ist ein IKT-Dienstleister. Unter NIS2 ist Ihre Organisation dafür verantwortlich zu bewerten, ob die Sicherheitslage dieses Anbieters — einschließlich seiner rechtlichen Jurisdiktion und Incident-Response-Verpflichtungen — Ihrer Risikoschwelle entspricht.

Wenn ein Sicherheitsvorfall bei Ihrem Passwort-Manager-Anbieter Ihre Anmeldedaten offenlegt, können NIS2-Incident-Reporting-Verpflichtungen auf Ihrer Seite ausgelöst werden: Erstmeldung innerhalb von 24 Stunden, detaillierter Bericht innerhalb von 72 Stunden.

Die Bereitstellung einer selbstgehosteten Lösung verändert dieses Risikoprofil. Die Angriffsfläche ist Ihre Infrastruktur, die von Ihren Sicherheitskontrollen geregelt und von Ihrem Team auditiert wird. NIS2-Lieferketten-Risikobewertungen werden wesentlich einfacher, wenn die „Lieferkette" für die Credential-Speicherung intern ist.

Das ANSSI-Mandat 2027 für quantensichere Kryptographie

Frankreichs nationale Cybersicherheitsbehörde ANSSI kündigte an, ab 2027 keine Sicherheitsprodukte (einschließlich Passwort-Manager) mehr zu zertifizieren, die keine quantenresistente Verschlüsselung haben. Bis 2030 erwartet ANSSI, dass alle Geschäftsbeschaffungen quantensichere Kryptographie erfordern. Für Organisationen in Frankreich und in der gesamten EU schafft dies eine harte Zertifizierungsfrist innerhalb der nächsten 12–18 Monate.

Die relevante Frage für Beschaffungsteams ist nicht nur, ob ein Anbieter PQC unterstützt, sondern ob die Organisation kontrolliert, wann und wie diese Umstellung erfolgt.

Bei einem cloudbasierten Passwort-Manager erfolgt die Migration der Tresor-Verschlüsselungsschicht nach dem Zeitplan des Anbieters, über gemeinsam genutzte Infrastruktur. Bei einer selbstgehosteten Bereitstellung wendet Ihre Organisation kryptographische Updates (einschließlich NIST-standardisierter PQC-Algorithmen) nach Ihrem eigenen Zeitplan an, ohne Abhängigkeit vom Release-Zyklus eines Anbieters.

Preisgestaltung und Gesamtbetriebskosten

Übersicht der Preise

1Password Business wird mit 7,99 $ pro Benutzer pro Monat (jährliche Abrechnung) berechnet. Der Teams-Plan liegt bei 4,99 $/Benutzer/Monat. Enterprise-Preise erfordern ein individuelles Angebot.

Die Preisgestaltung von Passwork ist auf europäische Käufer ausgerichtet:

Bei 100 Benutzern kostet Passwork Standardlizenz 3.600 €/Jahr gegenüber 1Password Business mit etwa 9.588 $/Jahr. Die Differenz wächst mit zunehmender Skalierung.

TCO jenseits der Lizenzgebühr

On-Premise-Bereitstellung erfordert Server-Infrastruktur, Wartung und internen operativen Aufwand. Für Organisationen, die bereits On-Premises-Infrastruktur betreiben (die meisten europäischen Unternehmen in regulierten Sektoren), sind die Grenzkosten für das Hinzufügen einer selbstgehosteten Passwork-Instanz gering. Für Organisationen ohne On-Premises-Präsenz ist der Infrastruktur-Overhead eine echte Überlegung und sollte vor Vertragsunterzeichnung ehrlich eingeschätzt werden.

Die TCO-Berechnung benötigt auch eine Zeile für Compliance-Risiko. Ein Sicherheitsvorfall mit einem cloudbasierten Credential-Speicher kann DSGVO-Artikel 83-Bußgelder von bis zu 10 Millionen € oder 2 % des weltweiten Jahresumsatzes für Verstöße gegen die Sicherheitsanforderungen von Artikel 32 auslösen. DSGVO-Bußgelder haben bis 2026 kumulativ 6,31 Milliarden € überschritten. Der Ambrosetti-Fall (85.000 € für MD5-gehashte Passwörter) zeigt, dass Datenschutzbehörden jetzt die kryptographische Implementierung direkt prüfen — nicht nur Zeitpläne für Benachrichtigungen bei Sicherheitsvorfällen.

Fazit: Welcher Passwort-Manager passt zu EU-basierten Organisationen

Die Wahl eines Passwort-Managers für den Enterprise-Einsatz läuft auf die Frage hinaus: Wo endet Ihr Compliance-Perimeter? Cloud-native Teams mit modernen Identity-Stacks finden eine natürliche Passung in tiefen Ökosystem-Integrationen und plattformübergreifender UX. Organisationen, die unter DSGVO, NIS2 oder DORA operieren, stehen vor einer anderen Einschränkung — nicht Benutzerfreundlichkeit, sondern Jurisdiktion. 

Wählen Sie 1Password Business, wenn:

• Ihr Team global verteilt und cloud-native ist
• Sie Entwicklererfahrung und plattformübergreifende UX über Compliance-Architektur priorisieren
• Ihr regulatorisches Umfeld keine strikte Datensouveränität erfordert
• Sie Extended Access Management oder tiefe Integration mit einem modernen Cloud-Identity-Stack benötigen

Wählen Sie Passwork, wenn:

• Ihre Organisation der DSGVO, NIS2 oder DORA unterliegt und Datensouveränität nachweisen muss
• Sie in kritischer Infrastruktur, Finanzdienstleistungen, Gesundheitswesen oder dem öffentlichen Sektor tätig sind
• Sie AD/LDAP-native Integration innerhalb einer bestehenden On-Premises-Identitätsumgebung benötigen
• Sie sich auf ANSSI-Zertifizierung oder EU-Beschaffung im öffentlichen Sektor vorbereiten
• Ihr Sicherheitsteam die volle Kontrolle über die Verschlüsselungsschicht, Audit-Logs und Schlüsselverwaltung benötigt

Für europäische Unternehmen in regulierten Sektoren ist die Architektur, die bei allen fünf Kriterien „Ja" antwortet, selbstgehostet, On-Premise und jurisdiktionell sauber. 

Passwork bietet europäischen IT-Teams einen selbstgehosteten, DSGVO-konformen Credential-Tresor mit vollständiger Audit-Protokollierung, AD/LDAP-Integration und Zero-Knowledge-Verschlüsselung — alles innerhalb Ihrer eigenen Infrastruktur. Fordern Sie eine Demo an oder erkunden Sie den Leitfaden zur selbstgehosteten Bereitstellung — passwork.pro

Häufig gestellte Fragen

Elegir un gestor de credenciales para una empresa europea en 2026 es tanto una decisión de cumplimiento normativo como una decisión de producto.

El abuso de credenciales sigue siendo una de las vías más comunes de acceso a entornos corporativos. El informe Data Breach Investigations Report 2026 de Verizon confirma que el 50% de las víctimas de ransomware experimentaron un evento relacionado con credenciales o infostealers en los 95 días previos al ataque.

Al mismo tiempo, la aplicación del RGPD tiene consecuencias reales. En abril de 2026, el Garante italiano multó a la consultora Ambrosetti con 85.000 € por almacenar contraseñas en texto plano y usar hash MD5, citando explícitamente el Artículo 32 del RGPD como fundamento. NIS2 ya no es un borrador: 23 de los 27 estados miembros de la UE lo han transpuesto a la legislación nacional, según el rastreador de transposición de ECSO.

Al evaluar soluciones como Passwork y 1Password, los factores más allá de las funcionalidades empiezan a importar. Este artículo compara ambos productos desde esa perspectiva: jurisdicción, soberanía de datos, flexibilidad de despliegue, preparación para auditorías, cumplimiento a largo plazo con RGPD y NIS2, y coste total de propiedad.

Puntos clave

• Ambas plataformas proporcionan gestión de contraseñas empresarial, pero utilizan enfoques arquitectónicos diferentes. 1Password es un servicio basado en la nube construido en torno a su modelo de seguridad Secret Key, mientras que Passwork ofrece despliegue autoalojado con cifrado AES-256 del lado del cliente.
• El modelo de despliegue determina quién controla la infraestructura y quién es responsable de ella. Con un despliegue autoalojado, su organización gestiona el entorno. Con un servicio SaaS, el proveedor opera la infraestructura y permanece sujeto a las leyes de su propia jurisdicción.
• La residencia de datos y la soberanía de datos abordan aspectos diferentes de la gobernanza de datos. Elegir un centro de datos en la UE determina dónde se almacenan sus datos. Por sí solo, no determina qué leyes de qué país pueden aplicarse al proveedor del servicio.
• El RGPD y NIS2 se centran en cómo las organizaciones protegen y gestionan el acceso a las credenciales. Las organizaciones deben poder demostrar controles técnicos apropiados, gestión de accesos, registro de actividad y evidencia de auditoría.
• Con 100 usuarios, Passwork licencia estándar cuesta 3.600 €/año frente a ~9.588 $/año de 1Password Business. Passwork tiene un precio de 3 €/usuario/mes (licencia estándar) o 4,5 €/usuario/mes (licencia avanzada). 1Password Business cuesta 7,99 $/usuario/mes. Los niveles Enterprise tienen precios personalizados en ambos casos.
• Elija 1Password si su equipo prioriza la comodidad operativa y una experiencia en la nube pulida sobre la soberanía de datos estricta. Elija Passwork si su organización está sujeta al RGPD, NIS2 o DORA y necesita demostrar que los datos de credenciales nunca salen de su propia infraestructura.

El campo de batalla del cumplimiento: Residencia de datos vs. soberanía de datos

Las organizaciones europeas que evalúan gestores de contraseñas necesitan distinguir entre residencia de datos y soberanía de datos. La residencia de datos define dónde se almacenan los datos. La soberanía de datos define qué sistema legal los gobierna. Una solución basada en la nube puede ofrecer residencia de datos en la UE mientras sigue estando sujeta a jurisdicción fuera de la UE. Las soluciones autoalojadas eliminan esa brecha al mantener los datos de credenciales completamente dentro de la propia infraestructura de la organización, bajo un marco legal único y predecible.

1Password ofrece residencia de datos en la UE: los clientes pueden seleccionar una región de alojamiento europea, y los datos de la bóveda residen en servidores dentro de la UE. Sin embargo, esto por sí solo no resuelve todas las preocupaciones jurisdiccionales para organizaciones con requisitos estrictos de soberanía.

Qué significa el acceso transfronterizo a datos para los proveedores en la nube

Cuando un gestor de credenciales basado en la nube es operado por una empresa fuera de la UE, la pregunta clave de cumplimiento no es dónde están ubicados los servidores, sino qué sistema legal puede obligar a esa empresa a divulgar datos.

Cualquier proveedor fuera de la UE puede recibir solicitudes legales de las autoridades de su jurisdicción de origen. La ley aplicable depende de dónde está constituido el proveedor, no de dónde se almacenan los datos.

La CLOUD Act de EE. UU. (2018) es el ejemplo más conocido. Permite a las fuerzas del orden estadounidenses exigir a los proveedores constituidos en EE. UU. que entreguen datos almacenados en cualquier parte del mundo.

1Password no es una empresa estadounidense. AgileBits Inc. está constituida en Canadá, por lo que la CLOUD Act no se aplica de la misma manera que a los proveedores estadounidenses. Sin embargo, Canadá participa en marcos de cooperación internacional de aplicación de la ley como Five Eyes, lo que significa que las solicitudes legales transfronterizas siguen siendo una consideración.

El Artículo 48 del RGPD establece que una orden judicial extranjera por sí sola no es una base legal válida para transferir datos personales desde la UE. Esa restricción se aplica principalmente a su organización como responsable del tratamiento de datos.

Como cualquier gestor de credenciales basado en la nube operado por una entidad fuera de la UE, 1Password introduce una capa de complejidad jurisdiccional que un despliegue autoalojado no tiene.

Cómo el despliegue en las instalaciones cierra la brecha

El modelo autoalojado de Passwork significa que ningún tercero tiene sus datos de credenciales. Desplegado en su propia infraestructura dentro de la jurisdicción de la UE, el contenido de las bóvedas nunca abandona su entorno. Ninguna empresa externa puede recibir una orden de un gobierno extranjero para datos a los que no tiene acceso. Las leyes que gobiernan sus datos son las leyes de la jurisdicción donde se encuentran sus servidores.

Passwork está disponible como solución autoalojada y en una nube soberana de la UE, ofreciéndole control total sobre sus datos e infraestructura. Explore las opciones de despliegue — passwork.pro

Comparativa de funcionalidades: Passwork vs 1Password

Passwork y 1Password en el nivel Business comparten una base común: cifrado AES-256, RBAC, SSO y herramientas para desarrolladores. Las diferencias emergen a nivel arquitectónico. El despliegue autoalojado de Passwork otorga a la organización control directo sobre las claves de cifrado, los registros de auditoría y el perímetro de administración sin dependencia de la infraestructura del proveedor ni conectividad saliente a servicios externos.

Arquitectura de seguridad

La arquitectura Secret Key de 1Password requiere una clave de 128 bits codificada como una cadena de 34 caracteres generada en la configuración del dispositivo, combinada con la contraseña maestra, para derivar la clave de cifrado. Incluso si los servidores de 1Password fueran comprometidos, las bóvedas cifradas serían computacionalmente inviables de descifrar sin la Secret Key. Es un modelo de seguridad en la nube bien diseñado.

Passwork utiliza cifrado de conocimiento cero del lado del cliente en una instancia autoalojada. El cifrado y descifrado ocurren en el cliente (dispositivo del usuario). El servidor almacena solo texto cifrado. Dado que usted aloja la plataforma, mantiene control completo sobre el servidor de aplicaciones, las claves de cifrado y los registros de auditoría. Este despliegue garantiza un entorno aislado, libre de infraestructura compartida, riesgos de multitenencia o dependencia de la gestión de claves del proveedor.

Administración empresarial: RBAC, AD/LDAP y SSO

Ambas plataformas cubren las funcionalidades de administración empresarial que los equipos de TI esperan.

1Password Business incluye aprovisionamiento SCIM, integración SSO vía Okta y Azure AD, y una consola de administración madura. Su producto Extended Access Management (disponible como complemento con licencia separada) extiende la confianza de dispositivos y los controles de acceso a aplicaciones más allá de la propia bóveda de contraseñas.

Passwork proporciona control de acceso basado en roles (RBAC) granular, integración nativa con Active Directory y LDAP para aprovisionamiento de usuarios y sincronización de grupos, y SSO SAML. Para simplificar la gestión a escala, Passwork separa el acceso a datos de los privilegios administrativos mediante dos mecanismos distintos:

• Los grupos de usuarios controlan el acceso a datos — Los administradores asignan permisos a bóvedas y carpetas a nivel de grupo. Cuando los usuarios se añaden a un grupo, heredan automáticamente el acceso a las contraseñas y credenciales correspondientes.
• Los roles definen privilegios del sistema — Los roles predefinidos y personalizados gestionan el acceso a la configuración del sistema, directorios de usuarios y registros de auditoría. Esto asegura que los usuarios estándar solo interactúen con sus bóvedas asignadas, mientras que los administradores gestionan la infraestructura sin tener acceso a las contraseñas reales bajo el modelo de conocimiento cero.

Para organizaciones que ejecutan infraestructura de identidad basada en AD (la mayoría de las empresas europeas), la integración LDAP significa que la incorporación y baja de usuarios se ejecuta a través de los flujos de trabajo de directorio existentes. Los grupos de seguridad se sincronizan automáticamente, asegurando que los permisos de bóveda y los roles administrativos permanezcan alineados con su directorio central.

Una diferencia práctica que vale la pena mencionar: debido a que Passwork es autoalojado, la consola de administración, los registros de auditoría y el directorio de usuarios residen dentro de su propio perímetro de red. Las operaciones administrativas no tienen dependencia del SLA de disponibilidad de un proveedor.

DevOps y gestión de secretos

1Password ha invertido fuertemente en herramientas para desarrolladores. Su CLI (op), Secrets Automation e integraciones nativas con GitHub Actions, Kubernetes y pipelines CI/CD lo convierten en un gestor de secretos capaz para equipos cloud-native. La experiencia de desarrollador está pulida.

Passwork ofrece una API REST completa y herramientas CLI para flujos de trabajo DevOps: inyectar secretos en pipelines, rotar credenciales programáticamente, gestionar claves API y credenciales de bases de datos junto con contraseñas humanas en una bóveda unificada.

Para equipos que operan en entornos aislados o estrictamente controlados por perímetro, la diferencia arquitectónica importa. 1Password ofrece un Connect Server autoalojado que almacena secretos en caché localmente y reduce la dependencia de la API de 1Password, pero la configuración inicial y la sincronización periódica todavía requieren conectividad saliente a la infraestructura en la nube de 1Password.

Passwork no requiere tal dependencia en ninguna etapa: toda la pila se ejecuta dentro del propio perímetro de la empresa desde el primer día, sin llamadas a servicios externos. Para organizaciones donde el tráfico saliente a la nube de un proveedor no está permitido por política o arquitectura, esa distinción es un requisito indispensable.

Preparación para el futuro: NIS2 y el mandato post-cuántico de 2027

NIS2 añadió una cláusula que los proveedores preferirían que no notara

El Artículo 21 de NIS2 coloca la seguridad de sus proveedores de servicios TIC en su registro de riesgos. No en el de ellos — en el suyo. Un gestor de contraseñas basado en la nube es un proveedor de servicios TIC. Bajo NIS2, su organización es responsable de evaluar si la postura de seguridad de ese proveedor — incluyendo su jurisdicción legal y obligaciones de respuesta a incidentes — cumple con su umbral de riesgo.

Si una brecha en su proveedor de gestor de contraseñas expone sus credenciales, las obligaciones de notificación de incidentes de NIS2 pueden activarse de su lado: notificación inicial en 24 horas, informe detallado en 72 horas.

Desplegar una solución autoalojada modifica ese perfil de riesgo. La superficie de ataque es su infraestructura, gobernada por sus controles de seguridad, auditada por su equipo. Las evaluaciones de riesgo de la cadena de suministro de NIS2 se simplifican sustancialmente cuando la «cadena de suministro» para el almacenamiento de credenciales es interna.

El mandato de seguridad cuántica de ANSSI para 2027

La agencia nacional de ciberseguridad de Francia, ANSSI, anunció que dejará de certificar productos de seguridad (incluidos los gestores de contraseñas) que carezcan de cifrado resistente a la computación cuántica a partir de 2027. Para 2030, ANSSI espera que todas las adquisiciones empresariales requieran criptografía segura ante amenazas cuánticas. Para organizaciones en Francia y en toda la UE, esto crea un plazo de certificación firme en los próximos 12-18 meses.

La pregunta relevante para los equipos de adquisiciones no es solo si un proveedor soporta PQC, sino si la organización controla cuándo y cómo ocurre esa transición.

Con un gestor de contraseñas basado en la nube, la migración de la capa de cifrado de la bóveda ocurre según el calendario del proveedor, a través de infraestructura compartida. Con un despliegue autoalojado, su organización aplica actualizaciones criptográficas (incluidos los algoritmos PQC estandarizados por NIST) en su propio calendario, sin dependencia del ciclo de lanzamiento de un proveedor.

Precios y coste total de propiedad

Precios principales

1Password Business tiene un precio de 7,99 $ por usuario al mes (facturado anualmente). El plan Teams está en 4,99 $/usuario/mes. Los precios Enterprise requieren una cotización personalizada.

Los precios de Passwork están estructurados para compradores europeos:

Con 100 usuarios, Passwork licencia estándar cuesta 3.600 €/año frente a 1Password Business con aproximadamente 9.588 $/año. La diferencia aumenta a mayor escala.

TCO más allá de la tarifa de licencia

El despliegue en las instalaciones requiere infraestructura de servidores, mantenimiento y gastos operativos internos. Para organizaciones que ya ejecutan infraestructura en sus instalaciones (la mayoría de las empresas europeas en sectores regulados), el coste marginal de añadir una instancia autoalojada de Passwork es bajo. Para organizaciones sin presencia en instalaciones propias, los gastos de infraestructura son una consideración real y deben evaluarse honestamente antes de firmar.

El cálculo del TCO también necesita incluir el riesgo de cumplimiento. Una brecha que involucre un almacén de credenciales basado en la nube puede activar multas del Artículo 83 del RGPD de hasta 10 millones de euros o el 2% de la facturación anual global por violaciones de los requisitos de seguridad del Artículo 32. Las multas del RGPD han superado acumulativamente los 6.310 millones de euros para 2026. El caso Ambrosetti (85.000 € por contraseñas con hash MD5) ilustra que las autoridades de protección de datos ahora auditan la implementación criptográfica directamente, no solo los plazos de notificación de brechas.

Veredicto: Qué gestor de contraseñas se adapta a una organización con sede en la UE

Elegir un gestor de contraseñas para uso empresarial se reduce a la pregunta: ¿dónde termina su perímetro de cumplimiento? Los equipos cloud-native con pilas de identidad modernas encontrarán un ajuste natural en las integraciones profundas del ecosistema y la experiencia de usuario multiplataforma. Las organizaciones que operan bajo RGPD, NIS2 o DORA enfrentan una restricción diferente — no la usabilidad, sino la jurisdicción.

Elija 1Password Business si:

• Su equipo está distribuido globalmente y es cloud-native.
• Prioriza la experiencia de desarrollador y la UX multiplataforma sobre la arquitectura de cumplimiento.
• Su entorno regulatorio no requiere soberanía de datos estricta.
• Necesita Extended Access Management o integración profunda con una pila de identidad en la nube moderna.

Elija Passwork si:

• Su organización está sujeta al RGPD, NIS2 o DORA y necesita demostrar soberanía de datos.
• Opera en infraestructura crítica, servicios financieros, sanidad o sector público.
• Necesita integración nativa AD/LDAP dentro de un entorno de identidad existente en sus instalaciones.
• Se está preparando para la certificación ANSSI o adquisiciones del sector público de la UE.
• Su equipo de seguridad necesita control total sobre la capa de cifrado, los registros de auditoría y la gestión de claves.

Para empresas europeas en sectores regulados, la arquitectura que responde «sí» a los cinco criterios es autoalojada, en las instalaciones y jurisdiccionalmente limpia.

Passwork ofrece a los equipos de TI europeos una bóveda de credenciales autoalojada, preparada para el RGPD, con registro de auditoría completo, integración AD/LDAP y cifrado de conocimiento cero — todo dentro de su propia infraestructura. Solicite una demostración o explore la guía de despliegue autoalojado — passwork.pro

Preguntas frecuentes

Choosing a credential manager for a European enterprise in 2026 is a compliance decision as much as it is a product decision. 

Credential abuse remains one of the most common paths into corporate environments. Verizon's 2026 Data Breach Investigations Report confirms that 50% of ransomware victims had a credential or infostealer event within 95 days before the attack. 

At the same time, GDPR enforcement has real teeth. In April 2026, Italy's Garante fined a consulting firm Ambrosetti €85,000 for storing passwords in cleartext and using MD5 hashing, explicitly citing GDPR Article 32 as the basis. NIS2 is no longer a draft: 23 out of 27 EU member states have transposed it into national law, according to the ECSO transposition tracker. 

When evaluating solutions like Passwork and 1Password, factors beyond features start to matter. This article compares both products from that perspective: jurisdiction, data sovereignty, deployment flexibility, audit readiness, long-term compliance with GDPR and NIS2, and total cost of ownership.

Key takeaways

• Both platforms provide enterprise password management, but they use different architectural approaches. 1Password is a cloud-based service built around its Secret Key security model, while Passwork offers self-hosted deployment with client-side AES-256 encryption.
• Deployment model determines who controls the infrastructure and who is responsible for it. With a self-hosted deployment, your organization manages the environment. With a SaaS service, the provider operates the infrastructure and remains subject to the laws of its own jurisdiction.
• Data residency and data sovereignty address different aspects of data governance. Choosing an EU data center determines where your data is stored. It does not, by itself, determine which country's laws may apply to the service provider.
• GDPR and NIS2 focus on how organizations protect and manage access to credentials. Organizations should be able to demonstrate appropriate technical controls, access management, logging, and audit evidence.
• At 100 users, Passwork Standard costs €3,600/year versus ~$9,588/year for 1Password Business. Passwork is priced at €3/user/month (Standard) or €4.5/user/month (Advanced). 1Password Business is $7.99/user/month. Enterprise tiers are custom-quoted on both sides.
• Choose 1Password if your team prioritizes operational convenience and a polished cloud experience over strict data sovereignty. Choose Passwork if your organization is subject to GDPR, NIS2, or DORA and needs to demonstrate that credential data never leaves your own infrastructure.

The compliance battlefield: Data residency vs. data sovereignty

European organizations evaluating password managers need to distinguish between data residency and data sovereignty. Data residency defines where data is stored. Data sovereignty defines which legal system governs it. A cloud-based solution can offer EU data residency while still being subject to non-EU jurisdiction. Self-hosted solutions eliminate that gap by keeping credential data entirely within the organization's own infrastructure, under a single, predictable legal framework.

1Password offers EU data residency: customers can select a European hosting region, and vault data sits on servers inside the EU. It does not, however, by itself resolve all jurisdictional concerns for organizations with strict sovereignty requirements.

What cross-border data access means for cloud vendors

When a cloud-based credential manager is operated by a company outside the EU, the key compliance question is not where the servers are located, but which legal system can compel that company to disclose data.

Any non-EU provider can receive lawful requests from authorities in its home jurisdiction. The applicable law depends on where the provider is incorporated, not where the data is stored.

The U.S. CLOUD Act (2018) is the best-known example. It allows U.S. law enforcement to require U.S.-incorporated providers to produce data stored anywhere in the world.

1Password is not a U.S. company. AgileBits Inc. is incorporated in Canada, so the CLOUD Act does not apply in the same way it does to U.S. providers. Canada, however, participates in international law enforcement cooperation frameworks such as Five Eyes, meaning cross-border legal requests remain a consideration.

GDPR Article 48 states that a foreign court order alone is not a valid legal basis for transferring personal data from the EU. That restriction primarily applies to your organization as the data controller.

Like any cloud-based credential manager operated by a non-EU entity, 1Password introduces a layer of jurisdictional complexity that a self-hosted deployment does not.

How on-premise deployment closes the gap

Passwork's self-hosted model means no third party holds your credential data. Deployed on your own infrastructure within EU jurisdiction, vault contents never leave your environment. No external company can receive a foreign government order for data it doesn't have access to. The laws that govern your data are the laws of the jurisdiction where your servers sit.

Passwork is available as a self-hosted solution and in a sovereign EU cloud, giving you full control over your data and infrastructure. Explore deployment options — passwork.pro

Feature comparison: Passwork vs 1Password

Passwork and 1Password at the Business tier share a common baseline: AES-256 encryption, RBAC, SSO, and developer tooling. The differences emerge at the architectural level. Passwork’s self-hosted deployment gives the organization direct control over encryption keys, audit logs, and the admin perimeter with no dependency on vendor infrastructure or outbound connectivity to external services.

Security architecture

1Password's Secret Key architecture requires a 128-bit key encoded as a 34-character string generated on device setup, combined with the master password, to derive the encryption key. Even if 1Password's servers were compromised, encrypted vaults would be computationally infeasible to crack without the Secret Key. It is a well-designed cloud security model.

Passwork uses client-side, zero-knowledge encryption on a self-hosted instance. Encryption and decryption happen on the client (user device). The server stores only ciphertext. Because you host the platform, you maintain complete control over the application server, encryption keys, and audit logs. This deployment guarantees an isolated environment, free from shared infrastructure, multi-tenant risks, or reliance on vendor key management.

Enterprise administration: RBAC, AD/LDAP, and SSO

Both platforms cover the enterprise administration features IT teams expect.

1Password Business includes SCIM provisioning, SSO integration via Okta and Azure AD, and a mature admin console. Its Extended Access Management product (available as a separately licensed add-on) extends device trust and application access controls beyond the password vault itself.

Passwork provides granular role-based access control (RBAC), native Active Directory and LDAP integration for user provisioning and group sync, and SAML SSO. To simplify management at scale, Passwork separates data access from administrative privileges through two distinct mechanisms:

• User groups control data access — Administrators assign permissions to vaults and folders at the group level. When users are added to a group, they automatically inherit access to the corresponding passwords and credentials. 
• Roles define system privileges — Predefined and custom roles manage access to system settings, user directories, and audit logs. This ensures standard users only interact with their assigned vaults, while administrators manage the infrastructure without having access to actual passwords under the Zero-Knowledge model.

For organizations running AD-based identity infrastructure (the majority of European enterprises) the LDAP integration means onboarding and offboarding run through existing directory workflows. Security groups sync automatically, ensuring that vault permissions and administrative roles remain aligned with your central directory.

One practical difference worth noting: because Passwork is self-hosted, the admin console, audit logs, and user directory all sit within your own network perimeter. Administrative operations have no dependency on a vendor's availability SLA.

DevOps and secrets management

1Password has invested heavily in developer tooling. Its CLI (op), Secrets Automation, and native integrations with GitHub Actions, Kubernetes, and CI/CD pipelines make it a capable secrets manager for cloud-native teams. The developer experience is polished.

Passwork offers a full REST API and CLI tools for DevOps workflows: injecting secrets into pipelines, rotating credentials programmatically, managing API keys and database credentials alongside human passwords in a unified vault.

For teams operating in air-gapped or strictly perimeter-controlled environments, the architectural difference matters. 1Password does offer a self-hosted Connect Server that caches secrets locally and reduces dependency on the 1Password API, but initial setup and periodic synchronisation still require outbound connectivity to 1Password's cloud infrastructure. 

Passwork requires no such dependency at any stage: the entire stack runs inside company’s own perimeter from day one, with no calls to external services. For organisations where outbound traffic to a vendor's cloud is not permitted by policy or architecture, that distinction is a hard requirement.

Future-proofing: NIS2 and the 2027 post-quantum mandate

NIS2 added a clause vendors would prefer you not notice

NIS2 Article 21 puts the security of your ICT service providers on your risk register. A cloud-based password manager is an ICT service provider. Under NIS2, your organization is responsible for evaluating whether that vendor's security posture (including its legal jurisdiction and incident response obligations) meets your risk threshold.

If a breach at your password manager vendor exposes your credentials, NIS2 incident reporting obligations may be triggered on your side: initial notification within 24 hours, detailed report within 72 hours.

Deploying a self-hosted solution shifts that risk profile. The attack surface is your infrastructure, governed by your security controls, audited by your team. NIS2 supply chain risk assessments become substantially simpler when the "supply chain" for credential storage is internal.

The ANSSI 2027 quantum-safe mandate

France's national cybersecurity agency, ANSSI, announced it will stop certifying security products (including password managers) that lack quantum-resistant encryption starting in 2027. By 2030, ANSSI expects all business procurement to require quantum-safe cryptography. For organizations in France and across the EU, this creates a hard certification deadline within the next 12–18 months.

The relevant question for procurement teams is not only whether a vendor supports PQC, but whether the organization controls when and how that transition happens.

With a cloud-based password manager, the migration of the vault encryption layer occurs on the vendor's schedule, across shared infrastructure. With a self-hosted deployment, your organization applies cryptographic updates (including NIST-standardized PQC algorithms) on your own timeline, without dependency on a vendor's release cycle.

Pricing and total cost of ownership

Headline pricing

1Password Business is priced at $7.99 per user per month (billed annually). The Teams plan sits at $4.99/user/month. Enterprise pricing requires a custom quote.

Passwork's pricing is structured for European buyers:

At 100 users, Passwork Standard runs €3,600/year versus 1Password Business at approximately $9,588/year. The gap widens at scale.

TCO beyond the license fee

On-premise deployment requires server infrastructure, maintenance, and internal operational overhead. For organizations that already run on-premises infrastructure (most European enterprises in regulated sectors) the marginal cost of adding a self-hosted Passwork instance is low. For organizations with no on-premises footprint, the infrastructure overhead is a real consideration and should be scoped honestly before signing.

The TCO calculation also needs a line for compliance risk. A breach involving a cloud-based credential store can trigger GDPR Article 83 fines of up to €10 million or 2% of global annual turnover for violations of Article 32 security requirements. GDPR fines have cumulatively exceeded €6,31 billion by 2026. The Ambrosetti case (€85,000 for MD5-hashed passwords) illustrates that DPAs are now auditing cryptographic implementation directly, not just breach notification timelines.

Verdict: Which password manager fits EU-based organization

Choosing a password manager for enterprise use comes down to the question: where does your compliance perimeter end? Cloud-native teams with modern identity stacks will find a natural fit in deep ecosystem integrations and cross-platform UX. Organizations operating under GDPR, NIS2, or DORA have an additional, non-negotiable requirement: jurisdictional control over where credentials are stored and processed. 

Choose 1Password Business if:

• Your team is globally distributed and cloud-native
• You prioritize developer experience and cross-platform UX above compliance architecture
• Your regulatory environment does not require strict data sovereignty
• You need Extended Access Management or deep integration with a modern cloud identity stack

Choose Passwork if:

• Your organization is subject to GDPR, NIS2, or DORA and needs to demonstrate data sovereignty
• You operate in critical infrastructure, financial services, healthcare, or the public sector
• You need AD/LDAP-native integration within an existing on-premises identity environment
• You are preparing for ANSSI certification or EU public sector procurement
• Your security team needs full control over the encryption layer, audit logs, and key management

For European enterprises in regulated sectors, the architecture that answers "yes" to all five of those criteria is self-hosted, on-premise, and jurisdictionally clean. 

Passwork gives European IT teams a self-hosted, GDPR-ready credential vault with full audit logging, AD/LDAP integration, and zero-knowledge encryption — all within your own infrastructure. Request a demo or explore the self-hosted deployment guide — passwork.pro

Frequently asked questions

Introduction

GDPR password security is an essential component of modern data protection strategies and a key aspect of GDPR compliance. Under the General Data Protection Regulation (GDPR), organizations are legally required to implement special technical and organizational measures to safeguard personal data. Passwords remain the most common authentication mechanism, and they also represent one of the weakest links in information security when poorly managed.

According to Verizon Data Breach Investigations Report 2024, human error, including credential misuse, remains a significant factor in data breaches, accounting for a substantial percentage of incidents. This highlights the critical need for effective employee training in GDPR password security. Strong technical tools are vital, but security gaps quickly appear if employees aren’t properly trained. This article examines best practices for employee training, identifies common mistakes, and demonstrates how business can mitigate risks through practical policies and modern tools.

Why training matters in GDPR password security

GDPR requires organizations to demonstrate accountability. That means it is not enough to set policies. Businesses must prove that employees understand and apply them. Password misuse remains one of the most frequent root causes of data breaches, often associated with weak or reused credentials.

From a regulatory perspective, insufficient password controls can be interpreted as a failure to apply "appropriate technical and organizational measures" under Article 32 of GDPR. This translates into direct financial and reputational risks, making cybersecurity training a critical investment.

Training employees is the bridge between abstract policy and daily practice. By equipping staff with knowledge and tools, companies not only reduce the risk of data breaches and cyberattacks but also create an auditable record of compliance.

GDPR password security training: Best practices

Effective GDPR password security training is not a one-time event but a continuous process. Employees must see security as part of their daily responsibilities rather than an annual compliance requirement. These are practical recommendations for employee training:

Ongoing, concise learning
Short, frequent sessions are far more effective than long, one-off seminars. Use onboarding modules, quarterly refreshers, and targeted updates after incidents. For example, new hires can generate their first password directly in a password manager, immediately experiencing how the system enforces company-wide security policies.

Learn by doing with simulations
Real-world simulations make lessons stick. A phishing exercise or a mock "compromised shared password" scenario shows how a single mistake can endanger the organization. In the Passwork password manager, such training can be replicated when the system flags outdated or reused passwords, prompting employees to walk through the secure update workflow with full audit logging.

Modern and practical password policies
Overly complex rules often push staff into shortcuts. Instead, focus on length, uniqueness, and blocking reuse. Passwork automates this by generating strong, unique passwords and preventing weak combinations, eliminating the burden of memorization and reducing risky workarounds.

Seamless integration with daily workflows
Employees are more likely to follow secure practices when security tools are built into their routine. Passwork integrates with LDAP and SSO, allowing staff to log in with their standard corporate accounts while administrators gain centralized oversight of accounts and groups.

Role-based training and access control
Different departments face different risks: general staff deal with operational routine issues, finance teams — with fraud attempts, and IT teams manage critical systems. Passwork role-based access control (RBAC) allows employees to see firsthand that they have access only to the credentials required for their role, no more.

A no-blame reporting culture
Security only works when staff feel safe reporting mistakes. Passwork provides audit trails and real-time alerts for critical events, enabling quick remediation and turning incidents into learning opportunities instead of sources of punishment.

The most successful programs blend practical exercises, clear communication, and tools that reinforce correct behavior at the point of use. With platforms like Passwork, secure practices become effortless, turning password management from a weak point into a core strength for compliance and resilience.

Common mistakes employees make with passwords

Despite awareness campaigns, many companies continue to face recurring issues in password behavior. These mistakes point out a gap between policy and practice, where employees either misunderstand requirements or prioritize convenience over security. Recognizing these pitfalls is the first step in addressing them through training and enforcement. Even in organizations with formal password policies, employees often fall into predictable traps:

• Reusing passwords across multiple systems
• Choosing weak or guessable patterns such as names, dates, or simple sequences
• Storing credentials insecurely on notes, spreadsheets, or messengers
• Failing to update compromised passwords after breaches
• Bypassing complex policies with shortcuts (e.g., adding "1!" each time)
• Neglecting multi-factor authentication (MFA) setup, even when available, is a common oversight that significantly weakens access control

Passwork helps businesses eliminate these problems systematically. Zero Knowledge architecture and AES-256 encryption ensure data protection by design. LDAP and SSO integration simplify authentication, and RBAC provides granular access control so that employees only see what they are authorized to use. Multi-factor authentication (MFA) further reduces risks if a password is compromised. Built-in audit trails and real-time monitoring enable security leaders to swiftly identify and address issues such as password reuse and weak credential creation. Employees naturally adopt secure practices, closing the gap between policy and daily behavior.

Business risks of poor GDPR password security

Companies that fail to secure passwords face multiple risks:

• Regulatory fines of up to €20 million or 4% of global turnover or non-compliance with GDPR requirements
• Operational disruptions if accounts are locked or compromised
• Financial loss from investigations, lawsuits, and compensation
• Reputational damage and customer churn
• Supply chain risks occur when compromised passwords affect partners

Password training is universally important, but some industries face higher stakes:

• Healthcare. Medical records are highly sensitive and overlap with HIPAA.
• Finance. Passwords protect transactions and client trust.
• Legal and consulting. Compromised credentials can expose client data.
• Public sector and education. High user volumes and limited budgets make password training a critical necessity.
• Technology and SaaS. Shared developer credentials and API keys require strict governance and oversight.

These risks represent everyday realities across industries. The vast majority of attacks exploiting weak passwords are opportunistic rather than targeted, meaning any business that relies on outdated password practices is automatically at risk. Poor password security is no longer just an IT issue. It is a strategic business risk with legal, financial, and reputational consequences.

By adopting strong training programs and enterprise-level solutions like Passwork, organizations can transform passwords from a liability into a managed part of their security posture.

Conclusion

GDPR password security is both a compliance requirement and a business safeguard. Employee training transforms password policies from abstract rules into daily habits that protect data, reduce risk, and demonstrate accountability.

Security leaders should combine concise training sessions, simulations, practical password policies, and strong technical tools. By embedding Passwork into this ecosystem, organizations both educate staff and provide them with resources to comply effortlessly. Training is about building a security culture where GDPR password security becomes second nature, protecting the business and its customers.

FAQ: Frequently asked questions about GDPR password security training

Q: What does GDPR say about passwords?
A: GDPR does not prescribe exact password rules (e.g., "must be 12 characters long"). Instead, Article 32 requires organizations to implement "appropriate technical and organizational measures" to ensure data security. This is a risk-based approach. For passwords, this means your policies (length, complexity, MFA) must be strong enough to protect the specific personal data you process. A failure to enforce strong password hygiene can be interpreted as a direct violation of this requirement, leading to significant fines.

Q: How can we make security training engaging so employees actually pay attention?
A: The key is to move beyond passive lectures. Effective training is interactive and context-driven. Use gamification (e.g., leaderboards for completing security quizzes), real-world phishing simulations, and role-playing scenarios where teams must respond to a mock data breach. Tying training directly to the tools they use daily, like a password manager, makes the lessons practical. For example, instead of just talking about strong passwords, have them generate one in the company's password manager during the training itself.

Q: What are the essential components of effective GDPR training?
A: Effective programs combine GDPR fundamentals with practical application. This includes secure password creation, using password managers, multi-factor authentication, breach response procedures, and role-specific scenarios to keep the content relevant.

Q: How does password training support GDPR compliance?
A: Documented training initiatives serve as proof of "appropriate technical and organizational measures" under Article 32. Good record-keeping shows regulators that employees have been properly trained and helps organizations track progress and demonstrate accountability during audits.

Q: What metrics prove training is effective?
A: Organizations should monitor the following metrics: reduced password-related incidents, stronger password strength scores, increased adoption of password management tools, and a decline in password reset requests. These metrics provide tangible evidence that training translates into improved security.

Further reading

HIPAA requirements for password management

Table of contents * Introduction * How HIPAA works * Cybersecurity and clinical efficiency * HIPAA and password management * How to train staff to meet HIPAA standards * How Passwork supports HIPAA compliance * Sustainable HIPAA compliance Introduction In the complex ecosystem of modern healthcare, patient data is essential for secure management. In 2024, the U.

Passwork BlogAna Moore

Cyber insurance: A false sense of security?

Table of contents * Introduction * Cyber insurance: What does it cover? * The day-to-day reality of cybersecurity * Navigating Global Compliance * The rewards and challenges of cybersecurity * Conclusion Introduction As cyber threats and data breaches become more frequent and sophisticated, many organizations are looking to cyber insurance as a way to manage risk.

Passwork BlogTurpal Mahaev

Four ways to make users love password security

Four ways to make users love password security

Passwork BlogIliya Garakh, CTO

Introduction

In the complex ecosystem of modern healthcare, patient data is essential for secure management. In 2024, the U.S. healthcare sector experienced over 700 large-scale data breaches, marking the third consecutive year with such a high volume of incidents. This surge compromised over 275 million patient records, a significant 63.5% increase from 2023.

"Healthcare data are more sensitive than other types of data because any data tampering can lead to faulty treatment, with fatal and irreversible losses to patients" — Healthcare Data Breaches, MDPI

The consequences go far beyond financial penalties and reputational damage. Breaches of electronic Protected Health Information (ePHI) can disrupt patient care, compromise safety, and erode public trust. As the American Hospital Association highlights, since 2020, healthcare breaches have affected over 590 million patient records — more than the entire U.S. population, with a significant number of individuals being affected multiple times. 

Healthcare operates in a 24/7 environment where delays in authentication can impact patient care. Systems must provide strong protection without disrupting urgent clinical workflows. Password management is no longer just an IT function. It is now a mission-critical process directly tied to patient safety and regulatory compliance under the Health Insurance Portability and Accountability Act (HIPAA).

How HIPAA works

HIPAA is a U.S. federal law that establishes strict requirements for safeguarding sensitive patient health information from unauthorized disclosure. In addition to privacy protection acts, the HIPAA Security Rule specifically addresses the protection of ePHI, any personally identifiable health information created, stored, transmitted, or received electronically.

HIPAA applies to:

• Covered entities: hospitals, clinics, physicians, insurers, and healthcare clearinghouses
• Business associates: service providers (IT, billing, cloud hosting, consultants) that handle ePHI on behalf of covered entities

HIPAA is structured around several interconnected rules, each serving a distinct purpose in protecting patient data:

• The Privacy Rule sets standards for how PHI can be used and disclosed
• Security Rule defines administrative, physical, and technical safeguards to protect ePHI
• Breach Notification Rule requires covered entities and business associates to notify affected individuals, the U.S. Department of Health and Human Services (HHS), and sometimes the media, in the event of a breach
• The Enforcement Rule outlines penalties for violations

Organizations must document their policies, conduct periodic risk assessments, and ensure that staff are properly trained. Non-compliance can lead to сivil fines up to millions of dollars, criminal penalties, including imprisonment, in cases of willful neglect or malicious misuse, and permanent listing on the public "Wall of Shame" for reported breaches. HIPAA compliance isn’t just about avoiding penalties — it’s about protecting patient safety and trust. A breach of PHI can result in identity theft, financial fraud, and critical interruptions to patient care, underscoring the vital importance of robust healthcare data security.

Cybersecurity and clinical efficiency

The 2024 NIST Digital Identity Guidelines (SP 800-63B) represent a significant evolution in cybersecurity best practices. These guidelines advocate for a shift away from overly complex passwords towards longer, more memorable passphrases, widespread adoption of multi-factor authentication (MFA), and enhanced breach detection capabilities. While these changes undeniably enhance healthcare cybersecurity, they also necessitate that healthcare providers reassess their existing tools and policies to align with modern security paradigms, like Zero trust architecture.

The NIST Digital Identity Guidelines provide a comprehensive framework that complements HIPAA requirements, offering detailed guidance on implementing robust identity and access management. For healthcare organizations, this means:

• Identity proofing. Ensuring that individuals are the ones who they claim to be during the account creation process, reducing the risk of fraudulent access.
• Authenticator Assurance Levels (AALs). NIST defines different levels of assurance for authenticators, from single-factor passwords to strong multi-factor methods. Healthcare organizations should strive for higher AALs for access to sensitive ePHI.
• Federated identity management. Leveraging standards like Single Sign-On (SSO) and LDAP Integration to streamline user access across disparate systems while maintaining strong security controls. This reduces password fatigue and improves overall security posture.
• Lifecycle management. Implementing robust processes for managing identities from creation to deactivation, including timely revocation of access rights for departing personnel. This is crucial for maintaining data integrity and preventing unauthorized access.

By integrating NIST recommendations, healthcare organizations can build a more resilient and adaptable cybersecurity posture in healthcare, moving beyond minimum compliance to proactive risk mitigation. This proactive approach is vital in combating evolving threats such as ransomware attacks and sophisticated phishing campaigns.

HIPAA and password management

The HIPAA Security Rule takes a structured approach to password management, breaking it into administrative and technical safeguards. Together, these safeguards form a framework that organizations must adapt to their operational realities, while still meeting regulatory expectations. All of that is done to keep their patient data secure.

Administrative safeguards focus on policy, governance, and people. They require:

• Documented password policies that define how passwords are created, changed, stored, and removed. These policies must be clear, enforceable, and aligned with risk assessments
• User training programs that educate staff on password hygiene, how to avoid common pitfalls such as reusing or sharing passwords, and how to recognize social engineering attempts. Training must be ongoing, not a one-time event
• Risk-based access controls that ensure staff have only the level of access they need to perform their duties, following the HIPAA minimum necessary principle
• Retention of documentation — all policies, risk assessments, and decisions must be recorded and kept for at least six years, enabling compliance audits and investigations

Technical safeguards address the systems and tools used to enforce secure authentication and access management. They include:

• Authentication mechanisms to verify that the person accessing ePHI is the one who they claim to be — for example, username and password combinations backed up by multi-factor authentication
• Logging and audit trails that record every authentication event and track changes to sensitive data, enabling investigation procedures of anomalies or breaches
• Interoperability, ensuring that authentication and password controls work consistently across all environments — from electronic health record (EHR) systems to medical devices and cloud services

HIPAA further differentiates between required and addressable specifications. Required safeguards are non-negotiable — failure to implement them constitutes non-compliance. Addressable safeguards give organizations some flexibility: they can either adopt the recommended control or implement an alternative that achieves the same level of protection. In either case, the decision must be well-documented, justified, and periodically reviewed to ensure it remains appropriate and effective.

A well-designed password management program under HIPAA doesn’t stop at compliance — it also considers usability, scalability, and the unique pressures of healthcare workflows. Implemented correctly, it can reduce risks without creating operational friction, making secure access part of the daily routine rather than a barrier to patient care.

How to train staff to meet HIPAA standards

Human error remains a primary driver of healthcare data breaches. Therefore, effective staff training is not just a regulatory checkbox but an essential component of HIPAA compliance and overall ePHI protection. While regular, role-specific security awareness training for clinicians, administrators, and IT staff is fundamental, a truly effective program extends far beyond basic awareness. The goal is to transform passive compliance into active participation, empowering employees to be the first line of defense against breaches. Compliance is as much about operational discipline as it is about technology. Healthcare organizations should:

• Implement Role-Based Access Control (RBAC) to enforce least-privilege policies.
• Utilize LDAP Integration and Single Sign-On for centralized onboarding and offboarding processes, enhancing access rights management.
• Separate vaults and permissions by department, specialty, or function to ensure granular control
• Maintain comprehensive audit trails for all credential activities, crucial for accountability and forensic analysis

Organizations should consider incorporating advanced training modules on emerging cybersecurity threats, such as ransomware and advanced persistent threats (APTs), specifically tailored to the healthcare context. This includes practical exercises in incident response, data recovery, and business continuity planning. Furthermore, training should focus on the human element of security and foster a culture of vigilance, making sure that every employee understands their role in protecting sensitive patient data. This can involve gamified learning, interactive workshops, and regular communication channels for security updates and best practices. 

How Passwork supports HIPAA compliance

Selecting a password manager for healthcare organizations means not only meeting the highest standards of healthcare data security and regulatory compliance, but also ensuring that the solution fits seamlessly into the daily workflow of medical staff. Complex tools are often rejected in practice, forcing employees to revert to insecure workarounds. Passwork architecture is designed to meet HIPAA-specific compliance challenges while remaining intuitive enough for fast and easy adoption.

• Certifications and security practices. Passwork is ISO 27001 certified, demonstrating adherence to internationally recognized information security standards. Regular penetration testing via HackerOne ensures the platform remains resilient against emerging threats.
• On-premise deployment. Passwork supports self-hosted deployment, allowing healthcare organizations to run the system entirely within their infrastructure. This approach keeps credentials under direct organizational control, meets HIPAA data protection requirements, and minimizes exposure to third-party risks.
• Data protection by design. With a zero-knowledge architecture and AES-256 end-to-end encryption, Passwork ensures that no one — not even the service provider — can access stored credentials. This aligns directly with HIPAA privacy, security, and technical safeguard provisions.
• Access management. Integration with LDAP and SSO centralizes authentication and user management, making it easier to enforce consistent security policies across large and distributed healthcare environments.
• Granular access control. Passwork RBAC enables administrators to assign precise permissions to each user or group. Only authorized staff can access specific vaults or entries, supporting the HIPAA minimum necessary standard.
• Audit trail and real-time monitoring. HIPAA requires detailed audit controls. Passwork logs all actions, including password creation, modification, sharing, and deletion. Real-time alerts for critical events enable quick detection and response to potential security incidents.
• Multi-factor authentication (MFA). Adding an extra layer of protection, MFA helps safeguard accounts even if a password is compromised.
• Easy onboarding and usability. The clean and intuitive interface allows healthcare staff to start using the system immediately without requiring extensive training or disrupting patient care workflows. Passwork received the "Ease of Use" award from Capterra, which confirms that the solution is user-friendly and does not require extensive training.

By combining advanced security measures, regulatory alignment, and user-friendly design, Passwork enables healthcare organizations to protect ePHI effectively while maintaining HIPAA compliance in a practical, sustainable manner.

Sustainable HIPAA compliance

Achieving compliance is only the first step. Maintaining compliance requires ongoing attention. Healthcare organizations should:

• Conduct regular risk assessments and update policies accordingly
• Review audit logs for anomalies
• Refresh training content annually
• Continuously evaluate tools and workflows against evolving threats and regulatory updates

HIPAA compliance is not just a legal obligation — it is central to fostering patient trust and ensuring patient safety. Secure, efficient password management plays a critical role in protecting ePHI and enabling high-quality care. By combining strong encryption, granular access controls, integration with enterprise systems, and ease of use, Passwork helps healthcare organizations meet and sustain HIPAA compliance. In doing so, it safeguards sensitive data, reduces breach risks, and supports the life-critical mission of healthcare.

Further reading

Insider threats: Prevention vs. privacy

Insider threats are a major cybersecurity risk, often overlooked. Prevention requires balancing trust and security focus on monitoring risk-based behaviors, not constant surveillance. Use AI for early detection, educate staff, and be transparent to foster trust while protecting data.

Passwork BlogTurpal Mahaev

Passwork 7: Security verified by HackerOne

Passwork has successfully completed the penetration testing, carried out by HackerOne — the world’s largest platform for coordinating bug bounty programs and security assessments. This independent evaluation confirmed Passwork’s highest level of data protection and strong resilience against modern cyber threats. What the pentest covered Security architecture and data

Passwork BlogEirik Salmi

How to protect your online business from cyberattacks

Protect your online business from cyber threats with actionable strategies, from employee education to advanced tools like Passwork. Learn about phishing, ransomware, and more while discovering how to enhance security with simple yet effective measures. Stay protected — read the full article!

Passwork BlogEirik Salmi