NIST Cybersecurity
Framework 2.0

Know what the business is actually here to do, so security spending protects what matters instead of chasing everything.

Figure out who cares about your security — customers, regulators, employees, partners — and factor in what they expect.

Track every law, regulation, and contract clause that dictates how you handle security and privacy, and keep meeting them.

Be clear about what services others rely on you to deliver, so you know what an outage or breach would cost them.

Map what you depend on to operate — cloud providers, suppliers, utilities — because their failures become your risks.

Agree, at the top, on what the risk program is trying to achieve — so everyone is working toward the same targets.

Put in writing how much risk you are willing to take and where your hard limits are, then keep it current.

Treat cyber risk as one of the company's business risks, not a siloed IT problem off to the side.

Decide up front how you generally handle risks — accept, mitigate, transfer, or avoid — and tell people the ground rules.

Set up clear channels so risk information flows up, down, and across — including risks coming from your vendors.

Use one consistent way to score and rank risks so you can compare apples to apples and fix the worst ones first.

Remember that some risks are worth taking — weigh the upside of new tech or approaches, not just the downside.

Leaders own the risk and set the tone — security is their job too, not something they can fully delegate away.

Spell out who does what and who has the authority to decide, so nothing critical falls through the cracks.

Fund and staff security in line with the risk you face — a strategy with no budget or people behind it is just paper.

Bake security into hiring, onboarding, role changes, and offboarding so people are an asset, not a gap.

Write clear security policies that reflect your actual context and priorities, then make sure people follow them.

Keep policies alive — revisit them as threats, tech, and the business shift, instead of letting them gather dust.

Check whether your risk strategy is actually working and course-correct based on what the results tell you.

Make sure the strategy still covers every requirement and risk you face, and fix any gaps you find.

Measure how well the program performs with real metrics, then tune it where the numbers show weakness.

Stand up a real program for managing supplier and third-party risk, agreed on by leadership — not ad hoc reactions.

Be explicit about who handles what security duties between you and your partners, so nothing is assumed.

Fold supply chain risk into your broader risk processes instead of treating vendors as a separate afterthought.

Keep an up-to-date list of your suppliers and rank them by how much damage they could cause if compromised.

Put your security expectations into contracts up front, so suppliers are contractually obligated to meet them.

Vet a vendor's security before you sign, not after — do your homework while you still have leverage.

Keep watching supplier risk for the whole relationship, not just at signing — risk changes over time.

Plan for incidents that involve your vendors, and make sure they are looped into response and recovery.

Bake supply chain security into the whole life cycle of a product or service and keep measuring how it is doing.

Plan for a clean breakup — how you offboard a vendor, get your data back, and revoke access when the deal ends.

Keep an up-to-date list of every physical device you own, from laptops to servers to IoT sensors.

Track every application, service, and system you run — including licenses and versions.

Keep current diagrams and maps of how data is allowed to move across and beyond your network.

Keep a list of the external and third-party services your organization depends on.

Rank your assets by how important they are, so you can protect the crown jewels first.

Know what data you hold, where it lives, and how it's labeled — especially sensitive types.

Manage assets from purchase to retirement, including secure disposal at end of life.

Find, confirm, and log the weaknesses in your systems before attackers do.

Subscribe to threat feeds and communities so you learn about new attacks early.

Identify who or what might harm you — insiders, criminals, nation-states — and write it down.

Estimate how likely each risk is and how much damage it would cause.

Combine threat, vulnerability, likelihood, and impact into a risk score to decide what to tackle first.

Decide how to handle each risk — accept, mitigate, transfer, or avoid — then plan and follow through.

Review changes and policy exceptions for the risk they add, and keep a record of them.

Set up a way for researchers and others to report vulnerabilities to you, and act on what comes in.

Verify that hardware and software are genuine and untampered before you buy or deploy them.

Vet the security of important vendors before signing them on.

Learn from audits, assessments, and reviews, and turn the findings into concrete improvements.

Use pen tests, red-team exercises, and tabletops — including with partners — to find things to fix.

Notice friction and failures in day-to-day operations and use them to improve how you work.

Build, share, and keep updating your response and continuity plans so they actually work when needed.

Every person, service, and device that gets in has an account and credential that the organization actually tracks and controls.

Before handing someone a credential, you verify they are who they claim to be — more rigorously the more sensitive the access.

The system checks that whoever (or whatever) is asking for access can prove their identity before it's granted.

When one system vouches for a user to another (like a single sign-on token), that assertion is kept tamper-proof and checked on the receiving end.

People get only the access they need for their job (and no single person can do everything), with those permissions written down and reviewed regularly.

Doors, server rooms, and physical devices are locked down, logged, and watched based on how sensitive they are.

Everyone in the organization learns the basics — spotting phishing, handling data safely, reporting problems — so they don't accidentally open the door.

People with security-heavy jobs (admins, developers, incident responders) get deeper, role-specific training beyond the general awareness.

Stored data — on disks, in databases, on laptops — is encrypted and guarded so it can't be read or tampered with if someone gets hold of it.

Data moving across networks is encrypted so it can't be intercepted or altered on the way.

Data actively being processed in memory or by an application is shielded from leaking or being tampered with while it's in use.

You keep good backups, protect them from tampering or deletion, and actually test that you can restore from them.

Systems are set up from known-good, hardened baselines, and changes to those settings are controlled rather than ad hoc.

Software is kept patched and up to date, and anything outdated, unsupported, or unneeded is replaced or removed.

Physical devices are kept up to date, and aging or unsupported hardware is retired and disposed of securely.

Systems produce useful logs and send them somewhere they can actually be watched and investigated.

Only approved software is allowed to run, so unvetted or malicious programs can't be installed or executed.

Security is baked into how software is built — from design to deployment — and measured, not bolted on at the end.

The network is segmented and filtered so attackers can't roam freely or reach systems they shouldn't.

Physical infrastructure is protected against things like power loss, fire, flooding, and overheating.

Systems are built to keep running — or fail gracefully and recover — even under stress, failure, or attack.

You keep enough compute, storage, and bandwidth headroom so systems stay available under peak or surge demand.

Watch your network traffic for anything that shouldn't be there.

Keep an eye on physical spaces (doors, badges, cameras) for suspicious access.

Watch what people and devices actually do, so misuse or a hijacked account stands out.

Keep tabs on your vendors and cloud providers; their access is your risk too.

Monitor your computers, servers, and software for signs of tampering or malware.

Dig into suspicious events to understand what actually happened.

Pull logs and signals from everywhere together so the full picture emerges.

Work out how bad it is and how far it spread.

Get the detection into the hands (and tools) of the people who can act on it.

Fold in threat intel and context so you know if this matches a known attack.

Have clear rules for when a weird event officially becomes an incident.

When something is officially called an incident, you kick off the written response plan and pull in the outside partners it names.

Every alert or report gets a first look to confirm it's real and actually worth responding to.

You sort each incident by type and rank it by how much damage it could do, so the worst gets worked first.

If an incident grows or crosses a threshold, you push it up to more senior people, other teams, or leadership.

You use agreed rules to decide when the crisis is contained enough to start putting systems back to normal.

You dig into the evidence to reconstruct exactly what happened and why it was possible in the first place.

Everything responders do gets logged, and those logs are protected so they can be trusted later in court or review.

You gather the forensic evidence — logs, disk images, memory — and keep it unaltered and traceable to its source.

You work out how big the incident really is — how many systems, records, or people are affected — and check that estimate holds up.

You tell the people who need to know — leadership, legal, customers, regulators, law enforcement — within the timelines the rules require.

You share useful incident details with the right people and partners so everyone can respond and defend more effectively.

You wall off the attack so it can't spread any further — isolating systems, cutting access, and blocking the attacker.

You remove the threat for good — wiping out malware, closing the hole it came through, and rebuilding what was tainted.

Once the response team gives the signal, you kick off the recovery playbook you prepared ahead of time.

Decide which systems come back first and how, then work the list in priority order rather than restoring everything at once.

Check that your backups and restore images are clean and uncorrupted before you trust them — attackers love to poison the very copies you'll fall back on.

Use what the incident taught you to set the new normal — sometimes 'back to how it was' isn't good enough, and some functions need to run differently.

After rebuilding, prove the systems are genuinely clean and working before you call them fully back in service.

Formally call the incident closed against agreed criteria, and finish writing up what happened so the record is complete.

Keep the people who need to know — leadership, staff, partners, regulators — updated on how the recovery is going and when things will be back.

When you go public, speak with one approved voice — vetted messaging through the right channels, not off-the-cuff statements.