Context
I worked on Sonic Healthcare's Level 1 IT service desk from July 2025 to July 2026. The role was in enterprise IT operations—not a dedicated SOC or digital-forensics position—but it regularly involved investigating identity, device, email and connectivity issues, recording evidence and making decisions about escalation.
My related Griffith University coursework included Cyber Security Defence & Incident Response and Digital Forensics. The separate Digital Forensics case study documents a fictional academic investigation and its evidence limits; it should not be confused with this professional service-desk work.
Identity and authentication investigations
Account access issues required checking several possible causes rather than assuming a password reset would solve the problem. I worked with Microsoft Entra ID and Active Directory to investigate sign-in failures, authentication methods, device state, account restrictions, group membership, and licences.
My work also covered joiner/leaver processes and approved access changes. Before modifying permission groups or mailbox access, I checked the requester's authority and applicable manager approvals. Requests that did not meet the required approval process were refused or escalated.
Evidence used for troubleshooting
Depending on the issue, I reviewed Entra sign-in information, Event Viewer, email message tracing, available VPN/network logs and ServiceNow history. I used Windows and network utilities to isolate likely causes and documented the observations and tests needed by the next analyst or specialist team.
These were operational investigations. I did not perform specialist evidence acquisition or independently determine the outcome of SOC incidents.
Suspicious email reports
When users reported suspicious messages, I assisted with initial assessment of common phishing indicators, explained safe handling and guided reporting through the established security process. The cybersecurity team handled specialist investigation and response beyond my Level 1 responsibilities.
Incident prioritisation: a real example
A ward printing problem was initially described as a Priority 1 incident. I assessed the reported impact against the organisation's priority criteria rather than accepting the label automatically. The issue was handled as an urgent Priority 2 instead.
This was a service incident, not a confirmed security breach. It demonstrates a transferable part of incident response: assess actual impact, follow the process and escalate with useful context.
What this experience demonstrates
Structured troubleshooting, identity controls, log-based reasoning, documentation and escalation under operational pressure. Together with academic security coursework, this is the foundation I would take into a junior security or identity-focused analyst role.