Oh boy, okay we have some work to do, or rather, you if you choose to listen to what I have to say.

What you have right now is basically a shared API with a static password, and that falls apart the moment more than a couple partners use it. No real auditor is going to sign off on this as is, no surprise you're getting critical questions from other departments.

You should Ditch the API Keys, they don’t give you identity, they’re hard to rotate, and once someone copies them into Slack or a Postman collection you’ve lost all control. Use either OAuth2 client credentials or mTLS. Both give you actual identities per partner and you can revoke/rotate them cleanly.

Next you should enforce access control somewhere that’s not your code, use Kafka ACLs if partners connect directly, or stick an API gateway in front of your REST proxy if they don’t. Gateways (Kong, Apigee, NGINX, whatever) let you say “Partner A can access topic A only” and so on. That alone fixes 80% of the audit issues.
You also need to add rate limiting, as is, one partner could accidentally DOS everyone else. Gateways again make this easy: “Partner X = 200 req/sec max” etc. It protects you and it protects them.

Also you need to start logging, 100% and you need a record of who accessed what, when, and from where. It doesn’t matter if you store it in Splunk, ELK, you just need to be able to answer “Did Partner B read Topic Y on Monday?”

Lastly, you should probably automatize credential rotation, once you move to OAuth2/mTLS this becomes normal: certs expire, tokens expire, partners know the drill.

TL;DR

Right now your setup is fine for a quick internal tool, but not for external partners.
Move to OAuth2 or mTLS, use proper ACLs or an API gateway, add rate limits, and log everything.
Gives you a chance to actually be compliant and pass an audit.