yeah,

that makes sense, Jake.

Then I go, okay, I've now got a whole set of security tools, like you pointed out, whether it's DR or Endpoint or GRC, whatever it might be, right? I'm now going to align that to my risks.

If I have after that point, if I have a risk where there's no tool, no headcount, no consulting, no services associated, that risk is exposed.

I've done nothing to buy down or reduce that risk.

On the flip side, if I now have a product or a person or a service where I can't attach it to any of my specific risks, why do I have it? Like I can't demonstrate the business need for that thing.

So by presenting the risk register as my business case, effectively saying, here's my risks.

I don't know why, but if you were to bring it down to a layman and, yes, definitely, like our procedure, without it feeling like a checkbox which someone is supposed to complete, how do you best present it to people who are being audited and also, at the end of the day, how are you able to manage that pressure?

And then if we look at where we are now, We start to say,

what will we do next? Like, if we now have this data, like, forget, like, here's the control, here's the evidence, here's the auditor.

Like, what workflows can I build? Like, how can I look at things that we're still doing and try to do them in a smarter way? So maybe look at, like, a risk assessment.

Historically, still, like, risk is like a finger in the air job, right? Everyone's risk register is, I take a number of risks.

I think they are risks because of AD&C.

I think the exposure and the likelihood is...

DNA, and therefore the value of that risk is F.

Is that a massive concern? I know you said it shits on shits out, but do people actually trust what it is spitting out because it's so high stakes, a lot of this stuff?

Can you elaborate a little bit on that?

Gosh, that, yes.

I've written that in a lot of places, in a lot of different variants, but I'll give you the most condensed version.

I think compliance has broken from every direction, right? I think if you look at how we came to a compliance journey, really like SOC 2 was written in the late 20 noughties.

It was like 2008, 2009.

And it was built for a time when we had DCs, like corporate infrastructure.

We deployed and maintained our applications.

And you were just touching on this, but could you give us a little bit more detail on FedRAMP 20X? What is it really doing differently? And then why should people who are listening to this be thinking about this compliance overhaul?