Launch HN: Stacksi (YC W21) – Doing Security Questionnaires, So Your Team Isn't
At our last company, we were the ones who filled these things out. We hated doing it, but got them done because we had to in order to close deals that could meaningfully impact the trajectory of the company.
If you’ve had to deal with these, you understand that they’re the worst way of broadly assessing a company’s security with a reasonable time / cost tradeoff…except for every other method that we currently have at our disposal.
Problem is, that they’re often 200+ questions sent to salespeople and forwarded ASAP to some other poor soul (often some sort of engineer). The questions asked (e.g. what is your company’s encryption standard? or “what events do your logs capture?“) - assuming that they’re even correctly phrased - touch sufficiently detailed aspects of a company’s security practices that make it difficult for someone who doesn’t have at least some security / compliance background (e.g. a salesperson) to answer properly. All of this means that high-capability individuals (CTOs in earlier-stage companies, Solutions and Security Engineers in later-stage ones) end up spending significant amounts of time answering the same questions that they answered a few days ago, just phrased sufficiently differently that rote copy-paste isn’t a viable solution.
This is what we’re trying to fix.
We do it, in a nutshell, by taking two things: 1) a company’s security docs (e.g. policies, diagrams, vuln scans) and 2) the questionnaire in whatever format it’s in (GRC portals, web forms, excel, word, PDF, tea leaves). Putting those two things together, we get the questionnaire done accurately and quickly using a human-in-the-loop model. (We combine a tuned BERT model searching on the company’s docs with manual review by a human on our team).
The product works something like this: Upload your docs; Upload the file, schedule 15 minutes to review with us in the next couple days, then forget about the questionnaire until the review call and do other work. In the background, we index all of your documentation and run a search for each question to find the most relevant sections of your documentation. Once that process is complete, a human on our team reviews what the system has output to make sure that answers are accurate and high quality. We then mark it as reviewed and you receive notification.
When Stacksi’s internal review is done, our team takes a few minutes to review it with you (usually within ~48 hours so we have enough time to ensure quality across many questionnaires), and then you send it back to the company that asked for the assessment.
In instances where your docs don’t touch on specific information (often comes up with questions around app-specific authentication options like “Does your application support SSO with our Identity Provider, [INSERT IdP here]?”), our software also has collaboration features to make it easy for teams to work together to get the questions answered without pulling out all their hair deciphering asinine questions or nagging teammates for answers. It then uses those answers to inform future questionnaires.
We currently charge for questionnaires per-question ($2), so companies don’t have to pay through the nose to get help or commit to a subscription. We’ve gotten some feedback that we are under-pricing right now (maybe too much), but our goal right now is to grow the number of customers we’re working with rather than trying to squeeze every penny out of every customer. The more customers we have, the better our product gets for everyone, since (quality) data is the biggest driver of a good vs garbage model. For that reason we want to make it as much of a no-brainer as...
89 comments
[ 3.2 ms ] story [ 130 ms ] threadMy company just onboarded RFPIO, which I'm super happy with which addresses everything it seems you're offering.
How is Stacksi different than RFPIO?
A couple points of differentiation:
1) First-shot completion: Our system typically gets 90%+ of the questionnaire completed with no user involvement. I don't think RFPIO (or other RFP-focused platforms) do that.
2) Guidance & Support: Some of the stickiest parts of RFPs are the questions that are either WTF? or that you answer "No" to and determining how to manage that. Does it actually matter that you don't have a WAF (depends on the rest of your architecture)? Does it actually matter that you're still using TLS 1.1 (probably want to change that)? Should you fix those things? RFP systems don't help with that; ours does (largely because we've put a human in the loop).
What I've heard from our customers using those systems is that RFP systems help (after you've spend time on curation) with ~30-60% of questions. If the questionnaire is 200 questions, that still leaves you with somewhere on the order of 100 questions to answer.
Ultimately, RFPIO provides a software tool only; we're providing a software-enabled service.
The time your team spends on questionnaires is reflected in that.
A number of our customers combine our service with loopio or rfp.io and we are perfectly fine with that.
We've built on top of an API (primarily for data I/O), but haven't exposed anything for public consumption yet (the API's only used by our app), simply because we have so much to tackle already that we're not ready to support a developer community using the API quite yet.
Like you said, building arbitrary logic into forms is hard...
And with that, you likely just won my company as one of your earliest customers.
The way that our system is built, every question has (up to) three possible inputs:
A selection An additional detail An attachment
When we parse a questionnaire, the system picks up whether there's a selection option available and shows that accordingly. Every question can have a detail or attachment.
Recorded a quick video here to give a bit better overview: https://www.loom.com/share/ed32e33598404bc7a883a66653c99258
You can also add an internal comment (by tagging someone like in Slack) to discuss with colleagues. That info stays on the internal system and doesn't get sent to the customer when the questionnaire is exported / sent off.
Like JJ said, we use Webflow for hosting the landing page and customized a template (softbit) https://webflow.com/templates/html/softbit-saas-website-temp....
Credit for customization of the design goes to the awesome Cristi Hurhui (https://dribbble.com/CristianHurhui)
I had the pleasure of interviewing Emre for my podcast. If anyone want's a listen, check it out: https://www.aakash.io/all-schemes-considered/stacksi-emre-mu...
One of the hardest parts though is when the question is too abstract so even as a human, I'm not sure what they are asking and in what context.
For example, a typical question would be "What encryption do you use at your company"? Dumb question and no accurate answer that would take less than 10 pages. How would you deal with these?
Our AI is probably not going to touch this as it's very unlikely a good answer in in your documentation, so a real person will take a stab at it and then flag it for review with you. We've seen a number of these BS types of questions and can generally give an answer that will satisfy the client, and we can review it with you to make sure you're happy with it.
The goal of this whole thing is to speed up the entire process of security review and actually reduce 3p vendor risk while getting business done.
I guess we've got our work cut out for us...
We've found that, trying to sell into the NHS. 150 trusts, all with different questionnaires.
That said, the biggest differentiator that I see is that we use a human in the loop model, while Skypher is a purely software solution.
In other industries, an AI that can answer even 90% of the questions well would be a fantastic result. On a security questionnaire, that's going to lead to more back and forth, more meetings, and more work for the vendor (in this case you). Our reviewers are there to make sure that every question is answered perfectly.
If Skypher solves the problem for you, great!
Here's what I know about our product - we can ensure that the quality of the responses are exceptionally high - our customers tell us that they're at or better than the responses that their teams would be providing.
Ultimately, what I think that translates to is more time saved on our customers' end and less back-and-forth with their prospect's infosec team to get the deal closed.
Super exciting to see more companies solving the security questionnaire pain points :)
Hope we both can solve this problem for the market and make it a win-win for all security, sales, and engineering leaders!
No one likes wasting time filling out forms, but in large businesses, theres a need to ensure the whole service (incl. subcontractors/vendors/data processors) are operating properly. So yeah some confirmation is needed... 200 page docs though? Geez. I think ours is ~15.
Questionnaires get sent when companies want to do business together that requires sharing sensitive info with each other.
I envy that you have never had to deal with these!
A lot of auditors make it seems like once you have your SOC2 or ISO27001 certification that you'll be free from these forever, but our finding is that it might get you out of 20% of these at best, and for the rest it's basically table stakes.
I'd be willing to bet (and infosec folks doing assessments should chime in here), but it's rarely, if ever, a binary decision on a single question (unless you have absolutely no encryption on a service that's handling sensitive information). It's a consistent degree of carelessness and lack of attention paid to basic security blocking and tackling.
You'll typically lose deals in security review because you've done no vulnerability scanning, have never done a pen test, are using outdated encryption, don't demonstrate that you properly protect data - and oh, by the way, you want to handle customers' or employees' sensitive personal information. If that's the case, your company should spend a month patching up these basic security gaps and delay on returning the security questionnaire.
Ultimately, we allow companies to edit and change responses (and require approval of any Stacksi-generated ones) to make sure that the responses are an accurate representation of the company's security processes and policies.
That's the purpose of having multiple levels of review.
Things go like this: AI takes first pass / Human on Stacksi team reviews for accuracy and quality / Stacksi Account Manager reviews with the customer.
I think our current customers would attest to the level of quality we're able to attain with this approach.
I see Stacksi as giving our client's an extra pair of hands on their team to help with this tedious work. We're a jr. team member though, so our work needs to be checked over before being sent :)
However answering these questions without nuance and context can at best cause a lot more back and forth between company and vendor, and at worse kill the deal immediately. Example:
Bad way, no context: Do you have external certification for HIPPA/PCI compliance: No.
Better way: Do you have external certification for HIPPA/PCI compliance: No, because product does not collect, store, or process health data or payment card data.
How do you handle cases like this in an automated fashion?
We build a 'profile' of the company - what it does, they systems used, the type of data it handles (and doesn't) to answer these questionnaires.
Part of the purpose of having a human-in-the-loop - especially for the first 1-2 questionnaires, is to support this type of review and ensure that answers are a sufficiently high quality.
As a general rule of thumb when answering security questionnaires (which our system supports), any "negative" answer should have additional clarification. FWIW, I'd say that a more appropriate answer to that question would be N/A instead of No to avoid confusion, assuming that the company doesn't handle any PHI / CHD.
This is pretty much the experience I expect. And I just don't see how this can be automated well (yes, I read the human-in-the-loop remark, but also the 15 seconds one), if there's such unstructured data, both on the input as well as the output side of this process. It seems to me you're just going to be renting out a glorified copywriter or editor.
It's totally fair to be skeptical that we can pull that off. I will say though that we are fanatical about NOT making this a business where we hire lots of humans to be reviewers. We'd rather fail than hire an army of low wage workers to do the soul sucking job of reviewing other people's questionnaires all day every day.
1. How do you handle any liability from having security-sensitive internal docs/info about all your customers?
2. How do you handle any liability from mistakes you make while answering questions? (Of course, both "good" and "bad" incorrect answers can be very bad, for your customer and/or their prospective/customer -- an incorrectly "bad" answer might cost a sale/relationship, and an incorrect "good" one might be relied upon and lead to a compromise incident or regulatory noncompliance.)
3. How many prospective/customers of your customers will accept security questionnaire answers prepared by an outside firm? How many will require the diligence and assurances to come from sufficiently knowledgeable in-house people, with the company standing behind it?
Seriously speaking - you bring up some interesting questions. I used our tool to respond to your questions, because I think it helps illustrate the point (see link below)
https://www.loom.com/share/22ccb2188c3744cd82f17baa31cfb2e9
A question for how you would deal with a client's IP was not really answered. Yes or no questions: Do you have some kind of liability insurance? What actual operational controls do you have to keep client information secure? Saying things like, "only people who are authorized to see the data can see the data." Doesn't say anything meaningful. What tools do you use? Actually use? Do you have samples of the reports, if you have them?
I've been at start-ups and those were superficial answers that I could send if a client/partner/vendor needed to check a box.
But I've also worn the hat of asking for those to be filled out and really caring about the answers. I wouldn't take anything I've heard so far as an indication of anything other than buzzword competency in a information security and compliance vocabulary. Sorry.
However, you'll have to forgive us for not posting all of that in a HN comment. I understand that you "wouldn't take anything that you've heard so far as an indication of anything other than buzzword competency" but I assume you also probably wouldn't be conducting such diligence in HN comments.
My answers go something like this:
1. We handle a company's security documentation the same way companies treat any sensitive info they are storing (credit card data, PII, etc). We store it encrypted at rest and in transit, ensure that only employees who need access to said data have that access, require 2FA on everything, require sufficiently strong passwords, encrypt the hard drives of our laptops, virus scan every file that is uploaded before use, virus scan our servers daily, virus scan our laptops daily, etc, etc. We are not SOC2 compliant today but are heading down that path so that we can provide our customers with the confidence that we can be trusted with their information.
2. We have liability insurance for our own company, but we do not take liability for our answers because every single answer is required to be reviewed by an admin or security team member of our client before it can be exported from Stacksi. If an answer has not been pulled directly from a client's policies, we specifically highlight it and review it with the client to ensure that it is accurate and that they are 100% comfortable with it.
3. I have no idea what an assessor might think of one of their vendors using a company like Stacksi to help handle questionnaires, and I imagine it would vary wildly from person to person. However, I see Stacksi exactly the same as having an extra team member on your infosec team who exclusively handles inbound questionnaires. You (their boss) make sure they are familiar with the policies and procedures of your company, and then you review their work to ensure that it is accurate. Does it really matter whether that person is a full time employee or your company, an infosec contractor who helps out part time, or a service like Stacksi?
I'll watch it, but at this point, I don't see the value add.
If I'm big enough to use the product- why wouldn't I just have/use 'junior employee' you mentioned above?
The vast majority of answers to questions comes directly from a client's own security policies, which we (admittedly) trust are up to date and accurate. We do our best to ensure that we don't use files that were uploaded more than 6 months ago in our algorithms, but if we're getting bad inputs to the system you're going to get bad outputs. When our reviewers do write something new, we check with the client to make sure it is accurate and again, it needs to be explicitly approved by someone on the client's team who has the rights to review questionnaires.
I don't see how this is any different from a jr. employee at a company answering a questionnaire based on the policies and then asking their boss to review. The jr. employee is definitely not going to go through every system themselves to verify that the policies and documentation are accurate. They are going to assume the policies are good and then double check with a trusted source (their boss on the infosec team), exactly what we are doing.
We understand that right now we're not actually helping companies be more secure, and we've never claimed to be doing that. One of our first priorities moving forward is to develop additional tools to actually validate that what is being said in security policies is what is in place. We're not there yet because we are a small and young company, but we will get there :)
More importantly, because of the rush the knowledge generated during the answering of questions is not captured in a reusable format.
I'm curious if could generate Security and Privacy white papers for companies that need to arm their sales/marketing teams using the information collected while fill out incoming questionnaires.
Definitely something we'll be thinking about. Would love to run it by you as we build!
We also have absolutely no requirement for our customers to generate docs with us. Any high quality security documentation will do. If you want to spend the hours required to take something open source and adjust them to your needs, more power to you!
Getting legal involved is a whole other level of time/expense.
If you're talking about the NDA process between vendors and assessors, that is a whole different can of worms which we have not really waded into at this point.
In my experience as a startup founder, the easiest way to handle these types of situations is to just read over and sign whatever NDA the bigger company has sent over.
That can cause problems down the road for a receiving party. For example:
1. Some NDAs include terms that assign ownership of newly-developed IP to the big company — this once resulted in Stanford University losing part-ownership of one of its biotech patents to Roche, in a case that Stanford (unsuccessfully) took all the way to the U.S. Supreme Court. [0]
2. Many, many old-fashioned NDAs still require the receiving party to return or destroy all of the disclosing party's confidential information. That can be quite burdensome and expensive for electronically-stored information. (Imagine having to search all your emails and backups to identify the disclosing party's confidential information.) And in any case, as insurance for possible future litigation, the receiving party would want to keep an archive copy to document what it received — and by implication, what it didn't receive — from the disclosing party. [1]
[0] Federal Circuit case: https://scholar.google.com/scholar_case?case=679137785502826... Supreme Court case: https://scholar.google.com/scholar_case?case=168732492844241...
[1] Additional information: https://toedtclassnotes.site44.com/Notes-on-Contract-Draftin... (my course materials for the law-school business contracts class I teach; it's a still-crude interim draft)
I fully admit that we do not have the legal expertise to try and tackle that problem at this point.
FWIW, I think pima (pima.app) does a pretty good job with this.
Additionally I'd be a little wary of handing off all my documentation to a third-party how do you protect this?
We also never send customer security data to 3rd parties, so your data is not heading off in some API to be processed externally, it all happens entirely in our environment.
Admittedly, we've not done SOC2 or ISO27001 yet (the company is only a few months old), but it's on our roadmap, and we're putting the appropriate controls in place from the get go.
I doubt I'll be able to convince you to trust us in a HN comment, so if you'd like to hear more, please do reach out :)