What the CRA coordinated vulnerability disclosure policy requirement asks for
If you manufacture a product with digital elements, Annex I Part II point (5) requires you to put in place and enforce a coordinated vulnerability disclosure policy for the whole support period. The policy is the standing rule for how people outside your company, such as researchers, customers and other vendors, report a suspected weakness to you, how you triage it, and how the fix reaches users. It addresses a specific failure: a vulnerability report arrives from outside, sits in an inbox, and is never acted on or fixed. Article 13(8) requires appropriate policies and procedures, including coordinated vulnerability disclosure policies, to process and remediate potential vulnerabilities reported from internal or external sources. Annex II point 2 then requires your user information to state where that policy can be found, and Annex VII point 2(b) requires the policy to appear in your technical documentation. Those three links mean the policy has to exist as a published, findable document, not only as an internal procedure. The hard part is usually ownership rather than drafting. Security teams own triage, product teams own the fix and release decisions, and legal or communications teams own disclosure wording and timing, so a policy that names only one of them tends to stall at the first real report. Ask who can accept a report on a weekend, who decides whether a fix is ready for publication, and who signs off on what users are told. Write those roles into the policy before a report arrives.
Keeping the policy current is the second difficulty. The Commission's guidance C(2026) 5252 (section 5) states that even where Article 13(10) lets you stop remediating older software versions, you must keep a coordinated vulnerability disclosure policy for all later substantially modified versions. Your policy therefore has to cover every version still in the field, and the user information pointing to it must stay accurate as products change. Confirm with your counsel how the Commission's guidance applies to your product line, and record where the current policy lives, who approves changes and which versions it covers. Tools that version-control documents, such as the open-source wiki XWiki, can keep a change history for the policy and its user-facing pages.
Which products, versions and teams the CVD policy must cover
The coordinated vulnerability disclosure policy is not a single company-wide document. Its reach depends on which products, versions, components and internal teams are in play, and each choice changes what the policy must say and who must act on it. The cards below set out the scoping decisions that most often change the work.
Every in-scope product
The policy must be in place for each product with digital elements that falls under the regulation, not only for the flagship product. Check each product line, including add-ons, companion apps and cloud backends that are part of the product as placed on the market. Record the product list and its version boundaries in the technical documentation so the policy's coverage can be traced product by product.
Substantially modified versions in support
Guidance C(2026) 5252 says the policy must cover every later substantially modified version still within the support period, even where the manufacturer may stop remediating older versions. Map each release line to its support end date and confirm which versions still receive the policy's protection. Ask engineering to flag any release that changes the product in a way that counts as substantial.
Third-party components
Reports about a vulnerability in a bundled library, firmware blob or vendor SDK still reach the manufacturer, so the policy has to say how those reports are received and passed on. Confirm which supplier contracts require vendors to share vulnerability information in time for you to meet your own duties. Identify the owner for each supplier relationship before a report arrives.
Open-source components you ship
Open-source components shipped inside your product are part of its attack surface, and reporters often find flaws in them before finding them in your own code. Decide whether reports about upstream projects are routed to the upstream maintainers, to your team, or to both, and say so in the policy. Keep the component list current with your SBOM so the people who triage reports can tell quickly whether a flaw touches your build.
Support, engineering and legal
A report usually reaches support or a public mailbox first, but triage and fixing sit with engineering, and disclosure decisions involve legal. Name a single intake owner, a triage owner and an approver for each step, and write these roles into the policy so that a report does not stall between teams. Test the hand-offs with a tabletop exercise before a live report tests them for you.
Communications and public relations
Public statements about a vulnerability, including advisories and press contacts, need to be consistent with the policy's disclosure timing and with what technical staff have confirmed. Agree who may speak publicly, which channels carry advisories, and how the communications team gets technical facts without waiting on a single contact. Keep a standing template for user-facing advisories so the policy's commitments can be met under time pressure.
How an assessor tests the disclosure policy
The assessor starts with the written policy and the technical documentation that must contain it. Annex VII point 2(b) requires the policy to appear in the technical documentation, so the reviewer checks that the document exists, is dated, names an owner and describes the full path from report intake to public disclosure. The reviewer also looks for the scope of versions the policy covers, since the Commission guidance expects the policy to remain in place for every later substantially modified version.
- Policy text: the current version, its revision history and the approval record showing who signed it off.
- Scope statement: which products, versions and third-party components the policy covers.
- Technical documentation extract: the section that references the policy, with the file name and version number.
- Timelines and roles: acknowledgement, triage and disclosure steps, with named roles rather than mailboxes alone.
- Common finding: a policy that exists as an internal draft or is not referenced anywhere in the technical file.
Check that the policy and the technical file quote the same version and that the reviewer can trace each claim to a dated artifact.
Annex II point 2 requires the user information to say where the coordinated vulnerability disclosure policy can be found. An assessor tests this by reading the user documentation as a customer would, starting from the product's main entry points, and confirming that the policy is reachable in a few steps. The reviewer records the path, the date of the check and the version of the user information, because a link that worked in one release may be missing in the next.
- Location in user information: the page, manual or in-product screen that names the policy.
- Working link: the destination URL or document path, checked on a dated screenshot or capture.
- Version match: the user information shipped with each supported release points to the same policy.
- Language and access: the policy is available to users without an account or contract, where that is feasible for the product.
- Common finding: the policy is published on a website but the user information shipped with the product never mentions it.
Ask the team to show the build artifact that contains the user information, so the reviewer can confirm what users actually receive.
Interviews test whether the people who receive reports know the policy and follow it. An assessor usually interviews the security contact, the engineers who triage and fix vulnerabilities, and the person who approves public disclosure. The aim is to confirm that the written process matches daily practice, that roles are staffed and that handlers know what to do when a report arrives outside the normal channel, for example through a support ticket or a social media message.
- Intake owner: who monitors the contact address and how coverage works when that person is absent.
- Triage and escalation: how severity is assessed and when management is informed.
- Coordination with reporters: how the team keeps reporters updated and handles disagreement about disclosure timing.
- Authority to disclose: who decides on publication and how that decision is recorded.
- Common finding: handlers describe a different process from the document, or no one can name the approver.
Record each interview with role, date and the statements that the evidence later confirms or contradicts.
Sampling shows whether the policy was enforced in practice. The assessor asks for a list of vulnerability reports received in the assessment period, selects a sample, and traces each one from intake to closure. The sample should include reports from different sources, reports that were rejected or declined, and reports that led to public disclosure, so the reviewer can see every branch of the process. The number and selection method should be agreed with the assessor before testing starts.
- Report log: a dated register of reports with source, status and closure reason.
- Acknowledgement records: timestamps showing when the reporter received a reply.
- Remediation and disclosure records: tickets, release notes and published advisories tied to each report.
- Version coverage: evidence that reports affecting older supported versions were handled under the same policy.
- Common finding: no reports are recorded at all, which leaves the assessor unable to test enforcement and prompts questions about whether intake is working.
Ensure the log is complete and unedited. Confirm with the assessor how the sample was chosen and whether the period covers at least one full release cycle.
Steps to put the policy in place and keep it enforced
This sequence turns Annex I Part II (5) into a working policy that names an owner, tells reporters how to reach you, feeds reports into remediation and the Article 14 path, and leaves a record that the policy is enforced across every in-scope version.
Define scope and assign ownership
Start by listing every product, version and support period the policy must cover, including software that is still in its support period after a substantial modification. Name an accountable owner, usually a product security or PSIRT lead, and a deputy, and confirm who in engineering, legal and customer support will act on reports. The output is a short scope statement and a role register signed off by the business owner of each product. Confirm that the scope matches the product classification and support period documented elsewhere in your CRA file.
Draft the policy with a full report lifecycle
Write the policy to cover how reports are received, acknowledged, triaged, remediated and coordinated with the reporter, including how you handle reports from internal teams, customers, researchers and third-party component suppliers. Describe the reporter's expectations in plain language, including what you will confirm and when you will update them, and state how coordination may be paused if a fix or a Article 14 notification is in progress. The output is a versioned policy document approved by legal and product security. Have counsel check that the wording matches your published safe-harbor and contact commitments.
Set timelines, severity criteria and escalation paths
Define internal timelines for each stage, the severity criteria that decide priority, and the escalation route to the product owner and executive sponsor when a report is severe or disputed. Decide who can authorize public disclosure and how that decision is recorded. Because the regulation does not set specific disclosure deadlines in the researched facts, confirm your own targets with product and legal teams rather than copying figures from other programs. The output is a triage matrix and an escalation table attached to the policy.
Connect the policy to vulnerability handling and Article 14
Link the disclosure workflow to the vulnerability identification, SBOM, remediation and advisory processes so a reported issue lands in the same tracking system as scanner and internal findings. Add a decision point where a report may meet the Article 14 criteria for actively exploited vulnerabilities, and route it to the owner responsible for the ENISA Single Reporting Platform notification. The output is a documented workflow diagram showing every hand-off, with named owners for each one. Test the workflow with a tabletop exercise using an illustrative report.
Publish the policy and reference it in user information
Publish the policy at a stable, public address and state in the user information where it can be found, as Annex II point 2 requires. Make the contact route for reports easy to find, and confirm that the page remains available for every in-scope version during the support period. Place the policy in the technical documentation as Annex VII point 2(b) requires. The output is a live policy URL, a dated change log and a checked copy of the user information wording. Verify the link after each release.
Run the intake and record every report
Operate the intake channel and log each report in a tracker with timestamps for receipt, acknowledgement, triage decision, fix and disclosure. Record the reporter's coordination choices and any disputes, and keep the rationale for each decision. Remediation of accepted reports follows the remediation process, and fixes are published as advisories under the disclosure process. The output is a complete audit trail for each report that an assessor or market surveillance authority can review.
Review enforcement and keep the policy current
Review the policy on a schedule you set and after any significant incident, new product version or change in the regulation's guidance. Sample closed reports to confirm the workflow was followed, and check that the published policy still matches the operating process. Record the review outcome, approve any changes, and update the user information and technical documentation references. The output is a review record showing the policy was enforced and kept in place for all versions in the support period.
How the disclosure policy connects to Article 13(8) and Annex II
The coordinated vulnerability disclosure policy is the document that ties three separate duties together: how the manufacturer processes reports, how users learn the policy exists, and how an assessor finds it in the technical file. Article 13(8) requires appropriate policies and procedures, including coordinated vulnerability disclosure policies, to process and remediate potential vulnerabilities reported from internal or external sources. In practice, the policy you publish under Annex I Part II point (5) should be the same procedure your engineers actually run when a researcher, customer, component supplier or internal test team reports a flaw. Before you publish it, confirm that intake channels, triage ownership, remediation tracking and closure criteria in the policy match your ticketing and security workflow, because a policy that describes a process nobody follows is the first thing a market surveillance authority will test.
The user-facing duty sits in Annex II point 2, which requires the user information to say where the manufacturer's coordinated vulnerability disclosure policy can be found. The technical documentation duty in Annex VII point 2(b) requires the policy itself to be included in the technical file. Those two locations serve different readers, so treat them as two deliverables with one owner: the public copy must be reachable from the product, its documentation and the support pages without a login, and the technical file copy must carry the same version and effective date. Ask the reader to check a simple question for each release: can a user find the policy from the device, app or installation guide, and does the technical file hold the version that was live when the product was placed on the market?
Commission guidance C(2026) 5252, section 5, addresses what happens at the end of a product's support period. Article 13(10) can let a manufacturer stop remediating older software versions, but the guidance states that the manufacturer must still keep a coordinated vulnerability disclosure policy for all later substantially modified versions. Plan for this now: the policy should not be tied to one major release or to the version a single team maintains. Decide which product versions the policy covers, record how a reporter can tell which version is affected, and make sure the policy remains published and linked for as long as any later substantially modified version is in use. The guidance is non-binding, so confirm its reading with your national market surveillance authority or notified body where your product class makes that relevant.
Evidence that passes a CVD policy review
A coordinated vulnerability disclosure policy only counts as compliant when its published text, its public location, and the records showing it runs in practice all agree. The cards below cover the artifacts a reviewer will request, and each one needs a named owner and a refresh routine so it stays accurate between assessments.
Published policy with version history
Keep the policy as a controlled document with a version number, an effective date, a named approver and a change log that records what changed and why. Annex I Part II (5) requires the manufacturer to put in place and enforce the policy, so a reviewer will check that the text in force matches the text published to users. Use version control in your documentation system so you can show the approved version that applied on any given date. Confirm that the approval is signed by someone with authority over product security, not only by the author.
Public location and user information reference
Annex II point 2 requires the user information to state where the coordinated vulnerability disclosure policy can be found. Record the public URL, confirm it resolves without a login, and capture dated screenshots or archived copies of the page as it appeared at each release. Check that the reference appears in the user documentation for every supported product line, not only the marketing site. Re-test the link after each website or documentation migration, because broken references are a common finding.
Technical documentation extract
Annex VII point 2(b) requires the policy to be included in the technical documentation. Prepare an extract that carries the same approved version as the public policy, with the same identifier and date, and store it alongside the rest of the conformity file. A reviewer will compare the two copies line by line, so any drift between them is a finding. Update the extract whenever the public policy changes, and record which product versions each extract covers.
Register of received vulnerability reports
Maintain a register of every report received through the disclosure channel, whether from researchers, customers, internal teams or third-party component maintainers. Each entry should record receipt date, triage decision, severity, affected versions, remediation status and the outcome communicated to the reporter. Vulnerability tracking tools such as DefectDojo can hold these findings and deduplicate them, but the policy-level register must still show the decisions made about each report. Review the register at a fixed interval to confirm that no report has stalled without a recorded outcome.
Coordination records with reporters
Keep dated correspondence showing acknowledgement, status updates, agreed disclosure timing and final close-out with each reporter. These records prove the policy is enforced in practice, not only written down. Note where a reporter asked for a delay, where a third-party component was involved, and how the coordinated date was set. Store them with restricted access, since they often contain exploit details and personal data, and confirm the retention period with counsel before setting it.
Coverage proof for each supported version
Commission guidance C(2026) 5252 states that a manufacturer must keep a coordinated vulnerability disclosure policy for all later substantially modified versions, even where it stops remediating older versions under Article 13(10). Produce a mapping from each supported product version to the policy version that applies to it, and show the policy reference in each version's user information. Refresh this mapping at every release and at the end of each support decision, so the record reflects the versions actually on the market.
What meeting the disclosure policy requirement costs
This table lists the cost components of putting in place and running a coordinated vulnerability disclosure policy, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No prices or durations are published here because none were supplied, so use the right-hand column to scope a quote.
| Cost component | Who is paid or who does the work | One-time or recurring | Main cost drivers and what to ask for in a quote |
|---|---|---|---|
| Legal review of the policy | Counsel, or the internal legal team | One-time, with periodic review | Number of jurisdictions, safe-harbor wording and any publication constraints. Ask whether the quote covers review after each Commission guidance update. |
| Policy drafting and scope definition | Product security lead, consultant or implementation partner | One-time | Number of product lines and versions in scope. Ask which products and support periods the policy covers in writing. |
| Intake and triage process setup | Engineering and security staff, or an outside PSIRT provider | One-time setup, then recurring operation | Reporting channels, ticket tooling and triage roles. Ask who staffs triage and how acknowledgement and handoff are defined. |
| Ongoing intake and triage time | Internal PSIRT or product security engineers | Recurring | Report volume, severity mix and duplicate rate. Ask for a staffing model tied to expected report volume and on-call coverage. |
| Publication and maintenance of the policy web page | Web team or documentation owner | One-time build, recurring upkeep | Number of languages, locations where the link appears in user information and update frequency. Ask who owns the link in user documentation. |
| Evidence upkeep | Compliance lead or documentation owner | Recurring | Frequency of version releases, number of retained reports and records of decisions. Ask how the policy version history and per-version applicability are kept. |
| External review or penetration testing supporting the policy | Independent testing firm or implementation partner | Recurring, usually tied to test cycles | Scope, number of applications and APIs, and whether testing covers the disclosure channel. Ask for fixed scope and deliverables in writing. |
| Assessor time | Notified body or independent assessor, where applicable | Recurring, per assessment | Conformity route, product class and documentation volume. Ask the assessor for its own fee and scope; implementation partners do not issue conformity results. |
Who owns the policy, who builds it, and who assesses it
The manufacturer is the legal owner of the obligation. Annex I Part II point (5) requires the manufacturer to put in place and enforce a coordinated vulnerability disclosure policy, and Article 13(8) expects it to process and remediate potential vulnerabilities reported from internal or external sources. Decisions about scope, the policy text, response commitments and who is accountable for each step stay with the manufacturer's leadership, product security and legal functions.
- Policy ownership: An accountable executive or product security lead approves the policy and its later revisions.
- Enforcement: Internal teams must follow the policy when reports arrive, including for older software that remains in its support period.
- Public commitments: Legal reviews the wording on how reporters are treated, what the manufacturer will and will not do, and how the policy is published.
- Signed records: Named staff sign triage decisions, disclosure timing and any statements made to reporters or authorities.
- Triage capacity: Staff who can assess severity and coordinate fixes must exist before the policy is published.
Confirm internally who holds each of these duties in writing before any outside party starts work.
An implementation partner such as DeployOpen can prepare the systems, documentation and workflows that the manufacturer uses to run the policy. The partner works inside the client's own infrastructure, so intake channels, ticketing and evidence stores remain under the client's control. Work is typically agreed as a fixed scope with written deliverables.
- Intake systems: Configuring a reporting address or web form, ticket routing and access rules for security reporters.
- Documentation: Drafting the policy text, the triage procedure and the user-facing location statement for review by the manufacturer.
- Workflow records: Setting up tools that log each report, its status, decisions and the date each step happened.
- Evidence packs: Assembling the policy, version history and sample case records that the assessor will request.
- Staff preparation: Walking the manufacturer's team through the procedure so the people who sign decisions can explain them.
DeployOpen does not issue reports, attestations or certifications. Ask any partner to state this in the scope and to name who the manufacturer's accountable owner is.
An independent auditor, assessor or certification body tests whether the policy exists, is enforced and is documented. Where the route to conformity requires a notified body, that body is designated by a Member State and listed in the Commission's NANDO system. For most products the manufacturer performs self-assessment under module A, so the assessor role may be limited to technical checks or may not apply, but the manufacturer still has to be able to show its evidence to market surveillance authorities.
- Design review: Checking that the policy covers scope, reporting channels and expected response steps.
- Operating evidence: Sampling reports and reviewing how they were handled, dated and approved.
- Consistency: Comparing the policy with the user information and technical documentation that reference it.
- Version coverage: Confirming the policy applies to every version still in its support period.
- Reporting: Issuing the assessor's own findings or report, which the manufacturer cannot write for itself.
Before engaging anyone, confirm with the assessor which conformity route applies to your product and which evidence they expect to receive.
Gaps that cause CVD policy findings and how to close them
Assessors and market surveillance authorities tend to find the same weaknesses in coordinated vulnerability disclosure policies: the policy exists on paper but does not reach users, does not cover every supported version, or does not match how reports are actually handled. Each card below names one gap, why it matters for Annex I Part II (5), and the closing action to check before an assessment.
Policy not linked from user information
The policy may be published on an internal wiki or a page nobody can find, while the user information required by Annex II does not point to it. Annex I Part II (5) expects users to be able to find the policy, so the link must appear where users look, such as product documentation, the support portal and the release notes. Close it by adding the public URL to user information for each product and checking that the link resolves from a clean browser session.
Older supported versions left out
Teams often write the policy around the current release and forget that it must hold for every later version that the manufacturer keeps supported. Commission guidance C(2026) 5252 states that the policy must remain in place for all later substantially modified versions, even where remediation of older versions is limited. Close it by listing every version inside the support period, confirming the policy applies to each, and recording the mapping in the technical documentation.
No record of past report handling
A policy that describes intake but has no history of how earlier reports were received, triaged and closed is hard to test. Assessors commonly ask for examples of reports handled under the policy, including dates, decisions and outcomes. Close it by keeping a dated register of every report, its severity decision, the remediation owner and the disclosure outcome, and by keeping that register under version control so changes are traceable.
Reports arriving by unmonitored channels
Vulnerability reports often arrive at a sales mailbox, a support form, a social media account or a developer's personal address, and nobody checks them on a fixed schedule. Article 13(8) expects processes that handle potential vulnerabilities from internal and external sources, so an unmonitored channel is a process failure. Close it by publishing one designated contact address, routing every other channel to it, and testing that a message to it reaches a triage owner within a set schedule that the team has written down.
No named policy owner
When the policy has no accountable owner, reports stall between engineering, legal and support, and nobody can answer an assessor's question about who decides. The owner should hold authority to assign remediation, approve disclosure timing and sign off the policy text. Close it by naming a role and a deputy in the policy itself, recording the appointment in the security governance records, and confirming that the owner has been briefed on the responsibilities.
Policy text out of line with triage
A policy may promise acknowledgment times, coordination steps or disclosure practices that the engineering team does not actually follow. Once an assessor compares the written text with the ticket history, the mismatch becomes a finding in its own right. Close it by walking through three recent reports against the policy step by step, then editing either the policy or the workflow until they agree, and repeating the walkthrough after each material change.
Questions buyers ask about the CVD policy requirement
What does a coordinated vulnerability disclosure policy have to contain?
Annex I Part II point (5) requires manufacturers to put in place and enforce a coordinated vulnerability disclosure policy, and Article 13(8) ties that policy to processing and remediating potential vulnerabilities reported from internal or external sources. The regulation does not give a template, so the policy should be written around the steps your organization will actually run:
- a published way for researchers and others to report a suspected vulnerability
- a defined process for triage, remediation and communication with the reporter
- roles and responsibilities for the people who receive and act on reports
- how the policy applies to third-party components and to every version in the support period
Have counsel and your product security team confirm the wording against the Annex I text and the Commission guidance before you publish it.
Can our team write and run the CVD policy without an outside partner?
Yes, a manufacturer can write and run the policy in-house, because the obligation sits with the manufacturer and not with an advisor. The work is mostly process design, documentation and staffing a reporting channel that stays open for the whole support period. Teams usually need to decide who owns intake, who triages and who writes public-facing communication, and they need to keep records that show the policy was enforced. An outside partner can help with the process design, the tooling that tracks reports and the evidence pack for an assessor, but the policy remains the manufacturer's own.
How long does it take to set up a CVD policy, and what drives that time?
No fixed duration applies to this requirement, so ask any advisor for a written scope and timeline rather than relying on a generic figure. The main drivers are how many products and product lines the policy must cover, whether a product security or PSIRT function already exists, how many third-party components need to be routed into the process, and how much internal review the legal and communications teams require before publication. Organizations with an existing vulnerability intake process usually start from a shorter base than those building one from nothing.
What does the work need from our engineering and security staff?
Engineering and security staff need to supply the product inventory, the list of supported versions and the existing bug bounty or security contact arrangements, then review the triage steps they will follow. Over the support period, staff must keep the policy consistent with how fixes are released, which means the people who ship security updates must be part of the disclosure workflow. Recurring effort is mainly reviewing incoming reports, tracking them to closure and keeping the published policy current when products, versions or contacts change.
How does the CVD policy apply to open-source components we use or publish?
The policy applies to the product you place on the market, so it must cover vulnerabilities that reach your product through open-source components as well as flaws in your own code. Any open-source component you integrate needs a route for reports to reach your triage process, and your SBOM work under Annex I Part II point (1) helps you trace which components are affected. Commission guidance C(2026) 5252 addresses free and open-source software, so check its treatment before deciding how your policy handles upstream projects and any work you contribute back.
How does the CVD policy relate to the Article 14 reporting route?
The CVD policy governs how you receive, triage and remediate vulnerability reports, while Article 14 governs what you must notify to authorities. Since 11 September 2026, manufacturers must notify actively exploited vulnerabilities through ENISA's Single Reporting Platform, so a report that shows active exploitation can trigger both the policy workflow and the Article 14 clock. Your intake and triage steps should therefore flag exploited vulnerabilities early, so the team can meet the reporting timelines in Article 14 while still following the disclosure process with the reporter.
What evidence will an assessor expect to see for the CVD policy?
An assessor will look for the published policy itself, the location where users can find it, the copy in your technical documentation and proof that the policy has been enforced across versions. Annex II point 2 requires the user information to state where the policy can be found, and Annex VII point 2(b) requires it in the technical documentation. Keep dated records of received reports, triage decisions and disclosures, because a policy that exists only on paper does not show enforcement. Confirm the exact evidence form with your conformity assessment route and any notified body involved.
How DeployOpen prepares a CVD policy for assessment
DeployOpen's work on this requirement starts with a scoping decision that the organization makes and DeployOpen documents: which products, product lines and versions the policy must cover. Because the policy has to stay in place for all later substantially modified versions, the scope should map product names to the version ranges still in support and to the components they ship with. DeployOpen then prepares intake and tracking in the client's own infrastructure, so that reports, triage notes and status changes are stored under the client's control. A typical setup pairs a web form or dedicated mailbox with a tracker such as DefectDojo, which imports findings from more than 500 report formats and deduplicates them using per-tool hashcode fields. Confirm with your team which intake channel the security contact will monitor and who holds the admin role in each system.
DeployOpen then drafts the policy, the user-facing pointer and the technical documentation entries for the client to review and approve. The drafts cover the reporting channel, the acknowledgment and triage process, the coordination commitments toward reporters, and the publication of fixed vulnerabilities. Version control matters here: a wiki such as XWiki keeps a record of every change, with who made it and when, so that assessors can see which version of the policy applied at a given date. Access to the approved text can be limited by role in a tool such as BookStack. The organization makes the final decisions on wording, owners and escalation paths, and it signs off on the content before anything is published.
The last step is assembling evidence for the independent assessor. This includes the approved policy and its revision history, the published locations in user information and technical documentation, the intake and triage records for reports received, and proof that the policy was applied to each supported version. DeployOpen prepares and organizes this material, but it does not issue reports or attestations. An independent assessor or certification body performs the assessment and issues any conclusion. Before engaging one, the organization should confirm the assessor's scope of work and what sample of records it will request.
