Types of Cybersecurity
Cybersecurity encompasses a broad set of disciplines, each protecting distinct layers of technology infrastructure, data, and organizational process. Classification matters because the controls, staffing, regulatory obligations, and risk profiles differ sharply across domains — a miscategorization can leave an organization applying the wrong framework to the wrong threat surface. This page maps the primary categories, explains how operational context shifts those boundaries, and identifies the jurisdictional dimensions that govern which types of cybersecurity practice carry binding compliance weight.
Edge Cases and Boundary Conditions
Classification of cybersecurity types breaks down at several well-documented boundaries. The most common friction points involve overlapping domains where a single control or incident touches two or more categories simultaneously.
Operational Technology (OT) and IT convergence presents the clearest boundary problem. Industrial control systems (ICS) and SCADA environments were historically air-gapped and governed under different engineering disciplines. As network connectivity extended into factory floors and utility grids, the National Institute of Standards and Technology (NIST) published SP 800-82, Rev. 3, "Guide to Operational Technology Security," specifically to address the gap between IT-centric security controls and OT safety requirements. A ransomware event that pivots from a corporate email system into a manufacturing control network simultaneously implicates endpoint security, network security, and ICS security — three distinct categories with different response playbooks.
Cloud-native application security sits at the intersection of application security and infrastructure security. When containerized workloads run on shared cloud infrastructure, vulnerability ownership under the shared responsibility model becomes contested: the cloud provider secures the underlying compute layer, but runtime application logic remains the customer's responsibility. NIST SP 800-190 addresses container security as a discrete concern, yet most organizations operationally fold it into either DevSecOps or cloud security programs depending on team structure.
Supply chain security straddles network, software, and vendor risk management. The Cybersecurity and Infrastructure Security Agency (CISA) and NIST jointly publish the Cybersecurity Supply Chain Risk Management (C-SCRM) guidance under NIST SP 800-161, Rev. 1, treating it as a distinct practice while acknowledging that its controls overlap with software security, third-party risk, and acquisition policy.
How Context Changes Classification
The same technical control can belong to different cybersecurity categories depending on the deployment environment, the regulated sector, and the threat model being addressed.
Sector context reshapes classification significantly. Encryption key management in a general enterprise context falls under information security or data security. In a federal civilian agency context, the same function becomes a FISMA obligation governed by NIST SP 800-53, Rev. 5, Control Family SC (System and Communications Protection). In a payment card environment, it maps to PCI DSS cloud environment controls under Requirement 3 (protect stored account data). The underlying technology is identical; the regulatory classification, audit evidence, and penalty exposure differ by sector.
Scale and architecture also shift boundaries. Identity and access management (IAM) in a small on-premises deployment is typically a subset of network security operations. At enterprise cloud scale, IAM expands into a dedicated discipline — cloud identity and access management compliance — with its own framework mappings under FedRAMP, SOC 2, and ISO/IEC 27001:2022.
Threat actor context determines whether an activity is classified as cybersecurity or national security. CISA's 2023 Cross-Sector Cybersecurity Performance Goals treat critical infrastructure protection as a cybersecurity function, while the same defensive action against a nation-state adversary may invoke Title 10 or Title 50 authorities under federal law — a jurisdictional boundary that affects which agency holds incident response authority.
Primary Categories
The following breakdown reflects the domain structure used by major standards bodies including NIST, ISO/IEC, and the SANS Institute:
-
Network Security — Protection of data in transit and network perimeter integrity. Covers firewalls, intrusion detection/prevention systems (IDS/IPS), segmentation, and VPN architecture. NIST SP 800-41 provides firewall policy guidance.
-
Endpoint Security — Protection of individual devices (workstations, servers, mobile endpoints). Encompasses antimalware, patch management, device encryption, and EDR (endpoint detection and response) platforms.
-
Application Security (AppSec) — Securing software during development and runtime. Governed in part by OWASP (Open Web Application Security Project) through frameworks such as the OWASP Top 10 and ASVS (Application Security Verification Standard).
-
Cloud Security — Protection of data, workloads, and infrastructure hosted in cloud environments. The regulatory context for cybersecurity obligations in this domain span FedRAMP, HIPAA, GDPR, and SOC 2, among others. The Cloud Security Alliance (CSA) publishes the Cloud Controls Matrix (CCM) as a domain-specific control framework.
-
Data Security — Protection of structured and unstructured data at rest, in transit, and in use. Intersects with privacy regulation directly — GDPR Article 32 mandates "appropriate technical measures," which data security programs must operationalize.
-
Identity and Access Management (IAM) — Governing who can access what resources under what conditions. Zero-trust architecture, first formalized in NIST SP 800-207, is the current federal reference model.
-
Operational Technology (OT) Security — Protecting industrial control systems, SCADA, and embedded devices. NIST SP 800-82, Rev. 3 is the primary guidance document.
-
Incident Response (IR) — Structured processes for detecting, containing, and recovering from security events. NIST SP 800-61, Rev. 2 defines the 4-phase IR lifecycle: Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity.
Jurisdictional Types
Jurisdictional classification determines which legal authority governs a cybersecurity obligation and what enforcement mechanisms apply.
Federal civilian cybersecurity in the United States is primarily governed through FISMA (Federal Information Security Modernization Act of 2014), implemented through NIST SP 800-53 controls and OMB Circular A-130. Agencies subject to FISMA must maintain Authority to Operate (ATO) documentation for information systems, a requirement that directly shapes how cloud security programs are structured under FedRAMP authorization.
Sector-specific federal regulation creates parallel tracks. Healthcare organizations handling electronic protected health information (ePHI) fall under HHS enforcement of the HIPAA Security Rule (45 CFR Part 164), which specifies administrative, physical, and technical safeguard categories. Financial institutions are subject to the Gramm-Leach-Bliley Act Safeguards Rule, enforced by the FTC, which was updated in 2023 to require specific technical controls including encryption and multi-factor authentication for covered financial data.
State-level cybersecurity law introduces 50-jurisdiction complexity. California's CPRA (effective January 1, 2023) imposes data security requirements enforceable by the California Privacy Protection Agency (CPPA). New York's SHIELD Act and the NY Department of Financial Services (NYDFS) Cybersecurity Regulation (23 NYCRR 500) apply distinct obligations to covered entities operating in New York — with NYDFS's 2023 amendments introducing a 72-hour incident notification requirement for covered entities.
International jurisdictional types extend obligations beyond US borders for organizations handling data of EU residents. GDPR Article 32's security requirements apply regardless of where the processing entity is incorporated, a principle confirmed in the Schrems II ruling by the Court of Justice of the European Union (CJEU) in 2020. For US cloud providers serving EU customers, GDPR cloud compliance obligations intersect directly with domestic US security program design.