Ir para o conteúdo
knightcoder

GDPR - Impactos no software

Mensagens Recomendadas

knightcoder    1
knightcoder

Olá a todos,

Abro este tópico para discutir com a comunidade quais os impactos e estratégias que vão implementar nos diversos softwares para cumprir com o GRDR?

Para os menos atentos, O GDPR é um regulamento da UE para a proteção de dados e entra em vigor em 25 de maio de 2018.

Mais info em: http://www.eugdpr.org/

De forma resumida, o GDRP foi criado para proteger os dados pessoais dos individuos que os sistemas de informação armazenam, como o Nome, NIF, Morada, E-mail etc

Existem 5 áreas onde as empresas devem trabalhar para cumprir o GDPR e evitar as multas pesadas do não cumprimento:

  1. Política de acesso aos dados
  2. Identificar onde estão os vários atributos e os dados
  3. Política de governação
  4. Proteção de dados
  5. Auditorias internas de avaliação

As áreas que têm impactos diretos no software e sistemas de informação são a 1, 2 e 4.

Pegando num exemplo simplificado de um software de faturação, normalmente existem tabelas de clientes e empregados. Essas tabelas contêm atributos para armazenar os dados pessoais dos clientes e empregados. O GDPR  obriga a que os dados pessoais devem estar protegidos na base de dados e a sua consulta seja controlada.

Visto que a legislação fiscal em vigor em Portugal, em alguns cenários, obriga a identificar os clientes (Nome, NIF e Domicilio fiscal) na emissão de documentos fiscais e esses mesmos dados são exportados no SAF-T, que é um ficheiro aberto, como cumprir com o GDPR neste caso?

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
knightcoder    1
knightcoder

O GDPR afeta qualquer tipo de software, desde programas de faturação, RH, lojas online, CRM, sites de empresas/produtos que tenham registo de utilizadores, ...

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
nunopicado    1069
nunopicado
Citação

Right to be Forgotten
Also known as Data Erasure, the right to be forgotten entitles the data subject to have the data controller erase his/her personal data, cease further dissemination of the data, and potentially have third parties halt processing of the data. The conditions for erasure, as outlined in article 17, include the data no longer being relevant to original purposes for processing, or a data subjects withdrawing consent. It should also be noted that this right requires controllers to compare the subjects' rights to "the public interest in the availability of the data" when considering such requests.

Esta vai ser interessante...
Fulano tem o direito de exigir que os seus dados sejam apagados da DB do programa, mas a AT exige que tais dados nunca sejam apagados...
:D

Lá virá a história do "public interest".

Editado por nunopicado

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
Rui Carlos    311
Rui Carlos
13 minutos atrás, nunopicado disse:

Esta vai ser interessante...
Fulano tem o direito de exigir que os seus dados sejam apagados da DB do programa, mas a AT exige que tais dados nunca sejam apagados...
:D

Lá virá a história do "public interest".

Acho que o GDPR define os casos em que tens esse direito, e no caso dos programas de facturação diria que o utilizador não irá poder invocar esse direito.  Mas pessoalmente acho que a legislação actual sobre facturação é uma das maiores ameaças que já vi à privacidade das pessoas (razão pela qual raramente peço factura com NIF), e não era mau de todo se a legislação tivesse que mudar para ser compatível com o GDPR.

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
knightcoder    1
knightcoder
33 minutos atrás, nunopicado disse:

Esta vai ser interessante...
Fulano tem o direito de exigir que os seus dados sejam apagados da DB do programa, mas a AT exige que tais dados nunca sejam apagados...
:D

Lá virá a história do "public interest".

Apesar de não ser perito em legislação, acho que as leis locais sobrepõem-se às diretivas da UE, pelo que não deve haver impactos no SAF-T.

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
Rui Carlos    311
Rui Carlos
1 minuto atrás, knightcoder disse:

Apesar de não ser perito em legislação, acho que as leis locais sobrepõem-se às diretivas da UE, pelo que não deve haver impactos no SAF-T.

Os estados são obrigados a adaptar as leis locais às directivas europeias, caso contrário a Comissão Europeia põe os estados em tribunal.

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
M6    76
M6

O tema é extremamente relevante. A 28 de Maio do próximo ano todas as organizações têm de estar preparadas para cumprir o GDPR. É um tema que me interessa bastante e no qual já estou envolvido há algum tempo profissionalmente.

Ainda há muita poeira no ar, como por exemplo quem vai ser a entidade nacional que vai ser responsável por isto, fala-se na Comissão de Proteção de Dados, mas nada se sabe ainda.

Mais do que o software, toda a organização tem de estar preparada para o GDPR, em particular os RH têm um trabalho doido pela frente e isto não atinge apenas o software.
Por exemplo, arquivos em papel também é informação contemplada neste regulamento.
 

Basicamente acho que o software que começar a sair e ser comercializado na UE vai começar a ter muita atenção a este regulamento. Há muita informação pessoal a ser mal tratada e a ser ilegalmente recolhida (nada de novo aqui), mas com isto as pessoas vão estar mais atentas e os infratores vão sofrer um pouco mais na pele (as multas são astronómicas).

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
CrominhO    271
CrominhO
1 hora atrás, Rui Carlos disse:

Os estados são obrigados a adaptar as leis locais às directivas europeias, caso contrário a Comissão Europeia põe os estados em tribunal.

Concordo Rui, 

Mas as multas impostas pela UE aos Países, são normalmente por não aplicação ou uma aplicação errada de determinada lei, resultante de um interpretação/transposição incorrecta dos diplomas, porque cada País tem de adaptar o diploma e transpor para a legislação. 

Pode ainda ser o caso, como tantos outros, em que o estado Português(ou outro) prefere pagar as multas a transpor determinado diploma simplesmente por não compensar. :)

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
nunopicado    1069
nunopicado
2 horas atrás, knightcoder disse:

Apesar de não ser perito em legislação, acho que as leis locais sobrepõem-se às diretivas da UE, pelo que não deve haver impactos no SAF-T.

 

1 hora atrás, Rui Carlos disse:

Os estados são obrigados a adaptar as leis locais às directivas europeias, caso contrário a Comissão Europeia põe os estados em tribunal.

 

No caso, por não ser uma directiva mas sim uma regulamentação, os estados são mesmo obrigados a adaptar as leis locais, com alguma margem de manobra dada pela propria regulamentação (ex: Idade mínima para dispensar autorização do tutor é por default 16 anos, mas os estados poderão baixar para até aos 13 anos se quiserem).

Editado por nunopicado

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
CrominhO    271
CrominhO
1 hora atrás, M6 disse:

(...)

Basicamente acho que o software que começar a sair e ser comercializado na UE vai começar a ter muita atenção a este regulamento. Há muita informação pessoal a ser mal tratada e a ser ilegalmente recolhida (nada de novo aqui), mas com isto as pessoas vão estar mais atentas e os infratores vão sofrer um pouco mais na pele (as multas são astronómicas).

Eu gostava de acreditar que sim, mas a CFA lançou o SAFT há anos e o resultado, 7 em 28 ??

Para mais não será Portugal o único com divergências entre os Diversos Códigos Fiscais e  o GDPR

Portugal->	SAF-T (PT)	1.03_01[3]	December 2, 2016	SAF-T v1.0	Portuguese Tax Authority / Autoridade Tributária e Aduaneira	
Luxembourg ->	FAIA	2.01[2]	March 13, 2013	SAF-T v2.0	Luxembourg Tax Administration / Administration de l’Enregistrement et des Domaines (AED)	Law rule (memo) A-206 of December 24, 2008.[6]

France	FEC	 -> 	January 1, 2014	N/A	French Ministry of Finance	FEC FR adopted December 5, 2012 making it obligatory pr. January 1, 2014 for companies to supply file covering years 2011, 2012 and 2013.[7][8] However, France's usage of the term "Standard Audit File for Taxation" has been adapted for a file format not based on the OECD SAF-T; their écriture compatible is proprietary.

Austria	SAF-T AT -> 	1.01[9]	January 31, 2009	SAF-T v1.0	Austrian Ministry of Finance / Bundesministerium für Finanzen	Decree of March 20, 2009 BMF-010102/0002-IV/2/2009.[9][10]

Poland	JPK[11] ->	1.0	July 1, 2016	SAF-T v2.0	Polish Ministry of Finance / Ministerstwo Finansów	The new requirement comes into place on 1 July 2016 for large companies. Small and medium-sized businesses (less than 250 employees) will be required to implement the requirement by 1 July 2018.[12]

Lithuania	SAF-T	->1.00	July 1, 2015[13]	SAF-T v1.0	State Tax Inspectorate / Valstybinė mokesčių inspekcija	
Article 16 of the Law on Accounting. Resolution No 699 of 1 July 2015 of the Government of the Republic of Lithuania. Order No VA-49 of 21 July 2015 of the Head of the State Tax Inspectorate under the Ministry of Finance. [14]

Norway	Norwegian SAF-T ->  Financial	1.00	January 1, 2018[15]	SAF-T v2.0	Norwegian Tax Administration / Skatteetaten	
The Norwegian Ministry of Finance are considering adopting SAF-T to law. [15]

 

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
knightcoder    1
knightcoder

Na área de proteção de dados quais as estratégias é que estão a implementar?

Pegando no exemplo de uma tabela de clientes na base de dados de uma determinada aplicação:

  • devemos proteger os dados pessoais do cliente encriptando o conteudo de cada campo?
  • o utilizador da aplicação só deve visualizar os dados de cliente estritamente necessários para a operação?
  • deixa de ser possivel tirar uma listagem de clientes com por ex: nome, nif, morada e email?
  • se o cliente quiser "ser esquecido" que informação podemos continuar a guardar?

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
jmiv    1
jmiv
Em 31/08/2017 às 10:33, knightcoder disse:

Na área de proteção de dados quais as estratégias é que estão a implementar?

Pegando no exemplo de uma tabela de clientes na base de dados de uma determinada aplicação:

  • devemos proteger os dados pessoais do cliente encriptando o conteudo de cada campo?
  • o utilizador da aplicação só deve visualizar os dados de cliente estritamente necessários para a operação?
  • deixa de ser possivel tirar uma listagem de clientes com por ex: nome, nif, morada e email?
  • se o cliente quiser "ser esquecido" que informação podemos continuar a guardar?

Do que ouvi falar, as informações restringem-se apenas ao estritamente necessário ( e para o fim a que se destina) , sendo que logo que ela já naõ seja util deverá ser destruida.

Posso tentar saber mais algumas informações

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
M6    76
M6
On 8/31/2017 at 10:33 AM, knightcoder said:

Na área de proteção de dados quais as estratégias é que estão a implementar?

Pegando no exemplo de uma tabela de clientes na base de dados de uma determinada aplicação:

  • devemos proteger os dados pessoais do cliente encriptando o conteudo de cada campo?
  • o utilizador da aplicação só deve visualizar os dados de cliente estritamente necessários para a operação?
  • deixa de ser possivel tirar uma listagem de clientes com por ex: nome, nif, morada e email?
  • se o cliente quiser "ser esquecido" que informação podemos continuar a guardar?

Acima de tudo o acesso deve ser condicionado, tanto em termos de saber se determinado utilizador deve ter acesso a que informação como à informação que é necessária para cada tipo de operação. Encriptar a informação é uma forma, mas lembro que o GDPR não é uma norma para IT, é para proteção de dados. Alguém está a ver a documentação em papel a ser encriptada?

Parece-me claro que uma listagem de clientes onde conste o nome, nif, moradas, etc. não viola o GDPR a menos que a mesma seja usada fora da empresa ou para fins inapropriados (mas isso já acontece hoje em dia). Uma coisa é uma listagem dessas de clientes com pagamentos atrazados que toda a gente no departamento financeiro tem acesso, outra coisa é essa mesma listagem nas mãos do serviço de apoio ao cliente.

O caso do esquecimento é um dos mais bicudos de todos e onde há menos certezas. Já ouvi dizer que tem de se fazer "delete" da base de dados, ao que eu perguntei o que é que eu faço com a integridade referencial e, pior, com a informação em backup! O cliente ser "esquecido" pode muito bem passar por colocar "XXXXX" no nome do mesmo, "000000000" no NIF, eliminar o mesmo logicamente com um "D" no campo "estado", etc..
Temos de ter em atenção questões legais, como por exemplo, um cliente não pode ser realmente "esquecido" durante 10 anos pois a informação dele é necessária para o negócio e como tal há responsabilidades legais para com as finanças. Não sei se isto que coloca todos dados do cliente como dados não pessoais uma vez que são dados fiscais.
Outra situação interessante é uma pessoa pedir a um jornal para ser esquecido. As notícias vão desaparecer? Não me parece. Aliás, a própria história desapareceria a partir de determinado momento se tal acontecesse.

Parece-me de bom senso ter apoio legal/juridico especializado nesta matéria dada a sua complexidade.

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!

Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.

Entrar Agora


×

Aviso Sobre Cookies

Ao usar este site você aceita os nossos Termos de Uso e Política de Privacidade