Use their same language back at them and talk about your "compensating controls". That's auditor lingo for I know A is the standard control but by doing B and/or C instead I have adequately addressed the risk.
Ran into this sort of thing at a .gov during audits for systems accreditation in 200x.
I made the mistake of using 'mitigation' in my
documentation and opened up a can of worms with the contracted auditing firm. They should have provided
a glossary of weasel words.
Took twice as long to get the system accredited because
of a common sense initial approach.
For a system in the scope of the audit, if you can demonstrate that the files coming in are checked for malware before they get on your critical systems, this is one example of a compensating control.
Further, if you can demonstrate in auditable fashion that there are no browsers or other network connections or other typical vectors for infection, that can be a compensating control.
[Edit]
Or if you can demonstrate that your email system will drop all attachments and links, that would be another (annoying) way.
So, in a typical SAAS cloud application environment, is ISO 27001 just off the table for anyone serious about security? As (in effect) the CSO for a bunch of decently-sized startups, I would have a hard time approving the deployment of any kind of antimalware tool, because the risk simply isn't worth the reward. Even when deployed on isolated systems and not every end system and server, they're still intrinsically dangerous systems: they're essentially most of the attack surface of a browser.
No, you just need to have some compensating control. For example: there is a very limited number of ways that I can get files to the ec2, I can audit how this happens and also there is no browser running there.
So to put it another way: can you set and enforce a policy as to how files get to your aws instance, set and enforce a policy as to how (that is with what programs) those files are accessed. And that there is a way to audit that such a policy is in place and enforced.
As an example Azure its own self is ISO 27001 (and a metric ton of other certs) and they don't run AV on their stuff. But you can be sure that they can tell you everything about each of the components that make up Azure itself up to the hypervisor level. I would presume that the same thing is true for AWS.
So now you put your stuff on top of this base service. If you can assure the auditors that you have somehow controlled that particular risk, then you won't need AV.
Also, of the 114 controls in ISO 27001, not all of the controls are relevant for the scope that you choose. You could say that "since we have total control of the character and nature files that land on each of our VMs, we don't need to have that control". Often you may need only 50 of the controls.
The thing about ISO 27001 is about understanding the risk that your systems in scope are subject to (e.g., loss of PCI-protected data, fire, downtime), building policies and procedures addressing those risks, and repeatedly auditing that those policies and procedures are in place and adjusting them when they are not.
Pro-Tip: don't take the approach of telling the auditors that AV is a fundamental risk. That conversation is not likely to be productive. Just demonstrate your control over the environment.
ISO 27001 is not that far removed from common-sense security.
Ran into this sort of thing at a .gov during audits for systems accreditation in 200x. I made the mistake of using 'mitigation' in my documentation and opened up a can of worms with the contracted auditing firm. They should have provided a glossary of weasel words.
Took twice as long to get the system accredited because of a common sense initial approach.