In terms of implementation, where do you think this option should appear, and what exactly should be deleted?

I would think that the ability to outright delete a client should be restricted by ACL to only those staff members who should have access. Also, the staff member should have to enter their password or something each time they delete a client record, which would prevent someone from deleting records on an unattended computer. The client, all contacts, invoices, services, transactions, would be deleted. However, any active services must be cancelled first.

Thoughts?

any active services must be cancelled first. 

Normally, delete button should be appear and functional if the fallowing criteria exist .

1 - the client has no active service, no pending invoice (not proforma), no transaction pending transaction.

2 - it should pass 5 years for the last canceled service.

3 - the client has not debit or credit amount in their account.

resuming the client should have 5 years for no activity with the company. (should not confused with the last visit).

ACL for deleting a user is a must have permission.

On delete Client, we should delete, invoices, services, transactions, support tickets, documents, emails, related logs ...

Yes, we wouldn't want to delete clients with active services!

I am grateful to see Blesta looking to adhere to GDPR: https://dev.blesta.com/browse/CORE-2463 Thank you.

However, it is still important for Administrators to be able to delete old (redundant) client information, to comply with UK Data Protection Laws, which will still apply alongside GDPR.

Therefore, it seems an opportune time to incorporate the necessary features at the same time as CORE-2463, as there is overlap.

To that end, the way I see this implemented is as follows:

• A Company setting called "Client cleanup".
• In Client Cleanup setting; specify number of days to delete clients considered to be redundant. 0 = never, 1826 = 5 years.
• You have a granular setting to select the Client Groups that the client cleanup will effect. This allows clients to be protected from deletion, if required for a particular purpose (that hasn't been considered).
• The client cleanup will be an automated task, run once a day.
• The client cleanup will work on clients with the following conditions met: 1. Marked as inactive in Blesta (which the admin does manually), 2. Has no active services, 3. Their last invoice was closed X days ago (as per number of days set in Client cleanup setting), 4. In client group(s) X (as per client groups set in client cleanup setting).

For example, this is how I see it operating:

You enable client cleanup by setting the company setting with the number of days that you want to cleanup redundant clients. eg. I set 1826 = 5 years (Blesta would ship with this setting disabled by default by having it set to 0).

You then choose the "Default" client group and this will mean that the client cleanup will look for clients in the Default client group -> for any that have been marked as inactive -> have no active services -> their last invoice was closed 1826 days ago.

It is debatable as to whether there is the requirement for the client to first be manually marked by the Admin as inactive. It doesn't matter either way, but could be a useful safeguard - comments on this?

Thanks for the feedback. Yes, I agree there should be some automation to removing client data when a client has not been active for a certain period of time. By default, the status for client's is not changed automatically, so removing client data shouldn't be limited by that factor unless the system also marks clients inactive at an earlier period. I've updated the task to mention this, and it's something we are looking at now.

Hi Paul,

Thank you for your hard work on this!

A few things:

1. What was your thinking for anonymising the data rather than deleting it?

2. Re CORE-2671: I think it would be good to have the option to not delete (by setting 0), thereby, people who don't need to comply with data protection can still 'cleanup' their active clients list by marking clients as inactive automatically. Otherwise, if there isn't this option, I don't see the need in having the 'auto-inactive' feature?

I note GDPR states that if there are lawful means for retaining the data (eg. for tax purposes - as originally mentioned), the client has no "right to erasure". Therefore, I am wondering about the need to anonymise data? the data won't be much use to admins either once anonymised - it seems better to remove the data entirely when no longer required and keep the database and admin portal clean (I can imagine masses of anonymised data being a "nuisance" to admins).

Additionally, the UK data protection law states that data must be kept accurate - anonymising the data will go against this. The data should be kept accurate, whilst you have a legal obligation to retain the data, and after that obligation has expired, it should be deleted.

1. Clients cannot be deleted if they have transactions for example, because the transactions would have to be deleted also, and they may be necessary for tax, accounting, and reporting purposes. Anonymizing the data allows for the personally identifiable information to be purged while maintaining those records. Anonymization and Pseudonymization are ideas included in GDPR. See https://gdpr.report/news/2017/09/28/data-masking-anonymization-pseudonymization/

2. Most clients will be anonymized and not deleted, because they will contain financial transactions. The automatic marking of clients as inactive is something that we would have done outside of GDPR, but it adds an additional layer of protection in that accounts can be marked inactive for a period of time before they are automatically deleted or anonymized.

If we do not anonymize data, and deleting data is the only way forward, then clients do not in fact have the same right to erasure/ right to be forgotten. A company may be required to retain certain financial information for 7-10 years, or longer. Information that can be retained without retaining any personally identifiable information with anonymization. Anonymization allows compliance, while retaining necessary, non personally identifiable business records.

If UK law does not allow anonymization, then you're stuck in the middle of two laws. What do you tell a customer who wants their personally identifiable information removed, if you're also required to keep financial data for 7 years? Wait 7 years?

There are conflicting laws in different places, as a result of GDPR compliance. It's up to each company to decide what is necessary for them to be compliant. Our goal is just to make it possible to do what you are required to do, preferably without breaking things.

I'm sorry Paul, I still don't understand.

GDPR states that if there are lawful means for retaining the data (we are agreed that the reasoning in this case is for financial purposes), the client has no "right to erasure". That's the end of it; there isn't any need to go any further than this and anonymise data. After that obligation has expired, it must be deleted.

So, to address your points (sorry, there is no quoting feature which would make this more polite):

>Anonymizing the data allows for the personally identifiable information to be purged while maintaining those records.

There is no need to anonymise the data.

>Most clients will be anonymized and not deleted, because they will contain financial transactions.

That's my concern with the current approach.

>What do you tell a customer who wants their personally identifiable information removed, if you're also required to keep financial data for 7 years? Wait 7 years?

Yes, exactly. The data cannot be removed for X number of years for financial reasons and after such time (this) retention policy must remove the data as there is no longer any right for the organisation to retain the data (and this original feature request is about complying with the requirement to delete data that is no longer required). As stated already, in this instance the "right to erasure" in GDPR does not apply. GDPR is not going against us in this instance, it is merely ensuring that we delete data when we no longer have a legal obligation to retain it....but the UK data protection act has always stipulated this, in effect they are both stating the same thing.

>but it adds an additional layer of protection in that accounts can be marked inactive for a period of time before they are automatically deleted or anonymized.

Yes, I like the idea, however, if the inactive client marking is automated and a client has been unintentionally marked inactive, if the admin does not want this to happen, the only way to get that client out of this status is to add an invoice or service etc. I do not see it adding any value that the "delete or anonymise" option would provide, except for tidying up the active clients list. Therefore, we are on the same page when you say:

>The automatic marking of clients as inactive is something that we would have done outside of GDPR

I agree, it will be useful for everyone for the purpose of tidying up the active clients list. Therefore, what I was trying to say is that the automated marking of inactive clients should be allowed to be enabled without the need to also set the following option regarding deletion or anonymisation. :)

It is really difficult to discuss something like this in written form - I hope that you see where I am coming from. I am trying to be constructive. :)

First of all, I appreciate the information. I'm going to assume that everything you've said is true for the UK. But it doesn't mean that it's the same across the EU, or that it's the preferred way to go for all businesses.

Anonymizing personal data removes GDPR considerations. While a business could deny a request for erasure for good reason, that reason may not be valid from the point of view of the requestor, or the government. In that case, the safest thing to do is anonymize because GDPR will no longer apply. There would no longer be any legal ramifications as a result of GDPR, if the data is properly anonymized.

It sounds like you're fine telling the client to go pound sand, and that the data will be erased after X years. I'm with you. You should be able to retain the data as long as necessary.. though it may result in a compliance complaint from a customer that does not think you have that right, along with nosey government regulators who are determined to make an example out of someone. It's not the kind of heat I would want.

The solution to your request, in as far as it involves Blesta, may require additional options for the complete and total erasure of all data associated with a client as an alternative to anonymization - regardless of how that may impact tax, accounting, or reporting (And it WILL impact those things). I'll dig into this in more detail. If you have any links to UK law that expressly forbid anonymization of data as a way to remove personally identifiable information I'd love to read more about it and try to understand the scope.

Thank you Paul, I appreciate your openness. :)

From what I've read, it appears that it is very similar across the EU (based on one of my later links alluding to this)...ie. a need to keep records for financial reasons (it would be great if others in the community could also pitch in).

What I was also trying to say is that once the data is anonymised, I cannot see how it can be valid for financial records anymore? ie. invoices will have no real name and address. I would also consider domain name entries as personally identifiable by GDPR definitions, so this would also need to be anonymised (they could include the name of the owner or they could be indirectly linked by a WHOIS lookup).

You wouldn't be able to track back or search anything once all of this data is anonymised. Therefore, I would have thought that it would be worthless to the admin also and it might as well be deleted. Besides this viewpoint:

See: https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/principles/

Point d). I read that as going against anonymising data, so that you can continue to keep it for financial records compliance. As I say, it is unnecessary to anonymise the data to enable you to continue to keep the financial records and comply with your other legal obligations, as this has been allowed for:

See: 1. https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/legal-obligation/

2. https://www.weightmans.com/insights/gdpr-countdown-week-6-gdpr-and-hr-record-retention/

^(although it is about HR records, it would similarly apply to financial records also)

3. https://www.sdworx.co.uk/blog/the-legal-obligations-of-processing-data-under-gdpr-part-2

Regarding right to erasure:

It is hinted to in link 3 above on the bottom paragraph but also see: https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-erasure/

Under heading "When does the right to erasure not apply?"

"to comply with a legal obligation".

>It sounds like you're fine telling the client to go pound sand, and that the data will be erased after X years.

As per my previous links, GDPR allows for this if you have a legal obligation to retain the data for this purpose and you put this information in your privacy notice. I acknowledge that not all of the data that Blesta stores could be considered required for financial obligations, eg. logs, so these would still need to be dealt with. I am just trying to address whether there is a need for anonymisation.

Another thought; support manager needs to have an additional independent cleanup mechanism? to cleanup tickets from unregistered users, which should be removed in a time frame that is different to client data.

For example; sales department receives tickets from unregistered (prospective) users - if the user did not become a client (and therefore register) then the ticket doesn't need to be kept for a very long time (unlike client data). However, if a user sent a sales email (at the time of being unregistered) and they subsequently became a client, a cleanup mechanism like this would also scoop-up current client's data. The trouble is, from memory, Blesta does not associate tickets from unregistered users with a later-registered client account (ie. if the user subsequently registers). How big a deal this caveat is, I don't know (you have to strike a balance, so personally I wouldn't have an issue with this happening).

There is a method that ties into deleting clients to notify plugins of the delete action so that plugins can delete any client data they contain. So no, there wouldn't need to be a separate independent cleanup mechanism for tickets. Unassociated tickets may not be purged though, because there's no simple way to make that distinction. However, in Blesta 4.3, you can delete tickets, so you could manually handle any such cases.

I'm pleased to hear that in the future it will be possible to delete tickets manually - thank you for adding this.

Going back to unassociated tickets, it is possible to query these in the database:

SELECT * FROM `support_tickets` WHERE `client_id` IS NULL AND `date_closed` > '2018-01-01 00:00:00'

It is a little tricky to manually run queries like this, because of the need to also delete the ticket's replies. I'm not knowledgeable enough to know how to link to the next query.

On another note regarding the anonymisation of data; the comments in the thread here reiterate what I have been saying previously (perhaps they put it in a way that would be easier to understand).