Before I started, I had a picture in my head of what a cybersecurity team at a real company would look like. Proprietary tooling. Mature automation. Processes defined down to the step, refined by people who'd been doing this for years. I figured I'd spend my internship mostly learning how all of it worked, and eventually earn my way into touching the more interesting parts.
That's not what I found.
The gap between expectation and reality
There were tools, but a lot of them weren't being used past the basics. There were processes, but plenty had obvious room to improve. None of that was because the team was careless. It was because everyone was already busy keeping the lights on. Incident response, access requests, audit prep, the daily fires. Improving a process takes time nobody has when they're already underwater on the work directly in front of them.
That's a different problem than the one I expected to walk into. I thought I'd be learning a system. Instead I was looking at a list of things that clearly needed fixing, sitting there because nobody had the room to fix them.
The golden image problem
The clearest example was the golden image process. It wasn't one task, it was a whole pipeline: open the tickets, configure and update a VM, run a vulnerability scan against it, reconfigure based on what came back, build out a reference machine from that VM, turn the reference machine into the actual golden image, capture the image, prep the media for deployment, and hand the result to QA. All of it running off a spinning disk drive, and all of it done by hand, start to finish, every time. The whole cycle took about 8 hours.
Every handoff in that chain was a place a step could get missed or done slightly differently depending on who was running it that day. Any mistake meant backing up and redoing part of the process, or worse, an image reaching QA with something wrong that should've been caught earlier.
I was still an intern at the time. I asked a senior engineer if it could be automated. He told me no, not for a process like this. Too many manual steps, too much that depended on doing things in the right order, at the right time, with the right configuration state.
I didn't take that as final, mostly because I didn't see anything in the process that was actually impossible to script. There was documentation for it, so the steps were clear. What didn't exist was anything that ran those steps for you. Someone still had to sit down, follow the doc, and do every part of it by hand.
Breaking it down
I went stage by stage and automated what could be automated. The ticketing and reconfiguration work still needed a person making judgment calls, but the mechanical middle of the pipeline, building the reference machine and turning it into the golden image, didn't need a person doing it manually every time. That part is now almost entirely automated.
The reason nobody had done it wasn't complexity, and it wasn't a lack of documentation either. The doc told you what to do. It just didn't do it for you. Turning a documented process into an automated one is a different piece of work, and once something's been run by hand long enough, closing that gap stops looking like an option worth pursuing.
So I built it out. What took 8 hours by hand takes 3 now with automation driving the parts that don't need a human in the loop, and those parts run the exact same way every time, regardless of who kicked it off or how careful they were feeling that day. No skipped steps, no different order, no drift between one person's mental checklist and another's.
What actually changed
That project reset how I thought about the role. The job wasn't about inheriting a polished system and learning to operate it. It was about noticing what was still manual, still fragile, still eating hours that could go somewhere else, and fixing it. Nobody had automated the golden image process because it was impossible. Nobody had made the time to turn a well-documented process into a script, and once something's been done by hand long enough, it starts to look like it has to stay that way.
That's most of what I've done since. Take someone's repeatable manual task and turn it into a script that does it the same way every time. Not because the manual version was wrong, but because every hour spent doing it by hand is an hour not spent on the things that actually move the company forward.
A small security team doesn't have the luxury of people whose whole job is maintenance. If a process can run itself, it should, so the people on the team can spend their time on the problems that actually need a person thinking about them.