Policies

Policy Editor [BETA]

Policies

Introduction

This page offers a Policy Generator feature, enabling you to create CRA-compliant policies. You can write policies and ensure they support the necessary requirements of specific standards. Once completed, you can download them as .docx documents and use them within your organization.

Z-CMS v2.13.0 proposes a vulnerability handling policy template that satisfies the requirements of prEN 40000-1-3 (in its draft phase). Using our template enables you to immediately set up your vulnerability handling processes and prepare effectively for the vulnerability handling requirements of the CRA (Annex I Part II). Keep in mind that these requirements must be met by 11 December 2027.

Before starting using this feature, we highly recommend reading our article on prEN 40000-1-3 . Moreover, it is important to realize that fulfilling vulnerability handling requirements requires cross-department alignment and cooperation. There are various stakeholders, including product security team, development team, customer support and legal, who must be involved in the processes related to vulnerability handling. The successful implementation of the vulnerability handling policy is tightly linked to how effectively these stakeholders collaborate.

Disclaimer

The vulnerability handling policy template and related features in Z-CMS will evolve as prEN 40000-1-3 is finalized; you should expect periodic updates. While the generator is designed to help you create a policy aligned with the draft standard, Zealience does not accept liability for your organization's compliance with the Cyber Resilience Act. It remains your responsibility to ensure that policies, procedures and product practices meet applicable legal and regulatory requirements.

Policies produced with the Z‑CMS generator are intended for internal use. Do not disclose them to third parties without appropriate authorization.

Overview of the Policy Generator feature

The Policy Generator feature comprises three pages where you will work:

Policies: Main page where all the work related to the policy will be done
Stakeholders: Supportive page where you can create Stakeholders
Standards: Supportive page where you can create Standards

The relationship between the three pages can be summarized as depicted in the figure below. You will create a number of Stakeholders that are responsible for performing certain activities detailed in the Policy. After linking the Stakeholders to the Policy, you will assign them to their respective tasks. For example, the Policy below has an activity called Activity A for which Stakeholder is responsible for.

You can create a Standard containing a number of requirements, which can also be linked to a Policy. You can then declare in the Policy which Activity supports a given requirement of the Standard. For example, Activity A supports the requirement #1 of the Standard. This means that when the Stakeholder1 performs Activity A, the organization satisfies the requirement #1 of the Standard. Complying with the Standard requires that all Stakeholders perform their respective activities in such way that all requirements are satisfied.

Finally, the Policy Generator can generate a .docx file of the policy. The policy can then be implemented across the organization.

The relationship among stakeholders, standard, and policy

Overview of Zealience’s vulnerability handling policy template

To prevent you from creating a vulnerability handling policy from scratch, we created a template which satisfies the relevant requirements of prEN 40000-1-3 with regards to vulnerability handling. The requirements addressing other aspects such as coordinated vulnerability disclosure or software/hardware components identification must be addressed separately.

Our policy template is organized around the five phases described in prEN 40000-1-3:

Receipt: The stakeholders involved in this phase monitor various sources and receive internal and external vulnerability reports. The receipt of a report marks the beginning of the vulnerability handling process.
Verification: After the reception of a report, the stakeholders involved in this phase investigate the vulnerability in order to assess its validity, applicability, and severity.
Remediation: Once a vulnerability has been verified, the stakeholders involved in this phase will first plan the appropriate mitigation, before developing and testing it.
Release: When a remediation is ready, the stakeholders involved in this phase distribute it through the adequate channels and publish advisories.
Post-Release: Finally, the stakeholders involved in this phase track certain metrics to quantify the effectiveness of the remediation and apply lessons learned within the organization to improve the vulnerability handling process.

Where applicable, each phase has specific objectives, mechanisms, principles, activities and success criteria, that ensure systematic and effective processing of all vulnerability reports.

Objectives: Briefly explain what activities must be done during a given phase.
Mechanisms: Technical solutions that must be in place to support the activities of a given phase.
Principles: Requirements that must be followed and that are not bound to a specific/single activity, but rather apply to all in a given phase.
Activities: The activities that must be performed during a given phase to meet the objectives.
Success criteria: Criteria linked to a specific activity. Can be used to measure the efficiency of this vulnerability handling policy.

The policy template is almost ready out of the box. There are only a few actions required to be performed:

Declare the relevant stakeholders that are involved in the vulnerability handling processes
Assign activities in the policy to their respective stakeholders
Define target timelines for the activities
Provide a link to the upstream stakeholders to support the component identification

We describe below how to create your CRA-compliant vulnerability handling policy. Once it is created, make sure to review it entirely and adjust it as necessary.

Create your CRA-Compliant Vulnerability Handling Policy using Zealience template

We explain below the steps required to complete your CRA-compliant vulnerability handling policy. We recommend reviewing all the steps before creating your first policy.

Step 1: Go to the Stakeholders page (under Policies) to create stakeholders

In the context of the vulnerability handling policy, the stakeholders are the entities (groups or individuals) involved in the processes related to vulnerability handling. Examples of stakeholders include the Chief Information Security Officer (CISO) and Product Security Incident Response Team (PSIRT). The stakeholders will be assigned to activities in the policy. This way, the policy will clearly define who is responsible for what.

In this step, you will create the relevant stakeholders. We also provide templates for the creation of stakeholders to help you get started. Additional information is provided in the guidance panel in Stakeholders.

You do not need to create all stakeholders at once. New stakeholders can be added later at any time. Policies can be created without stakeholders. It may be beneficial to first get familiar with the content of the vulnerability handling policy (see Step 2) and then create the necessary stakeholders.

Step 2: Go to the Policies page (under Policies) to create a policy

Once you have declared the relevant stakeholders involved in the vulnerability handling processes, navigate back to this Policies page and create a policy by clicking on the “Add” button. You will be asked for the following information:

Policy Name: Your chosen name, e.g., “Vulnerability Handling Policy”
Stakeholders: Select the stakeholders previously declared in Step 1.
Standards & Requirements: Select the standard “prEN 40000-1-3 (v1)”
Template: Select the template “Vulnerability Handling Policy (v1)”
Internal Notes: Optional - provide any notes about this policy

Click on Submit. You should now see the policy in the table. Click on its name to access the Policy Editor.

Step 3: Review the policy and adjust the necessary information

The Policy Editor looks like the screenshot below. As explained previously, the policy is made of sections (e.g., “Organizational Framework”) and sub-sections (e.g., “Leadership and Commitment”). You can use the table of contents on the left to navigate through them.

Zealience template of the vulnerability handling policy in the Policy Editor

In the top right, you can see the compliance results by hovering over the percentage displayed. By default, the policy we provide satisfies all the requirements expected by prEN 40000-1-3. For additional explanations about these requirements, refer to the guidance panel in the Standards page (under Policies).

You can edit the policy to fit your organization’s needs and specificities. To do so, click on any subsections to switch from Preview mode to Edit mode. Click anywhere out of the subsection to go back to Preview mode. The Save button will appear as soon as you switch to Edit mode. If you do not want to save, simply navigate away from the page or refresh it.

In this step, you need to go through the subsections entitled Mechanisms and Activities and set the Owner to the respective stakeholder responsible for the given mechanism or activity. See an example of activity below. Clicking on the dropdown in the column Owner will propose you the stakeholders that you previously linked to this policy in Step 2.

Example of activities that can be declared in a section of the policy. Each activity must have a timeline and an owner

For Activities, you need to also define the target timeline (i.e., the maximum time frame allowed to perform the activity). Our template already sets the timeline of certain activities to predefined values, such as “Ongoing” for activities that must be done continuously. prEN 40000-1-3 does not specify timeframes, so you can set them as needed for your organization.

The template includes default values for Target Remediation Timelines (e.g., Critical vulnerabilities must be remediated within 7 days). Adjust the target timeline as needed.

Step 4: Add sections and subsections (Optional)

There may be cases where you want to add specific subsections. To do so, click on the Add subsection button at the bottom of a section and select the block you want to add. The subsections proposed are organized by the sections of our template. You can add a subsection from any section or choose a generic subsection.

In any section, click on the + icon to add a subsection. Select the type of subsection you want for the palette

Note that a section can only have one Activities subsection and one Success Criteria subsection. When you add a new activity in an Activities subsection (i.e., add new rows to the table), you can also add a success criterion in the respective Success Criteria subsection.

Step 5: Download the policy in .docx

Once you are satisfied with the policy, you can generate it by clicking the Download button. Z-CMS will create a .docx file that you can use within your organization.

Fine tuning the requirements of prEN 40000-1-3

Z-CMS v2.13.0 contains by default the list of some of the requirements of the standard prEN 40000-1-3. However, it only contains the requirements that are relevant for the vulnerability handling policy and those that apply to all manufacturers. For instance, requirement [RCP-2-RQ-01] (vulnerability information or reports from internal and external sources must be monitored) is included, while the requirements for the coordinated vulnerability disclosure policy like [PRE-2-RQ-01] and the requirement enhancements are omitted. See the guidance panel in the Standards page for details.

There are two cases in which you may want to fine tune the list of the requirements:

Add the missing requirements to fit your organization’s need
Adjust the list of requirements based on new updates of prEN 40000-1-3

1. Add the missing requirements to fit your organization’s need

prEN 40000-1-3 contains requirement enhancements (RE) for which manufacturers must decide through a risk assessment whether they must be satisfied. An example of such RE is [PRE-5-RQ-01-RE] which states that the manufacturer must provide secure communication mechanisms for the reception and communication of vulnerability information. In case you identify that you must satisfy some of these RE, you can add them to the list of the requirements in Z-CMS. To do so, perform the following steps:

Step 1: Go to the Standards page (under Policies) and edit the standard “prEN 40000-1-3 (v1)”
Step 2: Add the necessary requirements and submit. For example, we add [PRE-5-RQ-01-RE].
Step 3: Go back to the Policies page and access the policy editor.
Step 4: Add a subsection (or edit an existing one) and write the necessary text so that it addresses the newly added requirements. For example, our template contains by default a principle which addresses [PRE-5-RC-01] as shown below (see section Vulnerability Handling Process, subsection Principles of Vulnerability Handling).

Example of a principle which supports the requirement [PRE-5-RC-01]. This means that when an organization follows this principle, it satisfies this requirement

We edit the text by changing “should” to “must” and add the requirement [PRE-5-RQ-01-RE] to indicate that this principle addresses it.

Any requirements can be added by clicking in the REQUIREMENTS column and selecting the relevant requirements

We keep both requirements since [PRE-5-RC-01] is also addressed by this principle. Upon save, the compliance result is updated and displays 100%.

2. Adjust the list of requirements based on new updates of prEN 40000-1-3

Given that prEN 40000-1-3 is under development, the requirements are subject to change. Whenever an update of the standard is available, you can adjust the list of the requirements as needed and perform the same steps described above.

Note on the removal of requirements

When editing a standard in Z-CMS, if you remove or change the text of a requirement, be aware that it may impact your policy in the following way. After the removal or change of a requirement, the latter will be removed from the parts of the policy which were supporting it. Let’s consider our example above in which we have a principle supporting [PRE-5-RC-01]. If we remove it from the list or rename it, it will be removed from the principle as shown below.

Example of the deletion of a requirement in the standard that is linked to a policy. The principle P1 was supporting [PRE-5-RC-01]. However, after deleting it from the standard, the requirement is also removed from the policy

If you add the requirement again to the list, you will have to go in the policy and manually indicate which part of the policy supports it.

Creating policies from scratch

Upon the creation of a new policy, you can leave the Template field empty to start working from a blank sheet. After accessing the Policy Editor, click on Add Section.

After creating a new policy without a template, you can add a section and select one of the types offered in the palette

You can start by adding a Front Page, before adding any sections from our vulnerability handling policy template or a Generic section. After adding a section, you can edit it as needed, by performing actions such as:

Editing the text of an existing subsection
Adding subsections
Deleting subsections
Rearranging the order of the subsections

If you have selected a standard when you created the policy, you will also be able to indicate the requirements supported by certain subsections. Make sure to save your progress regularly, and once you are satisfied with your policy, you can download it.

Contents

Policy-Vulnerability_Handling_Policy

13 sections50 sub-sections

100%

Version	1.0
Effective Date	1 Jan 2026
Last Reviewed	1 Jan 2026
Owner	None
Next Review	1 Aug 2026
Classification	Internal

Column 1	Column 2
table content another content	table content 2
what about this	and this

Term	Definition
Vulnerability	A weakness in a system, application, or network that could be exploited to compromise security
Reporter	An individual or organization that reports a potential vulnerability
PSIRT	Product Security Incident Response Team - the central coordination point for vulnerability handling
CVSS	Common Vulnerability Scoring System - industry standard for assessing severity (0.0-10.0 scale)
CVE	Common Vulnerabilities and Exposures - unique identifier for publicly disclosed vulnerabilities
Remediation	The process of fixing or mitigating a vulnerability through patches, updates, or workarounds
Disclosure	The act of making vulnerability information publicly available
Coordinator	An organization that facilitates coordinated vulnerability disclosure between parties

P#	Principle Description	Requirements (Not shown in final document)
P1	Access to non-public vulnerability information must be restricted to individuals who require it to perform their duties. Only the minimum information necessary for the vulnerability management process should be shared with relevant stakeholders.	[PRE-1-RQ-02][PRE-3-RQ-01]
P2	Secure communication mechanisms should be provided throughout the activities of receiving and communicating vulnerability information or reports.	[PRE-5-RC-01]
P3	Secure communication methods should protect the confidentiality and integrity of messages.	[PRE-5-RC-02]
P4	Secure communication methods must be designed to ensure that external communication remains accessible.	[PRE-5-RC-04]
P5	Communication with reporters and other stakeholders shall be established and maintained. Information to communicate comprises status updates, modifications to what has been previously communicated, planned date of disclosure. The objective is to minimize the uncertainty among stakeholders.	[PRE-4-RQ-01]
P6	Communication with users (during the release phase) shall implement accessible modes of communication.	[PRE-4-RQ-02]
P7	Reporters can report vulnerabilities anonymously. This means that a report should not be discarded in case the reporter does not disclose his/her identity.	[PRE-5-RC-03]
P8	When required, a coordinator can be appointed and involved in the vulnerability handling process.	[RCP-5-RC-01]

M#	Mechanism Description	Compliance evidence	Owner	Requirements (Not shown in final document)
M1	Reporting mechanism: Mechanism publicly available enabling the receipt of vulnerability information or reports	• The mechanism is publicly available and offers accessible means of communication	None	[RCP-1-RQ-01]
M2	Vulnerability tracker: Mechanism enabling the assignment of tracking number to reported vulnerabilities	• Stored vulnerability reports with their respective identifier	None	[RCP-1-RQ-02]

P#	Principle Description	Requirements (Not shown in final document)
P1	All reports should be accepted, even when they are received through less secure communication mechanisms.	[RCP-1-RC-01]
P2	If the vulnerability reported is actively exploited, it must be reported in accordance with this vulnerability reporting policy.

A#	Activity Title	Activity Description	Compliance evidence	Timeline	Owner	Requirements (Not shown in final document)
A1	Monitor vulnerability sources	Continuously monitor the internal and external sources listed in Vulnerability Sources listed below.	• List of the sources monitored • Relevant information collected through this activity	Ongoing	None	[RCP-2-RQ-01][RCP-2-RQ-02]
A2	Monitor 3rd-party components for end of support and usage	Continuously monitor the list of third-party components integrated into the products for end of support and usage.		Ongoing	None	[RCP-2-RQ-04]
A3	Add report to vulnerability tracker	After the receipt of a report, create a record and store the information provided in the report.	• Stored vulnerability reports with their respective identifier		None	[RCP-1-RQ-02]
A4	Report actively exploited vulnerability	Send the early warning notification through the Single Reporting Platform within 24h after becoming aware of the vulnerability.			None
A5	Send acknowledgment to reporter	Acknowledge the receipt of the report through the relevant communication mechanism. The acknowledgement must include tracking number.		Defined in CVD policy	None	[RCP-1-RQ-03]
A6	Identify software components potentially affected by vulnerability	When potential vulnerabilities are identified, determine whether software components are impacted.	• Performance of identification activities • If applicable: Software components identified to be potentially affected		None	[RCP-3-RQ-01]
A7	Identify hardware components potentially affected by vulnerability	When potential vulnerabilities are identified, determine whether hardware components are impacted.	• Performance of identification activities • If applicable: Hardware components identified to be potentially affected		None	[RCP-4-RQ-01]
A8	Conduct security testing	Security testing of the products must be conducted regularly, as described in the Security Test and Review Plan.	• Test reports	Defined in Security Test and Review Plan	None	[RCP-6-RQ-01]
A9	Conduct security reviews	Security reviews of the products must be conducted regularly, as described in the Security Test and Review Plan.	• Review reports • Updates made to the Security Test and Review Plan	Defined in Security Test and Review Plan	None	[RCP-7-RQ-01]
A10	Review cybersecurity risk assessment	The cybersecurity risk assessment must be reviewed at least annually to ensure that its inputs and assumptions are still relevant to the product. The review must be conducted even if the product design has not changed.			None	[RCP-7-RQ-02]

SC#	Success Criteria Definition	Linked to Activity #
SC1	An acknowledgment is sent to the reporter within the timeline.	A5
SC2	All vulnerability information and reports are captured in the vulnerability tracker and assigned a unique tracking number.	A3
SC3	There are no 3rd-party components integrated in the products that are out of support or unused.	A2
SC4	Potentially affected software components are identified within the timeline.	A6
SC5	Potentially affected hardware components are identified within the timeline.	A7
SC6	Security testing is conducted as defined.	A8
SC7	Security reviews are conducted as defined.	A9
SC8	The cybersecurity risk assessment is reviewed in accordance with the timeline.	A10

P#	Principle Description	Requirements (Not shown in final document)
P1	If the reporter did not provide sufficient details about the potential vulnerability to be verified, additional information should be requested from the reporter.	[VRF-1-RQ-01]
P2	If a vulnerability is identified to be critical, its resolution must be expedited.	[VRF-2-RQ-03]
P3	Actively exploited vulnerabilities must be considered critical.

A#	Activity Title	Activity Description	Compliance evidence	Owner	Requirements (Not shown in final document)
A1	Perform vulnerability assessment	An assessment of the vulnerability must be conducted in accordance with the Vulnerability Assessment Methodology in this policy.	• Evidence of vulnerability assessment performed (e.g., assessment reports) • Evidence that statuses of reported vulnerabilities are tracked • Vulnerabilities have their severity determined	None	[VRF-1-RQ-02]
A2	Send the vulnerability notification in case of actively exploited vulnerability	Send the vulnerability notification through the Single Reporting Platform within 72h after becoming aware of the vulnerability.		None
A3	Assess the risk introduced by the vulnerability	A risk assessment must be conducted. It must be aligned with EN 40000-1-2, Section 6.4.		None	[VRF-2-RQ-01]
A4	Assign the priority of the vulnerability	The priority must be determined based on the risk introduced by the vulnerability and the risk profile of the product.	• Evidence of prioritization activity	None	[VRF-2-RQ-02]
A5	Communicate verification results to the reporter	This activity is applicable only when the vulnerability was reported through the CVD.	• Communication with a reporter	None	[VRF-2-RQ-04]

SC#	Success Criteria Definition	Linked to Activity #
SC1	Vulnerability assessment report completed	A1
SC2	Risk assessment conducted and documented	A3
SC3	Vulnerabilities are prioritized	A4
SC4	Reporter informed of findings and next steps	A5

Severity	CVSS Score	Description	Key Characteristics
Critical	9.0-10.0	Exploitable remotely without authentication	Complete system compromise, no user interaction, widespread impact
High	7.0-8.9	Significant unauthorized access or compromise	Sensitive data exposure, privilege escalation, moderate prerequisites
Medium	4.0-6.9	Limited compromise requiring conditions	User interaction needed, specific configurations, moderate impact
Low	0.1-3.9	Minimal security impact	High complexity, extensive prerequisites, limited impact

P#	Principle Description	Requirements (Not shown in final document)
P1	Where technically feasible, security updates must be dissociated from functionality updates and provided separately.	[RMD-2-RQ-02]
P2	Actively exploited vulnerabilities must be considered critical.

A#	Activity Title	Activity Description	Compliance evidence	Timeline	Owner	Requirements (Not shown in final document)
A1	Decide on the remediation	A decision is taken to effectively remediate the vulnerability. Determine the most appropriate remediation approach based on vulnerability and (product) constraints, considering the Remediation Approaches in this policy.	• Documented decision		None	[RMD-1-RQ-01]
A2	Plan the remediation effort	Determine the resources required to implement the remediation. The target remediation timeline must be determined based on the severity of the vulnerability.	• Planning of the remediation with timeline		None	[RMD-1-RQ-02]
A3	Develop the remediation	Write remediation code, scripts, or configuration changes, depending on the remediation approach selected. Document changes, installation instructions, and any breaking changes.	• Remediation and its documentation are produced	Depends on vulnerability’s severity	None	[RMD-2-RQ-01]
A4	Test the remediation	Test the remediation according to the Remediation Testing Guidelines in this policy.	• Existence of the tested remediation • Test report of the remediation		None	[RMD-3-RQ-01]

SC#	Success Criteria Definition	Linked to Activity #
SC1	Remediation successfully eliminates the vulnerability and root cause	A4
SC2	No regressions introduced	A4
SC3	Remediation completed within target timeline	A4

Severity	Target Timeline	Response Requirements
Critical	7 days	Immediate action required. Continuous work until resolved. Executive notification about remediation progress.
High	14 days	Prioritize above normal development work. Expedited testing and approval. Daily status updates to PSIRT. Coordinate with stakeholders for deployment planning.
Medium	30 days	Include in next regular release cycle. Follow standard change management. Weekly status updates. May be batched with other security fixes.
Low	90 days	Address during routine maintenance. Can be bundled with feature releases. Bi-weekly status updates. May accumulate multiple low-severity fixes for batch deployment.

M#	Mechanism Description	Compliance evidence	Owner	Requirements (Not shown in final document)
M1	Mechanism to distribute security updates in a secure manner, ensuring the integrity and authenticity of the updates.	• Security update distribution • Implemented security update mechanisms for secure distribution of security updates • If products can support automatic updates, implementation of automatic security update distribution mechanism	None	[RLS-1-RQ-04][PRE-10-RQ-01]
M2	Mechanism to distribute security information	• Capability to distribute security information	None	[PRE-10-RQ-02]

P#	Principle Description	Requirements (Not shown in final document)
P1	Security updates are provided for free, unless there is an agreement with the customers in relation to a tailor-made product.	[RLS-1-RQ-01]
P2	Security updates must be distributed in a timely manner	[RLS-1-RQ-02]
P3	If applicable, the distribution of security updates must be automated.	[PRE-10-RQ-03]
P4	If the distribution of security updates is not fully automated, installation instructions must be provided to users. In such cases, installation instructions will be required as compliance evidence.	[RLS-1-RQ-03]

A#	Activity Title	Activity Description	Compliance evidence	Owner	Requirements (Not shown in final document)
A1	Coordinate disclosure	Work with the reporter (and affected third parties, if applicable) to agree on coordinated disclosure date.		None
A2	Prepare security advisory	Draft advisory in accordance with the Advisory Content Requirement in this policy.		None	[RLS-2-RQ-02]
A3	Request CVE ID	Request CVE ID from MITRE or appropriate CVE Numbering Authority.		None
A4	Deploy remediation to production	Deploy remediation to production systems to be ready for distribution.		None
A5	Distribute remediation	Distribute the remediation on download portal. If applicable, publish it with installation instructions.		None
A6	Publish security advisory	Release advisory on security portal with vulnerability details and remediation guidance.	• Published information on vulnerabilities addressed by the security update	None	[RLS-2-RQ-01]
A7	Notify customers	Send notifications through email, customer portal, and website banner, especially in case of actively exploited vulnerability.		None
A8	Notify partners and downstream users	Contact OEM partners, resellers, and known downstream integrators.		None
A9	Notify MITRE and update vulnerability databases	After publication of the advisory, notify MITRE about the publication. Submit information to relevant public vulnerability databases.	• Published information on vulnerabilities addressed by the security update at EUVD, if applicable	None	[RLS-2-RC-01]

SC#	Success Criteria Definition	Linked to Activity #
SC1	Security advisory published on coordinated disclosure date	A7
SC2	No premature or uncoordinated disclosure	A1
SC3	CVE and vulnerability databases updated
SC4	Customer notifications sent through all channels	A8
SC5	The security update is distributed in a timely manner	A6

A#	Activity Title	Activity Description	Compliance evidence	Owner	Requirements (Not shown in final document)
A1	Monitor initial response	Watch support channels, social media, and news for issues or questions.		None
A2	Monitor remediation adoption	Track customer uptake of patches through telemetry, support tickets, and direct outreach.	• Post-release actions exist • Evidence on the execution of the post-release actions	None	[PRA-1-RQ-01]
A3	Provide customer support	Answer technical questions and assist customers with remediation implementation.		None
A4	Case maintenance	After the remediation is released, continue to provide updates for the remediation if necessary, until no further update is required. This may involve the update of the advisory.		None	[PRA-1-RQ-01]
A5	Conduct post-mortem review	Hold a retrospective meeting with all stakeholders involved. Document what worked well, what could be improved, and specific action items to improve the vulnerability handling policy and processes.		None
A6	Review and improve development practices	Update coding standards, security requirements, the security testing and review plan, and training materials.		None
A7	Archive case file	Complete vulnerability record with all documentation and evidence for compliance and future reference.		None
A8	Close vulnerability case	Formally close the case in vulnerability tracking system once widespread adoption achieved and no issues reported.		None

SC#	Success Criteria Definition	Linked to Activity #
SC1	High remediation adoption rate achieved (target: 90% within 60 days for Critical/High vulnerabilities)	A2
SC2	Customer support questions resolved satisfactorily	A3
SC3	No significant issues with remediation reported	A3
SC4	Post-mortem completed with documented lessons learned	A5
SC5	Development practices updated to prevent recurrence	A6
SC6	Complete case file archived for compliance	A7
SC7	Vulnerability formally closed in tracking system	A8

Stakeholder Name	Contact Person	Email
Chief Information Security Officer (CISO)
Development Team
Legal & Compliance
Product Business Division
Product Security Incident Response Team (PSIRT)

Policy Editor [BETA]

Policy-Vulnerability_Handling_Policy

VULNERABILITY HANDLING POLICY ZEALIENCE TEMPLATE

Document Control Table

Compliance Statement

Document Review

Blank Table

Document Review

Scope

Blank Table

Purpose and Scope

Purpose

Scope

Terms and Definitions

Terms and Definitions

Organizational Framework

Leadership and Commitment

Roles and Responsibilities

Chief Information Security Officer (CISO)

Development Team

Legal & Compliance

Product Business Division

Product Security Incident Response Team (PSIRT)

Vulnerability Handling Process

Process Overview

Principles of Vulnerability Handling

Phase 1: Receipt

Objective

Mechanisms

Principles

Activities

Success Criteria

Vulnerability Sources

Phase 2: Verification

Objective

Principles

Activities

Success Criteria

Vulnerability Assessment Methodology

Severity Classification

Phase 3: Remediation

Objective

Principles

Activities

Success Criteria

Target Remediation Timelines

Remediation Approaches

Remediation Testing Guidelines

Phase 4: Release

Objective

Mechanisms

Principles

Activities

Success Criteria

Advisory Content Requirements

Phase 5: Post-Release

Objective

Activities

Success Criteria

Post-Mortem Review

Metrics and Reporting

Supporting Processes

Confidentiality Management

Performance Monitoring

Supply Chain Considerations

Appendix: Contact Information

Contact Information

Appendix: Upstream and Downstream Stakeholders

Upstream Stakeholders

Downstream Stakeholders