Where I Am and Where I'm Heading
Domains 1, 2, and 3 of the ISC2 Certified in Cybersecurity certification are done. Security Principles, Incident Response and Business Continuity, and Access Control Concepts — three modules, a 96% average across the assessments, and a set of ideas that have started to connect into something that feels less like study material and more like a working mental model.
I want to be honest about what that means and what it does not mean. Finishing three modules does not make someone a security tester. What it does is build the conceptual structure that makes responsible testing possible in the first place.
I have been clear with myself about where my interest sits. The long-term goal is offensive work — testing people's security, finding gaps before someone malicious does, and helping individuals and small businesses understand their actual exposure. Not a defender sitting behind alerts, but someone who thinks like an attacker within a controlled, authorized scope. I do not have a precise specialisation locked in yet. Home and small business security feels like the right place to start applying new skills — real environments, real exposure, and a level of complexity that matches where I am right now.
But here is the thing I keep returning to: the offensive path and the defensive foundation are not separate tracks. They are the same track, approached from two directions.
What the Foundations Actually Give You
Domain 1 covered Security Principles — the CIA triad, risk terminology, control categories, and the ethics framework that underpins every legitimate security role. That last part matters more than most people acknowledge at the start. The ISC2 Code of Ethics is not administrative filler. It is the line between a security professional and someone who has learned techniques without the judgment to use them responsibly.
Risk terminology from Domain 1 is directly relevant to offensive work. When you are scoping a test — even an informal one for a home network or a small business — you are already doing risk analysis. What are the assets? What vulnerabilities might exist? What is the likelihood of exploitation, and what is the potential impact? That mental model comes from Domain 1, not from a hacking tool.
Domain 2 covered incident response, business continuity, and disaster recovery. At first pass, this feels like purely defensive territory. But understanding the incident response lifecycle — preparation, detection, containment, eradication, recovery — tells you exactly what a defender will do when they spot anomalous activity. That knowledge is fundamental for any tester who needs to understand detection windows, response timing, and why certain approaches are noisier than others.
Domain 3 covered access control — physical and logical controls, the principle of least privilege, segregation of duties, and the major access control models. This is where the offensive relevance becomes obvious. If you are going to test whether access controls are working, you need to understand what they are supposed to do. Discretionary, mandatory, and role-based access control models each have different assumptions, different failure modes, and different things worth testing. Without that framework, you are guessing.
Why the Threat Landscape Makes This Urgent
I follow BleepingComputer as a regular reading habit — it tracks active threats, disclosed vulnerabilities, and real-world incidents with consistent technical depth. The current headlines are a useful reminder of why the foundational work matters: compromised supply chains, malware hidden inside legitimate platform features, zero-days being actively exploited before patches arrive.
For home users and small businesses, most of these threats land differently than they do at an enterprise level. There is no SOC, no dedicated security team, often no one whose job description includes security at all. The question is not whether a threat actor will use a sophisticated evasion technique. The question is whether the basics — access control, patching, least privilege, monitoring — are even in place. That is the gap I want to start working on understanding from the inside.
What Ethical Offensive Work Actually Requires
Ethical offensive security — commonly called penetration testing or security assessment — is authorized, scoped, and documented work. The word authorized carries real weight. Testing a system without explicit permission is not a learning exercise. It is unauthorized access, regardless of intent.
For someone starting out, the controlled path looks like this: practice environments (TryHackMe, intentionally vulnerable machines, home lab setups), moving toward work on systems you own or have written permission to test, with clearly defined scope and documentation. That is the progression. There are no shortcuts worth taking.
The foundational concepts from Domains 1 through 3 map directly onto this work:
- CIA triad thinking tells you what a tester is actually looking for — where confidentiality can be bypassed, where integrity can be subverted, where availability can be disrupted.
- Risk framing shapes how findings get communicated. A vulnerability with low likelihood and low impact is a different conversation than one with high likelihood and high impact.
- Access control knowledge is what makes testing access controls meaningful. You cannot find a misconfiguration you do not understand.
- Incident response awareness keeps your testing scoped and realistic — a good tester knows when to stop, how to document, and how to communicate findings without causing more disruption than the vulnerability itself.
Starting With Home and Small Business Security
Home networks and small business environments are where I am pointing first. Not because they are simple — they are often the opposite, with mixed personal and professional devices, minimal segmentation, default configurations left in place, and no baseline documentation to compare against. But they are the right scope for where I am in my learning.
The goal is to build a structured approach: understand the environment, map what is present, identify what controls are in place, and assess where the gaps are. Document everything. Frame findings in a way that helps the person understand their actual risk, not just the technical detail.
That process starts with the same question Domain 1 put at the centre of security thinking: what are the assets, and what are the realistic threats against them?
What I Am Still Working Through
Domains 4 and 5 — Network Security and Security Operations — are still ahead of me. Network security in particular is going to be directly relevant to offensive work, and I am not going to write about it as if I have covered it yet. The honest position is that I have the conceptual foundation, I am developing the practical skills through TryHackMe, and the next module will fill in gaps I can already feel.
That is what the process looks like. Not a straight line from study material to capability, but a continuous loop of concept, practice, reflection, and next concept.
The Core Point
Offensive security and defensive security draw from the same well. Understanding risk, access control, and incident response is not background knowledge for a tester — it is the actual work, applied from a different angle. The tools come later. The judgment that determines whether those tools are used responsibly comes from the foundation.
That is why Domains 1 through 3 mattered, and why I documented them before writing a single word about testing anything.