rosswilson and HereBeBeasties hit the nail on the head with their replies. As my company (a 3 year old enterprise SaaS platform raising a Series A) lands more clients, our highest-priority feature requests have been around (1) granularity of permissions, (2) granularity of workflow rules, (3) ability for clients to administer their own roles and permissions (through a UI or using SAML metadata), (4) APIs, and (5) reporting, in that order.
Your first couple security reviews are going to be a beast. They'll take time and you'll have a lot of technical and process remediations to do. When you go into a security review, make sure that the IT team on the other end understands what you do, what kind of data you'll be handling (if any), who at their company will have access, etc. You'll get the same security questionnaire as any other external vendor, but if your application is less sensitive you can sometimes make a strong case that the bar should be lower for you in certain areas. Sometimes (not always) you can use "we don't handle sensitive data" as a mitigation instead of building out an unecessary security feature.
If you haven't already, you'll need to create a set of Security Policies that you (and your future team) will follow. This can start out as a short document explaining your software development lifecycle and some common-sense policies like "we use MFA wherever possible" and "we encrypt data in transit and at rest." You'll end up making a lot of revisions to this document early on as you go through your first security reviews and start to align your process with what your clients expect and require. You can refer back to this document in security reviews as supporting evidence of your best practices.
The best thing you can do early on is track all of the technical and process requests from these security reviews, even the ones you don't incorporate. Keep a spreadsheet listing all of the technical and process requests from each of your clients and how your organization compares (e.g. "Client A requires 10 iterations before password re-use; we require 12" or "Client B has asked for strong encryption on passwords; we use PBKDF2 with a SHA256 hash"). This will make it easier to fill out future security reviews and it gives you a list of requirements when you consider changing something like your authentication user experience.
Find a third-party Penetration Testing as a Service company that you trust and start working with them right away. Getting an annual third-party pentest will be a requirement for almost any enteprise client, and it will give you a good idea of where you stand before heading into a security review. Our partner (BreachLock) also does monthly scans against our production website to make sure we haven't introduced any obvious security bugs.
It does get easier: once you've passed a handful of security reviews you'll be in a better position to push back on unreasonable requests. First off, you'll know what's reasonable and what's not. Second, you'll have enough other security considerations in place that you can make a good case for mitigation.
Finally, an aside... I want to reiterate the importance of keeping audit logs above and beyond what your clients might request. If you use a package that tracks every change to your models and who made those changes (django-audit-log or sqlalchemy-continuum in Python world) you'll be able to check the "audit trail" box during security reviews. But a hidden benefit is that you'll have a wealth of data you can mine for reporting later. You won't know what your clients want to report on until they're using your product, so keeping all of this data makes it much more likely you can do some archaeology and give them historical reports when you (and your clients) find out what's most important to them.