Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Day in the Life for the Security Operations Engineer persona

Security Operations Engineer - Day in the Life

Today is a Monday. It’s the first day following a busy on-call week for Alex, having been on call the prior Monday to Friday. Having already handed off the on-call duties to a colleague who did the weekend shift, Alex plans on spending significant time today closing things off, as well as getting up to speed on work done by others.

Morning: plugging-in

Opening the laptop, Alex’s first objective is getting up to speed. It’s really important for Alex to know what’s going on and be responsive, even while not being on-call. Alex checks the Security Department and Security Alerts channels on Slack to see what came in over the weekend, and also checks emails and TODOs, replying to various queries and requests. This usually takes Alex about 30 minutes to an hour.

Much of Alex’s morning is spent on meetings. It’s another part of plugging in, and participation is important to Alex. First meeting of the day is the weekly sync for the Security Operations team. In the meeting Alex shares highlights from the on-call week with the team, and learns what others have worked on during this past week. This should help him with diving back to regular work.

In the little time between meetings, Alex tries to work through issues and reply to comments.

As part of getting up to speed on regular sec engineering work, Alex has a 1:1 with another member of the operations team with whom Alex shares engineering responsibilities while not on-call. They discuss what the colleague was able to do last week, and what they are both looking to achieve this week.

A few meetings and one lunch later, it’s the afternoon.

Afternoon: “clean-up” mode

Alex has a lot of loose ends to tie following the on-call week, which makes those few days following being on-call a bit more hectic. Even though no longer on-call, Alex still owns the follow-up on any issues that were opened during the on-call shift. Alex still has a few of them opened right now, and so getting those closed in the next few days is top priority.

Alex tries to keep the afternoon free from meetings as much as possible. With SecOps work Alex very well knows that there’s a million things that could potentially drag you away from what you’re doing - even when you’re not on-call - but today thankfully is going to be a quiet afternoon for Alex.

The incidents which occurred last week were, for the most part, things the team hadn’t encountered before (that’s part of the excitement in SecOps work!). As a result, Alex has extra work to wrap up: In addition to the usual - documenting any last items taken and trying to close things out - Alex also spends this afternoon putting together RCAs (Root Cause Analysis) (link) and Runbooks (link). Some of the Runbooks include code snippets Alex created on the fly as part of responding to incidents last week, so now Alex is going to refine that code and document it for future use, should a similar incident occur again. This is all part of making the team more efficient going forward, and sharing lessons learnt with the team.

Alex is passionate about improving processes and making the team more efficient, and so it’s important for him to get documentation right. Not to mention that things need to be clear in case legal or some other party would want to enquire. Once documentation is over, Alex reaches out to the wider team to share the work and ask for feedback.

Tidying up last week’s incidents isn’t done yet (not all issues are closed), but things are now at a place where Alex can take a look at some backlog projects. Alex keeps a TODO list on a small notepad on the desk - scanning through it, Alex chooses something from the list to work on.

Learn more about the Security Operations Engineer persona

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license