I got asked the other day why a properly scoped ISO 27001 boundary couldn’t be a substitute for FedRAMP. And that got me thinking.
I used to have a really bad attitude about ISO 27001. Mainly because I’m used to the technical rigor of the NIST 800-53 control set. But the more I’ve worked with ISO over the years, the more I’ve come to appreciate (A) its reasonable approach to documentation and (B) its common sense approach to the management controls that, while they may not be technical, underpin a mature organization’s approach to security.
In fact, for the non-technical controls, I’m pretty sure I like ISO 27001 better than 800-53.
Unfortunately, aside from the fact that most ISO audits aren’t exactly renowned for their rigor, ISO 27k is pretty loose with technical controls. Not only do the ISO technical controls lack the specificity of the FedRAMP set, ISO is also really liberal about risk acceptances and boundary definitions, two things that don’t fly for FedRAMP.
So, I decided to pretend that I was a government Authorizing Official (AO) looking to authorize, at the moderate level, a cloud service that was ISO 27001. I asked myself, if I were in those shoes, what is the efficient set of 800-53 FedRAMP controls that I would want to see as an overlay on top of ISO 27k to give me about as much confidence in the ISO system as a FedRAMP moderate one. I also wanted to make this exercise somewhat rigorous, by picking controls that actually map to known security issues with some quantitative validity.
In the end, I picked 20. That’s it.
I was surprised, honestly, that I was able to scope it so tightly. But I stand by it. if I were an AO, and your cloud solution was ISO 27001, and you demonstrated to me that you were genuinely elite at this focused set of 20 technical controls, I’d have no problems signing your moderate authorization.
Here goes, with controls mapped to practice areas.
Vulnerability Management
- Evidence of Importance: Lots of different reports into attacks highlight that that vast majority exploit years old vulnerabilities that just don’t get patched.
- NIST Control: RA-5
SATAN, one of the first network vulnerability scanners, was released about 30 years ago. So you’d think that we’d be pretty good at it by now. But so many companies, even big ones, (A) don’t scan, and (B) don’t patch. ISO 27001 lets you get away with that via liberal risk acceptances. But if I’m the AO, I expect to see a disciplined, full-scope, full-coverage vulnerability scanning program. And I expect you to patch your damn systems.
Endpoint Detection and Response
- Evidence of Importance: EDR is associated with a 1/6th reduction in cyber insurance claim cost. We also see attackers going out of their way to avoid modern EDR (like this: https://www.s-rminform.com/latest-thinking/camera-off-akira-deploys-ransomware-via-webcam)
- NIST Control: SI-3; SI-4
Many of the security operations folks I respect most say that EDR is the one thing they can’t live without. Yet so many companies either don’t run modern EDR or have poor asset coverage. If I’m an authorizing official, I want to see a EDR everywhere feasible.
Misconfigurations
- Evidence of Importance: Misconfigs are the initial access point for 30% of cloud breaches, according to google cloud.
- NIST Control: CM-6
Misconfigurations are such an easy attack vector, and yet so few companies do significant hardening. Pick a baseline, preferably the CIS benchmarks but if you truly hate yourself go STIGs. Then implement it consistently and everywhere.
Network Monitoring
- Evidence of Importance: I got nothin’, just not letting go.
- NIST Control: SI-4, SC-7
Network monitoring doesn’t get much love these days, with many companies forgoing IDS or nextgen firewalls and just relying on EDR. But I’m old and still think span ports are cool. Collect network telemetry and you’ll thank me next time you have to put the kibosh on a massive exfil.
Network Segmentation
- Evidence of Importance: So many successful attacks (e.g., per Picus’s report on 2024 breaches, look at the AWS .env variables attack, Johnson Controls and AT&T) had lack of segmentation as a defining feature.
- NIST Control: AC-4; SC-7
Lots of companies, especially smaller SaaS providers, look at me like I’m a senile grandpa when I say that they need to aggressively segment their cloud networks. But network segmentation is often the difference between an event and crisis. It also makes monitoring so much easier (e.g., why is that machine over there trying to talk to this machine over here?). If I’m the AO, I want to see a disciplined, segmented network. So get off my lawn, and get back in that lawn over there, where you belong.
Logging
- Evidence of Importance: IBM / Ponemon finds that companies that detect fast save approximately $1.12m per breach.
- NIST Control: AU-2; AU-6; AU-7
Many companies have spotty logs covering patchwork sections of their infrastructure and may not have application-layer logs at all. FedRAMP makes you collect a defined log set, centralize them for correlation and analysis, and retain those logs for a documented period of time. This is basic security blocking and tackling that I would expect to be done well as an AO.
Software Assurance Testing
- Evidence of Importance: A three-year study by Synopsys revealed that 92% of test discovered vulnerabilities in the applications they tested. That’s a high hit rate.
- NIST Control: SA-11, SA-11(01), IA-5(07)
While static analysis is limited and full of false positives, it at least catches the easy stuff. It’s the year of our Lord 2025, yet software still winds up in production with juvenile vulnerabilities. So I would expect to see a disciplined software testing program that would at least keep the stupid stuff out of code. And please, no hardcoded authenticators.
Third-Party Security
- Evidence of Importance: 61% of respondents to a Prevalent survey experienced a third-party data breach in 2023; Per KPMG 73% of organizations have had a third-party initiated disruption in the last three years.
- NIST Control: SA-09
While FedRAMP is too strict, and agencies too risk adverse, when it comes to unauthorized third-party cloud services, as an AO I’m not willing to back off entirely. I wouldn’t want my data sent willy nilly to random unauthorized clouds, or there to be complex interconnections that allow lateral movement.
Access Control
- Evidence of Importance: Verizon DBIR says that credential related issues account for 40% of breaches while Google Cloud pegs it at 47% in the cloud.
- NIST Control: AC-8, IA-2(01), IA-2(02) IA-5, IA-8(01)
Saving the best for last, access control / identity is obviously huge. While ISO 27k technically covers it, ISO’s risk acceptances for access control issues are too generous. I need to know that you’re using a modern IdP (nothing homegrown, please) that the number of folks who have access to production is tiny, that they can’t do silly things like direct SSH in, that they use phishing-resistant MFA and that there are disciplined processes around identity verification and credential distribution.
What Do I NOT Care About for Low and Moderate Systems?
Pentests: Most of them are lame, glorified vulnerability reviews, especially those that follow the FedRAMP rules. When elite teams do them without any handcuffs, the results can be useful. But that’s rare.
Training: ISO 27k requires general awareness training. Fine, it can’t hurt. But FedRAMP layers on role-based, incident response and contingency, and insider threat etc training. There’s just no evidence that this stuff actually prevents breaches. So give it a rest.
Dedicated Federal Systems: There is no security benefit to requiring separation of federal and commercial data for Moderate data. 0. Zilch. Nada. I will not be convinced otherwise. Stop requiring it. There are various reasons that companies might choose to go down that path anyway. Fine. Just don’t make them do it.
Dedicated Ticketing Systems: Related again, FedRAMP essentially requires it, but it’s dumb. Fine, have a rule that keeps logs out of customer support ticketing systems. I get that. But let’s quit making people stand up dedicated ticketing systems.
Dedicated SIEMs: Ditto ad nauseam, FedRAMP essentially requires dedicated SIEMs for security monitoring. So you know what happens? Commercial providers pour all their resources into their commercial SIEM and monitoring team and spin up something janky for the feds that they end up ignoring. Stop making them do that. Lumping security monitoring into one centralized tool isn’t just easier, it’s a lot more effective for security teams.
Dedicated Authentication Systems: I’m on the fence for this one, but since I’m keeping it streamlined I’d accepted a well-run corporate authentication system with dedicated federal credentials and phishing resistant MFA (ideally hardware tokens). I’m not convinced that dedicated authentication systems make a significant difference to security posture, though I could be talked out of this.
FIPS-Validated Cryptography: LOL! What does that even mean anymore.
DNSSEC: I mean check the box in Route 53, sure, but turning ourselves inside out to implement DNSSEC in boundary? Most attacks today focus on compromised credentials, phishing, or direct misconfigurations, rather than sophisticated DNS spoofing.
Documentation: The ISO documentation set is perfectly fine. Death to SSPs.
There you have it. A 20-control overlay on top of ISO 27001 that, as a federal AO, I’d feel pretty good about at the moderate level.
