Jump to content
knightcoder

GDPR - Impactos no software

Recommended Posts

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?

  • Vote 1

Share this post


Link to post
Share on other sites
nunopicado

Boa pergunta, ainda nem tinha ouvido falar disso...
Tenho de me informar melhor!


"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Share this post


Link to post
Share on other sites
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, ...

Share this post


Link to post
Share on other sites
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".

Edited by nunopicado
  • Vote 2

"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Share this post


Link to post
Share on other sites
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.

  • Vote 1

Share this post


Link to post
Share on other sites
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).


10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Share this post


Link to post
Share on other sites
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]

 


As mentes humanas são realmente um local estranho!

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

  • Vote 1

10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Share this post


Link to post
Share on other sites
Ary

Boa noite.

Relativamente a este assunto gostaria de obter o vosso feedback e de que forma estão a fazer o plano para se adaptarem a tal realidade.

Na empresa em que trabalho temos uma multiplicidade de sistemas (internos e externos), base de dados, hardware,  serviços e afins, sendo que pelo que consegui apurar existem vários factores a ter em conta nas vertentes acima descritas.
Neste momento estamos a fazer o levantamento dos diferentes sistemas, serviços e etc (sendo que se trata de uma empresa relativamente grande) e está a ser complicado identificar tudo isto.

Qual o vosso concelho/plano?

 

Cumprimentos.

Share this post


Link to post
Share on other sites
jacPereira

Apesar das regras bicudas de implementar existem excepções autorizadas. 

Como primeira medida, no caso dos dados em BDs, encriptar a informação não publica (telefones, e-mails, nomes de contacto,...) e só desencriptar na apresentação (UI), se o utilizador estiver autorizado a ver/alterar a informação.

Importante mesmo é manter um log de todas as alterações efetuadas nessa informação (de preferência com o conteúdo também encriptado.

O resto depois logo se ve...

Share this post


Link to post
Share on other sites
M6
On 06/12/2017 at 10:41 PM, Ary said:

Boa noite.

Relativamente a este assunto gostaria de obter o vosso feedback e de que forma estão a fazer o plano para se adaptarem a tal realidade.

Na empresa em que trabalho temos uma multiplicidade de sistemas (internos e externos), base de dados, hardware,  serviços e afins, sendo que pelo que consegui apurar existem vários factores a ter em conta nas vertentes acima descritas.
Neste momento estamos a fazer o levantamento dos diferentes sistemas, serviços e etc (sendo que se trata de uma empresa relativamente grande) e está a ser complicado identificar tudo isto.

Qual o vosso concelho/plano?

 

Cumprimentos.

O melhor que tens a fazer é falares com um especialista em GDPR (posso indicar-te se quiseres) para fazer um levantamento e depois verificar o que tem de ser feito/corrigido.
Se tiveres a ajuda de um especialista a coisa torna-se significativamente menos dolorosa, nem que seja pelo colocar do esforço nos locais certos e não nos andarmos a dispersar...

  • Vote 1

10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Share this post


Link to post
Share on other sites
Rui Carlos

Algumas referências que me parecem interessantes sobre este assunto:

5 horas atrás, Cerzedelo disse:

Será que é desta que acabam os serviços do estado com password limitada a 8 carácteres? :)

  • Vote 1

Share this post


Link to post
Share on other sites
CJCV

daquilo que li , continuo com dúvidas : que impacto isto tem em softwares de faturação / POS / Contabilidade / Salários ?:confused:  

Share this post


Link to post
Share on other sites
M6
5 hours ago, CJCV said:

daquilo que li , continuo com dúvidas : que impacto isto tem em softwares de faturação / POS / Contabilidade / Salários ?:confused:  

Tem algum, em que grau depende de como o software está feito.

Por exemplo, situações tão simples como aceder à informação pessoal de uma pessoa apenas por quem necessita de lhes aceder versus toda a gente que usa uma determinada aplicação. Isso vai depender de como o software em causa estiver construído, o impacto pode ser simples ou nem por isso.

 


10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.