The deeper I get into cybersecurity, the more job titles I discover.
Security analyst.
Cybersecurity analyst.
SOC analyst.
Security engineer.
Incident responder.
Penetration tester.
Threat analyst.
GRC analyst.
And that’s before you even get into the more specialised roles.
Coming from SEO, I see the problem.
Tell someone you work in SEO, and they might assume everyone in the industry basically does the same job.
But an SEO working primarily on technical migrations can have a very different day from someone managing 300 Google Business Profiles.
Cybersecurity appears to work the same way.
One role I’ve kept coming across during my learning is SOC analyst.
So I wanted to understand it properly.
What does an SOC analyst actually do?
What are they looking at all day?
What happens when an alert appears?
What skills do they need?
And perhaps more importantly for someone like me who’s exploring cybersecurity from another technology career:
What does the job actually feel like beyond the job description?
I’m not a SOC analyst.
I’m an SEO Manager learning cybersecurity, so this isn’t me pretending to teach the profession from years of experience I don’t have.
Think of this as me looking through the window, trying to understand what the people on the other side are actually doing.
First, What Is a SOC?
SOC stands for Security Operations Centre.
At a basic level, it’s the function responsible for continuously monitoring an organisation’s technology environment for potential security threats and helping investigate and respond when something suspicious happens.
The people working inside a SOC may monitor endpoints, user accounts, networks, servers, cloud environments and other systems.
The exact setup varies considerably between organisations.
A large company might operate its own SOC with multiple analysts working different shifts.
Another organisation might outsource some or all of the work to a managed security provider.
Some SOCs operate 24/7.
Others don’t.
And the roles within them can vary too.
But the basic objective makes sense to me:
Something suspicious happens somewhere in the organisation. The SOC needs to determine whether it matters.
So, What Does a SOC Analyst Do?
A SOC analyst monitors security information, investigates suspicious activity and helps an organisation respond to potential security incidents.
That sounds simple.
The reality appears considerably more investigative.
Modern security tools generate alerts when they detect behaviour that could indicate something is wrong.
Maybe an account suddenly attempts hundreds of failed logins.
Maybe a device communicates with a suspicious domain.
Maybe malware is detected on an employee’s laptop.
Maybe someone successfully logs into an account from an unusual location.
Maybe a privileged account starts doing something it normally doesn’t do.
The alert doesn’t automatically mean:
We’ve been hacked.
It means:
Something happened that deserves investigation.
The SOC analyst has to work out which one it is.
Recent descriptions of the role consistently put alert triage, log and event analysis, incident investigation, documentation and escalation at the centre of SOC analyst work.
And that’s where the job becomes much more interesting to me.
A Security Alert Is the Beginning of the Question
Before learning about cybersecurity, I probably imagined security software working something like this:
Threat detected.
The alarm goes off.
A cybersecurity person presses a button.
The hacker was defeated.
Hollywood has a lot to answer for.
The more I’m learning, the more I realise that detection is only part of the problem.
Imagine an employee logs into the company network at 2:13 AM.
Is that suspicious?
Maybe.
But what if they work unusual hours?
What if they’re travelling?
What if they’re using a VPN?
What device did they use?
Where did the login originate?
Was authentication successful?
Were there failed attempts beforehand?
What did the account do after logging in?
Did it access unusual files?
Did another security alert occur around the same time?
Has this behaviour happened before?
Suddenly one alert creates ten questions.
The SOC analyst’s job isn’t simply to see the alert. It’s to investigate the story behind it.
Alert Triage Seems Like a Huge Part of the Job
One term I keep encountering is triage.
The concept comes from deciding what needs attention first.
An SOC can receive a large number of alerts, and not all of them represent genuine security incidents.
Some may be harmless.
Some may be false positives.
Some may require monitoring.
Some may indicate something serious enough that action needs to happen immediately.
An SOC analyst needs to help distinguish between them.
That’s harder than it sounds.
If you treat everything as critical, you waste enormous amounts of time.
If you dismiss something important, the consequences could be much worse.
So analysts investigate enough context to determine things like:
Is this legitimate activity?
Is this a false positive?
Does this require further investigation?
How severe could it be?
Does somebody else need to become involved?
That sounds less like watching a dashboard and more like continuously making small investigative decisions.
Logs Suddenly Make Much More Sense to Me
I’ve encountered logs through technical SEO.
Server logs can tell us how Googlebot and other crawlers interact with a website.
Which URLs were requested?
When?
What status code was returned?
How frequently did Googlebot visit?
Which parts of the site are receiving crawl activity?
I’ve written before about how SEO and cybersecurity are more connected than I initially thought.
SOC work is another example.
Cybersecurity analysts also work with logs, but they’re asking completely different questions.
Who logged in?
From where?
At what time?
Which device?
What process ran?
Which files were accessed?
What network connection was made?
What happened immediately before this event?
What happened afterwards?
One log entry might mean very little.
Several related events can start telling a story.
That’s something I’m beginning to appreciate about cybersecurity.
Individual events matter, but context matters more.
What Is a SIEM?
If you’re researching SOC analyst roles, you’ll encounter this acronym almost immediately.
SIEM stands for Security Information and Event Management.
The basic idea is that organisations have security information coming from many different places.
Servers.
Firewalls.
Applications.
Endpoints.
Authentication systems.
Cloud platforms.
Network devices.
Security tools.
A SIEM helps collect and analyse this information centrally so security teams can detect and investigate suspicious activity.
Instead of manually opening ten different systems trying to reconstruct what happened, analysts can work with centralised security events and alerts.
Products commonly associated with SIEM include platforms such as Microsoft Sentinel, Splunk and Google Security Operations.
I’m deliberately not trying to memorise every SIEM product at this stage.
I’d rather understand:
What problem does a SIEM solve?
Then learning a particular tool has context.
That’s the same advice I’d give somebody learning SEO tools as a beginner.
Learn what the tool is helping you accomplish before becoming obsessed with knowing every button.
What Happens When a SOC Analyst Finds Something Real?
Let’s imagine the investigation suggests that the alert isn’t harmless.
There may actually be a security incident.
Now the job changes.
Depending on the organisation, severity and the analyst’s responsibilities, the response could involve actions such as containing an affected device, disabling or securing an account, gathering additional evidence, documenting what happened and escalating the incident to senior analysts or an incident response team.
SOC analysts commonly operate within a broader detect-investigate-respond process rather than working completely independently.
This is another misconception I had about cybersecurity.
I imagined one person “solving” the attack.
Real security operations seem much more collaborative.
One analyst identifies something.
Another investigates further.
Someone might handle containment.
Someone else might examine malware.
Another team may restore systems.
Management may need information.
Legal or compliance teams could become involved depending on what happened.
The bigger the incident, the more people potentially enter the picture.
Documentation Is Apparently a Big Part of Cybersecurity Too
Nobody puts this part in the movies.
Imagine the scene.
An SOC analyst discovers suspicious activity.
Dramatic music starts.
They investigate the logs.
The attacker is identified.
And then…
They update the ticket.
Not particularly cinematic.
But documentation appears to be an important part of SOC work.
What happened?
When?
Which systems were affected?
What evidence was found?
What actions were taken?
Why was the alert closed or escalated?
Who was notified?
What still needs investigation?
Clear records help other analysts understand the investigation and provide a timeline if the incident develops further. Documentation and case management are specifically identified as essential duties of SOC analysts in current descriptions of the role.
This part actually feels familiar.
Technical work isn’t only about discovering the answer.
You also need to communicate what you found.
The SEO Manager in Me Finds the Investigation Part Familiar
I’m careful here because I don’t want to pretend investigating an SEO decline is equivalent to investigating a cybersecurity incident.
The consequences can be completely different.
But the thinking process interests me.
A client says:
Organic traffic dropped.
Okay.
When?
Sitewide?
One section?
One country?
Mobile or desktop?
Branded or non-branded?
Did rankings change?
Did impressions change?
Was there a Google update?
Did developers release something?
Did tracking change?
Was the site migrated?
Were pages removed?
Did competitors improve?
Is there seasonality?
An experienced SEO doesn’t immediately say:
I know what happened.
You investigate.
Cybersecurity appears to demand that same instinct at a much more technical level.
Something happened.
Don’t assume.
Gather evidence.
Establish the timeline.
Look for patterns.
Test hypotheses.
Then decide what the evidence supports.
That part of SOC work appeals to me.
What Does a Typical Day Look Like?
This is where I don’t think there’s one perfect answer.
A SOC analyst’s day depends on the organisation, shift, technology stack, level of seniority and whether an incident is underway.
But the recurring activities I’ve found include:
Monitoring alerts.
Reviewing security dashboards.
Triaging new alerts.
Investigating suspicious activity.
Searching and correlating logs.
Checking endpoint or network information.
Documenting findings.
Escalating incidents.
Communicating with other security or IT teams.
Updating tickets.
Reviewing threat information.
Improving detection rules or processes, depending on the role.
And then, presumably, occasionally wondering why somebody clicked the attachment.
Again.
What Are Tier 1, Tier 2 and Tier 3 SOC Analysts?
This terminology confused me initially because job descriptions don’t always use it consistently.
Broadly, SOC roles are sometimes organised into levels.
A Tier 1 or Level 1 analyst often handles initial monitoring and alert triage.
They may investigate alerts, gather information, close false positives and escalate suspicious cases that require deeper analysis.
A Tier 2 analyst may handle more complex investigations and confirmed incidents.
More senior analysts may take responsibility for advanced investigations, threat hunting, detection engineering, mentoring or major incident response.
But I wouldn’t treat these levels as universal definitions.
A Tier 1 role at one company may involve responsibilities that another organisation assigns to Tier 2.
The job description matters more than the title.
I’ve learnt the same thing in SEO.
Do SOC Analysts Actually “Hack”?
This was one of my beginner questions.
Not necessarily.
Cybersecurity is much broader than hacking.
An SOC analyst is generally working on the defensive side of security.
Monitoring.
Detection.
Investigation.
Response.
A penetration tester has a different job.
Their work may involve deliberately attempting to exploit weaknesses under authorised conditions, in order to identify vulnerabilities before malicious attackers do.
Both roles operate within cybersecurity.
But they aren’t the same thing.
This distinction has helped me understand the field much better.
When people say:
“I want to work in cybersecurity.”
that’s almost like saying:
“I want to work in technology.”
Okay.
Doing what?
Networking Looks Extremely Important
The more cybersecurity I learn, the more networking keeps appearing.
IP addresses.
Ports.
Protocols.
TCP.
UDP.
DNS.
HTTP.
HTTPS.
Firewalls.
Network traffic.
Packets.
Connections.
If you’re investigating suspicious network activity, you need some understanding of what normal network activity looks like.
This is one reason networking is part of my cybersecurity learning roadmap.
I’ve worked with websites for years.
I know DNS.
I know HTTP status codes.
I know HTTPS.
I’ve dealt with servers.
But knowing what something is from an SEO or web perspective doesn’t automatically mean I understand it deeply enough from a security perspective.
Cybersecurity is forcing me further down the stack.
Linux Keeps Appearing Too
Then there’s Linux.
Servers frequently run Linux.
Security tools use Linux.
Labs use Linux.
Command-line work appears everywhere.
Log files live there.
Processes run there.
Permissions matter there.
At first, the command line can feel like the computer has removed all the useful buttons just to see whether you’re serious.
But I’m slowly becoming more comfortable with it.
Commands that initially felt completely abstract start having a purpose once you’re trying to investigate something.
That’s another pattern I’m noticing throughout my learning.
Tools become easier to remember when I have a reason to use them.
And Then There’s Python
Naturally, this is another reason I’m glad I’m learning Python.
I’m already experimenting with Python for SEO automation and data analysis.
I’ve written about why I’m learning Python as an SEO, and cybersecurity gives me another reason to continue.
An SOC analyst doesn’t necessarily need to be a software developer.
But scripting can be useful for working with data, parsing logs, automating repetitive tasks, interacting with APIs and processing information.
Even my beginner Python work is starting to change how I think.
Take a log file.
Read it.
Extract certain values.
Count events.
Filter entries.
Look for patterns.
Export results.
Those are programming problems.
They can also become security problems.
What Skills Does a SOC Analyst Need?
If I were building my learning roadmap specifically around SOC work, the foundations I’d pay attention to would include networking, operating systems, security concepts, log analysis, SIEM platforms, endpoint security, incident response, basic scripting and communication.
Google’s own cybersecurity training describes analysts as professionals who continuously monitor systems and networks, investigate breaches and report their findings.
But I think there’s another skill underneath all of those:
Curiosity.
Why did this happen?
Is this normal?
What changed?
What else happened at the same time?
What evidence supports my assumption?
What am I missing?
That’s the kind of thinking I’m finding increasingly attractive about cybersecurity.
Is SOC Analyst an Entry-Level Cybersecurity Job?
You’ll often see SOC analysts mentioned as a route into cybersecurity.
That doesn’t necessarily mean:
No experience required. Walk in on Monday.
“Entry-level” in technology can be misleading.
A junior SOC analyst may still be expected to understand networking fundamentals, operating systems, basic security concepts and logs.
They may also encounter SIEM and endpoint-security tools.
That’s why I’m trying not to approach cybersecurity as:
Which certificate will help me get the job?
I’ve already looked at entry-level cybersecurity certifications I considered when starting.
Certifications can provide structure.
But eventually I need to do things.
Open the terminal.
Look at logs.
Use Wireshark.
Work through labs.
Investigate alerts.
Write Python.
Break things safely.
Fix them.
That’s where I expect the real learning to happen.
Could I See Myself Doing SOC Work?
This is an interesting question.
Maybe.
The investigative side definitely appeals to me.
Looking at information.
Finding patterns.
Working out what changed.
Following evidence.
Understanding systems.
Those things already overlap with parts of what I enjoy about technical SEO.
But I’m not currently planning some dramatic announcement:
After years in SEO, I’m officially becoming a SOC analyst!
No.
I like SEO.
I’m interested in AI.
I’m learning Python.
I’m learning cybersecurity.
I’m enjoying seeing where all these things connect.
I’ve written before about why an SEO Manager is learning cybersecurity, and my answer hasn’t changed.
I don’t think every subject I learn needs to become my next job.
Sometimes understanding another discipline simply makes you better at understanding technology.
The More I Learn About Cybersecurity, the Less It Looks Like the Movies
There are hackers.
There are attacks.
There are serious incidents.
But there’s also an enormous amount of:
Monitoring.
Investigating.
Reading logs.
Checking evidence.
Following processes.
Writing notes.
Escalating issues.
Communicating.
Waiting.
Checking again.
And trying to determine whether the scary red alert is actually scary.
That reality makes cybersecurity more interesting to me, not less.
Because underneath all the tools and acronyms, the SOC analyst seems to be doing something very human.
They’re trying to make sense of incomplete information.
Something happened.
The system noticed it.
Now, someone needs to determine:
What actually happened here?
So, What Does a SOC Analyst Actually Do?
The simplest answer I’ve arrived at is this:
A SOC analyst monitors an organisation’s systems for suspicious activity, investigates security alerts, determines which threats are real, documents what they find and helps escalate or respond to genuine security incidents.
But after learning more about the role, I think the most interesting word there is:
Investigates.
The dashboard doesn’t contain all the answers.
The alert doesn’t contain all the answers.
The security tool doesn’t contain all the answers.
Someone still has to understand the context.
That’s the part I hadn’t appreciated before I started learning cybersecurity.
And it’s another reason I’m enjoying documenting my cybersecurity learning in public.
I’m not trying to pretend I already know where this journey ends.
Right now I’m still learning what the different jobs even look like.
SOC analyst is one I understand considerably better than I did before writing this.
And the more I understand it, the more one thing stands out:
Cybersecurity isn’t only about knowing the tools.
It’s about knowing which questions to ask when the tools tell you something might be wrong.
