I recently left the US Federal “Cyber” space, which involves practically everything that enterprises claim they want with respect to “security”. I also work for a company looking to get into the enterprise space, so have some experience on the side of spinning up these practices.
> After meeting with our first client's security team it's clear that we don't have any of the procedures in place that these clients are used to vendors having with regard security and oversight.
As mentioned in other answers, your potential customers will often give you an absolutely brutal questionnaire about this in the early exploration phase. Something that may surprise you though is that many “requirements” can actually be waived or reduced in scope, especially if the individuals investigating your product have some clout within the organization.
Be attentive to the actual needs of these customers, not the “hard requirements” of the paperwork, but make sure that as part of the legal paperwork all of your “we won’t have this ever, we don’t have this yet, we have this in x capacity” answers are all in writing. You might be surprised how many of these “requirements” don’t actually matter once these answers are written down.
Note that I mentioned “we don’t have this yet” as a valid answer. Some of the requirements presented might actually be things you know you need to implement, but don’t have the capacity to do so immediately. In my experience, customers appreciate your honesty about these sorts of requirements and can temporarily waive them with the understanding that they will be made available at a later date. Be sure that you mean what you say here: saying “we’ll have this at some point” can eventually become a point of contention if you don’t ever actually implement these features.
> While our app and infrastructure has been built with common-sense security and best practises, we haven't put in place things like vulnerability scanning, anti-malware, patch management procedures etc.
I have no idea what your tech stack looks like, but if you use cloud services at any level, you should look into how your cloud providers fare against the provided requirements.
Other answers have mentioned NIST SP 800-53 as a potential starting point for security requirements. This set of standards includes the concept of “inherited controls,” where the security requirements can be fulfilled by your upstream service providers without any additional effort on your part. This same concept also applies to the private enterprise space.
As an example, if you use a “serverless” architecture from a major cloud provider, you can automatically assume compliance with “anti-malware,” host-level vulnerability scanning, and patch management requirements. If you host your source on Github, you can legitimately claim Github’s built-in dependency vulnerability alerting as source-level vulnerability scanning.
If you happen to be running your own infrastructure here, your employer should seriously consider a migration to managed services wherever it makes sense to do so. Technical compliance with security requirements is a huge operational overhead. There’s a reason the US Federal Government has given up on in-house hosting and is now buying cloud services from Amazon and Microsoft.
> 3. Documenting procedures
At a tactical level, in order to close a sale or get your security validation, you’ll want to take the approach of “document first, implement eventually.” The best technical implementation of security controls in a NIST SP 800-53 scenario will utterly fail validation without adequate documentation, but you could skip actual implementation entirely and still squeak through an assessment with no more than an answer of “we promise to follow our own documentation.” counter-response.
Sure, you’ll eventually need to implement the documented procedures and follow the documented policy. This is going to sound extremely cynical, but so long as the fault of non-implementation can be externalized from the rest of the organization, the end customers will be happy enough to keep paying you. This is why documentation is so much more important than implementation: end customers and vendor organizations get to state that they already went through their due diligence by writing everything down, and point fingers at individuals when things aren’t following the documentation.