I've been using https://clay.earth for this - it does #s 1-2 by default, and the rest can be done with notes on a particular contact. More people focused than lead focused so might work for what you need
Same. I've been pretty happy with Clay (https://clay.earth). They just rolled out a Facebook birthdays integration and between that and Linkedin / iMessage it has most of the people I care about seeing.
Your question has two specific parts that I want to address:
1) Single Point of Failure
2) Larger target for malicious actors
Regarding point #1:
- We have invested significant amount of resources in making our product as stateless as possible and our core product can live on different cloud providers' edge networks.
- We conduct failover tests every 2 weeks to ensure we have the capability to respond to any blips in downtime. Our SOC2 Type2 report is available to discuss the availability and disaster recovery items in detail.
- As a side note: We solve the issue of the "vendor is down" problem -- for example, we have customers who seamlessly switch between providers, say credit score checks, when one of them is down without the liability of storing that data themselves.
Regarding point #2:
- This is our core focus. We take on the liability. The idea here is if this is the core focus, we can do this better than a lot of folks out there.
- We also broker access to different Fortune 500 institutions that visit our offices and constantly pen-test us, audit us, etc.
I think it's important to acknowledge that as developers security is always important, but never prioritized until its urgent. We are trying to change that @ VGS.
Please, email me directly and I'm happy to have a further chat: mahmoud @ ${COMPANY_NAME}.com
You had me at "cloud providers". If you store the data on some cloud provider, then you are just as bad as what your prospective customers are doing.
I don't want any of my sensitive data stored on "some cloud provider".
Also, your security strategy apparently boils down to "we'll be REAL CAREFUL, pinky swear!"
That strategy does not work, and has never worked before. The whole reason why you think your product is needed is because your prospective customers do it just like that.
I'm stunned you found investors with this proposition.
If by outsourcing PCI compliance entirely, they mean "ensure you don't store cardholder data by tokenizing it and we store the real stuff" this is very much not a new solution, so I'd struggle a bit to see the value of a new entrant.
There's already quite a few payment gateways where an e-commerce site can iFrame the payment page (or similar) to ensure that they never see the real cardholder data.
(the fact that this shouldn't really make them out-of-scope for PCI is a different problem)
This is not a payments gateway. We use them for something entirely different than processing payments or credit cards. I haven't seen a general PCI-compliant transparent PII tokenizer proxy service like that. If you know of one, let me know, maybe we'll even switch. But this is not a payment gateway solution, and it's offering many more use cases than an iframe or credit cards.
1.) Shared resources, and exploits like meltdown and spectre
2.) Cloud provider employees potentially have access
3.) Cloud providers are subject to law enforcement requests
However, there are benefits. Typically Google Cloud for example is going to have much better systems and security that a home-rolled data center setup. They've been working on it for years and essentially have unlimited resources (time and capital).
Here in HN, we all know what happened whenever a large actor took on the liability. The answers here are almost insulting given the category of the service provided; dismissive even.
agreed, imagine the ability to look at all of the data they have and find a dump on that.
idea time: Cryptographically store this data on physical cards that can fit into wallet and be managed by the user and 'revoked' if they lose the card. obviously things like backing up and storing will still need to be done, but that does not necessarily need to be reachable via an API or on the internet all after it has initially been created.
