A vulnerability management policy is a key component of an Information Security Management System (ISMS). This is especially true for SaaS companies selling cloud products. Before buying such products, customers will seek proof that product security vulnerabilities are consistently managed.

While a vulnerability management policy, on its own, cannot offer bullet proof guarantees, it is still considered a must-have. Any customer needing assurance that proper vulnerability management practices are being followed by suppliers will expect one.

Want to quickly crate a vulnerability management policy using chatbots? Then buy our awesome chatbot vulnerability management policy creation cheatsheet to get building fast!

Policy fundamentals

A good SaaS vulnerability management policy rests on a couple of key fundamentals: scope, depth of content and structure.

Scope

As discussed in our SaaS ISMS quickstart, the ISO 27001 standard grants a certain degree of freedom in defining the scope of a company’s certification. The standard grants the freedom to specify which areas of the business are covered by ISMS controls, and which are not. SaaS companies looking to obtain certification can leverage this flexibility to define a minimal scope that is efficient to implement.

For SaaS companies, such scope should cover solely the management of information security within the development, maintenance and operation of the SaaS products themselves; not the whole company. This sustainably reduces the amount of policies, tools and processes needed for a minimal ISMS implementation, without compromising the ability to obtain the certification.

The same concept can be applied to the scope of a SaaS vulnerability management policy. The policy’s scope should only cover the detection and remediation of vulnerabilities affecting a) the software inside your SaaS product and b) any infrastructure hosting your product. Anything else (such as vulnerabilities affecting laptops) can be excluded.

Depth of content

The policy should provide a high-level overview of your organization’s vulnerability management process. Specific technical details about how vulnerability management is implemented should be left out. These details will need to be documented through separate operational guidance and standards.

However, while technical depth is not required, you’ll still need to explain the overall approach behind your vulnerability management process. In the context of SaaS products, which rely on multiple software and infrastructure layers, this is easier said than done.

Fortunately, AI chatbots such as Google Gemini or ChatGPT can help us with writing such a policy. However, remember that these chatbots should be mostly used to accelerate the writing process. Avoid relying on them to write your entire vulnerability management policy. Chatbots must be used correctly and with an understanding of their general limitations when it comes to generating ISO 27001 policies.

Structure

While AI chatbots will accelerate your writing, you should define a structure to build a strong policy document. Without an adequate structure, your policy won’t successfully define a vulnerability management approach intuitive to employees, customers and auditors. A minimal vulnerability management structure should always contain the following sections:

• Section one: policy scope and objectives
• Section two: vulnerability management approach
• Section three: vulnerability management implementation requirements
• Section four: vulnerability management remediation requirements

This structure will help you build a simple, yet effective, vulnerability management policy. While light on the details, it will effectively outline the general principles driving product vulnerability management. Moreover, it’ll give engineers sufficient implementation guidance without being too prescriptive.

Writing the policy

Use AI chatbot queries that are prescriptive. If you give chatbots too much freedom they will invent a policy entirely from scratch. The resulting text will be too vague and won’t be sufficiently precise for the SaaS-specific nature of our policy.

More importantly, the text may contain errors or omissions which may be difficult to spot. If given complete freedom, chatbots will rapidly generate a long policy with standardised, yet irrelevant, content as seen below:

Auditors will struggle to accept a policy that is too vague. Tailoring ISMS policies to the context of your organisation is fundamental to ensure auditors do not flood your team with feedback or, worse, identify non-conformities that put your ISO certification at risk.

More importantly, prescriptive queries allow you to work around chatbot constraints, such as the processing limitations contained within ChatGPT’s free plan. Simple queries will be interpreted easily by all basic AI models to generate accurate content.

Note that, compared to ChatGPT, Google Gemini does not impose any constraints on AI models; for the moment at least. Regardless of the tool used, prescriptive queries will be better processed by free AI models, reducing the risk of poor content being produced.

Finally, when writing the policy, you must be careful not to introduce sensitive information within the chatbot prompting window. The vulnerability management approach outlined within the policy will be too high-level for attackers to exploit. However, details regarding resolution timelines and vulnerability management tools should be manually added outside of a chatbot program.

To write the policy skeleton, start by prompting chatbots as follows:

Create an empty ISO27001 vulnerability management policy that contains the following sections:
- scope and objectives
- vulnerability management approach
- vulnerability management implementation requirements
- vulnerability management remediation requirements
Keep each section empty.

Notice how prescriptive the prompt is. It leaves the chatbot limited room for interpretation and reduces the amount of text it can invent. When writing ISMS policies using AI, you want chatbots to produce the minimum necessary amount of text. You’ll then progressively add more content and details with later queries.

After creating the skeleton for your policy, you should then add a table to capture vital document metadata such as document owner, the policy’s information classification level, the approval status as well as last review and approval dates.

Policy scope and objectives

In this section, you’ll describe the boundaries of your vulnerability management activities. For SaaS companies, it is important to describe how vulnerability management activities apply solely to the product. You should do this across three subsections:

• Scope: this section defines the boundaries of the policy, specifying how SaaS applications are covered. The scope should also explain how the activity is aligned with the organization’s security objectives
• Objectives: this section outlines the specific goals the organization aims to achieve through the policy. The objectives should provide a clear purpose, giving a high-level direction regarding its implementation
• Area of application: this section outlines to whom the policy applies and delineates the overall responsibility for vulnerability management

Again, chatbots can be used to write each section. For every prompt, make sure to explicitly outline what you want the chatbot to write and to avoid inventing any text. The output will be much cleaner, crisp and concise, as seen in the example prompt below:

Add section 1.1, titled Scope. Add text explaining that the scope of the vulnerability management policy applies solely to company SaaS products. Specify that all in-house developed software, third-party software dependencies and hosting infrastructure integrated within company SaaS products are covered by the scope of the policy. Follow these instructions prescriptively and do not invent any additional text.

The above query is just an example of the many you’ll need to write to complete your policy. However, the query structure can be reused and adapted to all other policy sections.

Vulnerability management approach

The approach section is the heart of your vulnerability management policy. Here, you describe the company’s SaaS-focused approach in concrete terms. To do that effectively, you can follow a few simple steps:

1. Start by explaining the principles governing your SaaS-focused approach. You can be creative here but try to keep things high-level. At a minimum, your approach should mandate shift-left strategies (such as static application security testing embedded within CI/CD release pipelines) to minimise vulnerabilities in production. Then, it should describe how vulnerability scanning activities cover SaaS assets deployed to production. Conclude with a high-level description of the standard environments to be covered and a high-level description of how vulnerabilities should be detected, reported and remediated according to specific resolution timelines
2. Next, you’ll need to help employees understand how the policy should be applied. Describe your SaaS products using a “logical” structure. At a minimum, each SaaS product should be described as a system composed of several layers. For example, you could describe your products as being composed of an egress/ingress layer, a software layer, a containerization layer and an infrastructure layer. By doing so, the policy will provide readers with a standardised description and understanding that is transposable across each SaaS product
3. Finally, describe the high-level implementation requirements expected to be defined for each layer. At a minimum, make sure to describe how each layer should be scanned by a dedicated tool, with a defined scan frequency while targeting a specific set of expected environments

You could condense all of the above information into a high-level diagram. Strictly speaking, this is not necessary in a high-level policy. However, it will further help readers understand the overall vulnerability management approach, as seen below:

Implementation requirements

In this section, you define the implementation requirements for each vulnerability management layer. The goal here is not to define detailed operational requirements. Rather, the idea is to provide your team with high-level implementation guidance.

Building on the previous section, each layer in your vulnerability management “logical” diagram should consistently describe the implementation requirements.

For each layer, you should explain what is covered within the layer’s scope. Then, you should provide a table that describes the vulnerability management tool used to scan the layer in question. Finally, the table should describe the scan frequency and environments in scope.

For example, say you have structured your SaaS product in line with the diagram included in the previous section. You can see that your company’s SaaS product is “logically” described as a grouping of technologies stacked over four layers. Each layer is protected by a dedicated vulnerability management solution reporting data to a centralised security analytics dashboard.

To describe, say, the infrastructure layer you should start with an introduction that explains a) what that layer is, and b) how it is to be protected from a vulnerability management perspective. Then, after the introduction, you can add a table to describe the high-level implementation requirements, as shown below:

Requirement	Description
Tool	Tenable Web Application Scanner
Scan frequency	Every Wednesday at 5:30 AM CET
Environments scanned	Production, Failover
Additional requirements	Scan results should be reported to the security team via email

By applying the above structure across all layers of your SaaS product you will provide your team with all the requirements. All of this without including an excessive amount of detail within your policy.

Remediation requirements

This is the simplest section to write, yet the hardest to agree on. Include a high-level statement indicating that vulnerabilities must be remediated according to specified timelines. Then, you should indicate these within a simple table, listing the remediation timelines for each vulnerability severity level. Note that these should be quantified in days. You should also specify whether weekends are included in the overall count.

The hard part is agreeing on common remediation timelines across security and product/engineering teams. Before writing this section you should make sure to have the necessary buy-in from engineering teams. Let these teams define the timelines. They’ll appreciate the flexibility and be more willing to accommodate security requirements.

Avoid imposing such metrics unilaterally without consulting stakeholders. Once your policy is implemented, track remediation performance by measuring average resolution times, broken down by the severity of findings. Then, meet periodically with engineering managers to decide whether the remediation timelines should be tightened or relaxed.

Final steps

Once the policy has been written, store it in your ISMS policy management or documentation repository. With a simple prompt, chatbots can convert your policy into any required documentation format, as seen below:

The resulting policy will be compact but precise. It will be tailored to the context of your SaaS company and will be acceptable to auditors. Once added to your ISMS, you should identify any additional guidance needed to provide your teams with all the implementation details (i.e. implementation architecture, operational guides etc.). Avoid storing these additional documents within the ISMS. Instead, store them within your security wiki.

Finally, as you define the low-level implementation requirements, encourage your team to adopt a GRC engineering approach. If you can, identify opportunities to automate the inspection of vulnerability management controls across each layer of your SaaS products. Then, address these automation opportunities in the early implementation stages. This will help your team save precious calories and manual work in the future.