Lifecycle of a SOAR Automation

Cybersecurity teams face an ever-growing range of responsibilities, from investigating threats and managing risk to responding to incidents and supporting the wider business. As these demands continue to grow, finding ways to make routine processes more efficient and sustainable has become increasingly important.

In this article, Senior Security Automation Engineer, Dmitry Kosarev shares his perspective on how automation can support cybersecurity professionals by reducing manual, repetitive tasks and creating more consistency across operational processes. Drawing on lessons learned over the past two and a half years, Dmitry explores the lifecycle of an automation and the people, processes and collaboration required to develop solutions that genuinely support the teams who use them.

Over to Dmitry…

Have you ever had to perform a laborious, repetitive task in an IT role?

I certainly have. Whether it's manually triaging suspicious emails in a reporting mailbox or pulling metrics from half a dozen systems to build a monthly slide deck, many of us have spent countless hours on work that should be automated.

Some teams take steps to solve this. There are plenty of courses on Python, Bash, and scripting in general. And if you're lucky, you might build small automations for your own workflow.

• How do you scale those automations?
• How do you monitor them?
• How do you maintain them over time?

While software engineering has mature practices and guidance, there is still a noticeable gap when it comes to operationalising automation in cybersecurity. In practice, this often leads to immature, makeshift and fragile solutions.

Earlier in my career before joining Admiral, I managed automation for a Security Operations team supporting over 15,000 users. Those automations consisted of PowerShell scripts running on a server, triggered by Task Scheduler, with credentials stored in text files accessible to specific accounts.

They worked, for the most part.

• Logs were reviewed manually, once a week
• Fixes were implemented on the fly with no oversight or control under an extreme time crunch
• Ownership was subject to a single point of failure
• And during high-risk periods (like Christmas), automations were simply disabled "just in case"

So what does it look like when automation is treated as a first-class discipline?

That's exactly what the Security Automation Engineering (SAE) team at Admiral has been exploring over the past 2.5 years.

Through a series of Medium posts, we want to share what we've learned and learn from others — because this still feels like a niche but rapidly advancing discipline within cybersecurity which seems to be locked away within siloes. We're also planning on sharing some of our technical solutions such as scripts that have made our security automation program more mature and scalable.

Lifecycle of an Automation

We support multiple specialist cybersecurity teams, each pushing the boundaries of their domain.

While we use Google SecOps SOAR as our central platform, the principles we follow are platform-agnostic: a central orchestration layer that integrates with tools via APIs, executes actions, and processes results in a scalable and repeatable way. But building a successful automation is about far more than just development.

It's about the entire lifecycle.

Automation Lifecycle

Each phase matters. Strong automations don't come from great code or visual workflows alone — they come from well-executed processes across the entire lifecycle.

Request

Every automation starts with a request.

We use a simple submission form that captures:

• Scope and goals
• Systems involved
• Quantitative benefits (time savings)
• Qualitative benefits (e.g. faster response times)

But forms aren't enough.

We actively engage teams proactively through:

• One-on-one in depth conversations (in person where possible certainly helps when you're dealing with a remote distributed workforce)
• Internal collaboration spaces
• Quick exploratory calls

Letting people see what has been done already does wonders for sparking ideas for other automations.

Triage

Not all requests are equal. Even after 2.5 years, our backlog remains full — but prioritisation is critical.

Some requests:

• Deliver high value
• Deliver otherwise unavailable capabilities
• Remove significant operational burden
• Close risk gaps

Others do not. Learning to say "No" or "Not right now" is essential. Good triage:

• Prevents burnout
• Keeps delivery consistent
• Ensures the team focuses on meaningful impact

Discovery

This is where ideas meet reality. We work closely with the requesting team to:

• Understand the true problem
• Set expectations for human involvement
• Identify edge cases
• Discuss the user interface of the automation

Good discovery saves time later. Misaligned expectations don't.

Many teams don't know what's possible or what's not. Interestingly, fresh perspectives often challenge assumptions and push us to rethink solutions even if some requests end up being way beyond the capabilities of the team.

Checklists help early on, but experience builds intuition.

Prerequisites

Before development begins, we identify all external prerequisites that need to be established first:

• Tool access (temporary or permanent)
• Training requirements for us to better understand the tools being used
• Firewall changes to network communication between the tools and the SOAR platform
• Service accounts (with least privilege)
• Other miscellaneous work by other teams? This could be finalising the process to be automated, configuring the external tooling (e.g. appropriate tagging or entity mapping)

This last point is often underestimated. Automations should not compensate for broken processes. It's always better to fix issues at the source than build workarounds.

Development

This is the part everyone expects to enjoy the most.

And it is — but it's evolving.

With LLM tooling, development time is reducing. That creates space to:

• Design more robust solutions
• Improve testing
• Build reusable components
• Cover more functionality from day one
• That said, discipline matters:
• Stay focused on high-value requirements and avoid bloat
• Build atomically
• Prefer vendor-supported functionality where possible
• Keep custom scripts simple and scoped (reusable templates can save just as much time as an LLM here!)

Documentation

This is what makes automation sustainable.

Good documentation:

• Captures design decisions
• Provides operational context for the automation's existence
• Supports future maintenance and tracks known, expected and accepted errors
• Tracks post-implementation improvement opportunities

Standardised templates and clear diagrams go a long way — not just for us, but for the teams we support.

User Acceptance Testing

This is one of the most critical phases. We deploy the automation in a development environment and require:

• A dedicated representative from the requesting team that can speak effectively to their needs and pain points
• Time for proper validation and reviews
• Detailed feedback on outputs and behaviour

The challenge?

Teams are busy. The automation may save them time — but in the future. To make this phase effective:

• Present outputs clearly
• Abstract away complexity
• Engage collaboratively
• Take feedback and questions seriously
• Demonstrate a tangible difference from the engagement

This builds a virtuous cycle of engagement that smoothens collaboration in the future.

And most importantly: We do not proceed until the team is happy.

Peer Review

We have a very specific way of doing this:

• Presenting a sample of automation execution in the SOAR
• Providing a link to completed documentation
• Live video demo to the whole SAE team with a feedback session
• Structured feedback submission

Our team brings diverse backgrounds across cybersecurity and IT, which helps us:

• Identify weak points
• Improve scalability
• Enhance usability
• Evaluate the "business logic" of the automation

Attention to detail, especially in UI and presentation — often elevates the overall experience beyond initial expectations. Under-promising and overdelivering is an ethos that is central to our success.

Implementation

This is typically the shortest stage but with plenty to consider:

• Deployments still involve manual steps. Manual steps are much likelier to go wrong if not considered and pre-emptively outlined.
• These manual steps are standardisable but only to a certain point. Deploying custom scripts takes different steps than just deploying an automation built with out of the box steps. Event based automation triggers need to be configured differently than schedule based ones. Documenting these considerations and what configurations to use ahead of time and getting those peer reviewed via a change management process helps prevent failed deployments and ensures broad awareness of production activities amongst the team.
• Notifying users and giving them an easy forum to comment on upcoming changes helps prepare the teams that will be using our automations.

Monitoring

This comes in two stages:

• Short term: Intensive manual oversight immediately after deployment to make sure the automation is performing as expected "in the wild", outside of test conditions
• Long term: Daily automated reporting on execution health. Using a bespoke technical solution we're planning to share in the future, we run a dedicated automation that for each production automation fetches the results of each automation step. Whether successful or not, that step's output is collected, data is normalised and structured and known errors filtered out. The end result is a report that focuses our attention on material errors in our automations, allowing us to catch errors before the users do and allowing us to start resolving the issues as soon as possible.

Demo

Demos are not just for showcasing functionality. They are an opportunity to:

• Drive adoption
• Gather feedback
• Identify new automation opportunities
• Build relationships with users

For interactive playbooks especially, demos help analysts understand how automation enhances their overall workflows.

One of our learning curves is that building engagement takes more than just a desire to help on our part. We have to engage users early and often, find different communication methods to engage them (even for users within the same teams), be visible and responsive publicly. Demos is one of the many ways we accomplish that.

Team Management Review

Final validation comes from the requesting team's leadership. Approval ensures:

• The automation meets expectations
• Value has been delivered
• The request can be formally closed

This doesn't require a heavy, formal process — a confirmation in a corporate messaging tool like Teams is enough.

Review Cycle

While feedback and improvement suggestions are always welcomed and tracked formally in automation's documentation, teams can get busy and siloed — organic suggestions may not get enough encouragement to flow. There is also the temptation to keep racing forwards and conquering new automation frontiers; formal reviews initiated by my team prompts the requestors to reflect meaningfully on the automation developed once some experience using has been gathered.

We engage the original requestors asking for improvement opportunities, check the use of playbooks in a more detailed, manual manner and consider whether any improvements or updates are worth prioritising in the short term. Whether its Python libraries in custom scripts or updates made by the vendor for dedicated integrations supported by them, software supply chain security is an important consideration for us as well.

Conclusion

Although presented linearly, this lifecycle is not rigid. Phases overlap, loop back, and influence each other continuously.

Yes — it's a lot of effort.

But there is nothing quite like seeing your automations in action, reducing toil, empowering users, and delivering real impact.

At its best, security automation feels less like engineering…

and more like a form of modern-day magic.