Build A Cybersecurity Risk Assessment Process Funnel 

Can you truly perform a risk assessment without first defining what “secure” looks like?

In today’s digital landscape, where cyber threats are evolving faster than ever, security standards provide the foundation every cybersecurity risk assessment needs. Without them, assessments lack focus — and risk decisions lack clarity.

The average cost of a data breach reached $4.9 million in 2023 and continues to rise annually, having security standards is no longer optional — it’s a critical foundation for any effective risk management strategy. At the same time, businesses are increasingly relying on digital operations and artificial intelligence (AI) to drive growth and innovation. Yet, despite this shift, only 24% of generative AI initiatives are currently secured— exposing a significant and often overlooked vulnerability.

Security Standard

To better understand the importance of having a security standard in place, let’s start with a relatable analogy.

Imagine you’re dating. At first, you may not have a clear idea of what you’re looking for. But over time, through various experiences, you begin to recognize patterns — deal-breakers, green flags, and non-negotiables. Eventually, you establish a personal standard for relationships.

Security standards operate in much the same way. They are built over time through experience, guided by industry best practices, business priorities, and accumulated insights. Initially, your team might not have documented standards specific to a given platform, but as assessments are conducted, patterns and expectations start to emerge. These learnings gradually form the foundation for security standards that can be applied consistently across the organization.

And just like in dating, establishing clear expectations from the start can prevent a lot of problems down the road.

Why Security Standards Matter in Risk Assessments

Security standards act as a baseline. They set the “minimum viable security posture” for systems and services under review. More importantly, they give your cybersecurity team — and your business — a framework to evaluate risks, guide implementation decisions, and align with broader governance goals.

While not every organization starts with these standards in place, maturing your cybersecurity governance, risk, and compliance (GRC) approach depends on them. Over time, these standards create repeatable, efficient frameworks for evaluating threats, defining mitigation techniques, and enabling faster decision-making in risk assessments.

Let’s explore the three primary sources that shape security standards — and how to leverage them to accelerate your cybersecurity risk assessment process.

Components Influencing Security Standards

1. Industry best practice – Published guidance on recommended controls.
2. Company culture – The level of security standards already set within the company. These include privileged access management (using separate service accounts), single-sign-on solutions (like Okta), and even network zones for external access, and the use of production data on development systems. MFA on all external authenticated. These standards that have been set as the ‘standard’ can be inherited to these new system standards.
3. Specific risk mitigation standards.

Let’s walk through each of these components to building a security standard. Based on this systematic approach you’ll be able to quickly create brief and straightforward security standards for the technology you’re assessing. These standards will be used as the core of your agreement with the business and serve as a critical component to show the risk visibility as a result.

1. Industry Best Practice

As a cybersecurity expert, your time is valuable. Leveraging a documented, already created, security standard saves you a lot of time. Resources like the Center for Internet Security (CIS) Benchmarks, NIST 800-53, and ISO/IEC 27001 offer well-established control sets for various technologies. It also can save you a lot of time on the back end by reducing the time spent answering people’s questions. Questions like, ‘Where did this setting come from’, ‘why do we need that turned on’? By reflecting your response to an industry-standard you’ll save you time defending the standard. All the while, giving you the freedom to adjust the standard to your specific business.

Some great security standards for operating systems have existed for years. CIS provides an extensive list of security standards already available, and often in different levels of risk.

As we go up the OSI stack, these published standards become less and less available. In today’s world of SaaS applications, you’ll find it harder to find published standards.

2. Company Culture Standards

There are security standards that have already been set within your company. This is the time to review them and inherit them for this new system.

These standards often include:

• If production data can be used in the development
• If the vendor-hosted system has an SSEA16 or SOC2 attestation
• If the Multi-Factor Authentication (MFA) is required on external systems
• The certificate authority requirements, or SSL protocol standards
• Single-Sign-On solution integration requirements.

What we do at Asher Security: for organizations that perform enough assessments to benefit, is to create blanket security standards for service platforms. For example, take all your requirements that you’ll always have for SaaS applications and create a ‘SaaS application security standard’.

Create another one for ‘Vendor Hosted Application Standards’.

These standards serve as a bar, the minimum expectations for systems introduced to your company.

They can also serve as speed bumps. They buy you more time. They are documents you can give to the business unit asking you to perform a security assessment, and ask them to review the published standard for this technology.

These documents serve as baselines — or speed bumps — that communicate expectations upfront to business units. While not meant to create resistance, they can be used as part of a collaborative advisory approach, helping teams align faster and focus on what matters most.

3. Specific Standards

Even though you have a great set of industry standards that may or may not cover this technology you’re accessing, and you have company culture standards, there will most likely still be security configuration settings specific to the solution you’re reviewing.

Take Salesforce, for instance. While it’s known for strong security, a default implementation still poses significant risks. Through risk assessment, a vCISO or cybersecurity consultant should identify which configurations fall under User Control Considerations (UCCs) — the security settings users are responsible for managing.

For platforms like Salesforce, Microsoft 365, or custom cloud environments, reviewing these UCCs can highlight misconfigured roles, data exposure points, or audit log gaps. By documenting expectations around these settings, you formalize them into a security standard specific to the platform — closing gaps and enabling more accurate data breach protection planning.

Here’s a great learning module from Salesforce that helps educate on the security control settings: Salesforce Basic Features

Scope

One mistake in developing security standards is trying to boil the ocean. Most risk assessments today focus on SaaS platforms or cloud-hosted apps, not the full infrastructure stack.

So don’t attempt to define security standards for the entire OS layer if it’s managed by the vendor. Focus instead on the scope of the platform or system you’re evaluating. Identify which settings fall under your control and which are vendor-managed.

Lean, clear documentation is more effective than lengthy, unreadable policies.

Remember: less is more. Your standard should be precise, actionable, and easy to align with the business’s goals.

(side note: We’ve always advocated for a super short infosec policy that just says, “Don’t be stupid” No client has allowed me to that yet.)

Summary

These steps should help you develop a security standard for the technology or platform you’re reviewing. The standard can be used in the cybersecurity risk assessment process by supporting the business initiative as long as the system is implemented and configurated according to our security standard.

Having a security standard also helps the advisory process with the business by explaining where the concerns are;

• Are they external concerns about the vendor responsibility?
• Are the internal concerns about how it’s implemented?

Creating a standard for platform levels can save you time by covering the majority of security expectations across several systems.

 

As the cybersecurity landscape evolves, so must our approach to defining and managing risk. Creating documented, repeatable security standards ensures your risk management plan isn’t reactive — it’s strategic.

Whether you’re building a standard for a newly onboarded SaaS app or refining your risk assessment maturity across the organization, starting with best practices, culture, and specific configurations provides a strong foundation.

Security standards aren’t just about checkboxes. They’re the blueprint for how your organization defines acceptable risk and builds cyber resilience at scale.

 

Previous Article: