How to Get Started with a Cybersecurity Framework

This Expert Perspective is the third in a series on cybersecurity. Learn about the three core branches of cybersecurity, IT, product, and OT, in part one and what frameworks do and don't provide in part two.

Going from zero to a working defensive strategy in five practical steps

In the first two articles in this series, we described the three prominent branches of cybersecurity (IT, product, and OT) and examined what frameworks, standards, and models in each branch do — and don't — provide. Here, in part three, we take on the challenge of putting new cybersecurity frameworks into practical use.

Implementing a cybersecurity framework isn't just about securing operations today; it's about building a pipeline for continuous improvement, generating the documentation and evidence needed to satisfy regulators, investors, and insurers, and ensuring the organization is fully prepared for an attack and its aftermath.

Organizations beginning this work, whether launching a security program for the first time, responding to a customer or regulatory requirement, or formalizing practices, frequently run into early obstacles, including unclear scope, framework mismatches, or treating adoption as a one-off project rather than an ongoing practice. Adopting a framework may also require alignment among technical teams, legal and compliance functions, and organizational leadership, particularly when implementation spans multiple systems or cybersecurity branches.

Five practical, sequential steps can help organizations get started implanting new frameworks across IT, product, and OT cybersecurity.

Step one: Define the scope before choosing a framework

Before selecting a framework, define what is actually being protected and why by identifying the systems, data, products, or physical processes in scope and their corresponding cybersecurity branch (IT, product, or OT). For example, a hospital IT team securing employee laptops and a medical device manufacturer building a connected infusion pump face fundamentally different risks, even though both may eventually reference FDA guidance.

Scoping should also account for boundaries, dependencies, and stakeholders:

• Operational Dependencies: An OT environment dependent on enterprise IT for remote access or a product reliant on an external cloud backend extends the practical scope.
• Internal Stakeholders: Cybersecurity, IT, engineering, legal, procurement, and executive leadership all may shape requirements and effort, making it important to identify who needs to contribute to or approve the initiative.
• External Stakeholders: Regulators, customers, auditors, insurers, and partners may influence framework selection and compliance demonstration. 

Organizations that skip this step may select a framework that fits an industry label rather than their actual systems, risks, and stakeholders, discovering the mismatch only during an audit, incident, or dispute.

Step two: Match the framework to the risk (not vice versa)

Select a framework suited to your defined scope rather than adapting the scope to a familiar tool:

• IT Environments often start well with the NIST Cybersecurity Framework to establish a common risk vocabulary, identifying high-level gaps and layering in CIS Controls for technical baselines or ISO/IEC 27001 if a certifiable management system is required by customers or regulators.
• Product Environments benefit from adopting a secure development approach early, such as the NIST Secure Software Development Framework or ISO/SAE 21434 for connected vehicles, as retrofitting practices after product architecture finalization is far more costly and less effective.
• OT Environments may start with IEC 62443 for zone-and-conduit segmentation and security-level targets, supplemented by NIST SP 800-82 for control-system-specific guidance. The Purdue Model can be used as an architectural reference rather than a compliance target.

Many organizations need more than one framework because their systems span more than one branch. A connected industrial sensor, for example, may need product-security practices during development and OT-security practices once deployed. Similarly, a robotaxi may require an automotive cybersecurity framework such as ISO/SAE 21434, while the backend systems supporting its operations may follow a different information-security framework. Selecting frameworks based on the systems, risks, and cybersecurity branches involved, rather than defaulting to one framework for the entire organization, produces a more accurate and defensible risk picture.

Step three: Assess current state against the framework

Next, conduct a gap assessment comparing current practices against the framework's functions, controls, or requirements to identify what already exists, what is partially in place, and what is missing. This is typically where organizations first discover informal or undocumented practices and security work that is happening but isn't visible, measurable, or consistently applied.

A useful gap assessment captures tangible evidence, such as policies, logs, architecture diagrams, test results, and prior audit findings, that demonstrates current practices. This evidence forms the foundation for future compliance claims, insurance underwriting, or incident response. Organizations that treat the gap assessment as a one-time exercise, rather than a baseline to be revisited, often find their evidence stale or inconsistent by the time it's needed.

Frameworks are only useful to attorneys, insurers, and regulators to the extent an organization can demonstrate what the frameworks actually did.

Step four: Prioritize and build a roadmap

Few organizations can close every gap simultaneously, so prioritization matters. Effective roadmaps weigh three core factors:

1. Severity of the risk represented by a gap
2. Cost of disruption and remediation
3. External deadlines, such as contractual obligations, regulatory deadlines, or insurance renewal requirements

In OT environments, prioritization must also account for operational constraints, such as scheduling changes around maintenance windows. If a control cannot be deployed feasibly, organizations may need to prioritize an alternative measure that reduces the underlying risk.

Not every early priority needs to correspond to the highest risk. Addressing gaps that extend work that is already underway or those that are relatively simple to close can create early wins that build momentum, credibility, and confidence.

Sustaining momentum requires executive sponsorship. Framework efforts without visible leadership support can lose funding and staffing after the initial assessment. Clear ownership, realistic timelines, and regular reporting can help maintain engagement from leadership and keep implementation moving.

Step five: Implement, document, and generate evidence continuously

Implementation should produce not just improved security but continuous evidence that it exists. Frameworks are only useful to attorneys, insurers, and regulators to the extent an organization can demonstrate what the frameworks actually did. This means documenting decisions, retaining records of control implementation, and tracking exceptions and their justifications rather than leaving gaps unaddressed and unexplained.

Because threats, products, and systems evolve, periodic reassessment helps keep the framework relevant and supported by strong, defensible evidence.

Common pitfalls to avoid

• Treating a framework as a checklist: Checking boxes without understanding underlying risks can leave real exposures unaddressed.
• Choosing based on familiarity rather than fit: A well-known framework or one from a previous organization may not fit a different risk profile.
• Confusing adoption with certification: Conflating guidance documents with certifiable standards can lead to overestimating compliance.
• Confusing alignment with implementation: Being "informed by" a framework is useful, but it is not equivalent to demonstrating that the relevant controls, principles, or requirements have been addressed.
• Scoping inaccurately: Scoping either too narrowly (missing critical dependencies) or too broadly (diluting focus) can create vulnerabilities and waste resources.
• Underinvesting in maintenance: Neglected implementations quickly become outdated historical records rather than active risk tools.

Tying it together

Getting started with a cybersecurity framework is less about picking the right framework on the first try and more about establishing a disciplined process. Scope deliberately, select frameworks suited to each branch, assess honestly, prioritize realistically, and maintain the effort over time. For attorneys and insurers, this structured process is often what determines whether an organization's cybersecurity practices will hold up under scrutiny. For executives and product teams, it's what converts cybersecurity from an abstract obligation into a concrete, measurable, and defensible program.