What Is This Podcast About?
Shane: Welcome to AI and Automation in Action, where we show business leaders how to turn AI from a buzzword into measurable operational results. This podcast is for CEOs, COOs, and technology decision makers who are tired of manual processes, disconnected systems, and underperforming teams. In every episode, we walk through real client implementations, the architecture, the tools, the integration strategy, and the governance controls, so you can see exactly what works in the real world.
What Problem Was This Client Trying to Solve?
Shane: Today we are stepping through our first automation case study. It is especially relevant for IT directors and business leaders dealing with compliance requirements, whether that is HIPAA, PCI, SOC 2, or in this case, CMMC. Hunter Holderfield, our automation engineer, is here to walk us through the challenge, the solution, and the outcome. Hunter, can you kick us off?
Hunter: Sure. The customer came to us needing to disable Active Directory users after their accounts became stale past a certain number of days. In their case, that threshold was 90 days. A list of stale users would be generated, and those users then needed to be disabled in Active Directory. This was something they had been trying to address for years, and it was directly tied to achieving CMMC compliance.
What Is CMMC and Why Does It Require This?
Hunter: CMMC is a compliance requirement for organizations that do federal Department of Defense work under contract. It governs how those organizations must secure their environments, and specifically how they protect unclassified data inside their technology systems. Part of that requirement is ensuring that all inactive users and computers are removed from access permissions on an ongoing basis.
Why Not Just Handle This Manually in Active Directory?
Hunter: You can handle it manually, but that means dedicating someone to that task every day or every week. This was a perfect candidate for automation because it freed up that point of contact from doing repetitive cleanup work. The automation generates the list and disables the accounts automatically.
Shane: And that consistency piece is critical for compliance. It is not enough to state a policy. You have to show controls that enforce it consistently, document it, and prove that nothing gets missed. Being sick one day or out on vacation cannot be the reason a stale account stays active. Correct?
Hunter: Exactly. And on top of running the automation, the system delivers a notification to the point of contact listing every user that was disabled. That gives them visibility to spot-check their other records and confirm everything is fully aligned.
Shane: So it does the work and also produces the documentation that the compliance regulation requires.
Hunter: Correct.
How Was the Automation Built?
Hunter: We used an API platform that integrated with where the client's devices are remotely accessed, and that platform connects with their Active Directory server. It pulls all users, generates the list of accounts that have hit the 90-day threshold, and then a PowerShell script runs on that Active Directory server using those stale users as parameters. The script disables them automatically.
What Is an API and How Is It Different from RPA?
Shane: For listeners who may not be familiar, can you explain what an API platform means in this context?
Hunter: Sure. An API is a backend access method supported by a software tool. To contrast it with the alternative: robotic process automation, or RPA, mimics what a human does on screen. Think of someone clicking into Active Directory, selecting new user, and filling out fields. That is RPA. API access skips the visual interface entirely and communicates directly with the software at a deeper level. You would not see it happening. You would only see the end result, or the delivery notification.
Shane: So an API is essentially a hook directly into the software, while RPA mimics a user clicking through a screen. With RPA, someone watching the bot's machine could see it happening in real time. With API, it all runs silently in the background.
Hunter: Exactly.
Can an API Automation Talk to More Than One System?
Shane: Is this type of automation limited to a single system, or can it connect to multiple tools?
Hunter: No limits, as long as each system supports API access. That is the key requirement. If a system does not support API access, then we would look at the RPA path instead.
What Results Is the Client Seeing?
Hunter: They no longer have to fear a missed user on their network that could lead to a security incident later. The automation helped them reach CMMC compliance and has streamlined their ongoing processes. They still submit manual separations when employees leave so those can be completed correctly across all tools, but the automated stale-account cleanup runs every day at noon without anyone touching it.
Shane: So it is handling security, compliance documentation, and consistency all at once, with no manual effort required.
Hunter: Exactly. And the cadence was set in coordination with the customer based on their specific CMMC compliance needs.
How Much Time and Money Did This Save?
Hunter: This automation is saving the customer eight hours a week. And it is not just time. It is accuracy. No users get missed because someone is out sick or on a holiday. The automation still runs every day at noon regardless.
Shane: You can attach a dollar figure to those eight hours per week based on what that person earns, but the value goes beyond that. Anything handled manually is subject to mistakes, missed steps, and time constraints. Removing that risk has its own value, and sometimes that accuracy and consistency component is the primary driver, not just the time savings.
How Long Did It Take to Build and Was There Immediate ROI?
Hunter: The build-out for this automation took approximately eight hours. The ROI was immediate. The organization was able to achieve CMMC compliance right away, their point of contact was freed from the tedious manual review work, and they now have reliable documentation with nothing falling through the cracks.
What Can Be Built on Top of This Automation?
Shane: One thing we always look for is what can be layered on top of an initial automation once the platform is in place. Once you have the API connection and the first workflow running, you can extend it and connect more data. The goal is to find that first use case that delivers ROI and then build from there.
Hunter: A good example would be taking the same logic used to disable stale user accounts at 90 days and applying it to stale computers. Or going the other direction and automating new user provisioning when employees are onboarded. The platform is already there. You just need a defined process and you can automate it.
Shane: So the possibilities really do expand once you have that foundation in place.
Hunter: Absolutely. And what we see consistently is that once an organization starts automating, they quickly identify more processes they want to automate, because now they understand what is possible and can see the time savings for themselves.
What's Coming in Future Episodes?
Shane: Hunter, thanks for walking us through this. In future episodes we will cover additional use cases, including more traditional RPA automations and AI-powered chatbot implementations. If today's conversation sparked ideas about how automation could improve your operations, reach out to us at ideas@innovative.ai.