Sorry- but the responses were regurgatory and vapid.

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.

Did you seriously just join HN to try and troll our Launch HN post? If so, I'm sorry, I hope you find better uses of your time. We're trying to solve a problem for founders and infosec teams alike. You're perfectly entitled to your opinions and judgements. Feel free to build something and share it with the community if you disagree with our approach. You can get in touch with us through our website if you'd like to try the product. Thanks!

Questionnaires are definitely a pain point for folks, but I'll have to wait and see if it's really viable to outsource them. How's that? Nicer?

Much :)

Yes. A co-worker suggested it, and when I read about it and saw the response, I joined and commented.

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?

If you want to go in depth on our operational or security controls in due diligence as a potential customer, we'd be happy to do so over email. You could even send us a questionnaire ;)

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.

You share what you want to share, of course, but they're also just challenging their (I have to assume: earnestly) perceived holes in your business model, you could just trying to answer in general terms, without having to post the detailed legalese here.

You're right.

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?

Oh and, "How many prospective/customers of your customers will accept security questionnaire answers prepared by an outside firm?" Was answered by saying that being a third party- hey! That brings value right there! Huh? You're helping answer questionnaires. The risk is that your bullshitting my clients by writing technical, impressive answers but you don't work at the company. You don't know if - do you check if it's 256 bits or 512 bits? And why it's better or worse to use one or the other? No-You're not designing, implementing, monitoring, or auditing in any way, are you? Your deliverable is to eat data and format/match it to the questionnaire. How is your product actually add value to infosec and GRC? I can't use an answer written by you that explains that your company is actually adding value other than making answering questionnaires more efficiently. I mean- that's a good thing- but it doesn't validate you and answer the question above.

Every single answer that comes out of Stacksi needs to be approved by an employee of the client before it can be exported and downloaded.

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 :)