SMALL BUSINESS CYBERSECURITY

Small Business Cybersecurity Incident Response Plan: What to Do Before, During and After an Incident

A cybersecurity incident is a bad time to decide who should make decisions, which systems matter most, who needs to be called, or whether usable backups exist. A practical small-business incident response plan establishes those answers before an emergency and gives the people involved a clear sequence for containing damage, preserving useful evidence, restoring operations and learning from what happened.

What is a cybersecurity incident response plan?

A cybersecurity incident response plan is a documented set of responsibilities, contacts and actions your business can use when something goes wrong. The incident might involve a compromised email account, malware on a computer, ransomware, stolen credentials, suspicious financial activity, exposed data or another event that threatens systems, information or business operations.

The goal is not to predict every possible attack. The goal is to remove avoidable confusion. Your plan should establish who can make decisions, how employees report suspicious activity, which systems and accounts are most important, how affected technology can be contained, who may need to be contacted and how the business will move from containment into recovery.

Incident response also fits into a broader cybersecurity program. The NIST Cybersecurity Framework 2.0 organizes cybersecurity outcomes around Govern, Identify, Protect, Detect, Respond and Recover. An incident response plan puts particular emphasis on what your business will do when a potential incident is detected and how it will restore operations afterward.

What should you prepare before a cybersecurity incident?

The most useful incident response work happens before an emergency. A small business does not need a large security operations center or a complicated response manual, but it should know who is responsible, what needs to be protected first and how the right people will communicate if normal systems become unavailable.

Keep this information somewhere the response team can reach even if a primary computer, server or cloud account is unavailable. Your small-business cybersecurity checklist can help identify preventive gaps, while a documented small-business backup strategy helps establish what will be available when recovery begins.

The first 15 minutes: what to do when an incident is suspected

The first few minutes of a cybersecurity incident are about establishing control, not solving everything immediately. Move deliberately enough to avoid destroying useful information, but quickly enough to reduce the chance that the problem spreads or causes additional damage.

1. Record what was observed

Write down what triggered the concern and when it was noticed. Record the affected user, device, account, application or service; any unusual messages or alerts; and the actions already taken. Screenshots, alert details, timestamps and relevant error messages can help establish a useful timeline.

Do not rely on memory alone. Even a simple incident log becomes valuable as more people become involved and the sequence of events becomes harder to reconstruct.

2. Notify the response owner

Use the reporting path established in the incident response plan. The response owner can coordinate technical help, determine who else needs to know and prevent several people from making conflicting changes at the same time.

If the suspected incident involves business email or another normal communication system, use a trusted alternate method to contact the response team rather than assuming the affected channel is private.

3. Limit immediate exposure

If a workstation appears compromised, isolating it from the network may help prevent additional communication or spread. If an account appears compromised, the response may involve restricting access, revoking active sessions or securing credentials. The appropriate action depends on what happened and which systems are involved.

Avoid making unnecessary changes simply to make the problem disappear. Deleting files, wiping a device, clearing logs or immediately rebuilding a system can remove information that may be useful for understanding the incident.

4. Start an incident timeline

Record significant actions as they occur: who was contacted, what was isolated, which accounts were changed, what evidence was preserved and when each decision was made. The timeline helps technical responders coordinate work and gives the business a clearer record for recovery, insurance, legal review or a later after-action assessment.

The first hour: determine scope and coordinate the response

After the immediate situation is stabilized, the response should shift toward understanding what happened and how far it may have reached. Avoid assuming that the first affected computer, account or alert represents the full incident.

Determine what may be affected

Identify the users, devices, accounts, applications, cloud services and data that may be involved. Look for connections between them: a compromised email account may expose cloud files, while malware on one computer may have interacted with shared storage, credentials or other systems.

Separate what you know from what you suspect. Maintaining that distinction helps the response team avoid treating an early assumption as a confirmed fact.

Preserve useful evidence

Keep the incident timeline, alerts, relevant emails, screenshots, logs and other available records. If professional incident-response or forensic assistance may be needed, avoid wiping devices, deleting accounts, clearing logs or making unnecessary changes that could remove useful evidence.

Containment is still important, but containment and evidence preservation are not always the same thing. Isolating an affected device from the network, for example, is different from erasing or rebuilding it.

Bring in the right help

Escalate according to the type and seriousness of the incident. That may include internal IT, a managed service provider, cybersecurity specialists, relevant technology vendors, legal counsel, a cyber-insurance provider or financial institutions.

For a serious incident, early professional guidance can help the business make containment and recovery decisions without unintentionally creating additional technical, contractual, insurance or legal problems.

Set the next response priorities

Decide what needs attention first based on business impact and the evidence available. Priorities may include stopping unauthorized access, protecting unaffected systems, securing privileged accounts, preserving critical data, maintaining essential operations and preparing for a controlled recovery.

Containment vs. evidence: stop the damage without losing the story

Containment is meant to limit additional damage while the business determines what happened. The challenge is that some actions that appear to solve the immediate problem can also remove logs, files, session information or other evidence that may be useful to technical responders. The right balance depends on the incident, but a few principles can make the decision more deliberate.

Isolate affected devices when appropriate

If a computer appears to be actively compromised, separating it from normal network access can help limit communication with other systems. Isolation may involve disconnecting a network cable, disabling Wi-Fi or using an endpoint-management or security tool's isolation capability.

Isolation is not the same as erasing the device. Unless there is an immediate safety or operational reason to do otherwise, avoid wiping, reimaging or unnecessarily altering a potentially important system before deciding whether its information needs to be preserved.

Secure compromised accounts

If an account is being used without authorization, containment may include disabling access temporarily, changing credentials, revoking active sessions or tokens and reviewing authentication methods. Privileged, email, financial and cloud-administration accounts deserve particular attention because access to one account can provide paths into other systems.

Make security changes from a device you reasonably believe is clean. If the affected account used the same password elsewhere, those other accounts may also require attention.

Protect unaffected systems

Do not focus so narrowly on the first compromised asset that the rest of the environment is ignored. Review whether similar accounts, devices or services could be exposed through the same weakness, credential or connection.

Temporary restrictions may be appropriate while the scope is being determined, especially for unnecessary remote access, suspicious accounts or connections between affected and critical systems.

Preserve logs and records

Save relevant security alerts, authentication records, email details, administrative changes, system logs and other available evidence. Continue the incident timeline and record containment actions so later responders can distinguish attacker activity from changes made by the business itself.

If logs have short retention periods, preserving useful records early can be especially important. Avoid clearing logs or deleting suspicious messages merely to clean up the environment.

Do not rush into restoration

Restoring a system before the cause of the incident is understood can recreate the same problem or reconnect a still-compromised environment. Recovery should begin when the business has enough confidence that the affected path has been contained and the restoration source is appropriate to use.

A documented small-business backup strategy can make this decision easier by identifying what is protected, where backup copies are stored and which systems should receive recovery priority.

Know when to escalate

A small business should not assume every incident can be handled internally. Consider qualified outside assistance when the scope is unclear, privileged accounts are compromised, ransomware is involved, sensitive information may have been exposed, important systems remain unavailable or the incident could create contractual, insurance, regulatory or legal obligations.

Document every major containment decision

Record what was changed, who authorized it, when it happened and why. This creates a clearer technical history and helps the business explain later why a device was isolated, an account was disabled, a vendor was contacted or a recovery action was delayed.

What to do if an email or cloud account is compromised

A compromised email or cloud account can become more than an account problem. Email is often connected to password resets, shared files, customer communication and other business services, while a cloud administrator account may provide access to users, applications and security settings. Respond as though the attacker may have done more than simply learn the password.

Secure access from a trusted device

Use a device you reasonably believe is clean to secure the affected account. Depending on the service and your administrative capabilities, that may include changing the password, revoking active sessions or tokens, reviewing registered authentication methods and temporarily restricting access while the incident is investigated.

If the password was reused on other services, treat those accounts as potentially exposed too. Moving toward unique credentials and a business password manager can reduce the damage caused by password reuse, while multi-factor authentication adds another layer of protection around important accounts.

Check what may have changed

Review available sign-in history, security alerts, administrator activity and account settings. For email accounts, look for unfamiliar forwarding rules, inbox rules, delegates, recovery information or other changes that could allow continued access or hide malicious activity.

Preserve relevant records before removing suspicious settings where practical. If the account has administrative privileges, expand the review to changes involving other users, permissions, applications and security controls.

Check connected accounts and warn affected people

Determine what the compromised account could access and whether it was used to send messages, open cloud files, reset other passwords or impersonate the user. Employees, customers or vendors may need to be warned if they received suspicious messages or requests from the account.

For businesses reviewing the preventive controls around this attack path, our small-business email security guide covers additional technology options. During an active incident, however, restoring control of the account and determining what the attacker accessed or changed come first.

What to do if a business computer has malware

A malware alert can represent anything from a blocked malicious file to a broader compromise involving credentials, persistence or access to other systems. Treat the affected device as one part of the investigation rather than assuming that removing the detected file ends the incident.

Isolate the affected computer

If compromise appears active or credible, isolate the computer from normal network access when appropriate. This can help limit additional communication or spread while allowing the response team to determine what happened. Avoid immediately wiping or reimaging the device if logs or other information may still be needed.

Determine what the device could access

Consider which user was signed in, whether the computer had administrative privileges, what shared drives or cloud services were accessible and whether sensitive business information was stored locally. Review available security alerts and logs for signs that other devices or accounts may also be involved.

Consider exposed credentials

If malware may have captured credentials or browser sessions, securing the computer alone may not be enough. Important passwords, active sessions and authentication methods may need review from a trusted device, particularly for email, administrator, financial and remote-access accounts.

Clean, rebuild or replace only after the scope is understood

Depending on the malware and the confidence you have in the investigation, remediation might involve security-tool cleanup, rebuilding the system from a trusted source or replacing it. The goal is to return a known-good device to service without reconnecting the same compromise. If the scope is uncertain or important systems are involved, qualified technical assistance may be appropriate.

Endpoint protection can help prevent, detect and investigate malicious activity, but it is one layer of the response rather than the entire response. Our small-business antivirus and endpoint-security guide covers options businesses can evaluate for ongoing protection.

What to do if ransomware hits the business

Ransomware can turn a security incident into an operational crisis by encrypting systems, disrupting access to data or combining encryption with data theft and extortion. The immediate priorities are to limit additional impact, understand the scope of the incident and protect recovery options rather than rushing to restore systems.

Contain the spread and protect unaffected systems

Isolate affected devices and systems when appropriate and look for signs that other parts of the environment are involved. Pay particular attention to administrative accounts, remote-access tools, shared storage and other connections that could allow the incident to spread.

Do not connect backup media or recovery systems unnecessarily while the environment may still be compromised. Preserve available alerts, logs, ransom notes and other relevant information, and continue documenting actions in the incident timeline.

Bring in appropriate help early

Ransomware can involve technical recovery, business interruption, insurance, legal obligations, law enforcement and possible data exposure. Depending on the circumstances, contact the organization's cyber insurer, qualified incident-response or forensic specialists, legal counsel and other appropriate parties early enough for their guidance to influence important decisions.

Verify backups before restoring

Do not assume that the newest backup is automatically safe to restore. Determine which backup copies are available, whether they were accessible from affected systems and whether there is evidence that they were altered, encrypted or deleted. Recovery should use a backup or other trusted source that the response team has reasonable confidence is suitable for restoration.

A documented small-business backup strategy should identify critical systems, backup locations, recovery priorities and restoration procedures before an incident occurs.

Restore in a controlled order

Recovery is more than copying files back. Address the compromised access path or other known cause where possible, secure important accounts, rebuild or remediate affected systems as appropriate and restore business services according to priority. Validate restored systems before returning them to normal use and watch for signs that malicious activity has resumed.

Decisions involving ransom demands, reporting obligations or potentially exposed information can carry legal, financial and operational consequences. Those decisions should be made with appropriate professional guidance based on the facts of the specific incident rather than from a generic incident-response checklist.

What to do if sensitive business or customer data may have been exposed

A suspected data exposure requires more than determining whether a computer is working again. The business needs to establish what information may have been involved, who or what had access to it, how the exposure occurred and what obligations may apply. Avoid making broad statements about the scope of the incident before those facts are reasonably understood.

Preserve relevant records and involve appropriate technical, legal, insurance or other professional guidance when the circumstances justify it. Notification requirements can vary by jurisdiction, industry, contract, type of information and the facts of the incident, so a generic checklist should not be treated as a substitute for advice specific to the business.

Keep confirmed facts separate from assumptions as the investigation develops. If the scope changes, update the incident timeline and the people responsible for response decisions. This makes later communications and recovery decisions easier to support with a documented record of what the business actually knew at each stage.

What to do after business email compromise or suspected financial fraud

Business email compromise can combine account takeover, impersonation and fraudulent payment instructions. If money may have been sent, banking information changed or a payment request acted upon, treat the financial transaction and the underlying account compromise as related but separate response priorities.

Contact the financial institution quickly

If a fraudulent transfer or payment may have occurred, contact the bank or financial institution as quickly as practical using a phone number, banking portal or other contact method already known to be legitimate. Explain that the transaction may be fraudulent and ask what options are available to stop, recall, hold or investigate it. Speed can matter, but the available actions depend on the transaction and institution.

Verify payment instructions through a trusted channel

Do not rely on phone numbers, reply addresses or contact information contained only in the suspicious email thread. Verify changed banking details, wire instructions or unusual payment requests using a previously established contact method or another independently trusted channel.

Secure the affected email account

If a real employee, executive, vendor or partner account may have been compromised, follow the account-containment process as well. Review sign-ins, active sessions, authentication methods, forwarding rules, inbox rules, delegates and other settings that could provide persistence or hide messages. Determine whether the account was used to impersonate the owner or target additional people.

Preserve the messages and transaction details

Keep the suspicious messages, headers or other available email details, invoices, payment instructions, transaction references and relevant timestamps. Record who received the request, what verification occurred, when money was sent or changed and when the suspected fraud was discovered.

Look beyond the first payment request

Determine whether other employees, customers or vendors received similar messages and whether previous conversations were monitored or altered. Review related accounts and transactions for additional suspicious activity, and involve appropriate financial, technical, insurance, legal or law-enforcement resources based on the circumstances.

Who should a small business contact during a cybersecurity incident?

The right contacts depend on what happened. A small incident may stay with the person responsible for IT or an outside technology provider, while a serious event may require leadership, an incident-response specialist, the cyber insurer, legal counsel, a financial institution, affected technology providers or appropriate government and law-enforcement resources. Not every incident requires every contact, but the business should know in advance who can be reached and who has authority to make important response decisions.

Keep essential names, phone numbers, policy information, vendor support details and escalation instructions somewhere that remains accessible if normal email or business systems are unavailable. Preparation should also make clear how employees report suspicious activity internally. Our small-business cybersecurity checklist can help identify preventive and readiness tasks that support the incident-response plan.

How should a small business communicate during a cybersecurity incident?

Decide who is authorized to communicate about the incident and keep internal updates focused on confirmed facts, current priorities and actions employees need to take. Separate what is known from what is still being investigated, and avoid speculation about the cause, scope or affected information. If normal email, messaging or another communication system may be compromised, move response coordination to an alternate trusted channel identified in the incident-response plan.

External communication may involve customers, employees, vendors, insurers, financial institutions, regulators, law enforcement or other parties depending on the incident. Coordinate significant notifications and public statements with the people responsible for business, legal and incident-response decisions, and document what was communicated and when. Requirements can vary with the circumstances, so do not assume that one notification process or timeline applies to every incident.

How should a small business recover safely after a cybersecurity incident?

Recovery should begin only after the business has enough understanding of the incident to avoid immediately recreating the same problem. Before restoring normal operations, address the compromised access path where reasonably possible, secure affected accounts and systems, determine which services should return first and use backups or other recovery sources that the response team has reasonable confidence have not been altered, encrypted or otherwise compromised.

Restore critical services in a controlled order based on business priorities and dependencies, then validate that systems, applications, accounts and data are functioning as expected. Continue monitoring restored services for unusual activity or signs that the original compromise persists. Document what was restored, which recovery source was used, what security changes were made and when the service returned to operation. A small-business backup strategy supports this process, but having a backup is not the same as confirming that recovery is safe and complete.

What should happen after a cybersecurity incident?

After operations are stable, conduct an after-action review while the timeline and response decisions are still reasonably fresh. Reconstruct what was detected, when important events occurred, which systems or accounts were affected, what containment and recovery actions were taken and how the business communicated. Identify what worked, what caused delays and where responders lacked information, access, authority or a reliable process. Keep evidence-supported findings separate from assumptions when the cause or full scope remains uncertain.

Turn the review into specific improvements rather than simply filing the incident record away. Update the incident-response plan, contact information, recovery procedures, employee guidance and relevant security controls based on what was learned. Assign important follow-up actions to an owner and track them to completion. The incident record should also preserve the timeline, major decisions and lessons learned so the business has a stronger starting point if another incident occurs.

Small business cybersecurity incident response plan template

Your incident response plan does not need to be a large document. It needs to give the people involved enough reliable information to make the first decisions without searching for contacts, responsibilities, system priorities or recovery information during an emergency. Use the following six areas as a practical starting template and adapt them to your business.

1. Incident response leadership

Document the primary incident lead and at least one backup decision maker. Record who has authority to isolate systems, disable accounts, contact outside specialists, approve recovery actions and make significant business or communication decisions. Include names, roles and contact information that can be reached even if normal company systems are unavailable.

2. Critical systems, accounts and data

List the systems and information the business depends on most, such as email, identity and administrator accounts, financial systems, customer records, cloud applications, shared storage, line-of-business software and essential devices. Note important dependencies so responders understand which services should receive priority during containment and recovery.

3. Incident reporting and escalation

Define how an employee should report a suspicious email, compromised account, malware alert, lost device, unusual financial request or other suspected incident. Document where the report goes, who evaluates it and what types of events require escalation to leadership or outside assistance. The reporting path should be simple enough to use under pressure.

4. Emergency contacts

Maintain current contact information for the people and organizations that may be needed during an incident. Depending on the business, that can include the IT provider, incident response specialist, cyber insurer, legal counsel, financial institution, critical technology vendors and appropriate government or law-enforcement resources. Record relevant policy numbers, support numbers and escalation instructions where appropriate.

5. Alternate communications

Document how the response team will communicate if normal email, messaging or another primary business system cannot be trusted or is unavailable. The alternate method should be established before an incident and accessible to the people who may need it rather than invented after the normal communication channel has already been disrupted.

6. Backup and recovery information

Record where important backups are maintained, who can authorize a restoration, how recovery access is obtained and which systems should normally be restored first. Include enough information for responders to locate the recovery procedure without placing sensitive credentials directly in an incident plan that may be broadly accessible. The small-business backup strategy guide explains how backup layers and recovery planning fit together.

Small business incident response checklist: before, during and after

A short checklist can help responders remember the most important actions when an incident creates pressure and uncertainty. Adapt these steps to your systems, providers, legal requirements and business priorities rather than treating them as a substitute for the more detailed incident-response plan.

Before — assign responsibility: Name the incident lead and backup decision makers, document who can isolate systems or accounts, and keep emergency contact information available outside the systems that might become unavailable during an incident.

Before — know what matters most: Identify critical systems, administrator and business accounts, important data, major dependencies, backup locations and the services that should normally receive priority during recovery.

Before — prepare the response path: Give employees a simple way to report suspicious activity, establish alternate communications, maintain recovery procedures and periodically confirm that important contact and escalation information is still current.

During — record and contain: Start an incident timeline, record what was observed and when, notify the response owner, limit immediate exposure where appropriate and avoid unnecessary destructive changes that could remove useful evidence.

During — determine scope and get help: Identify the accounts, devices, applications, data and business processes that may be affected. Preserve relevant records and bring in the appropriate technical, insurance, legal, financial or other specialist help based on the nature and seriousness of the incident.

During — recover deliberately: Address the compromised access path where reasonably possible, protect unaffected systems, verify the recovery source and restore services in a controlled order. Validate restored systems and continue monitoring for signs that the incident persists.

After — learn and improve: Reconstruct the timeline, document major decisions and lessons learned, identify response or recovery gaps and assign follow-up improvements to owners. Update the incident-response plan, contacts, procedures and relevant security controls so the experience improves the next response.

How should a small business test its incident response plan?

You do not need to wait for a real attack to find out whether the plan works. A tabletop exercise lets the people involved talk through a realistic incident without disrupting production systems. Periodically exercise the plan and consider another review after significant technology, provider or personnel changes, or after a real incident exposes a gap.

• Choose a realistic scenario, such as a compromised Microsoft 365 account, ransomware alert, infected laptop or fraudulent payment request.
• Ask how the incident would first be detected or reported.
• Confirm who becomes the incident lead and who serves as the backup decision maker.
• Verify that responders can find current emergency contacts without relying entirely on potentially affected systems.
• Walk through which device, account or service would be isolated first and who has authority to do it.
• Identify what evidence, logs, messages, alerts and timestamps responders would try to preserve.
• Discuss how the team would determine which additional systems, accounts or data might be affected.
• Confirm when outside IT, incident-response, insurance, legal, financial or other specialist help would be contacted.
• Test how the team would communicate if normal email or messaging could not be trusted.
• Ask which business services would receive priority if normal operations were disrupted.
• Confirm where recovery procedures and backup information are kept and who can authorize restoration.
• Identify decisions or steps that were unclear, slow or dependent on information the team could not readily access.
• Record the lessons from the exercise, assign needed improvements to owners and update the incident-response plan.

FAQ

What counts as a cybersecurity incident?

A cybersecurity incident is an event that threatens the confidentiality, integrity or availability of business systems, accounts, networks or information and requires investigation or response. Examples can include a compromised email or administrator account, malware, ransomware, unauthorized access, exposed sensitive data, a lost device containing business information or suspicious activity connected to financial fraud. Not every alert becomes a confirmed incident, which is why the response process should distinguish what is known from what is still being investigated.

Should you disconnect a compromised computer from the network?

Isolation can be an appropriate containment step when a computer appears actively compromised or could spread malware, expose shared resources or allow continued unauthorized access. Depending on the environment, that may mean disconnecting its network connection or using a security or management tool to isolate it. Isolation is different from wiping, rebuilding or unnecessarily altering the device, which can remove information useful to the investigation.

Should you turn off a compromised computer?

Not automatically. Abruptly powering down a computer can cause volatile information to be lost, while leaving an actively compromised system connected can create additional risk. When practical, isolate the affected system and obtain guidance from the person or provider handling the incident before making destructive or irreversible changes. Immediate safety, operational impact and the risk of continued compromise can change the appropriate response.

What should a small business do if ransomware is discovered?

Begin by containing affected systems and protecting unaffected devices, accounts, shared storage and backups from additional exposure. Preserve relevant alerts, logs, ransom notes and timeline information, determine what may be affected and bring in appropriate technical and other professional help early when the incident is serious. Verify backups and the recovery environment before restoration rather than assuming that restoring files alone has removed the cause of the incident.

When should a small business bring in outside incident-response help?

Outside help becomes particularly important when the business cannot confidently determine the scope of an incident, privileged or administrator accounts may be compromised, sensitive information may have been exposed, ransomware or significant malware is involved, financial fraud is suspected, critical operations are disrupted or specialized forensic, insurance or legal guidance may be needed. The incident-response plan should identify likely contacts before an emergency so the business does not have to search for help under pressure.

Does cyber insurance replace an incident-response plan?

No. Cyber insurance may provide access to resources or coverage for certain incident-related costs subject to the policy, but the business still needs to know how employees report an incident, who makes decisions, which systems matter most, how affected technology can be contained and where critical response and recovery information is kept. Review the policy's notice, coverage and provider requirements in advance so the incident-response plan reflects how the business should engage the insurer if an event occurs.

Bottom line

A cybersecurity incident response plan gives a small business a practical way to make difficult decisions before an emergency creates pressure and confusion. The plan does not need to predict every possible attack. It needs to establish who is responsible, how incidents are reported, which systems and accounts matter most, how immediate exposure can be limited and where the business will turn for help.

During an incident, focus on establishing reliable facts, containing additional damage, preserving useful information and coordinating the people who need to respond. Recovery should be deliberate: secure the affected environment, verify recovery sources, restore important services in a controlled order and continue watching for signs that the incident has not been fully resolved.

After operations stabilize, use the incident as an opportunity to improve. Document what happened, identify gaps in technology or process, assign follow-up work and update the response plan. A plan that is periodically exercised and revised is far more useful than one that is written once and forgotten.

Sources

• NIST — Cybersecurity Framework 2.0: Small Business Quick-Start Guide (SP 1300)
• NIST — Cybersecurity Framework 2.0 for Small Business resources
• CISA — #StopRansomware Guide
• FTC — Data Breach Response: A Guide for Business
• FTC — Cybersecurity for Small Business

Tech Fit Guide is an independent technology publication. This article provides general cybersecurity and technology information, not legal advice. Incident-response, reporting and notification requirements can vary by jurisdiction, industry, contract and the facts of an incident. References to NIST, CISA and FTC resources do not imply endorsement of Tech Fit Guide or of any product, service or recommendation discussed on this site.