4 ms·

I think every process needs a paper backup. There’s just no telling when something will be down. If you run a SAAS you could offer this as a feature. Even hire

I think every process needs a paper backup. There’s just no telling when something will be down. If you run a SAAS you could offer this as a feature. Even hire data entry people to input transactions later if needed.

ethbr1 2y ago
Is there anything relevant to recovery / graceful functional degradation in SoC2? If not, this feels like an obvious match there. E.g. "Company has a defined and demonstrated process by which they can (a) offer degraded but limited functionality in the event of full system outage & (b) accept data updates via a backup method, until system restoration." Sure would have helped with Change Healthcare...
- quercusa 2y ago
  I think you have to have a tabletop exercise once a year. So all good, right?
  - ethbr1 2y ago
    I mean, better than not. Everytime I see something basic in a standard, it makes me realize there were businesses out there who weren't doing anything of the sort.
codemac 2y ago
You can price this relatively quickly, and see that it's probably not worth it. ~1 week outage once every ~5 years, let's say you lose 100% of revenue that week, that's 0.38% of revenue. Now most likely they're not losing 100% of revenue, demand for cars is not very elastic... it starts to get pointless all around. Which is frustrating for consumers, but the profit for perfection isn't usually there.
- karaterobot 2y ago
  I think you'd have to compare that .38% of revenue to the cost of developing the paper process, as well comparing what revenue you'd lose with the paper process anyway. It doesn't seem crazy to me, unless your paper process is hard to develop. There's also an argument that developing a backup process is a great exercise to help people understand all the parts of your system and how they interact, as a first step to making them more efficient/redundant/secure/delightful.

ethbr1 2y ago

Is there anything relevant to recovery / graceful functional degradation in SoC2? If not, this feels like an obvious match there. E.g. "Company has a defined and demonstrated process by which they can (a) offer degraded but limited functionality in the event of full system outage & (b) accept data updates via a backup method, until system restoration." Sure would have helped with Change Healthcare...

quercusa 2y ago
I think you have to have a tabletop exercise once a year. So all good, right?
- ethbr1 2y ago
  I mean, better than not. Everytime I see something basic in a standard, it makes me realize there were businesses out there who weren't doing anything of the sort.

codemac 2y ago

You can price this relatively quickly, and see that it's probably not worth it. ~1 week outage once every ~5 years, let's say you lose 100% of revenue that week, that's 0.38% of revenue. Now most likely they're not losing 100% of revenue, demand for cars is not very elastic... it starts to get pointless all around. Which is frustrating for consumers, but the profit for perfection isn't usually there.

karaterobot 2y ago
I think you'd have to compare that .38% of revenue to the cost of developing the paper process, as well comparing what revenue you'd lose with the paper process anyway. It doesn't seem crazy to me, unless your paper process is hard to develop. There's also an argument that developing a backup process is a great exercise to help people understand all the parts of your system and how they interact, as a first step to making them more efficient/redundant/secure/delightful.