Your First Night Shift: The First 180 Days in a SOC

Most SOCs run on a queue. Alerts arrive from detection tools, someone picks them up, looks at them, decides what they are and records the decision. On your first shift you will probably not own the queue. You will sit next to someone who does, and watch.

That is the right start. Your job on day one is to build a map, not to close tickets. A good map has three things on it: where alerts come from, where work is recorded, and where you go to look something up.

The three tools to learn first

• The SIEM or log search. This is where you ask questions of the logs. Learn one query that finds every event for a single user or host over the last 24 hours. That one query will carry you through your first month.
• The EDR console. This shows what happened on a laptop or server: processes, network connections, files. Learn how to open a host timeline and how to read a process tree.
• The ticketing or case system. This is where the decision lives after you go home. Learn the fields that are mandatory, the status names and what each one means to the next shift.

Everything else, the SOAR playbooks, the threat intel platform, the email gateway, the cloud consoles, can wait a week. You will touch them, but someone will show you when.

What to write down

1. The names of the alert sources and roughly how many alerts each sends in a shift.
2. The status names in the case system and who moves a case between them.
3. The runbook location, and which alerts have a runbook and which do not.
4. The words people use that you do not know yet. Look them up later, or ask at the end of the shift.

Watch how your buddy decides. Not just what they click, but what they check before they close something. Ask them, after the alert is closed, "what would have made you escalate that?" The answer tells you more about the team than any slide deck.

Rule of thumb:Rule of thumb: on day one, learn to find things, not to judge things. Judgement comes from seeing a few hundred alerts with someone who explains them.

On a night shift you will sometimes be the only person awake who is looking at security alerts. That feels heavy until you know one thing: you are never expected to handle a serious incident alone. You are expected to notice it and get the right people involved fast.

What escalate really means

To escalate is to hand a decision to someone who has more context, more access or more authority than you. It is not an admission that you failed. It is the system working. A SOC that never escalates is not calm, it is blind.

There are usually two kinds of escalation, and it helps to keep them apart:

• Technical escalation. You need a more experienced analyst to look, or someone with access you do not have, such as the owner of a cloud account.
• Severity escalation. The thing in front of you might be an incident, and someone who can declare one needs to know. That person can wake up other people. You usually cannot.

Find these out today

1. Who is on call tonight for the SOC, and how you reach them: phone, pager, chat.
2. What severity levels your team uses and what each one triggers.
3. Which alert types must be escalated no matter what, for example a known ransomware behaviour or an admin account doing something new.
4. Who to call if the on-call person does not answer within the time in the runbook.
5. Where to write down that you escalated, and when.

How to make the call

Keep it short and in the same order every time: what you saw, when, on which system or account, what you checked, and what you think it might be. Then say what you need: "I need someone to decide whether to isolate this host." A clear ask gets a fast answer, even from someone half asleep.

Rule of thumb:Rule of thumb: if you are asking yourself whether to escalate for more than ten minutes, escalate. The cost of a short call is small. The cost of a quiet night that was not quiet is not.

Triage is deciding what an alert is and what should happen next. The four outcomes you will hear most are true positive (the alert fired and something bad really happened), false positive (it fired but nothing bad happened), benign true positive (it fired correctly on real activity that turned out to be allowed, like an admin running a scan) and, the one you never see in the queue, false negative (something bad happened and nothing fired).

The most common mistake in the first month is choosing a verdict too early. The alert title says "possible credential theft", you open it already believing it, and every fact after that gets read in that light. Or the opposite: this rule fires a hundred times a day, so it must be noise again.

Gather context first

1. Who. Which user or service account? What is their role? Are they new, leaving, or travelling?
2. What. What exactly did the detection see? Read the raw event, not just the alert title.
3. Where. Which host or cloud resource? Is it a server, a laptop, a build agent?
4. When. At what time, and what happened just before and just after on the same host or account?
5. Is this normal? Has this user or host done the same thing before? Search the last 30 days.

Only then decide. Often the context makes the decision for you. A PowerShell download on a developer machine at 2pm with a ticket open for a tooling install is a different alert from the same command on a finance laptop at 3am.

Speaking the same language

Many teams tag alerts with MITRE ATT&CK tactics and techniques. A tactic is the attacker's goal at that step, such as Initial Access or Lateral Movement. When the source was read for this book, the Enterprise matrix listed 15 tactics, including Stealth and Defense Impairment. Check the version your team uses, because ATT&CK changes over time.

Rule of thumb:Rule of thumb: write your verdict last. If you notice you wrote it first, go back and check one thing that could prove it wrong.

Your ticket is read by people who were not in your head at the time: the next shift, the incident lead, an auditor months later, and you, three weeks from now, when the same alert fires again. Write for them.

The test of a good ticket is simple. Could someone pick it up at the start of their shift and carry on without messaging you? If the answer is no, something is missing.

A shape that works

1. Summary in one sentence. "Finance laptop FIN-0231 ran an encoded PowerShell command at 03:12 UTC; closed as benign, matches a scheduled IT script."
2. What fired. Rule name, alert time, host, user.
3. What you checked. Each check and its result, in order. Include the queries you ran, so someone can rerun them.
4. Evidence. Links to the events, hashes, IPs and domains you looked at. Paste the key line from the raw log.
5. Verdict and why. True positive, false positive or benign true positive, and the fact that decided it.
6. What happens next. Escalated to whom, a tuning request raised, a user contacted, or nothing.

Habits that help

• Use UTC, or state the time zone every time.
• Write what you saw, not what you assumed. "No outbound connection in EDR for 10 minutes after" is useful. "Looks fine" is not.
• If you closed it as a false positive, say whether the rule should be tuned and raise the request. Otherwise the same alert will waste someone else's time tomorrow.
• Record what you did not check and why. "Could not see proxy logs, no access" tells the next person where the gap is.

Keep a personal snippet file of the queries and phrases you reuse. After a month you will write a clear ticket in half the time, and your tickets will look the same from one shift to the next, which helps everyone who reads them.

Rule of thumb:Rule of thumb: a ticket is finished when a stranger could defend your verdict from what is written, without your memory.

This is the question most new analysts carry and few say out loud. At some point you will close an alert as benign and later learn it was not. Or something will happen that no alert caught at all. Both are part of the work, for everyone, at every level.

Two kinds of miss

• A wrong verdict. The alert fired and you judged it wrongly. This is usually about missing context, a gap in the runbook, or too many alerts at once.
• A false negative. Nothing fired. This is a detection gap, not a triage failure. Nobody in the queue could have seen it.

The second kind is far more common than people think, and it is why a quiet queue is never proof of a safe network.

What a blameless review is

Good teams review misses without looking for someone to punish. The question is not "who got it wrong?" but "what made the wrong call look right at the time?" The answers are usually things like a vague alert title, missing logs, a runbook that said close, or a shift that had three times the usual volume. Fixing those protects the next person too.

If your team does reviews, take part honestly. Say what you saw and what you thought. The worst thing you can do is hide or tidy up the story, because then the real cause stays in place.

Escalation fear

Fear of a miss often turns into fear of escalating: "what if I wake someone and it is nothing?" These two fears pull in opposite directions, and the way out is the same for both. Make your reasoning visible.

1. Write down what you checked and why you decided, every time.
2. When unsure, escalate with your reasoning attached, not just the alert.
3. Ask for feedback on your closed tickets, especially the ones you were unsure about.
4. After a miss, ask what one check would have caught it, and add it to your routine.

Rule of thumb:Rule of thumb: the analyst who says "I think I got this one wrong" on the same day is worth more to a team than one who is never seen to be wrong.

SOCs love numbers. Some help you get better. Some are easy to read the wrong way. It is worth knowing the common ones before someone shows you a dashboard with your name on it.

Using MTTD and MTTR honestly

Averages hide the cases that matter. One incident that took weeks to detect sits in the same average as dozens found in minutes. If your team reports these numbers, ask to see the slowest few cases too. Those are where the lessons are.

Also ask how the clock is started and stopped. If "respond" ends when the ticket is closed, then closing faster improves the number without making anyone safer.

Numbers that help you personally

• How many of your closed alerts were later reopened.
• Which alert types you still need help with.
• How long your tickets sit before someone else can act on them.

Numbers are a starting point for a conversation, not the end of one. When a metric looks bad, ask what is behind it before deciding anything.

Rule of thumb:Rule of thumb: any number that can be improved by doing less checking will be, unless someone also watches quality.

A strange thing about triage is that you rarely learn whether you were right. You close an alert, the queue moves on, and nothing tells you if that call was good. Without feedback, you can do the same thing wrong for months with full confidence.

So build the feedback yourself. It does not need to be formal.

Four small loops

1. Reopened tickets. Once a week, search for any of your closed tickets that were reopened or linked to an incident. Read what changed.
2. Peer review. Ask a senior analyst to read three of your tickets a week, picked by them. Ask one question: "What would you have done differently?"
3. Shadowing upward. Sit in on one escalated case per week, even if you only listen. See what the next level checks that you did not.
4. Your own notes. Keep a short list of alert types you got wrong or were unsure about. Revisit it each month. Watch it shrink.

Feedback you can give

Feedback runs both ways. You see the alerts every shift. If a rule fires on nothing all day, tell whoever owns detections, with examples. If a runbook step no longer matches the tools, say so. Many improvements in a SOC start with a tired analyst saying "this alert is always the same backup job".

• Raise a tuning request with two or three example alerts attached.
• Suggest a runbook edit with the exact step and the exact fix.
• Share a useful query in the team channel. Others will improve it.

Practice outside the queue helps too. A lab where you get an immediate answer, right or wrong, trains judgement faster than weeks of unscored alerts.

Rule of thumb:Rule of thumb: if you cannot name one thing you learned from a mistake this month, you are not getting enough feedback. Go and find some.

Detection engineering is building and maintaining the logic that creates alerts. Engineers decide what to watch for, write the query or rule, test it against real data, and tune it so it fires on the right things and stays quiet otherwise.

Analysts make good detection engineers because they know what a bad alert costs. You have seen rules that fire on every backup job. You know which alert titles mislead. That knowledge is the hard part.

Signs this might be your path

• You often think "if this rule also checked X, it would be quiet".
• You enjoy writing queries more than closing tickets.
• You keep a list of tuning ideas without being asked.

How to start

1. Learn your SIEM's query language properly, beyond copying queries. Filters, joins, time windows, counting.
2. Pick one noisy rule and propose a tuning change with evidence: how often it fires, on what, and what your change would remove.
3. Learn a portable rule format such as Sigma, so you can read rules shared publicly and translate them.
4. Map each rule to an ATT&CK technique. It helps you see which tactics your team covers and which it does not.
5. Test your rule against known-bad activity, not only against yesterday's logs.

A good detection has a clear title, a description that says what it looks for and why, the data source it depends on, known false positives, and a short note on what the analyst should check first. Write rules you would want to receive at 3am.

You can start this path without changing jobs. Offer to own the tuning of one rule for a quarter. Track how often it fires before and after your change, and how many real cases it still catches. That record is the strongest case you can make for moving into detection work.

Rule of thumb:Rule of thumb: a new rule is not done when it fires. It is done when an analyst who has never seen it can triage its alert in a few minutes.

Triage reacts to alerts. Hunting starts with a question: "If an attacker were doing this here, what would we see, and would we have noticed?" Then you go and look.

Hunting matters because of false negatives. Every SOC has things it cannot see. A hunt is a deliberate look into those gaps.

A simple hunt plan

1. Hypothesis. One sentence. "An attacker with a stolen password would sign in from a new country and then add a mail forwarding rule."
2. Data. Which logs would show it? Do you have them, and for how long?
3. Query. What search would find it? What would normal look like?
4. Time box. How long will you spend before writing up what you have?
5. Outcome. Findings, gaps in data, and at least one detection or tuning idea.

Where hypotheses come from

• A recent public report about a technique used against organisations like yours.
• An ATT&CK technique your detections do not cover yet.
• Something odd you noticed during triage that did not fire an alert.
• A change in your environment, such as a new cloud service or a merger.

Hunting needs time away from the queue. Ask your lead whether you can have a few hours a week. Bring a written hunt plan to the conversation. A plan makes the request easy to approve.

Write up each hunt in the same short format: the hypothesis, the data you used, the queries, what you found and what you recommend. Store it where the team can find it. Over a few months these write-ups become a record of what your SOC has looked for, what it can see and what it still cannot. They also make it easy to repeat a useful hunt later, when the environment has changed.

Rule of thumb:Rule of thumb: every hunt should leave something behind, a new detection, a tuning change or a logging request, even when it finds no attacker.

When an alert becomes an incident, the work changes. There are more people, more pressure and more decisions that affect the business: whether to take a system offline, who needs to be told, what to say. Someone has to hold the picture together. That is the incident lead.

What the role involves

• Keeping one timeline of what is known, with times and sources.
• Assigning tasks and checking they are done.
• Making or getting containment decisions, and recording who made them.
• Giving regular, short updates to managers and other teams.
• Making sure evidence is kept before systems are changed.

How the field frames it

NIST SP 800-61 Revision 3, published in April 2025, replaced Revision 2 from 2012. It presents incident response as part of overall cybersecurity risk management and is written as a Community Profile of the NIST Cybersecurity Framework 2.0. It is worth reading after a few months on the floor, because it explains why preparation and recovery matter as much as the response itself.

How to grow towards it

1. Volunteer to keep the timeline during the next incident. It is the best seat in the room for learning.
2. Read old incident reports in your team's records. Notice which decisions took longest and why.
3. Take part in tabletop exercises and practise speaking clearly under pressure.
4. Learn your organisation's notification duties: who must be told, by whom, and when. Your legal or privacy team owns this, so ask them.

Notice how good incident leads speak. They say what is known, what is not known yet and when the next update will come. They avoid guessing out loud. They ask for one specific thing from each person. You can practise this today in your escalation calls and handovers, long before anyone asks you to lead.

Rule of thumb:Rule of thumb: during an incident, a decision written down with a time and a name is worth more than a perfect decision nobody recorded.

More and more of what a SOC watches lives in cloud platforms and software-as-a-service apps. The alerts look different. There may be no laptop and no process tree. Instead there is an identity, an API call and a resource that changed.

What changes in the cloud

• Identity is the perimeter. Most cloud alerts are about who did something: a user, a role, a service account, an access key.
• Configuration is the attack surface. A storage bucket made public or a security group opened to the internet can matter as much as malware.
• Audit logs are your main evidence. Each provider has its own audit trail of control-plane actions. Learn what yours records and what it does not by default.
• Things are short-lived. A container or virtual machine may be gone before you look. Evidence has to be captured quickly or logged centrally.

Skills to learn first

1. Read an audit log entry for one provider and name the identity, the action, the resource, the source address and the result.
2. Understand how roles and permissions are granted there, and how someone could assume a role.
3. Learn what a leaked access key looks like in logs, and the first steps to contain it.
4. Find out which cloud logs your SOC actually collects, and for how long.

Cloud work rewards curiosity about how things are built. Ask the platform team for a walkthrough of one account. You will learn more in an hour with them than in a week of reading.

Also learn the difference between control-plane and data-plane activity. Creating a user or changing a policy is control plane and usually lands in the audit trail. Reading objects from storage is data plane and is often not logged unless someone turned that on. Knowing which is which tells you what you can and cannot prove.

Rule of thumb:Rule of thumb: in a cloud alert, find the identity first. Almost every next question follows from who it was and what they were allowed to do.

A SOC asks you to stay alert to rare, important events inside a stream of common, unimportant ones, often at hours your body would rather sleep. That is hard for anyone. It is not a personal weakness if it wears on you.

Alert fatigue

Alert fatigue is what happens when you see the same harmless alert so often that you stop really looking. It is dangerous because it feels like efficiency. You close faster, and you check less.

• Notice when you close an alert without opening the raw event. That is the warning sign.
• Take a short break after a run of identical alerts, even five minutes.
• Turn repeated noise into a tuning request. It helps you and everyone after you.
• Rotate alert types with a colleague if your team allows it.

Shift work

1. Protect your sleep window like a meeting you cannot move. Dark room, phone away.
2. Keep the handover sacred. A clear handover means you can actually stop thinking about work.
3. Plan meals and exercise around the shift, not around everyone else's day.
4. Tell the people you live with your rota, so they can help protect your rest.

Signs of burnout

Burnout tends to creep in. Watch for dread before shifts, cynicism about the work, feeling that nothing you do matters, trouble switching off, and making careless mistakes you would not have made before. If several of these are true for weeks, talk to someone: your lead, a colleague you trust, or a health professional.

Look after the people around you too. If a colleague has had a hard incident or a run of nights, offer to take the next difficult alert or simply ask how they are doing. Teams that notice each other's tiredness catch problems earlier, in people and in the queue.

Rule of thumb:Rule of thumb: a tired analyst is a detection gap. Rest is not time away from security work. It is part of it.

By month six you will see your SOC more clearly. You will see what it does well and where it struggles. Many SOCs share the same few blind spots. Naming them helps you avoid copying them, and helps you suggest something better when you are ready.

1. Treating alert volume as success

A slide that says "we handled thousands of alerts this month" sounds impressive and says almost nothing about safety. More alerts can mean more noise, not more protection. Better questions: how many led to real action, how many rules produced only false positives, and what did we miss?

2. Tuning nothing

Rules get added after every incident and report, and almost never removed or improved. Over time the queue fills with alerts nobody believes. Analysts close them by habit, and real signals get buried. Tuning is not lowering your guard. It is making sure your guard is pointed at the right place.

• Every rule should have an owner.
• Every noisy rule should get a tuning review on a schedule.
• Analysts should have an easy way to say "this one is always noise".

3. Hero culture

Some teams admire the person who stays all night, knows every system and fixes everything alone. That person is often exhausted, and when they leave, their knowledge leaves too. A strong team writes things down, shares the hard cases and makes sure no single person is the only one who can handle something.

Where you are now

You know the queue, you know who to call, you can write a ticket someone else can act on, and you have a direction in mind. That is a good 180 days. The next step is choosing what kind of analyst, engineer or leader you want to become, and practising on purpose.

Rule of thumb:Rule of thumb: judge a SOC by what it learns after a miss, not by how many alerts it closes.