Hacker News new | ask | show | jobs
by tptacek 1233 days ago
Having been through a SOC2 audit: this wouldn't fly. It's on the checklist of issues that you get hit with regardless of what kind of company you are: when customer accounts are terminated, the data retention clock starts ticking.

You can pick an arbitrary time frame for retention, but whatever you pick, you have to communicate to users, and you can't just change it on a whim. Normal customers want this clock short. They don't want you to retain their stuff after they cancel.

4 comments

But this isn't an account termination. They deleted the data of an active account, without informing the user.

Why could they not turn it into a read-only database without access from the Heroku apps instead? Then it'd just be a routine change to the service offered, would it not?

The customer account wasn't terminated, the free DB being used by paid Dynos was deleted without any input from or notification to the customer.

I highly doubt normal customers want this clock short when the cancellation is not customer initiated.

Data retention policies are written by compliance people, not product people, so distinctions like overt, deliberate cancellation and "cancellation for nonpayment" or "abandonment" or "discontinuation" usually aren't captured in them. I'm not saying it's great that Heroku deleted these databases; I'm saying: the description given upthread, that the databases were deleted because of contractual requirements, is super plausible.
Plausible, sure, but that doesn't mean it isn't a cop out. There are many things that Heroku could have done to prevent this, like delaying the disconnection when they don't have confirmed delivery of the notifications and/or when they are connected to paid dynos/accounts.

Thus didn't happen because of the contract, but because the people implementing this transition didn't give a crap.

I'm just telling you that what the commenter upthread said rang true. I'm not offering an assessment of compliance regimes.
If you start disconnecting the database, in the same way a user could (on most services?) to keep the database around and idle, there's no way that counts as any kind of deletion. So do that if you need to and you really want to give customers 90 days to react.
It feels like it would've been better to have written things such that if it's attached to a still active account that's paying for other services things would be permitted to work a bit differently, but of course the relevant clauses will have been written long before anybody anticipated a new owner deciding to turn a bunch of things off, so under the circumstances at the time of writing it's unsurprising and not really the authors' fault that they didn't consider that.

I had a vague thought for a moment about maybe being able to give customers the option to opt in to an updated set of terms that would've been better designed for the situation ... but since the original Tell HN author didn't get any emails about this at all, presumably they wouldn't've got that one either so even if (and given 'vague thought' I'm not claiming any particular level of 'good idea' to it) that had been done it presumably wouldn't've helped them anyway.

It seems to me the root problem here isn't so much the compliance initiated policies as a complete failure to take 'make sure people have been adequately warned' sufficiently seriously given the potential consequences.

Deeply unfortunate.

(read that last sentence in understated deadpan dry en_UK to get an appropriate read on just how impressed I'm not by the communications cockup)

Compliance people are product people too (even if in disguise), and obviously (?) vice versa.

Silos lead to issues like this. Cross-functional teams cost more, etc.

Not so much, no.
If compliance affects any user-facing property of the product, then they are, by definition.

Onboarding users/partners would be easier without making them read/click all those consent checkboxes, etc.

That's like saying everybody in a product company is a product person. No, it really doesn't work that way, at least not in general.
The simplest test is "who are you defending"?

Ideally, product people defend the end users. Realistically, compliance people defend the company from getting screwed in an audit and ultimately sued by the government.

They’re accountants in my experience.
Of course it’s plausible. Literally anything to do with contracts or legal in a corp like Salesforce is plausible.
I don't think there's anything in SOC2 that says you can't have multiple tiers of deactivating an account. I think the crucial point here is that Salesforce is requesting the termination, not the customer, so any of their obligations to be responsive to customer data deletion requests are moot (unless the customer comes back and actually requests termination).
Create a passphrase, derive the key, encrypt the data dump with the key, send the passphrase to the customer, delete the key. Presto, you can keep the data as long as you want without any privacy implications, since only the customer could decrypt it. Of course, this assumes working communication channel between the provider and the customer.