Before the AI spectacle of RSA arrives, let’s talk about what actually keeps regulated organizations secure
RSA is only weeks away. And if you’ve been paying any attention to the pre-conference buzz, or if you work in technology generally, you already know what it’s going to feel like walking that floor: artificial intelligence, everywhere, in everything. AI-powered detection. Autonomous response. Agentic security copilots in everything from threat monitoring to your morning coffee. The demos will be impressive. Some of the technology will be genuinely transformative. I’m looking forward to it.
But I want to say something before we all get on planes to San Francisco – something that tends to get lost in the excitement of a big conference year.
The fundamentals haven’t changed. And in the noise, they’re getting harder to hear.
That’s why at CalCom we’re talking more openly about compliance these days. Because in the industries we serve, including banking, healthcare, government infrastructure, security and compliance are tightly connected.
The problem is that too many organizations assume compliance is security. It isn’t. But it is the baseline. And when you treat it as such, you build from solid ground instead of false confidence.
AI-Driven Security Tools Still Depend on Strong Security Fundamentals
Let me be clear: we are not AI skeptics. Our core product, CalCom Hardening Suite (CHS) relies on it. But there’s a difference between adopting new capabilities and becoming consumed by them.
New capabilities deserve attention. They just shouldn’t come at the expense of disciplined configuration, hardening, and control. In regulated environments, no amount of AI layered on top can compensate for weak baselines, unmanaged configuration drift, or inconsistent hardening. The fundamentals still carry the weight.
The most advanced threat detection platform in the world cannot compensate for server misconfigurations that need to be fixed.
Unhardened Baselines and Server Misconfigurations: Where Breaches Begin
Here’s the reality: default device configurations were never designed to meet regulatory standards. Out-of-the-box server or workstation builds routinely fall short of hardened baseline expectations, and attackers know it. Not zero-days. Not sophisticated tradecraft. Misconfigurations.
Baseline Hardening is the discipline of systematically removing unnecessary services, locking down default credentials, enforcing least-privilege access, and establishing known-good configuration states across your server environment. It is not glamorous. It does not demo well. It will not get its own keynote slot at RSA.
But it works. Consistently. Quietly. And in regulated industries, it is not optional. If you operate in a regulated environment, audits are part of the operating reality. Compliance begins with disciplined control over your configuration baseline.
CIS Benchmarks: The Standard That Should Already Be Your Standard
The Center for Internet Security’s CIS Benchmarks represent some of the most rigorously developed, consensus-driven configuration guidance in the industry. These are not arbitrary checklists. They are the distilled output of security practitioners, vendors, and researchers working together to define what secure looks like for specific operating systems, cloud platforms, databases, and applications.
When we harden a client’s server environment, CIS Benchmarks are usually the foundation. They give us a defensible, auditable, widely recognized baseline one that aligns directly with what regulators and auditors are looking for. If your team isn’t actively working to CIS Benchmark standards, that’s a gap worth addressing before you evaluate any new AI-powered tool.
FFIEC Compliance and the Security Discipline It Demands
For financial institutions in the US, the Federal Financial Institutions Examination Council’s guidance including the FFIEC Cybersecurity Assessment Tool and its successor frameworks is the regulatory foundation of their security programs. Too many organizations treat FFIEC compliance as a documentation exercise. Something you do to satisfy examiners, distinct from the “real” security work happening elsewhere.
That framing is a mistake, and an expensive one.
FFIEC guidance maps closely to the actual attack surface of a financial institution. It demands attention to access controls, patch management, vendor risk, incident response, and configuration management, exactly the domains where breaches originate. When you approach FFIEC compliance as a security discipline rather than a compliance checkbox, you end up with a stronger security posture almost by default.
The same dynamic holds across regulatory regimes — whether it’s HIPAA in healthcare, Digital Operational Resilience Act in the EU, NIST2, or The UK Cyber resilience build — each framework ultimately reinforces disciplined control over systems, access, and configuration.
This is the overlap we’re talking about. This is why we’re speaking more directly about compliance.
Security and Compliance Are the Same Conversation in Regulated Industries
There has long been an artificial divide in this industry between “security teams” and “compliance teams,” as though their work exists on parallel tracks that occasionally intersect during audit season. In our experience working with regulated organizations, that divide is not only false, but operationally dangerous.
The controls that satisfy an FFIEC examiner are largely the same controls that reduce your attack surface. The server hardening your security team performs maps directly onto the configuration management requirements in your regulatory framework. The patch management discipline your team maintains satisfies both your CISO and your auditor.
We’ve always understood this. What we’re choosing to do differently is say it out loud, consistently, as a core part of how we position our work because our clients deserve a partner who speaks both languages fluently and refuses to treat either as secondary.
Go to RSA. Explore the AI. Then Come Home and Check Your Configurations.
I’ll be at RSA. My team will be at RSA. We’ll walk the floor, see the demos, have the conversations, and come back with a clearer picture of where AI-driven security tooling is genuinely maturing and where it’s still mostly slide decks.
But here’s the question I’d encourage every security leader to ask themselves when they return: Is my foundation solid enough to layer any of this on top of?
No AI-powered detection platform catches threats introduced by a misconfigured server you didn’t know had drifted from its baseline. No autonomous response tool closes the regulatory gap created by an FFIEC finding from 18 months ago that never got properly remediated. No shiny new capability substitutes for the disciplined, unglamorous work of getting your environment hardened and keeping it that way.
The organizations that are hardest to breach and easiest to audit are usually the ones that got serious about fundamentals before they chased the next innovation cycle. That’s not a criticism of innovation. It’s an argument for sequencing.
We’re talking more about compliance because it matters. Because in regulated industries, it has always mattered. Because the difference between assumed security and actual security won’t be solved by an impressive RSA booth.
If you’d like to meet at RSA to talk about server misconfigurations, regulatory compliance, or anything else, reach out directly, or schedule time on my calendar.
