How much cybersecurity is enough? The answer depends on your organization’s risks, obligations, and ability to recover from an incident. Spending less can be reasonable when you understand what protection changes, what risk remains, and how a loss would be handled. This guide helps you compare costs, recognized standards, insurance considerations, and documented responsibilities before deciding which safeguards to keep, replace, or reduce. The same questions apply to any IT provider, software vendor, consultant, or other advisor.
Sharing this with another advisor? Start with the advisor questions, complete the recommendation record, and use the email template. The reference section provides the independent sources.
Cybersecurity standards do not originate with EasyITGuys or any other individual IT company. Modern cybersecurity is shaped by overlapping frameworks, government guidance, laws, regulations, contracts, insurance requirements, industry standards, technical research, and organizational risk decisions.
| Source | What it contributes | What to understand |
|---|---|---|
| NIST | Risk-management frameworks, technical standards, cybersecurity guidance, and small-organization resources. | NIST guidance is widely used, but the applicability of a particular publication depends on the organization, contract, regulation, or program involved. |
| Center for Internet Security | The CIS Critical Security Controls and Implementation Groups provide prioritized cybersecurity safeguards based on risk, resources, complexity, and data sensitivity. | CIS describes Implementation Group 1 as essential cyber hygiene. Higher Implementation Groups add safeguards for organizations with greater risk or complexity. |
| CISA, FBI, NSA, FCC, and SBA | Cybersecurity practices, threat information, planning resources, technical recommendations, training, and small-organization guidance. | Government guidance can provide strong independent reference points without automatically making every recommendation a legal requirement for every organization. |
| Regulators and regulated programs | Examples include HIPAA security requirements, FTC Safeguards Rule requirements for organizations within its scope, CMMC and defense-contract requirements, and other sector-specific obligations. | Applicability matters. A requirement that applies to a healthcare organization, financial institution, defense contractor, or another regulated entity should not automatically be described as a universal requirement. |
| State and regional authorities | States, economic-development organizations, universities, and cybersecurity centers publish education, minimum-baseline programs, and localized resources. | State laws and regulatory requirements should be evaluated separately from voluntary state educational guidance. |
| Insurance carriers | Underwriting questions, required controls, eligibility conditions, policy terms, exclusions, limits, and incident-response resources. | The organization’s actual policy, application, representations, endorsements, and carrier decisions control. Never assume coverage from a general article or checklist. |
| Contracts and customers | Customer agreements, vendor contracts, government contracts, payment-processing agreements, and other relationships may create cybersecurity obligations. | A voluntary framework can become important when a contract, insurer, customer, or governing program incorporates it. |
| Organizational leadership | Leadership determines how much residual risk the organization is willing and financially able to retain after required obligations are addressed. | IT can explain risk. Insurance can transfer defined financial risk. Legal counsel can interpret legal obligations. Leadership still owns the organizational decision. |
Important distinction: Authoritative does not always mean mandatory. NIST guidance, CIS Controls, CISA recommendations, an insurance requirement, a state law, and a contractual requirement may all influence a cybersecurity decision, but they do not have the same legal or contractual effect.
Organizations should not purchase security simply because a vendor sells it. A security control should address a known risk, applicable requirement, operational dependency, recovery objective, or reasonable cybersecurity practice. That also means an organization should be willing to question controls that no longer make sense. Technology changes. Applications move to the cloud. Employees leave. Locations close. New authentication methods reduce older risks. Duplicate products sometimes accumulate. A healthy cybersecurity program should change with the organization.
The useful question is not simply, “Do we need this product?” The better question is, “What risk does this control address, and what happens to that risk if the control goes away?”
“Excessive security” can be a reasonable conclusion, but it needs a comparison point. Without one, it is only an opinion.
A useful recommendation should be able to explain something similar to this:
Example of a risk-based recommendation: “This control currently addresses this specific risk. Your environment has changed in these specific ways. Another control now addresses most of the same risk. Removing the original control saves approximately this amount per year. This is the remaining risk leadership would be accepting.”
That is much more useful than saying an organization has “too much security.” The same standard should apply when someone recommends adding security. The person making the recommendation should be able to explain why it is needed.
Sometimes that is the right decision. Cybersecurity should be proportional to the organization. A one-person operation with little stored information can have a different risk profile from a manufacturer with 100 employees, a medical practice, a municipality, a defense contractor, or an organization holding large amounts of customer data.
| Situation | Questions to answer before reducing protection |
|---|---|
| One owner and no employees | Does that one person still depend on email, banking, cloud applications, customer information, a website, payment systems, or a critical computer? |
| Most applications are in the cloud | What protects the cloud identity, email account, authenticated browser session, administrator access, account recovery process, and endpoint used to access the application? |
| Little or no local data | Could a compromised computer still provide access to cloud applications, stored credentials, email, banking, customer portals, or active sessions? |
| Passwordless authentication, passkeys, or security keys | Are all important users, administrators, recovery methods, and critical applications protected to the same standard? |
| No business email | Are SMS, mobile devices, websites, cloud applications, social-media accounts, payment systems, or vendor portals now the primary attack paths? |
| No Wi-Fi or guest network | What protects the wired network, router, firewall, endpoints, internet-facing services, remote access, and cloud identities? |
| No digital payments | Does the organization still have payroll, banking, invoices, ACH, wire transfers, customer information, employee information, or valuable accounts? |
| Very little identifiable customer data | What information actually exists in email, accounting, payroll, employee records, contact lists, backups, cloud applications, and vendor systems? |
| Strong internal IT ability | Does the organization have the knowledge, time, documentation, monitoring, patching, backup, testing, incident-response ability, and coverage needed to perform the work consistently? |
| Strong vendor-provided security | Exactly where does the vendor’s responsibility begin and end? Does it include endpoints, identities, email, local networks, fraud, backup, account recovery, and business interruption? |
| Independent breach or identity monitoring | Does the service only alert after information appears in a known breach, or does it actively reduce the likelihood and impact of account compromise? |
| Large cash reserves | Has leadership intentionally decided to self-insure some cyber risk, and is the organization financially prepared for investigation, legal, recovery, interruption, fraud, notification, and other possible expenses? |
Any of these circumstances can change the risk calculation. None should be treated as automatic proof that cybersecurity is unnecessary.
Different security controls address different problems. Removing one control because another control exists only makes sense when the two actually address the same risk.
| Control | Primary purpose |
|---|---|
| Multi-factor or phishing-resistant authentication | Reduces the chance that a stolen password alone can be used to access an account. |
| Endpoint protection, EDR, or MDR | Helps prevent, identify, investigate, contain, or respond to malicious activity on managed devices. |
| Email security | Reduces phishing, malicious attachments, impersonation, spam, and other email-borne threats. |
| Patching and update management | Reduces exposure to known software vulnerabilities and unsupported software. |
| Backups | Provides recovery options when information is deleted, corrupted, encrypted, damaged, or otherwise lost. Backup design and recovery testing still matter. |
| Password manager and breach awareness | Supports unique credentials and can help identify exposed credentials. It does not replace MFA or other identity controls. |
| Security awareness training | Helps employees recognize phishing, fraud, social engineering, unsafe behavior, and reporting expectations. |
| Least privilege and separate administrator access | Limits what a compromised user or account can access or change. |
| Firewall and network security | Controls and monitors network communications and can reduce exposure between systems, locations, users, and the internet. |
| Logging and monitoring | Improves visibility into activity and can help detect, investigate, and understand unusual events. |
| Incident-response planning | Defines who does what when something goes wrong so decisions do not have to be invented during an incident. |
| Cyber insurance | Transfers defined portions of financial risk according to the actual insurance policy. It does not prevent the incident itself. |
Every control has a cost. That cost should be visible and questioned. The other side of the decision is the amount of financial and operational risk the organization will retain if the control is changed. That does not mean every possible cybersecurity loss is catastrophic. It means leadership should understand how a realistic incident would be financed and managed.
Risk does not become unacceptable simply because it exists. Some risks can reasonably be accepted. The important part is making that choice before the incident, understanding the consequences, and having the financial and operational ability to live with the decision.
Anyone can raise a useful cost-saving idea. Before relying on the recommendation, understand the person’s relevant experience, what they reviewed, and where their expertise ends. An application vendor may understand its platform without having assessed your email, computers, insurance, or recovery needs. Ask whether the advisor works with cybersecurity assessments, IT operations, incident response, insurance underwriting or claims, compliance, or your specific industry. Relevant training, credentials, and experience with similar organizations can help establish their background. They do not replace evidence about your environment.
An advisor does not need experience in every discipline. They should identify which questions require input from someone else. A qualified insurance professional may address coverage questions while a cybersecurity specialist evaluates technical protection.
Also disclose any financial interest in the outcome. A recommendation may increase or reduce revenue for the current provider, a replacement provider, or an application vendor. That does not automatically invalidate the advice. It makes independent evidence more important. A written response on the advisor’s normal letterhead or through its established process is acceptable when it addresses the same questions. The purpose is a useful decision record, not a paperwork test.
Accountability should work in both directions. If an IT or cybersecurity provider says a control must remain, ask what it protects. Ask what recognized baseline supports it. Ask whether another control could accomplish the same goal for less money. Ask what changes in the environment would allow the control to be reduced later. “Because we require it” is not a complete cybersecurity explanation. A provider should be able to explain its standard and why the standard exists.
EasyITGuys uses the CIS Critical Security Controls as a foundation for standard organizational cybersecurity. Plan 2 is designed around a CIS Implementation Group 1 baseline. Plan 1 is designed around the broader Implementation Group 2 level. Organizations with greater regulatory, contractual, data-sensitivity, or operational risk may require additional controls. Those environments may use higher CIS safeguards together with requirements from frameworks or programs such as NIST, HIPAA, FTC/GLBA, CMMC, ISO 27001, state requirements, federal requirements, and other applicable standards. This is an EasyITGuys service-design standard. It is not a statement that every organization is legally required to purchase an EasyITGuys service. An organization may use another provider, maintain controls internally, or use different technologies, subject to its applicable agreements and obligations.
A framework-based service design is not proof that every applicable safeguard is implemented throughout an organization. Ask for the framework version, applicable safeguards, assigned responsibilities, documented exceptions, and evidence of implementation. Distinguish services the provider performs from responsibilities retained by leadership, employees, application vendors, and other parties. CIS Implementation Groups are not interchangeable with CMMC levels. Using a higher Implementation Group does not automatically establish HIPAA, CMMC, or other regulatory compliance. Each applicable program requires its own scope and requirements review.
Organizations that want to understand the service models can review Business IT Support and Security Membership Plans and Business Membership Pricing.
Do not assume that a general business insurance policy automatically provides the cyber protection the organization expects. Cyber protection may be provided through a dedicated policy, endorsements, supplemental coverage, or other policy structures. Coverage varies substantially.
Before changing an important control, consider asking the organization’s licensed insurance professional or carrier:
The insurance policy and carrier determine coverage. An IT provider cannot promise that an insurance claim will be paid.
Cork Protect activation began for qualifying EasyITGuys Plan 1 clients during 2026. Plan 2 activation is planned for the fourth quarter of 2026. A rollout schedule or plan membership is not proof that a particular organization has active financial protection. Confirm the organization’s current activation status, warranty documents, eligibility requirements, and applicable financial limits before relying on the protection. Cork Protect is a limited cybersecurity warranty and financial protection program. It is not cyber insurance and does not replace an appropriate cyber insurance policy. EasyITGuys does not issue the warranty or decide whether Cork pays a particular claim. Current plan references, financial limits, sublimits, eligibility requirements, exclusions, and client-specific status can change. Review the current Cyber Warranty Financial Protection and Cork Protect Guide and the organization’s current Cork documentation before relying on any amount or coverage.
An organization can manage cybersecurity risk in several ways. It can reduce risk through safeguards. It can avoid an activity that creates risk. It can knowingly retain some risk. It can also transfer or share portions of financial risk through insurance, warranties, contracts, or other arrangements.
| Risk response | Example |
|---|---|
| Reduce | Use security controls to lower the likelihood or impact of an incident. |
| Accept | Leadership knowingly retains the risk and has sufficient financial and operational capacity to absorb it. |
| Transfer or share | Use insurance, warranties, or contractual arrangements to allocate defined portions of financial risk. |
| Avoid | Stop the activity creating the risk, such as no longer storing a particular type of sensitive information. |
Transferring financial risk does not make the technical risk disappear. Insurance may help pay defined expenses after an incident. It does not stop an employee from being unable to work, restore a damaged reputation automatically, or prevent a compromised account from being used.
When a recommendation could materially change organizational risk, documenting it is healthy. The purpose is not to trap the person providing advice. The purpose is to make the assumptions, reasoning, responsibilities, and final decision visible. A written recommendation should identify what is being changed, why the change is recommended, what information was reviewed, what baseline was used, what risk remains, and what role the advisor expects to have if an incident occurs. An advisor who declines to assume financial liability is not automatically wrong. Professional advisors normally provide recommendations without becoming the organization’s insurer. It is still reasonable to ask them to document the recommendation and the basis behind it.
A signature is not automatically a transfer of liability. Signing a recommendation documents what someone advised. It does not automatically make that person or company responsible for future losses. If the parties want actual indemnification, reimbursement, guarantees, or other financial risk sharing, that should be established in a separate written agreement reviewed by appropriate legal and insurance professionals.
Organization: [Organization name]
Date / reference: [Date and optional reference]
Advisor / company: [Name, role, legal entity, and email or phone]
Proposed change: Name the control or service and affected systems, users, or data. [Enter response]
Basis for the recommendation: Briefly identify relevant experience, information reviewed, supporting standard or evidence, and important limits or assumptions. [Enter response]
Cost impact: Estimated net monthly savings and one-time costs. Include replacement costs and labor. [Enter response]
Protection after the change: State what replaces the protection, who maintains it, and the remaining risks or downtime exposure. [Enter response]
Requirements review: Identify insurance, warranty, legal, or contractual effects. Name the reviewer or state what remains unchecked. [Enter response]
Response plan: Who will assist, with what tasks, availability, and charges? Identify the contact and agreement. Mark proposed services as proposed. [Enter response]
Who pays? Identify existing coverage or cost sharing, the responsible entity, limits, and document reference. State who funds remaining costs, or what is unresolved. [Enter response]
Additional financial risk sharing: ☐ Not proposed ☐ Open to a separate agreement
This selection does not create new coverage or a payment commitment.
Advisor confirmation: This records my recommendation based on the information and limits stated above. It is not a guarantee of an incident-free outcome.
Advisor signature / date: [Signature and date]
☐ Proceed as described ☐ Proceed with conditions ☐ Keep current controls ☐ Further review
Conditions / implementation: Record conditions, the change owner, validation required before removal, target date, and next review date. [Enter response]
For an approved change, I acknowledge the stated remaining risks, response plan, and funding arrangements.
Authorized decision maker / signature / date: [Name, role, signature, and date]
Purpose and limits: This record does not itself authorize technical changes, amend agreements, release existing duties, create insurance, a warranty, or a payment obligation, or determine the cause of a future incident. Follow applicable requirements and the normal change-approval process. Document new service or financial commitments separately with authorized parties. Obtain legal and insurance review as appropriate. Do not include credentials.
Download the Word form above, add your organization’s details, and attach it to the email. Replace the bracketed details before sending. The recipient can return the completed form or provide a written response covering the same points.
Subject: Please document the proposed cybersecurity changes
Hi [Name],
Thank you for helping us review our costs. We are open to changes that make sense for our organization. Before we decide, please complete the attached Cybersecurity Recommendation & Decision Record with your recommended changes, supporting reasons, expected savings, and remaining risks. Your usual written recommendation is also welcome if it covers the same information. Please explain what assistance you would provide if an incident occurred and who would cover the costs. Clearly distinguish commitments under existing agreements from any proposed services or financial risk sharing. We will review the recommendation and applicable requirements before approving changes.
For background, here is the guide we are using: How Much Cybersecurity Is Enough?
Thank you,
[Name]
[Organization]
Example: Removing a $100 monthly service creates $1,200 in annual invoice savings. If replacement tools cost $25 per month and implementation costs $300, first-year savings are $600 before staff time or other costs. This is an arithmetic example, not an estimate of incident likelihood or loss. A provider change and a reduction in security are different decisions. An organization may change providers while preserving or improving its controls. It may also reduce unnecessary products without reducing the protection it needs.
These videos provide additional cybersecurity education. Use the reference section to review the supporting sources and current guidance before applying recommendations to your organization.
For a general starting point, review the NIST, CIS, FTC, and CISA resources. Use insurance, industry, federal-contracting, and state resources when they apply to your organization. You do not need to read every reference to begin a useful discussion. These sources serve different purposes. A technical framework, educational tutorial, commercial service description, advocacy statement, and legislative announcement are not interchangeable. Inclusion here does not mean the publisher endorses EasyITGuys, a particular product, or a specific recommendation. Some resources are historical or describe a specific program. Check publication dates, framework versions, applicability, and current governing requirements before using them to justify a change. External links open in a new tab or window.
Review defense-sector guidance in the context of the organization’s work, information, and applicable contract requirements. Do not assume every defense-contract requirement applies to every small organization.
This resource provides federal and acquisition context. It is not a universal cybersecurity checklist for organizations that do not have the relevant federal obligations.
These resources are provided as examples of how major insurance carriers discuss cyber risk and cyber insurance. They are not substitutes for the organization’s actual insurance policy or advice from its licensed insurance professional.
These are examples of requirements that may apply when an organization operates within a particular regulated or contractual environment. Applicability should be confirmed for the specific organization.
NSBA is a private small-business advocacy organization, not the U.S. Small Business Administration. This page presents advocacy positions. It is not a government cybersecurity standard or an insurance coverage document.
These resources document legislative proposals and reporting at the time of publication. A proposal, press release, or news article is not proof of a currently applicable legal requirement. Verify current legislative status, enacted text, applicability, and effective dates before relying on legislation.
Secondary commentary can be useful for perspective. It should not replace current authoritative standards, governing requirements, insurance documents, or organization-specific risk analysis.
This guide is educational. It does not determine an organization’s legal obligations, insurance coverage, cybersecurity requirements, contractual responsibilities, or acceptable level of risk. Applicable laws, regulations, contracts, customer requirements, insurance policies and applications, governing agreements, documented technology configuration, approved organizational risk decisions, and current authoritative standards remain the source of truth where applicable. For EasyITGuys clients, the applicable MSA or Terms, Service Guide, accepted Quote or Order, documented configuration, and current client-specific Cork documents also remain controlling where applicable. A signed recommendation record documents advice and a decision process. It does not by itself create indemnification, insurance coverage, reimbursement obligations, guarantees, or a transfer of legal liability.
No. Cost is a legitimate part of risk management. Organizations should regularly identify unused services, duplicate controls, obsolete technology, unnecessary accounts, and protections that no longer address a meaningful risk. The important part is understanding what changes when the cost is removed.
No. Risk varies based on users, data, applications, industry, contracts, locations, technology, regulatory obligations, insurance requirements, operational dependence, and the organization’s ability to absorb a loss.
No. CIS Controls are a recognized cybersecurity framework and prioritization model. CIS describes IG1 as essential cyber hygiene, but CIS itself does not make IG1 a universal law. A particular safeguard may still become important through a contract, insurer, regulatory requirement, customer requirement, or organizational standard.
CIS provides a structured way to prioritize safeguards according to organizational risk and complexity. EasyITGuys uses IG1 as the Plan 2 design baseline and IG2 as the Plan 1 design baseline. That is an EasyITGuys service standard. It does not mean every organization is legally required to purchase those services or use the same technologies.
Yes. The important question is what the new environment includes, what it removes, which risks remain, whether applicable requirements are still satisfied, and who is responsible for each function. The provider name matters less than the resulting risk and accountability.
Possibly. Cloud applications can remove substantial local infrastructure, but the computer may still provide access to authenticated sessions, email, credentials, banking, customer information, administrator portals, and other cloud services. The risk often moves rather than disappears.
Strong passwordless authentication can materially reduce some credential-related risks. It does not automatically address malware, unpatched software, data loss, unauthorized administrator access, backup, network risk, employee fraud, monitoring, or incident response.
That can reduce one common attack surface. The organization should still evaluate websites, mobile devices, SMS, cloud applications, banking, vendor portals, social-media accounts, remote access, and other digital systems it depends on.
That can materially reduce exposure. Confirm what actually exists before making the decision. Email, employee information, payroll, accounting, customer contact information, credentials, cloud applications, backups, and payment records can still contain sensitive or operationally important information.
That is valuable, but determine the boundary of the vendor’s responsibility. A cloud application provider may secure its platform while the organization remains responsible for user identities, endpoints, administrator access, email, local networks, account recovery, and other systems.
No. Breach monitoring can identify information that has appeared in known breach data. It does not prevent a new phishing attack, malicious login, stolen session, weak recovery method, or future credential theft.
Not simply because another month has passed. NIST SP 800-63B-4 says authentication systems should not require periodic password changes, but should require a change when there is evidence of compromise. The publication is linked in the NIST references above. Use unique credentials and appropriate authentication protection. Follow applicable requirements and review conflicting policies with the responsible technical or compliance advisor. Routine password changes do not replace MFA, secure recovery methods, or protection of the device used to sign in.
Not automatically. Insurance transfers defined portions of financial risk according to the actual policy. It does not prevent an incident. Security changes can also affect underwriting, renewal, policy conditions, or other insurance considerations. Review material changes with the organization’s licensed insurance professional.
No. Cyber warranty financial protection and cyber insurance are different. A warranty may complement insurance when its requirements are satisfied, but it does not replace an appropriate cyber insurance policy.
No. Some advisors may have policies that prevent them from signing client-created documents or accepting financial responsibility. Ask whether they will provide their technical recommendation and reasoning through their normal written process instead.
Not automatically. The signature documents the recommendation. Actual indemnification, reimbursement, guarantees, or financial risk sharing should be established through a separate enforceable agreement reviewed by appropriate legal and insurance professionals.
The question helps separate technical advice from financial risk transfer. Someone can reasonably recommend that a risk is acceptable while also stating that the organization will retain the financial consequences. That distinction should be understood before leadership makes the decision.
Yes. EasyITGuys should be able to explain why a control exists, what risk it addresses, what baseline supports it, what alternatives may exist, and what changes if the control is removed. Accountability should not depend on which direction the recommendation goes.
Yes. Leadership can make an informed decision to retain risk after applicable obligations are addressed. The organization should understand the expected savings, remaining exposure, insurance implications, recovery plan, financial capacity, and decision owner. The decision should also be reviewed when circumstances change.
Organizational leadership makes the organizational risk decision. IT providers, cybersecurity professionals, insurers, attorneys, auditors, regulators, vendors, and other advisors can provide important information. They do not normally replace leadership’s responsibility to decide how much residual risk the organization is prepared to retain.
The applicable governing source controls. That may include law, regulation, contract, insurance policy, customer requirement, accepted agreement, documented configuration, or current authoritative program requirement. This guide is intended to help organizations ask better questions and make better-informed decisions. It does not replace those sources.
