Understanding What Cybersecurity Frameworks Do

This Expert Perspective is the second in a series on cybersecurity. Learn about the three core branches of cybersecurity, IT, product, and OT, in part one.

How can organizations leverage cybersecurity frameworks to manage risk, and what are the limitations of those frameworks?

Cybersecurity failures, whether in enterprise systems, products, or industrial operations, can expose organizations to significant legal, financial, and operational consequences. In the first article in this series, we defined three common branches of cybersecurity: information technology (IT), product, and operational technology (OT). In this article, we examine how frameworks, standards, and models apply to each branch, and how organizations can effectively employ them, along with their inherent limitations. 

What cybersecurity frameworks do — and don't do 

Cybersecurity frameworks, standards, and models provide a common approach and language for identifying, managing, and communicating cybersecurity risk. They help organizations prioritize investments, assess maturity, assign responsibilities, and organize and generate evidence for customers, regulators, insurers, and business partners. Some are certifiable or auditable; others are guidance documents, control catalogs, maturity models, or architectural reference models. By adopting these widely recognized approaches, often developed through expert consensus, organizations can demonstrate that they are following accepted cybersecurity practices and taking reasonable, risk-based steps to protect their systems, products, data, and stakeholders.

On their own, however, frameworks do not guarantee security, eliminate liability, or automatically establish compliance. Their value depends on correct scoping, implementation, evidence, and maintenance. When organizations misapply these frameworks or misunderstand their scope, they can overlook exposures that aren't always visible until something goes wrong. Understanding the limits of these frameworks helps corporate counsel assess exposure, product executives plan cybersecurity work, and insurers evaluate risk.

Securing the business: IT cybersecurity

IT cybersecurity protects digital infrastructure such as email, instant messaging, corporate networks, and cloud services that keep an organization operating efficiently. Because breaches here typically result in data theft or service outages, frameworks in this space focus heavily on safeguarding data confidentiality, integrity, and availability (the "CIA" triad) across off-the-shelf business systems.

IT frameworks vary in scope, detail, purpose, and adoption. Common examples include:

The NIST Cybersecurity Framework, often called NIST CSF, is a high-level risk management framework organized around six functions: govern, identify, protect, detect, respond, and recover. Organizations use it to assess capabilities, set targets, prioritize improvements, and communicate cybersecurity risk. NIST CSF provides a common language and structure for managing risk, but not detailed technical controls, implementation instructions, or automatic legal compliance.

ISO/IEC 27001 is an international standard for creating and improving an information security management system (ISMS). It helps organizations manage risk, assign responsibilities, select controls, conduct audits, and demonstrate formal security governance. ISO/IEC 27001 provides the requirements for establishing, implementing, and maintaining a certifiable management system, but it does not guarantee security or prescribe every technical control. However, ISO/IEC 27002 does provide technical control best practices and objectives to guide control implementation. An ISMS's value depends on certification scope and implementation quality.

CIS Controls are a set of priority cybersecurity safeguards maintained by the Center for Internet Security. Organizations use them to improve cyber hygiene and implement baseline protections such as asset inventory, secure configuration, vulnerability management, access control, logging, and incident response. CIS Controls provide practical security practices, but not a full risk management program or specialized guidance for every environment.

Securing the product: product cybersecurity

As software becomes embedded in everything from connected medical devices to vehicles, product cybersecurity has evolved into a specialized engineering discipline. Rather than deploying third-party software, professionals in this branch focus on engineering security directly into products from the ground up, utilizing secure development lifecycles to address real-world risks.

Frameworks, standards, and models in this category vary by industry, product type, development process, and adoption. Some prominent examples include:

The NIST Secure Software Development Framework, often called NIST SSDF, is a set of practices for building security into software design, development, testing, release, and maintenance. It provides a common structure for secure software development, but not product-specific threat models, detailed coding rules for every technology, or proof that software is vulnerability-free.

ISO/SAE 21434 is a cybersecurity engineering standard for road vehicles. Automotive manufacturers and suppliers use it to manage cybersecurity risk across the vehicle lifecycle, from concept through decommissioning. It addresses governance, threat analysis and risk assessment, cybersecurity requirements, verification, validation, vulnerability management, and post-production monitoring. It provides a lifecycle structure for automotive cybersecurity, but not a complete product security framework or proof that a vehicle or component is secure.

A Versatile Cybersecurity Development Lifecycle (AVCDL) was developed to make ISO/SAE 21434 practices more usable for day-to-day practitioners, though it can be mapped to cybersecurity engineering standards from other industries. It translates the standard's requirements into actionable processes, but does not provide implementation details such as tool selections, ready-to-use procedures, or work instructions. As AVCDL does not provide a certified implementation of ISO/SAE 21434, organizations need to assess and certify their own use of its practices.

The Building Security in Maturity Model (BSIMM), is a software security maturity model based on observed practices from real-world programs. Organizations use it to benchmark software security activities, identify maturity gaps, and compare programs to peers. BSIMM describes what mature programs do, but it is not a prescriptive checklist or list of product-specific requirements, certification, or proof that any product is secure.

Securing operations: OT and industrial control system cybersecurity

OT cybersecurity encompasses the hardware and software used to monitor and control physical industrial processes, such as manufacturing lines, power grids, and water systems. In these environments, safety, reliability, and continuous uptime are priorities. Because many OT systems run on decades-old, resource-constrained legacy technologies, standard IT practices like routine reboots or unverified patching can inadvertently halt critical physical infrastructure. Specialized OT frameworks, standards, and models are used to manage operational risk. Prominent examples include:

IEC 62443 is a family of standards for industrial automation and control system security. Asset owners, integrators, service providers, and product suppliers use it to manage OT cybersecurity risk across systems, components, and operational environments. It provides concepts such as zones and conduits, security levels, foundational requirements, and secure development expectations. IEC 62443 provides OT-specific security structure and requirements, but not a one-size-fits-all checklist, automatic compliance, or a substitute for site-specific engineering and safety analysis.

NIST SP 800-82 is NIST's guidance for industrial control system security. Organizations use it to understand and secure SCADA systems, distributed control systems, programmable logic controllers, and other OT technologies. It explains OT architectures, threats, vulnerabilities, and security control considerations. NIST SP 800-82 provides practical guidance for OT security planning, but it is not a certifiable standard and does not replace IEC 62443, sound engineering judgment, or operational risk analysis.

The Purdue Model is an architectural reference model for industrial control system environments. It describes how physical processes, control devices, supervisory systems, operations systems, and enterprise IT systems relate to each other. It is useful for OT segmentation and architecture discussions, but it is not a cybersecurity framework, control catalog, risk management process, or compliance standard. It may also not fully reflect modern cloud-connected, remote access, or industrial IoT-enabled OT environments.

Tying them together

IT, product, and OT cybersecurity frameworks, standards, and models address different risks, but the risks often overlap. A vulnerable product can create enterprise or OT exposure once deployed. Weak IT controls can affect product security through compromised development, build, or update systems. OT environments may depend on both enterprise infrastructure and vendor-supplied products.

The frameworks covered here help answer different questions about governance, secure development, industrial operations, and evidence of diligence; however, no framework can answer every question on its own or substitute for sound judgment about scope, implementation, and what a given framework was designed to do. The practical takeaway is to treat frameworks as complementary tools: choose the ones that fit the risks, systems, and decisions at hand, define where each applies, and tailor implementation to the organization's actual environment.