How AI Changed the SOC, Part 3: A Certificate Is Not a Fitness Test
The concrete pillow: you can be fully compliant and still sell nobody what they wanted. Chris Jordan and Henry Denner on inherited compliance, what really drives SIEM cost, and the SOC report as an assurance paper.
What are you actually buying when you buy compliance? In Part 3 of our webinar How AI Changed the SOC, Chris Jordan's answer is the concrete pillow: you can be fully ISO 9001 compliant as a pillow maker while making your pillows out of concrete. Every requirement met, and not remotely what the buyer thought they were getting. The same trap catches people with a provider's certificate, because it is not inherited: I'm SOC 2, he says, does not mean you're SOC 2 when you use me. Henry Denner hears the same assumption from clients on Azure and AWS, that the cloud is compliant so therefore they are safe. The platform is only the road you are travelling on, and Microsoft will never certify that your systems are secure. The episode then gets specific about money. The cloud charges for three things, stored capacity, processing power and network bandwidth, and Chris traces per-event and per-data-source pricing back to Oracle charging by the number of processors in a machine: way more profitable, while the software never changed. It closes on what AI added to reporting, forecasting, comparison and analysis without knowing the data set in advance, which turns a monthly SOC report into a piece of assurance paper for an audit committee.
Transcript
Henry Denner: So with all of these awesome things to do with data, there's infrastructure behind it. So Fluency is not something that you host on-prem in your own data center, in your own server. Just tell us a little bit about Fluency from an architecture perspective. If somebody's thinking you need to change your Fluency, what do they actually need to be able to move?
Chris Jordan: So we have very simple ingress and egress points. So this is how we want to capture data. That's a data strategy. That's the whole reason why Ingext has its own name. We have to be able to capture the data, enrich it, and store it. And that piping, it's well understood. If you want to grab your Microsoft, I just send an email to admin saying, just click this. Put your tenant ID and click this. And they're up and running.
The data is coming into the system. Most people, you need what's called the endpoint, which is the URL and a token. And you're pulling the data. The older systems, you have syslog. So pulling the data is relatively easy. If you're not able to pull your data quickly in an organization, you have a problem with your customer or your product. Now, once the data is into the system, most people get caught up too much on what's going on.
Obviously, we have an entire framework of piping and enrichment and searching and alerting, and how do we interface, how do we get data out? And that's a longer discussion around scheduling and notifications and ad hoc querying. But the more important thing is, let's take a step back. You're in Africa. Data sovereignty is huge. So one thing that we do is we make sure that we can change where we are in the universe. So I have systems in Germany, Ireland, and Cape Town.
So we have to be able to place the data in a place where there's sovereignty. So we have to look at the requirements and how we store it. So it's not just what our infrastructure is, but where our infrastructure is. And then, again, how do we handle the data? We store the data for 12 months. Why? Almost every requirement is 12 months. You want more than 12 months? I can give you a namesake. You can store it for as many years as you want.
This is around understanding what are the actual governance requirements, and people miss that. That's probably the other part about infrastructure, is we build the infrastructure based upon the governance needs of the user, not our own governance needs. I'm SOC 2. It doesn't mean you're SOC 2 when you use me. That's the weird part. People think that that happens automatically. No. You still have to meet your requirements. I store your data for three months. And then you pay three times to four times as much money to be compliant.
Henry Denner: That's a very interesting statement you just made. I often deal with clients where they are on some other cloud platform, Azure or AWS or whatever, and they say, well, they are SOC compliant, so therefore I'm safe. And you explain to them, but guys, no, that's the road that you're traveling on. If your car is not safe, you're not safe. If your applications and service that you host on a platform is not protected, then you're not automatically protected.
And it sounds simplistic to you and I probably, but I've had so many clients that don't understand that concept. They would say, but here is the ISO certificate from Microsoft. That's it. But guys, it doesn't matter. That's the back end. Microsoft will never certify your systems from being secure.
Chris Jordan: I think the big one is the 9001. ISO 9001 was huge like 15 years ago. And what we used to joke is we called the concrete pillow. I can be 9001 compliant pillow maker, but I'm using concrete. Okay. I've met every requirement for 9001, but is that what you really wanted? And that's the thing. I can be ISO 27001, but it doesn't mean that's what you were really thinking you were buying. Yeah.
Henry Denner: Let's quickly touch on commercials. So a challenge that you often have is if you have a new client that's never had a SOC or a SIEM and you ask them, what is your EPS? How much data do you ingest? Or what's your log volumes? They look with you like your cash for the ghost. So from a Fluency perspective, just touch a little bit on the commercial side. Not what your actual costs are. It's just your commercial model.
Chris Jordan: So our commercial model is really simple. We create what we could — originally we had two different models. One was user assets and the other one was capacity. And then we combined them because what we found was that I give like the average user three gigabytes a month. But you have a capacity number and then you have an overage charge. And that's how we do it. 80% of our customers will never go into the overage charge.
They only do that if they're a massive data center or if they're storing multiple firewalls or they just and say, I've got 100 users and there's a thousand of them in their organization. Then the capacity in. But for the most part, that's how we do things. Now, you might ask, well, where's EPS? Where's the number of data sources? All these other things that you see. And the reality is, those things are created so they can charge more money.
Okay. Cloud only charges you for capacity of data stored and processing power. Those are the two ways you pay money. And network bandwidth. I'm sorry. Three. Three. So if you ask EPS, where's EPS? It's not in there. It's not in there. It's done because they're going to have to use more powerful machines and therefore more computation and they want to charge you for it. But the reality is they could have just charged you based upon gigabytes.
To tell you the truth, more processing power that the computation number goes to have. So this is a bizarre thing in our industry. It's who started it? Oracle. Oracle. When they did databases, they started realizing you could buy a bigger machine. So they started charging by the number of processors in the machine. Then the industry got a hold of this and said, I'm going to charge as much as I can. We all know this because we all bought Office 365 20 years ago. Some of us.
Henry Denner: And then now they charge you for a year.
Chris Jordan: Did they change the software? Did they? No. The subscription is just way more profitable. And EPSing is way more profitable. Charging for a number of data sources is way more profitable. So these are all ways people want to make more money off you. But the reality is you're only paying three things when you're delivering a service. And why do I have to have anything more complicated than those three things?
Henry Denner: Cool. Let's touch on the reporting. In my view, when you look at a SOC, the one thing that shows the value to any client, apart from generating that alert and waking somebody up until the top of the morning, is when you do that weekly or monthly report, when you are able to give something to a client and they can walk them and say, well, this has actually helped me. So touch a little bit on reporting capability.
Chris Jordan: So that's a major change. So let's go back to AI because it really starts with AI. AI allows us to do three things that we could not do in software before. It allows us to forecast. Not knowing the data set. Forecasting without knowing the data set. It allows me to compare without knowing ahead of time what the data sets are. It allows me to analyze without knowing ahead of time what the data sets are. So I can forecast, compare, and analyze.
Great. And I can do that in an individual case. That's what most people think about when they think about AI versus SIEM. But now I can grab all those cases and say, tell me the trend of those cases. Compare it to last month. Tell me what changed. These are massive questions. And it goes back to that very first statement I told you: decision making. Why do I need to know it? Because it allows me to make a decision better.
Then I can turn around and say, give me all my configurations. Tell me weaknesses in my configurations. Tell me how the configuration changed since last month. Do the same thing for my firewall. What rules did I change? How did that impact? These are massive questions that, like a year ago, when a SIEM could never answer. And now you can turn those reports out left and right if you have the right infrastructure. We do have the right infrastructure for that.
So everything I just told you about, we can do with our system. And that's the weird thing, is like when somebody realizes that they can ask a completely different question, they start seeing the real value. The real value wasn't what did you do last month? The real value is help me plan for tomorrow on what happened. Yeah. How can I fix and be better? Hercules is a great example. He lifted this cow up, or a horse.
I'm sorry, it's a horse. And every day he lifts that horse up. And then when he gets older, he's lifting an entire horse up. Obviously, that's not realistic. But it is realistic when it comes to AI, that we incrementally improve every day. Feedback, feedback, feedback. And pretty soon we have a system that we could never imagine. The strength of the system is much more stronger because of this feedback loop and the things that AI can now do.
Henry Denner: What you just mentioned about the firewall changes and configuration changes and that kind of stuff, that's quite important. Because when you look at things from a GeoSheet perspective or an audit perspective, all of a sudden, your output from your SOC becomes an assurance report, almost to a sense. Where you've got a report that's based on actual fact and not somebody in IT saying, oh, but we've got this. We've done a firewall conflict review. We check that systems change or don't change the environment that's going to be.
So that output from the SOC that says this is what actually happened this past month in your environment. Not how many alerts, but these are the things that change that matter. And it either makes your overall risk posture better or it makes it worse because you've made all of these changes. And all of a sudden you've got a couple of any rules in your firewalls, which means your environment is more at risk. So that report then actually becomes almost like an auditor saying, here's a piece of assurance paper that you can take to your audit committee or your risk people or your executives that says, guys, we've got a problem. We need to do X, Y, and Z. So it comes back to decision, as you mentioned. Yeah.
Chris Jordan: And there's two things that really come out of that. The first one is you have to know what person has to know how to ask that question. You've always had that data. My customers have always had that data. And for the last four months, they've had the MCP capability. But it's the person who knows how to ask that question, who realizes, oh, that can answer that question. The other thing that's really interesting is that a lot of things we just talked about, like firewall impact roles, surface area of attacks, which is you're getting at when it changes.
These are their own product line right now. And this is that thing people are worried about, the SaaS-opsy or the apocalypse of SaaS. What that means is that all of a sudden, I can now have AI use my data set and get me an answer that I would have paid another product to do. And now you've got this huge disruption. Because now the MSSP, with its tool set, can start answering questions where I don't have to buy another product.
And that's where does the data source come from? It comes from a very strong SIEM or data source. And that SIEM, like I told you, you talked about before, I'm grabbing the logic, put it in the MCP. Claude doesn't have to figure out how to run. It just has to figure out how to analyze and do those three basic things: to analyze that data, pull it in, compare, and then forecast. So this is changing the industry.
An MSSP is actually not obsolete, just the opposite. When you have an MDR, you're getting prevention in the past, and you're never improving. Now you get an MSSP that knows what they're doing or analyzing their data. You're improving every day. You're getting better every day. And that's the reason why I really think an MDR is a commodity. You shouldn't be buying MDR prevention and saying, I'm done. It means you're going to get hacked in a couple months.
That's what it really means. It means that you're not seeing the diff of what's changing and where your new risks are, and you're not staying ahead of it. And we like to say in the security industry, it's not that you're the strongest. You're just stronger than your neighbor.
Henry Denner: Yeah, for me, it's about the attack surface management. MDR doesn't help you to drive that to a closure, whereas it's okay. Let me close out with this, and I'm going to put you on the spot. Yeah. Give us your 30-second elevator pitch for Fluency.
Chris Jordan: Wow. It really changed. I would say that our elevator pitch is this. We might be the best at examining and using AI to close tickets and analyze data, and that's true. But the biggest change is that Fluency now with Claude and Codex and everything now empowers our users to ask questions to themselves directly to the SIEM. When every one of our competitors puts an interface in the way, they limit the answers. I'm doing the opposite. I'm giving you unlimited questions and unlimited answers.
Henry Denner: Awesome. Thank you.
About the webinar
How AI Changed the SOC aired live on September 16, 2026. It was a conversation between Henry Denner of ASI Connect, who runs security operations on the managed services front line, and Chris Jordan, CEO of Fluency Security, moderated by Patrick Evans. The session set out to answer one question: what are you actually trying to achieve with a SOC? Across four parts it covers how AI changes detection and response, what an MSSP should deliver beyond closing tickets, how data pipelines and infrastructure shape cost and compliance, and how buyers should evaluate vendors.
This post is Part 3, Cost, Compliance, and What You Buy. The transcript has been lightly edited for readability. Watch the full episode and the rest of the series on the Fluency Security YouTube channel, or book a demo to see how Fluency turns alerts into cases.