Where I Am and Where I'm Heading
I've now finished Domains 1, 2, and 3 of the ISC2 Certified in Cybersecurity certification — Security Principles, Incident Response and Business Continuity, and Access Control Concepts. The assessments went well, averaging 96% across the three modules. More usefully, the concepts are starting to connect.
I want to be clear about something as I keep documenting this journey publicly: my interest in cybersecurity is not primarily defensive. I'm drawn to the offensive side — testing systems, finding weaknesses before someone else does, and understanding how security controls actually hold up under pressure. Not every cybersecurity professional is built for the SOC, and that's fine. The discipline still requires the same foundational knowledge regardless of which direction you specialize.
That said, I'm not rushing toward anything. My plan is to start applying skills in home and small business environments — legal, controlled, and with proper authorization — before anything else. The foundation has to come first.
What the First Three Domains Actually Gave Me
It might seem counterintuitive that a certification module on incident response or access control models would be useful to someone interested in offensive security. In practice, it's the opposite of counterintuitive — it's essential.
Domain 1 — Security Principles established the mental model. The CIA triad (confidentiality, integrity, availability) is not just a framework defenders reference. It's the same framework used to evaluate what a successful attack actually achieves. When a penetration tester identifies a vulnerability, the question immediately becomes: what does exploiting this compromise? Confidentiality? Integrity? Availability? That language comes from Domain 1.
Risk terminology — asset, vulnerability, threat, likelihood, impact — is equally foundational. A tester who doesn't understand how risk is assessed can't communicate findings in a way that means anything to the client. The technical skill of finding a weakness is only part of the job.
Domain 2 — Incident Response, Business Continuity, and Disaster Recovery might read like pure defense material. It isn't, not entirely. Understanding the incident response lifecycle — preparation, detection and analysis, containment, eradication and recovery, post-incident — gives you a picture of what happens after a breach is discovered. That matters when you're trying to understand how detection-resistant a technique might be, or how to frame a findings report around realistic organizational response capabilities.
Concepts like RTO (recovery time objective) and RPO (recovery point objective) show up in risk assessments. A small business with no tested recovery plan and a 72-hour RTO is a very different security posture than one with automated backups and a two-hour window. These distinctions matter when evaluating risk exposure.
Domain 3 — Access Control Concepts is possibly the most directly applicable module for anyone interested in offensive work. The principle of least privilege, need-to-know, segregation of duties, and access control models (DAC, MAC, RBAC) describe exactly what testers probe. Misconfigured access controls are among the most common findings in security assessments. Understanding how they're supposed to work makes it significantly easier to recognize when they don't.
The IAM lifecycle — provisioning, periodic review, deprovisioning — is another area where real-world weaknesses appear frequently. Accounts that were never deprovisioned, permissions that were never reviewed, roles that accumulated far beyond what any individual actually needed. These aren't exotic attack surfaces. They're routine findings.
The Area I'm Starting In
My plan is to begin with home networks and small business environments. This is deliberate. Large enterprise environments involve complexity, scale, and regulatory context that I'm not ready to navigate responsibly yet. Home and small business security is a legitimate space with real problems — default router credentials, flat network architectures, weak Wi-Fi configurations, unpatched devices, no segmentation between personal and business traffic.
It's also a space where the gap between a professional assessment and no assessment at all is often enormous. Small organizations frequently have no security review, no policy, and no visibility into their own exposure. That's a problem worth working on.
I'm building toward this through TryHackMe (currently Level 4), where the structured rooms cover enumeration concepts, basic Linux navigation, and understanding how guided assessments work in a safe, legal environment. The hands-on practice is where theory starts becoming skill.
Why Foundation Before Testing
The temptation in offensive security learning is to chase tools and techniques before the concepts are solid. That's backwards. A tool produces output. Knowing what the output means — what it implies about risk, what control it bypasses, how a defender would detect it — requires the conceptual background first.
Domains 1 through 3 built that background. I can now look at an access control misconfiguration and understand not just that it's misconfigured, but what the principle it violates is, what risk that creates, and what a remediation recommendation should address. That's the difference between running a scan and doing a security assessment.
What Comes Next
Domains 4 and 5 — Network Security and Security Operations — are still ahead of me. Network Security in particular will be directly relevant to the kind of work I'm planning. Understanding how traffic flows, how protocols behave, and how network-layer controls are structured is prerequisite knowledge for anything in that space. I'll document that progress here as I work through it.
For now, the foundation is real. The direction is clear. The next step is continuing to build the technical layer on top of it — carefully, methodically, and in environments where I have explicit authorization to be there.