CMMC & Research – USC

Sit down with Daniel Akridge, CMMC CCP, Summit 7, while he talks with Rob Groome, CIO at USC Institute for Creative Technologies. In episode 15 of That CMMC Show Daniel & Rob discuss scoping & implementation pain points, L2 certification process, and so much more!

---

Transcript

Daniel: Hello everybody, welcome back to That CMMC Show. We’re now in 2026 — we took a little break over the holidays. I happened to venture to Australia, got to see some very interesting animals and eat some great food. Vegemite’s still off the table for me, sadly. But coming back full steam, and I’m joined by an incredible guest who I’ve gotten to meet in person and physically shake hands with, which is pretty rare these days — Rob from USC. Rob, thanks for joining us today.

Rob: Well, thanks for having me, Daniel. It’s good to see you again — it’s been a minute.

Daniel: It has been a minute.

Rob: Yeah, happy to be here, happy to see you. I’ve done the Vegemite — I haven’t been to Australia, but I’ve done the Vegemite. It’s a little too much for me as well. You’ve got to apply the right amount.

Daniel: I was told a little bit of butter, a little bit of Vegemite on some toast. It was okay, but it’s not anything I’d ever seek out.

Rob: Just grab a salt lick — it does the same thing.

Daniel: That’s exactly what it is. That’s what it tastes like.

Rob: There you go. So, thank you for having me. Rob Groome — I’m the CIO for USC’s Institute for Creative Technologies. We are a fully funded DoD research center; we’re what’s called a University Affiliated Research Center. We were stood up in 1999 to bring together Hollywood, the military, and academia, to transform the way the Army does training scenarios and training systems. Believe it or not, the initial impetus for the Institute was to build the holodeck. Our executive director was a very, very big fan of Star Trek — he was an old Paramount exec — and part of the credo, part of the remit, was: how do we put a soldier anywhere in the world in 24 hours, so that you can understand what their approach is going to be, how they’re going to handle it from a mental-capacity and stress standpoint? And then that work turned into post-traumatic stress scenarios for folks coming home from theater, and we’ve continued to grow and build on that. We just celebrated our 25th anniversary last year. I’ve been here off and on for those 25 years — I was the original IT director, then I stepped out for a bit and went to USC proper, where I was the director of security operations for about three and a half years. Then I left the university to go on a little sojourn to build a startup, and I had the opportunity to come back, and here we are.

Daniel: Nice. Now, you’ve seen quite a bit over that time. I’m thinking — cloud services weren’t exactly the hot topic in the ’90s when this started, right? Regulations really weren’t even in place for the internet, or any level of cybersecurity — that was a word no one could barely spell at the time. All the way through 25 years, and now we’re building holodecks and talking about cyber regulations and keeping North Korea out of our systems and all the crazy things. It’s a whirlwind. I knew you guys were doing some cool stuff — I did not know you did stuff quite that cool, especially the bridging of Hollywood. I didn’t know that was such a core component — the media training component. That’s amazing.

Rob: Well, think about when you’re training anything. Think about the regular trainings you have to go through every year — the sexual harassment trainings, the security trainings.

Daniel: Yep.

Rob: They are boring.

Daniel: So bad.

Rob: They’re the same drivel at any company you go to. It’s all written the same. So bringing that Hollywood element in ramps up the ability to have a better narrative and better storytelling. You build better stories.

Daniel: Yep.

Rob: The efficacy of the training is going to rise, and that’s what we’ve been able to support and try to accomplish. To your point, we’ve gone through it all — from the beginning days where everything was just “for official use only,” and then they decided that 800-53 and DFARS 7012 was going to be the new fun and the new joint in 2014–2015. That’s kind of where I got my start in this whole world. And then the shift to 800-171, when there was so much pushback on 800-53 and people saying there’s just no way this is going to happen — so they sort of tried to invent this new 800-171 so it didn’t look as difficult as 800-53.

Daniel: I mean, depends on who you talk to. I think that’s true — just as difficult in a lot of ways, in some ways more.

Rob: And then, given the nature of what was going on in the DIB, CMMC was that next logical step.

Daniel: And that’s the interesting thing we’ve seen. With DFARS 7012, people were upset about it, but no one was really too upset, because no one was actually doing it for a long time. Talking to people like you who’ve been on it for so long — and then I talk to people now who can’t spell DFARS 7012, and they just think CMMC is this multi-hundred-thousand-dollar burden on their laps, or potentially millions depending on the size, and they’re like, “Why did the DoD do this to us?” And it’s like, no, you signed up for this contract years ago. It’s interesting to see the dynamic. I was recently in a conversation where somebody lost a huge contract because they had an SPRS score that was lower than the minimum requirement for CMMC. It’s really starting to get traction.

But here’s the thing I’ve realized — I think I’ve shared this on the podcast before. People would call me and say, “Daniel, I’m protecting CUI.” I’d say, “Oh, fantastic, how are you doing it?” This is a true story: “I’ve locked my server in the attic. We should be good to go.” And you quickly realize it’s not that people lack the desire to protect national security and the warfighter. The motto of most people in the defense space is integrity, right? They want to protect the warfighter with what they’re doing — but the means to do it? There’s just not a deep bench of people who know that. And, by the way, taking your researchers and somehow making them redo the CUI training in a Hollywood theme — I’d highly recommend it; that leaves the rest of the world behind. But outside of that, one of the things we talk about pretty frequently is scoping and implementation of these requirements, because that’s the missing piece — especially in higher ed, because the CMMC Level 2 and Level 3 scoping guidance, I’ll honestly say, wasn’t really written for research. It was written a lot for manufacturing, or just your traditional corporate IT system. So in your world, what were some of the scoping and implementation pain points you wrestled with, and how did you look to solve for those?

Rob: Yeah, you make a really good point. There’s research technology on one hand, and then there’s technology on the other, and the requirements for each of those don’t sync — they don’t jibe. One of the challenges in a research environment is administrative access — those kinds of rights. As an IT professional, your first instinct is, “Nope, can’t have it, not going to do it, not going to happen.” Come into a research environment, and it’ll change your entire outlook on how that works. So some of that went into the planning: the boundary. What does our boundary need to be for our CMMC Level 2 enclave? We’d already gone through 7012 for years, but we wanted to segregate out the very specific requirements and the boundary for controlled unclassified information, outside of the FCI requirements, outside of what we’re doing from a DFARS perspective. So it was really making a determination of: what is our boundary?

Daniel: Yep.

Rob: How do we define our boundary? Who’s going to use the data? That was probably the biggest pain point — defining who’s using the data and in which way. Because before, it was just the wild west; we could just use the data and it was fine. And sometimes the sponsors just mark everything. So there was the identification of: what do we need to protect, how do we want to protect it, where do we want to put it? And from the implementation phases, our boundary changed a few times. I think that pivot is incredibly important — people need to go into this with the understanding that whatever you think your boundary is when you start, it will not be that when you’re done. That can range from the inside of the boundary — what systems, protocols, services, operating systems, requirements are inside — to where that boundary lives. For us, when we first started, our boundary was — percentages are hard, but I’d say probably 40 to 45% more broad.

Daniel: Okay.

Rob: Simply because nobody knew what the rule was going to be. Jacob will tell you — watching Jacob go through the whole thing for years, and you talking about it, and so many others — nobody knew what that final rule was going to look like. So we had to plan for the worst. And what was the worst? That every system that touched the environment in any way was going to be in scope. But then the rule actually did us a favor by taking out the system you used with your Azure Virtual Desktop. Taking that system out of scope reduced our boundary, reduced our scope, reduced the complexity. So those pain points we had in the beginning — “Oh my god, how many machines are we going to have to onboard into this enclave? How many systems will we have to manage? How are we going to show our auditors, when the time comes, that all of their home environments are protected properly?” No — they’re really not allowed to print at home.

Daniel: Yeah.

Rob: So that really helps reduce the scope. And then — I bring up printing. We made a decision as an organization — and we’re running an enclave, Azure GCC High and GovCloud — we made a decision that there’s no printing. No printing.

Daniel: No printing. By the way, the fact that you can make that decision is great. I know a bunch of IT people who’d love to make eliminating printing a corporate policy. Printing and boundaries — the conversations I have. Printing and plotting will break a boundary faster than anything else, because you have some legacy individuals who, potentially based on their political clout in the organization, can basically force that to happen. But what they don’t realize is that the risk — to your point — of expanding that boundary and jeopardizing an easier compliance case just shoots through the roof.

Rob: Yeah. And you go from not having to manage and maintain paper, which simplifies your boundary. We bought a printer, set it up in our CUI on-prem enclave, and then we removed it. We took it out. It was discussed with the researchers and the PIs — we said, “Look, do you really need to do this?” And they all kind of sat back and went, “No, we really don’t.” So that was another piece of the scoping: really having discussions about what you need. Not what’s a nice-to-have — what do you really need?

And then the other piece, from a scoping perspective, is something I’ve tried to preach when I can: don’t scope for today. Scope for as long down the road map as you can — two years, three years. If you can scope for what you believe your organization is going to look like at the time of your next audit, your refresh audit, do that. Because then you have limited chance of having a significant change that will cause an audit in between. And given that the wonderful folks in charge of all this don’t want to actually tell you what a significant change is, articulate what a significant change is — you want to make sure you’re playing things out. That was another scope change. I was at the conference where you and I met, and somebody asked the question — I think it was Cyber AB and the DoD on a panel — “Hey, what’s a significant change? Will you tell us?” And they both said no.

Daniel: So they’re like, “Wait a second — you want us to follow this thing, but no one can actually define it?” Well, yeah. That’s going to be a lawyer’s heyday, by the way. Unless the DoD provides — which I have a feeling, in an upcoming FAQ, we’ll probably see some clarification — but the DoD usually over-rotates on things, because they know two things really well: they know NIST, they know FedRAMP. So they’re going to over-rotate a little bit on that. But to your point, when it comes to that significant change — I can’t tell you, Rob, how many people I talk to who are technical people tasked with fixing CMMC for their business, and they don’t actually do the due diligence to interview the people going to use the environment.

Rob: That’s right.

Daniel: So they end up with this black box that no one is using or can use, because they didn’t, to your point, do the due diligence and the interviews. They didn’t plan for a one-, two-, three-year horizon. They were just like, “All right, here’s a technical solution, users — you have to adopt it the way it is.” And the users are like, “How? We don’t use those systems, and we don’t know a way to transform into them.” So that’s one huge missing piece I see all the time.

Rob: No, it is. And then there were a few auditors who came up at the next panel, right after those guys, and I asked, “What would you think is a significant change?” — given their experience, since they’d done audits at that point. This was, what, 10 months ago? They’d done maybe 50, 60 audits between them. And one of the auditors said, “Let’s say you add Linux systems into your environment — that’s a significant change.” We were on the fence on whether to implement Linux systems, whether to wait. But the minute that came up, the thought was, “Well, of course — you manage them differently, different security baseline, different access controls, different requirements.” So we came back and built a very mature Linux environment inside our enclave. And of course, because Murphy always sits right here and pokes you in the side of the head, the first project we needed to put into the enclave was, “Hey, we need a Linux system.” Great. So we would have had a significant change the minute after we went through our audit.

Daniel: And that’s what people don’t realize — that due diligence is going to save you so much time and money in the long term, especially on the research side. You don’t know what kind of work a PI wants to pursue. You don’t know what kind of systems they’re going to need to do the work. It’s not like a manufacturer where you’re like, “I know I have to always use these six systems every time, no matter the contract.” It’s, “No, we could be doing crazy PHI stuff for the DoD. We could be making training curriculum. We could be doing modeling and simulation for a new DARPA initiative.” It’s all over the place. And it goes to show the flexibility you have to have in the research world versus other major industries, because you’re literally just handed a piece of paper from the PI that says, “We need these seven requirements to do this work.” And you have to work in tandem with them to figure out: Can we achieve it? What’s the cost burden? What’s the spend? What does that actually look like? It’s so interesting, because prepping and laying the groundwork for a good boundary leads to that good certification — which, hats off, by the way, Rob. Certification Level 2!

Rob: Level 2, baby, all day. October 2nd will live in my brain for the rest of my life, I’ll tell you.

Daniel: I usually show people — I can’t obviously publicly show it — a CMMC certification we have from back in January, and I’m like, of all the money people have to spend to do this, they should ship you a gold-plated certificate, not the equivalent of a PowerPoint slide. That’s really what it looks like at the end of it. “Oh great, this makes me feel warm and fuzzy” — and it’s a bad one, right? October 2nd is the date. That’s incredible.

Everyone always asks this question, and I always have to ask people who join the show: Number one, how did it go? What types of people do they ask to interview? Any common gotchas you’d recommend other people going through certification be on the lookout for — like, “Hey, collect your FIPS-validated certificates ahead of time,” or “Make sure to ask your HR team this, or your operational security team that”? Can you give us a few pointers — where you went through the assessment and thought, “Man, I wish someone had told me to invite these people, or to do this ahead of time”?

Rob: Yeah, the assessment went really, really well. We prepared a lot. I’d say at least a couple times a week we’d have sprint meetings to talk about status, where we were. We prepped everybody who was going to be in the audit, in the certification process — and I did it in a bit of a different manner. I’d do it just randomly. We’d be in a sprint meeting, talking about something, and I’d look at something and say, “So, Daniel, how are you supporting Linux in the enclave? What’s your configuration management platform?” And I’d want to hear them just say, “Oh, we’re doing XYZ” — and stop.

Daniel: Oh, that’s the key.

Rob: I didn’t ask them if there were clouds in the sky. I asked them, “What color is the sky?” “The sky is blue.” And stop. Don’t talk anymore. Don’t try to prove how much you know. This is hard for us IT people — we always like to show how much we know and how awesome we are. Don’t be awesome. Just be good. Just be solid and be good. Know what they ask, and be able to define it, explain it, and move on.

I’d say the other thing we did is we probably overshared from an evidence perspective. If you’re going through the assessment guides and you think something is a good piece of evidence, give it to them. Can’t hurt. If they don’t need it, they won’t use it. And be very clear on how you tie things together. I used a phrase from a very good friend of mine I worked with for a long time — I’ve said this in a few other talks — it’s the “red thread” principle. If I look at the SSP, the policy, the standard, the evidence, that red thread goes all the way through it. Think about how you’re going to approach your certification, how you’re going to present your information, how you’re building your documentation. If you have any varied information in some of those documents, they’ll catch it.

The thing I was so impressed and surprised about during the certification process: they pulled out some language that was buried pretty deep in our documentation and said, “Hey, we were really impressed that you did X, Y, and Z.” And I said, “Wow, I can’t believe you actually saw that — you actually read the hundreds of pages we submitted ahead of time.” Thousands of pages — I think we figured out it was probably about 1,500 pages of documentation. That’s everything from policies to SSP to standards to procedures to forms, all of it. And make it clear. That was the other piece — if you’re trying to put everything in one big document, try to clean it up a little so it’s easier for them to read. Imagine you were going to read it. I think the biggest thing to watch out for is that inconsistency of information. If you’re working with an MSP/MSSP and you have a shared responsibility matrix, and they say their timeout sessions for systems are 15 minutes, but your policies are 10 — well, notate that somewhere. Say there’s a variance between the MSP’s shared responsibility matrix, what they recommend setting up, and what you’re doing. By the way, you’re not going to get in trouble for that. You can have two separate values. People struggle with this — they’re like, “But they’re not both 10 minutes. The assessor’s going to fail me.” No — there can be variance there, with justification.

Daniel: Yeah, that’s right. Or — that’s a great call — have your MSP/MSSP change it to your institutional requirement.

Rob: Exactly. And that’s what we did. It’s going to sound counterintuitive when I realize it, but: don’t overthink it, but don’t underthink it. There’s that balance that’s difficult to obtain. You’ll start to feel when you’ve gone over the edge — like you have to back off a little, you don’t need to do that as much. Be clear, be concise, and make sure you document everything. When we went through our gap assessment, that was the thing that sort of separated out the 7012 work we’d done in the past from the CMMC work. They really hit us a lot on documentation. Your processes are here, you’re doing the right things, but it’s not documented properly —

Daniel: Yep.

Rob: — and it’s not documented consistently. It was that consistency that I think would have buried us if we’d gotten to our certification earlier.

Daniel: I tell people all the time, it’s worth having a pseudo-technical writer, or someone who can bridge that gap. Because — listen, I’ve been in IT long enough to know most IT people are not the hugest fans of documentation. Change control logs and commits and stuff, that’s one thing, but written Word-document or Google-doc documentation just feels like a burden to most people. But to your point, if you don’t have that, how are you going to justify things like changes in the environment? How are you going to document that you’re actually following what you’re doing? You’re probably doing the right thing nine times out of 10 — maybe even 10 times out of 10 — but there’s no policy or procedure you’re following. You’re working off tribal knowledge a lot of the time. So those are some incredible takeaways.

And I always ask, Rob — this gets to our final question. I always end with closing remarks, because there’s always something people hold on to, or advice they’d love to give. This can be technical, non-technical, personal — whatever you recommend. I’ve heard things from “don’t burn out by doing this alone” all the way up to “make sure you’re using FedRAMP clouds,” because I know someone who did a full CMMC implementation in the wrong cloud, had to pay to undo it and do it somewhere else. That’s crazy — you hear crazy stories. I felt so bad for them when they called, because they didn’t realize Microsoft removed the FedRAMP boundary, the authorization, for the commercial cloud they’d fully deployed and documented — hundreds and hundreds of pages of documentation for 110 controls — only to have to move platforms. But anyway — closing remarks, words of sage advice, wisdom, you name it.

Rob: Yeah, a couple of things. CMMC burnout is real. It’s hard — it’s a lot harder than people expect going into it. If you’re a leader or a lead, somebody really helping drive the process, look out for your people. Because that burnout will impact what you’re doing from an implementation perspective, and also the efficacy of your environment.

The other thing — and this is one I say quite a lot — remember that CMMC isn’t just an IT project. It’s an organizational transformation disguised as a cybersecurity compliance project. The success has to come from treating it as a complete, overarching, business-critical infrastructure requirement, and not a checkbox for the government. When you work in an environment like I do — we’re an institute within a university, so we’re not the CMMC enclave for the entire university, we’re for our DoD-funded institute — that doesn’t mean we didn’t have to work with the rest of the organization. We changed some of the way contracts and grants flow through our environment. We worked with our office of compliance — we engaged them, we embedded them, they’re now in our enclave. So this is not Rob’s problem, this is not Daniel’s problem — it’s a project we all have to come together on for it to be successful. And if you don’t look at it that way, and you don’t get that organizational buy-in from leadership at multiple levels — for us it was my executive director, then our dean, then the rest of the university — you need that buy-in, that support.

The last piece of wisdom: you may have been in technology, IT, and security for 20 years, and you get handed CMMC and you’re like, “I can do this. I can do it myself.” No, you can’t. Get help. There are a lot of resources out there — you’re not in it alone. Reach out to people who’ve done it, who can give you advice, and then listen to the advice. Even if it’s not what you would do, listen to what they’re doing, because it’s a beast. You don’t realize the level of granularity you have to document for CMMC in order for an auditor to understand what you’re doing. Remember, your audit’s only three or four days, and they have a week or two — depending on your auditor cycle — to read your documentation before they come in and assess you. So make sure you’re prepared, and you can get prepared by reaching out to people who’ve done it and getting that support.

Daniel: Man, great closing remarks, Rob. You can tell you live it, because I know your certification and the people on your team, and they actually do the things you’re talking about. You take very good care of the people underneath you in this journey, because it takes a team — it’s not a solo project. And listen, if you’re out there trying to make it a solo project — to Rob’s point, please try to find help in some capacity. Go do some e-learning courses, go get your CCP, go network on LinkedIn. There’s a great Discord channel we can drop the link to — a public forum of people asking questions back and forth. Find help, because you will face burnout, and nobody wants that. We want to make sure we’re not only protecting national security, but protecting your health and well-being as part of this journey too. So, Rob, thank you so much for joining, my friend. We look forward to having you again — and hey, who knows, maybe we’ll see you on a CMMC Level 3 someday. Why not just throw it out there? I’m just kidding. But thanks for joining again, my friend. And thanks, everybody, for watching — we’ll see you next time.

Rob: Thanks, everybody.