What ID.RA-08 asks an organization to have in place for vulnerability disclosure
ID.RA-08 asks an organization to have processes in place for receiving, analyzing and responding to vulnerability disclosures. The situation behind it is familiar: a customer's security team, a regulator, a partner or an outside researcher reports a flaw in one of your products or services, and nobody can say quickly who owns the report, whether it is real, or who must act. The outcome is a repeatable intake, so that a disclosure is logged, assigned and answered on a known path rather than sitting in a general inbox or a personal email account. In CSF 2.0 this is a Subcategory of the Risk Assessment Category in the IDENTIFY Function, and it takes over the outcome that CSF 1.1 recorded as RS.AN-5 under a new identifier. Confirm the mapping in NIST's CSF 1.1 to 2.0 Core Transition Changes spreadsheet before you cite it in an audit file.
The risk this addresses is disclosures that go unread or unassigned. A valid report about an internet-facing component can wait for weeks because the sender used a channel no one monitors, or because the product team assumes the security team has it and the security team assumes the supplier has it. Supplier-delivered components make this harder, since the flaw may originate in a library or appliance you do not build yourself. The hard part is rarely the technical fix. It is agreeing on ownership across supplier management, product engineering and security operations, and writing down who triages, who decides severity, who contacts the reporter and who tells customers.
Start with three checks. First, list every channel through which a disclosure can arrive, including government advisories and supplier notices, and confirm each one reaches a monitored queue. Second, write a short assignment rule that names an owner for triage within a defined window your organization sets. Third, keep a record for each disclosure that shows receipt, analysis, decision and closure, so the evidence exists when an assessor asks. An open-source tracker such as DefectDojo can hold that record, and the ID.RA-08 Implementation Examples in the NIST CSF 2.0 Reference Tool export describe the responsibility assignment NIST expects. Whether a given intake design satisfies your contracts or regulators is a question for your legal team and assessor.
Which disclosures, systems and teams fall under ID.RA-08
ID.RA-08 covers disclosures that reach the organization from outside, and the internal teams that must act on them. The cards below separate the four disclosure sources named in the outcome, the systems each one can touch, and the teams that must own triage and response. Scoping decisions made here determine which disclosures the process must catch.
Supplier disclosures
Vendors and open-source maintainers often learn about flaws in components you run before you do. Your process should name who receives these notices, which contract clauses require suppliers to report defects, and how you share vulnerability information back under those rules, as NIST's Implementation Examples describe. Check that every critical supplier has a documented contact path, and that notices arriving through procurement or account managers reach security staff.
Customer and researcher reports
Customers, penetration testers and independent researchers report flaws through support tickets, sales channels or a public contact address. Reports from these sources often describe exposed interfaces or misconfigurations in products you run for them. Confirm that a single intake address or form exists, that reports are logged as tickets rather than handled in private inboxes, and that reporters receive an acknowledgment and a named contact.
Partner and integrator notices
Integration partners, resellers and managed service providers can see flaws in shared interfaces, connectors or deployment templates that your team owns. Scope these disclosures to the integration points you control, such as APIs, single sign-on connections and shared configuration. Agree in writing who notifies whom, and how quickly partner staff must escalate a finding that affects your environment.
Government and CERT advisories
National cybersecurity organizations and sector computer emergency response teams publish advisories and sometimes notify organizations directly about exposed systems. These disclosures carry the most urgency because they can name active exploitation. Assign an owner who monitors these channels, matches advisories against your asset inventory, and records the decision to act or accept the risk.
Public products versus internal systems
Scope the process by deciding whether it covers only the products you ship to others, only the internal systems you run, or both. Customer-facing products usually need a public disclosure policy and coordinated timelines, while internal systems need faster patching and internal reporting. Document the decision, because an assessor will test whether the scope matches the systems in your asset inventory.
Third-party components you ship or run
Open-source libraries, container images, firmware and hosted platforms you embed in products or operate internally all generate disclosures that name someone else's code. Record each component, its version and its owner in your software inventory so that a disclosure can be matched quickly. Confirm which team receives advisories for each component, and who decides whether a fix, a workaround or an accepted risk applies.
How an assessor tests ID.RA-08 and what they ask to see
When an organization assesses itself against the CSF Core, the test is a walk-through of the outcome: is there a documented process for receiving, analyzing and responding to vulnerability disclosures? The reviewer compares what the process says with what actually happened in recent cases. NIST's two Implementation Examples for ID.RA-08 give useful prompts: how information is shared with suppliers under contract rules, and who is assigned and verified to process disclosures from suppliers, customers, partners and government organizations.
- Written intake process: a procedure that names every channel, such as a security mailbox, a published disclosure page or a supplier portal.
- Triage records: tickets showing how each disclosure was analyzed, scored and linked to affected assets.
- Named owners: a role or person for each step, with evidence that the assignment was checked, not only written down.
- Response timelines: targets the organization set for itself, with records showing whether they were met.
- Closure records: proof that each disclosure ended in a fix, a documented acceptance or a transfer to the risk register.
A common self-assessment finding is an intake channel that exists in practice but appears nowhere in writing. Check that your procedure matches how disclosures really arrive.
An independent assessor, auditor or consultant tests ID.RA-08 by sampling. They select disclosures from a defined period, then trace each one from intake to closure and check that the steps happened as documented. NIST does not offer certification for CSF implementations, so the output is an assessment report prepared for your organization, not a certificate. The assessor's scope and sampling method depend on the agreement with your organization, so confirm both before fieldwork begins.
- Sample selection: the assessor chooses disclosures, often including ones from less common channels.
- Traceability: each sampled item should link intake, analysis, decision and closure in one record.
- Verification of responsibilities: the assessor looks for evidence that the assigned owner actually acted, such as review sign-off or access logs.
- Supplier-facing terms: contracts or security addenda showing how vulnerability information is exchanged with suppliers.
- Gaps in the sample: no records for a channel the policy lists is a frequent finding.
Before the assessment, pull a complete list of disclosures for the period and confirm that nothing sits only in an inbox or a personal email account.
Customers and partners often ask about vulnerability disclosure in security questionnaires. These questions are usually answered from documents rather than tested in the field, so the reader wants a short, accurate answer backed by a document they can request. A questionnaire answer should describe the process as it operates today, and it should not claim practices that no record supports.
- Published or shareable policy: a current document describing how disclosures are received and who handles them.
- Contact route: a stated address or portal that customers can use to report a vulnerability.
- Evidence on request: redacted examples of triage and closure records, showing the process without exposing other customers' data.
- Supplier questions: answers on how your organization receives disclosures about third-party components it depends on.
- Consistency check: the questionnaire answer must match the policy, the contract and the self-assessment.
A frequent problem is an answer that promises a response timeline the team has never measured. Only state targets you can show were applied in practice.
How to build a vulnerability disclosure process step by step
This sequence turns ID.RA-08 from a policy statement into a working intake path, where every disclosure from a supplier, customer, partner or government organization is logged, analyzed, assigned and traced to a tracked remediation.
Name an intake channel and owner
Publish one documented way for outside parties to report vulnerabilities, such as a monitored security mailbox or web form, and name a single accountable owner for it. Confirm that the channel is listed where suppliers, customers and partners can find it, and that the owner has a backup. The output is a written intake procedure with a named owner and a tested route for each audience.
Define how disclosures are logged
Set the minimum fields every disclosure must carry, including reporter, source type, affected product or system, date received, description and reproduction details. Record each disclosure in one system of record so duplicates and related reports can be linked later. The output is a disclosure log with a consistent template that every intake path uses.
Triage and confirm each report
The owner checks whether the report is a valid vulnerability, whether it affects an in-scope asset, and whether it duplicates an open item. Triage records a severity estimate and the reason for it, and it confirms receipt to the reporter when the procedure requires that. The output is a triaged record with a status of valid, invalid, duplicate or needs more information.
Assign and verify responsibilities by source
Assign each confirmed report to an engineering or product owner, and record who verifies the fix. Keep separate, written responsibilities for supplier reports, customer and partner reports, and reports forwarded by government cybersecurity organizations, because each source may carry different contract terms or handling rules. Check that every report has both an owner and a verifier before analysis starts. The output is an assignment record per report that names both people.
Analyze and set the response workflow
The assigned owner reproduces the issue, identifies the affected versions or components, and determines whether compensating controls exist. Agree on the response path, such as a patch, configuration change, workaround or documented acceptance, and check whether any supplier sharing rules in the contract restrict what can be told to whom. The output is an analysis note and a chosen response path, reviewed by the verifier.
Connect confirmed issues to the risk register
Enter each confirmed vulnerability in the risk register with its threat, likelihood and impact assessment, and link it to the related asset record. Route any risk the organization will not fix immediately to the risk response and exception process so it is accepted, transferred, mitigated or avoided on purpose. The output is a register entry that cross-references the disclosure log.
Track remediation and close the disclosure
Track the fix in the remediation backlog or plan of action and milestones, and have the verifier confirm that the fix works before closing the record. Where the contract or a government organization requires it, communicate the outcome to the reporter. The output is a closed disclosure record with the fix evidence, the verification date and the communication sent, ready for an assessor to sample.
Evidence that shows a disclosure process works between audits
An assessor looking at ID.RA-08 wants to see a process that runs in practice, not a policy that exists on paper. The cards below describe the records that show intake, triage, assignment, remediation and supplier notification working over time. Each record should be reviewed on a fixed schedule so it still matches how the organization actually handles disclosures.
Published intake channel
A public security contact (such as a monitored mailbox or web form) with a published address, a stated acknowledgment process and a named owner. Keep the published text, the routing rule behind it and dated copies of any change. Review the address and the security.txt-style contact details at least once a year, and test that a message sent from outside the company reaches the triage queue within the time your procedure states. Confirm with your counsel whether the channel should also accept reports from government cybersecurity organizations.
Disclosure procedure with named roles
A written procedure that sets out who receives a report, who validates it, who decides severity, who approves the fix and who speaks to the reporter. Each role should name a person or a function, with a backup. Record the approval date and version, and review the procedure after every disclosure that exposed a gap in it. Auditors frequently test whether the people named in the document still hold those roles.
Tracked log of received reports
A log in which every disclosure receives a unique record, the date of receipt, the source category (supplier, customer, partner or government organization), the triage decision and the reason for it. Declined reports need a recorded rationale too. Assessors often sample this log for completeness, so check that no report exists only in an inbox. Tools such as DefectDojo can hold findings from several sources, but the intake decision still belongs in a record your team controls.
Responsibility assignment and verification records
Records showing that someone was assigned to process each disclosure category and that the assignment was checked. This includes RACI-style tables, on-call rotations and periodic confirmation that the assigned owners are still in post. Keep sign-off records from the review. Running a tabletop exercise on a sample disclosure is a practical way to produce this evidence, and the exercise notes should go into the same file.
Linked remediation tickets
Each validated disclosure should link to one or more remediation tickets in your issue tracker, with owner, due date, fix version and closure evidence. Closure should require a retest or a documented reason for accepting the risk. Check that tickets link back to the disclosure record, so an assessor can trace a report from intake to closure in both directions. Where the source is a scanner, Greenbone Community Edition stores scan results that can support the validation step.
Supplier notification records
Evidence of when and how you notified suppliers about vulnerabilities in their products or services, and when they responded. Where the contract sets notice periods, confidentiality terms or coordinated disclosure rules, keep a copy of the clause next to each notification. Check contracts at renewal, because the terms you rely on may have changed. This record also supports the supplier-facing Implementation Example for sharing information under contract rules.
What meeting ID.RA-08 costs in staff time, tooling and external review
This table breaks down the cost components of running a vulnerability disclosure process under ID.RA-08, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. No prices or durations are supplied for these components, so use the right-hand column to build your quote request and internal budget. The main takeaway is that most cost comes from recurring triage and remediation effort, which scales with report volume and product count, and that open-source tracking can remove license cost but not staff time.
| Cost component | Who is paid | One-time or recurring | What drives it and what to ask for |
|---|---|---|---|
| Intake channel setup | Internal staff or implementation partner | One-time, with periodic review | Published reporting address, web form or security.txt-style contact. Ask the partner to list the channels, the intake workflow and who monitors each one. |
| Triage staff time | Internal security or product security team | Recurring | Report volume, severity mix and number of products. Ask how triage hours are estimated and which roles own acknowledgment, validation and routing. |
| Tooling and licenses | Software vendor or open-source project maintainers | Recurring for commercial tools, one-time setup for self-hosted | Commercial case-management or scanner licenses scale with users or assets. Self-hosted open-source tracking such as DefectDojo (BSD-3-Clause) removes license fees but still needs hosting, patching and administration. Confirm license terms and hosting effort in writing. |
| Legal review of disclosure and supplier terms | Internal counsel or outside counsel | One-time for templates, recurring for new supplier or partner contracts | Number of supplier and partner agreements that include vulnerability sharing terms. Ask for a template library so each new agreement does not start from scratch. |
| Remediation effort | Engineering, operations and product teams | Recurring | Volume and complexity of confirmed vulnerabilities, release cycles and dependency on suppliers. This is usually the largest component. Ask how remediation work is tracked against the risk response record under ID.RA-06. |
| Process design and documentation | Implementation partner or internal team | One-time, with annual review | Scope of products and suppliers covered, and the number of roles in the workflow. Ask for written deliverables, including the intake procedure and responsibility assignments. |
| Independent assessment fees | Independent auditor or assessor | Recurring, tied to assessment cycle | Scope of the assessment and the framework or contract that requires it. NIST does not offer certification of CSF implementations, so confirm with the requiring customer or regulator what independent evidence they will accept. |
What your team, a partner and the auditor each own for disclosure handling
Your organization owns the vulnerability disclosure process and is accountable for how it runs. ID.RA-08 asks for processes that receive, analyze and respond to disclosures from suppliers, customers, partners and government cybersecurity organizations, so the people who answer for those outcomes must be named inside the company. Ownership does not transfer to a partner or to a tool, even when both do much of the setup work.
- Accountable owner: Name one executive or security leader who approves the disclosure policy and receives reports on open cases.
- Intake channel and contact point: Decide where external parties report issues, who monitors that channel and what hours they cover.
- Triage and response decisions: Set who assesses severity, who approves fixes or compensating controls and who decides on notification to affected customers.
- Supplier and contract terms: Confirm which contracts require suppliers to share vulnerability information and how those obligations are enforced.
- Records: Keep the case history that shows each disclosure was received, analyzed and closed.
Before any outside work starts, confirm that the named owner can explain the process end to end without reading a document.
DeployOpen works as an implementation partner. It prepares the systems, procedures and evidence that the organization's process depends on, inside the organization's own infrastructure. It does not decide what the organization accepts as risk, does not run the organization's disclosure inbox as a substitute for its own staff unless that is agreed in a written scope, and does not issue assessment results.
- Intake tooling: Set up self-hosted platforms that record incoming findings and deduplicate them, such as DefectDojo, which imports findings from more than 500 security tool report formats and deduplicates using per-tool hashcode fields.
- Procedure drafting: Draft intake, triage and closure procedures for the organization to review, adapt and approve.
- Evidence collection: Configure logging and case records so that the organization can show each disclosure's history to an assessor.
- Integration: Connect disclosure records to vulnerability scanning and ticketing where the organization already uses them.
- Handover: Document the configuration and train the named staff who will operate the process.
Agree in writing which of these items are in scope, who holds the administrator credentials and who approves the procedures before work begins.
An independent auditor, assessor or certification body judges whether the process meets the requirement and issues any report or certificate. NIST does not certify CSF implementations and has no plans for a conformity assessment program, so a CSF 2.0 alignment statement is the organization's own claim unless an independent assessor has tested it under a separate engagement. The auditor's independence is the reason its conclusions carry weight, which is why it cannot also build the controls it tests.
- Testing the design: Reviewing whether the disclosure procedures exist, cover the four named sources and assign responsibilities.
- Testing operation: Sampling past disclosures to confirm they were received, analyzed and answered as the procedure says.
- Evaluating evidence: Deciding whether the records, logs and approvals are complete, consistent and attributable.
- Issuing results: Only the independent assessor issues findings, reports or certificates.
- Setting scope: The auditor agrees the scope and sample with the organization, and cannot accept scope that its own staff designed.
Before engaging an assessor, ask whether it has tested this kind of process before and how it will separate its testing from any advisory work it has performed.
Common gaps that fail a disclosure process review
Assessors reviewing ID.RA-08 usually find the same weaknesses: the process exists on paper but cannot be shown to work. Each gap below breaks the chain from a disclosure arriving to a fix being verified, so each card pairs the gap with a closing action the organization can evidence.
No published intake channel
Outside researchers, customers and suppliers cannot report a vulnerability if they do not know where to send it. Without a published address or form, reports land in general mailboxes or sales inboxes and may never reach security staff. Check that a single, documented channel exists, that it is linked from a public security page, and that the people who monitor it are named in the process. Ask whether the channel has been tested by sending a message from outside the company.
Reports arriving in email
When disclosures live only in inboxes, there is no record of when they arrived, who triaged them or what was decided. An assessor asking for the disclosure log for the past year will find nothing to sample. Close this by routing every report into a ticketing or vulnerability management system, such as the findings store in DefectDojo, with a timestamp, reporter, affected asset and status field. Confirm that the log is retained and that emailed reports are copied into it.
Unclear owner for government notices
Notices from national computer emergency response teams or government cybersecurity agencies often arrive with urgent deadlines and specific instructions. If no role owns them, they may sit unread during leave or reorganizations. Assign a named role and a backup for these notices, define the hours within which they must be acknowledged, and document how they are escalated to executives. Test the assignment by checking who receives the notice when the primary owner is absent.
Supplier notices not handled as contractual inputs
Supplier vulnerability notices are most useful when they are tied to the contract terms that govern how information is shared and how fixes are timed. A process that treats them as ordinary emails misses obligations the organization agreed to. Review each critical supplier contract for disclosure and notification clauses, map those clauses to the intake process, and keep a register of which suppliers have a named contact for security notices.
No link from disclosures to remediation
A disclosure that is acknowledged but never traced to a patch, configuration change or documented risk acceptance cannot be shown as handled. This gap often appears when the vulnerability tracker and the change system are separate tools. Require each validated disclosure to reference a remediation ticket, a change record under ID.RA-07 or a risk response under ID.RA-06, and check a sample of closed disclosures to confirm the link exists.
No evidence that responsibilities were verified
The Implementation Examples for ID.RA-08 call for assigning responsibilities for processing disclosures and verifying that they are carried out. Many programs name owners in a policy but never check that the owners understand the duty, have access to the intake channel or have performed the task. Close this with a periodic walkthrough: send a test disclosure through the channel, record who handled it and when, and keep the results as evidence that the assignment works in practice.
How ID.RA-08 differs from RS.AN-5 and the other ID.RA Subcategories
ID.RA-08 is the CSF 2.0 home for a process that CSF 1.1 filed under incident analysis. According to NIST's CSF 1.1 to 2.0 Core Transition Changes spreadsheet, ID.RA-08 takes over RS.AN-5 under a new identifier. The outcome itself is not new: it still asks for processes that receive, analyze and respond to vulnerability disclosures. What changed is placement. In 2.0, the work sits in the Identify Function because it is about knowing your exposure before an incident, not only reacting to one. If your 1.1 assessment or policy still cites RS.AN-5, update the reference so the intake process is not lost between incident analysis and risk assessment in your records. Confirm the mapping against the transition spreadsheet and your own control register rather than relying on memory of the old numbering.
The Subcategories around it answer different questions. ID.RA-01 covers finding and recording flaws in your own assets through scanning, testing and review, so the organization is the source of the finding. ID.RA-08 covers disclosures that arrive from outside: suppliers, customers, partners and government cybersecurity organizations. The decision you must make is who owns intake, how a report is validated against your asset inventory, and how it is deduplicated against findings you already hold. A useful check is whether an outside report can enter your queue, be assigned and be closed without anyone manually re-keying it. NIST's two Implementation Examples for ID.RA-08 also point to contract terms with suppliers on sharing vulnerability information, so review those clauses alongside the intake procedure.
ID.RA-08 hands off to ID.RA-06, which is where a validated disclosure becomes a tracked decision. Once a report is confirmed, it needs a response (accept, transfer, mitigate or avoid), an owner and a date, recorded in a POA&M or risk register. Intake that stops at a ticket does not satisfy the outcome in practice. Before you finish the procedure, confirm three things: which system records the disclosure and its decision, how the response is traced back to the original reporter where the reporter expects an update, and how accepted risks are later revisited under ID.RA-07. The ID.RA-08 evidence is strongest when a single disclosure can be followed from receipt to a documented response.
Questions buyers ask about ID.RA-08 cost, effort and assessment
How much does it cost to meet ID.RA-08 vulnerability disclosure handling?
No supplied figure sets a price for this, and the cost depends on your scope, not on the Subcategory itself. Most of the spend falls into three buckets: staff time to write and run the intake and triage process, tooling (open-source tools carry no license fee, but hosting, storage and operations still cost money), and external help for design or review. Costs recur through monitoring, triage and periodic review, so ask any partner to split a quote into one-time setup work and ongoing support. Drivers that raise cost include the number of suppliers and products in scope, the number of disclosure channels, and how many contracts need new clauses. DeployOpen issues quotes from a written scope, not from a price list.
How long does it take to set up vulnerability disclosure handling?
No supplied duration applies, so confirm timing against your own environment and scope. The work usually runs in stages: assign responsibilities, define how disclosures arrive and who reviews them, connect the intake to your vulnerability tracking, and then test the process with a sample report. Timing grows with the number of business units, the maturity of existing vulnerability management, and how many supplier contracts must be updated. Ask for milestones in the written scope so progress is measurable.
What does ID.RA-08 ask internal staff to provide?
Internal staff own the decisions, so the requirement needs named people with clear authority. Expect to provide a process owner who accepts or rejects disclosures, security analysts who validate and prioritize findings, and legal or procurement staff who write the rules for sharing vulnerability information with suppliers. Engineers who fix affected systems also need a defined handoff. The effort is steady rather than heavy, but it depends on those roles being staffed before any disclosure arrives.
Can we run ID.RA-08 handling in-house without outside help?
Yes, an organization can own this subcategory internally, because the outcome is a documented process that your staff operate. Outside help is useful when you lack staff who can triage technical reports, need a tool to ingest findings, or want a review of the process before an assessment. An implementation partner can prepare systems and evidence, but the organization remains responsible for its controls. Only an independent auditor or assessor issues a report or opinion on whether the control works.
Does NIST certify that we meet ID.RA-08?
No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. Any claim that a vendor or consultant has certified your ID.RA-08 alignment should be questioned. Alignment with the CSF is self-determined or assessed by an independent party under the terms you agree with that party, such as a customer audit or a contract requirement.
What will an assessor ask for to test ID.RA-08?
Assessors usually ask for evidence that the process exists, is followed and is reviewed. Typical requests include the written disclosure procedure, the list of named roles, sample intake records showing receipt, analysis and response, the criteria for prioritizing findings, and records of supplier notifications under contract terms. They will also check that lessons from disclosures feed back into your risk assessment. Evidence should show real cases or tests, so keep a log from the start. The assessor sets the sampling and test approach for their own engagement.
When should we bring in an implementation partner for ID.RA-08?
Bring in a partner when internal work stalls on tooling, process design or evidence preparation, or when a customer or regulator needs the work done by a fixed date. DeployOpen plans and implements self-hosted open-source platforms in your own infrastructure, including vulnerability management tooling such as DefectDojo and Greenbone Community Edition, and prepares the associated process and evidence. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not issue audit reports, attestations or certifications.
How DeployOpen scopes and prepares disclosure handling evidence
DeployOpen plans and builds the intake, triage and tracking systems behind ID.RA-08 Vulnerability disclosure handling inside your own infrastructure, using self-hosted open-source platforms. Your organization owns the process and its decisions, and an independent assessor reviews the evidence.
How we scope
- Agree in writing which disclosure sources are in scope: suppliers, customers, partners and government cybersecurity organizations.
- Confirm which internal teams receive, analyze and respond to each disclosure type, and who holds final accountability.
- Define the systems, data stores and environments where disclosure records will live and who can access them.
How we build
- Configure a self-hosted intake path so disclosures land in one tracked queue rather than scattered mailboxes.
- Set up finding import and deduplication so reports from different tools and sources are consolidated and traceable.
- Document triage steps, handoffs and response records so each disclosure leaves a reviewable trail.
How we hand over
- Deliver the written configuration, runbooks and access model for the disclosure workflow, with named owners.
- Provide sample records and an evidence map showing which artifacts an assessor would ask to see for ID.RA-08.
- Confirm with your team and assessor which evidence formats and retention periods your obligations require.
How we support
- Offer ongoing support, upgrades and continuous testing of the disclosure platform as a retainer after handover.
- Review the workflow after real disclosures or exercises and record improvements for the next cycle.
- Keep certification and attestation decisions with your organization and the independent auditor, since DeployOpen does not issue them.
