Try a piece of the work · 6 min read

Is cybersecurity right for me? A safe first experiment that is not hacking

Explore cybersecurity with a fictional incident and a simple risk exercise. No hacking, live targets or specialist software required.

Written by Nivaan, founder of OffLadder · Last reviewed 10 October 2026 · Sources listed at the foot of this page

The field is wider than the dramatic part

Security work can involve analysing events, building safeguards, reviewing access, assessing risk, supporting response and explaining requirements. NIST's NICE Framework describes cybersecurity through work roles, tasks, knowledge and skills. It is a better starting point than assuming everyone spends the day trying to break into a system.

Different roles require different depth. This exercise tests a little evidence handling and communication. It does not establish technical competence, qualify you for incident response or show that a career will be easy to enter.

Everything you need is below. Use only the fictional material. Do not scan a website, attempt a login or contact a real employee as part of the exercise.

The incident brief

A fictional company has twenty employees. Its support team receives a report from an employee, Alex: “I received a sign-in approval request this morning that I did not expect. I rejected it.” The security owner is available, but wants a short factual summary before investigating.

You receive these simplified practice events:

The records do not explain how the successful sign-in occurred. They do not prove that data was exported. The backup event may be unrelated. Your job is to preserve those distinctions.

First pass: what do you actually know? Create three short sections: observed facts, concerns and unanswered questions. Put the event times in order. Separate Alex's report from the system records, since they are different sources.

A justified concern is that an unexpected successful sign-in was followed by account changes. An unjustified conclusion is “the attacker bypassed multifactor authentication using a particular technique.” You have not been given evidence of a technique, an attacker identity or even the full account history.

Useful questions include whether the device was genuinely unfamiliar, whether Alex made any authorised changes, what the forwarding rule did and whether the export completed. Ask how those details would be verified through trusted internal channels. Do not invent the answers to make the case feel finished.

Write the handover

Produce a 150-word summary for the designated security owner. State why the sequence merits prompt review, what is known, what remains uncertain and which records should be preserved according to the organisation's procedures.

One possible response is:

Please review a potentially unauthorised sequence on Alex's account. The supplied records show a failed sign-in, a denied approval request and then a successful sign-in from the same unfamiliar device. A mailbox forwarding rule and a file-export request followed. Alex reports rejecting an unexpected approval request. We have not confirmed the legitimacy of the successful sign-in, the forwarding destination or whether any export completed. Preserve the relevant account, mail and export records and verify Alex's report through an established contact route. Any containment should follow the security owner's authorised response process. The scheduled backup concerns a different employee and is not currently linked to this sequence.

This is a practice communication, not a complete incident-response procedure. In real work, follow the organisation's authorised process rather than improvising technical actions from a career article.

Notice the temptation to sound certain

A neat explanation can feel more impressive than a careful one. Security work often requires resisting that temptation. “Potentially unauthorised” may be more useful than a confident claim of a breach when the evidence is incomplete.

Also notice whether you enjoy reconstructing the sequence. Do you want to know which record would resolve the uncertainty? Are you willing to update your interpretation when a fact changes? Or do you mainly enjoy the excitement of the story?

Now change one fact: Alex confirms that the new device was theirs, but says they did not create the forwarding rule. Revise the summary. The new information changes the investigation; it does not automatically make every subsequent event legitimate.

A second task: assess a supplier without investigating its systems

A fictional small charity is considering a document-sharing service. It plans to store internal volunteer schedules. The proposal says the service has administrator accounts and external sharing, but does not explain how access is removed when a volunteer leaves.

Write five questions for the charity to ask before adopting it. Focus on the information stored, who can access it, how access is reviewed and removed, how incidents are reported and who owns the decision. Do not claim the service is unsafe simply because the brief omits an answer.

Then write a short recommendation: proceed, pause or conduct further checks, with reasons. A sensible answer might pause the upload until responsibilities and access removal are clear. The purpose is to connect a control to a real risk, not to produce the longest possible checklist.

Compare the two experiences

The incident task asks you to interpret events under uncertainty. The supplier task asks you to clarify requirements before something goes wrong. You may prefer one strongly.

Use that reaction to explore different work roles through NIST's framework and actual local vacancies. Check what employers expect at entry level, including technical foundations, writing, organisational knowledge and experience. A certification may help in a particular route, but collecting certificates before choosing the work can become an expensive form of browsing.

Talk to a practitioner about the routine parts: documenting decisions, reviewing repetitive events, maintaining controls, attending meetings and following up unresolved issues. Do not judge the profession only by the most dramatic incident.

Boundaries that belong in the experiment

Use authorised training environments for any later technical practice. Never test a real system because it looks publicly accessible. Do not enter credentials, install unfamiliar tools or upload private logs to a public AI service just to complete a career exercise.

If AI helps you review the fictional summary, ask it to identify unsupported conclusions. Check the response against the supplied facts. The goal is to learn how you reason, not to outsource the entire task and admire the result.

Do I need to code? Some roles require substantial programming or scripting; others place more emphasis elsewhere. The right answer comes from the work role and employer, not a blanket yes or no.

Can this tell me whether I am suited to security? It can identify something worth testing again. It cannot predict long-term fit or competence. A safe second exercise and an informed conversation are better next steps than declaring a new professional identity.

Follow the part that interested you

OffLadder helps you investigate career directions through manageable experiments. Tell Laddie whether the timeline, the uncertainty, the written handover or the supplier questions held your attention. Keep the two outputs in You, and use Explore to find another piece of the work. Start exploring cybersecurity and nearby directions. The first useful sign may be that you want to ask a better question, not that you want to break into anything.